Logic Apps reuse with microservices design
•Descargar como PPTX, PDF•
2 recomendaciones•1,725 vistas
How do you structure you Logic Apps and related items in a solution? What is your naming conventions for Logic Apps? Mikael Sand will show a real customer case where he used a Microservices approach, the upsides, and the downsides.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Logic Apps reuse with microservices design
Similar a Logic Apps reuse with microservices design (20)
Más de BizTalk360
Más de BizTalk360 (20)
Último
Último (20)
Logic Apps reuse with microservices design
- 1. Logic Apps reuse with microservices design Mikael Sand https://se.linkedin.com/in/mikaelsand
- 3. WELCOME
- 4. Mikael Sand Long time blogger & community contributor Did 10 years of BizTalk! Works for Enfo Sweden – Solution Architect Microsoft integration leason and gray-back @mikaelsand http://mikaelsand.com mikael_sand@hotmail.com
- 5. Mikael Sand 4th talk at Integration Monday Checkout my Beginner’s guide 1 and 2
- 6. AGENDA 1. TRADITIONAL LOGIC APPS VS MICROSERVICES ARCHITECTURE 2. REUSABILITY 3. COMPOSITE SERVICES 4. ABSTRACT VS DETAILED 5. SCALABILITY 6. CHALLENGES 7. NOTES FROM THE FIELD
- 7. Preface about Azure Functions
- 9. • Workflow (large) that solves a particular problem. • End to end: Move data from system A to system B. • Mixing process with solution TRADITIONAL LOGIC APP
- 10. • Independently deployable, easy to replace. – Contract – ”Binary compatability” • Small and message based • Modular structure • Reusable + Idempotent => Highly scaleable MICROSERVICES
- 11. • Independently deployable, easy to replace. – Contract – ”Binary compatability” • Small and message based • Modular structure • Reusable + Idempotent => Highly scaleable REUSEABILITY
- 12. Nothing new…
- 13. DEMO – GET KEY Get Customer data Get Key From Keyvault Is key expired? Login to system Get Key Store Key in Keyvault Set Key as new value Get Data from System A using key Return the data Set Key as value Key Problems! Reuse get key for other flows?
- 14. DEMO
- 15. IF • Reusable • Servicebased • Message enabled • Idempotency • Etc MICROSERVICES - EVOLVE Composite services!
- 16. • Litte tiny parts (services), combined to make a new whole • Combine services to make new things COMPOSITE SERVICES
- 17. DEMO – GET CUSTOMER DATA Get Customer data Get Customer data system A Get Customer data system B Combine A+B Return Customer data Get key
- 18. DEMO
- 19. • Combination of lots of small services => Create a new whole • Combination of a new whole => Process • Process is abstract • Detail is technical HIERARCHY OF SERVICES – PROCESS VS DETAIL
- 20. Functionality (/services) Services Process HIERARCHY OF SERVICES – PROCESS VS DETAIL Register Order GetCustomer Stock availability Get Order discount Login Get from system A Get from system B Combine Customer info Abstract Concrete
- 21. • Microservices architecture fit very well • Scaleability built right into Logic Apps • ForEach – Parallel 20 exec by default • Start new Logic App – also parallel exec • Can your downstream system take it? SCALEABLE
- 22. DEMO – SCALEABILITY – GET NEW ORDERS Get orders by status Get order by ID Call Save instance Get key Combine Return orders ForEach Get New Orders Call Call Call List Orders Key Get Order Aggregate orders
- 23. DEMO
- 24. • Naming discussions turn rational poeple into these => • Deciding on a name for a LA depends.. – Who is calling it? – What is the conext? • A process might be a service for someone else • Here is a proposal from Enfo: NAMING – HARD AS NAILS
- 25. Remember the guys to the right…. <Unique ID_><Affiliation_><Business Need> Examples INT0001_ACT0004_CustOnboarding SVC0001_COM005_Customer NAMING – HARD AS NAILS CONT
- 26. • No visual tool – Connecting the Logic Apps visually to show composite services • Need to plan – Rework andreuse • Compatability and versions CHALLENGES
- 27. • Excel sheet: Names and descriptions befor you build • Use the clone feature in the Azure portal – Good for copy – And renamning • Use search in the list of artifacts • Drill down debugging • Plan ahead! Design before you build. • Don’t go overboard with abstraction. Getting key/Loggin in. NOTES FROM THE FIELD
- 28. • You do not need to restart the whole process. • Debug only a certain part of the flow. • ”Seal” a Logic App by making it accessable only by other Logic Apps. • Retry policy for calling Logic Apps. • Use schemas, required, and validation. NOTES FROM THE FIELD CONT
- 29. www.enfogroup.com THANK YOU For further contact please use: Blog: www.mikaelsand.com Twitter: @mikaelsand Email: mikael_sand@hotmail.com
Notas del editor
- This is my MAIN focus for this session.
- Start: Talk about how services often have tokens that might expire. This is a great pattern for that.
- Unique ID The unique id should be seen as a representation of the integration or part of integration. The ID can have a qualifier appended. Ex. INT for integration or SVC for service. All artifacts that are connected to the same integration should have the same ID. Recommendation INT0004 – for initiating artifact of the integration SVC0004 – for integration internal artifacts Business Need Business business specific definition ex. Contract or information object. This should be the business used notation for what is build. Affiliation To manage a specific affiliation/membership (ACT) or identifying a common component (COM). The affiliation should be non-system specific if it is replaced. Affiliation should have a unique ID to correlate to CMDB. Even the integration platform should have a unique ID defined for internal processes.
- Realized that this might be a session all by it self.