The document discusses Microsoft Azure integration services and patterns that can be used for integrating both cloud-based and on-premise systems. It describes how Logic Apps can be used for application-specific communication between systems using various protocols. It also discusses how Azure Service Bus can enable loose coupling between publishers and subscribers using a publish/subscribe pattern. The document also references how integration strategies and architectures can be established to define common integration patterns, roles, and processes across organizations.

2. •
•
•

4. Microsoft
cloud

7. AzureIntegration Services white paper
https://azure.microsoft.com/en-us/product-
categories/integration/
Azure ServiceBus
Kösystem
Azure Logic Apps
Workflow, low code
Azure EventGrid
Möjliggör eventbaserad ark.
Azure API Management
API Governance
Azure Functions
”För allt du inte kan göra i en LA”
+

9. Cloud based/external
System B
Cloud based/external
System A
The application specific
Logic Apps are
responsible for system
specific communication
and can handle a
number of protocols and
transports. Also
responsible for
transforming between
systemspecific format
an shared formats.
Publish/subscribe - Azure Service Bus
Subscribers are
only subscribe to
specific messages
using a Service
Bus Subscription.
Publishers only
publish messages
to the Service Bus
with the right
properties set.
BizTalk acts very similar
to the Logic Apps
Publisher and
Subscribers and either
publishes or subscribes
to messages on the Bus
On-premise data gateway
System specific
Publisher
System specific
Subscriber
System specific
Subscriber
System specific
Publisher
System
specific
Publisher
System
specific
Subscriber
On premise based
System C
On premise based
System D
Depending on
previous
investments,
strategy etc. Logic
Apps might also
be used for
communicating
with on-premise
applications
On premises
Cloud

11. System
specific
Subscriber
Prices
Service
Storage
SystemA
System
specific
Publisher
POST
async
SystemB
GET
sync SystemC
GET
sync
Publishers are responsible for
transforming to the format required
by local storage
If querying against source system,
local storage is not needed
System
specific
Subscriber
Event Grid can be used for
content based routing. It also
enables loose coupling.
Api Management
Consumers
Consumers
External
consumers
APIs can be consumed, combined
and exposed externally using APIM
Event
Grid

14. Development in own subscription
🥺
No local debug possibilities!
Long and time consuming
loop from development to
test and production
ARM contains both runtime
and infrastructure
ARM
ARM
scripts
Requires custom tools to get right
Test Azure
Subscription
Prod Azure
Subscription

15. Where's my message!?
We need end-to-endtracing!
Application
Insights
Log
Analytics
🥺No way to get end-to-end logging
using v. 1

16. 😅

17. •
•
•
•
•
•

18. Function App runtime
Logic App runtime v. 1
Runs in container – local
development
Runs in container – runs
everywhere
Logs to Application Insights
New network isolation
possibilities

20. On premises
Cloud
Endpoints
ISEDedicated
environmentare
expensive and “non
elastic”
Azure - VNET
Subnet
Traditional on premiseinfrastructure
usually has firewalls to protectthem
Public Azure
Endpoints
Endpoints in Azureareper default
public In v.1 we can use IP
filter in the Logic App

21. Public Azure
Function App runtime
Azure - VNET
On Premise
App Service Environment
Dedicated
environments
Logic Apps can
now run in a App
Service
Environment
Subnet
Service Endpoints
Runs in public Azure. But only traffic
fromspecific subnet allowed
PrivateLink
Endpoints live in VNET. Mapped to
privateIPs. Traffic contained to VNET.
VNET integration.
Allows componentto communicate in to
subnet.

22. •
•
•
•
•

24. Nuläge
?
? ?
?

25. Avgränsning genom strategi och
arkitektur
Nuläge
Vision
Nästa
läge
Nästa Nästa
Nästa
Nästa

26. Verksamhet
•Vision
•Mål
IT
•Strategi som stödjer vision och mål
•Organisation som möjliggör vision/mål
Integration
•Integrationsstrategi som stödjer IT-startegi
•Arkitektur som detaljerar strategin

27. Infrastruktur
- Hosta servrar?
- Köpa tjänster?
Teknikval
- Kompetens
- Resurser
- Information
Plattformar
- Legacy?

28. Integrationsstrategi
Process
Roller
Arkitektur

29. Skapa
Integrationsstrategi
Gemensamt
integrationsmönster,
namnsättning,
arkitektur
Gemensam
dokumentationsprincip
Tydliga roller
integrationsansvarig,
integrationsarkitekt
Integrationsöversikt
Gemensam källkod och
ALM-hantering
Gemensam
beställning- och
leverans-process
Säkerställa
driftsansvar, loggning
och övervakning
Referensprojekt

30. Arkitektur
- Integrationsmönster
- Återanvändbara mönster
- Förvaltningsbara lösningar
Säkerhet
- Autentisering
- Kryptering
- Endpoints
Standard
- Namnstandard
-Dokumentation
- APIer

31. GIP1: Vid all autentisering används OAuth 2.0 authentication model
GIP2: När filstorlek överstiger begränsningar i komponenter skall ett claim check pattern
tillämpas
GIP3: API/tjänster skall tillgängliggöras via HTTP/REST
IP1: Client id och client secrets lagras i lämpligtrepository och hämtas om möjligt i runtime
(GIP1)
IP2: För att åstadkomma"end-to-end" loggning skall givet loggningsramverk användas
IP3: Namnstandardför applikationer och komponenter INTXXX.<syfte>

32. Behov Förstudie Realisering
Integrationsstrategi
Beställning
Krav
Utveckling
Test
Leverans
Acceptans-
test
Drift
Analys
Design

33. Rutiner för godkännande och
överlämning mellan stegen i
processen
Roller
Ansvarsområden
Rutiner för
utveckling
ALM
Rutiner för
Dokumentation

37. •
•
•
•

38. •
•
•
•