Skip to Content
Last modified by Danniar Firdausy on 2024/09/18 21:32
From version 7.4
edited by Danniar Firdausy
on 2024/09/11 20:48
Change comment: There is no comment for this version
To version 9.3
edited by Danniar Firdausy
on 2024/09/18 21:32
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Considering Dependencies between integrations
1 +Considering dependencies between integrations
Content
... ... @@ -1,5 +1,5 @@
1 1  {{container}}{{container layoutStyle="columns"}}(((
2 -In this microlearning, we will learn what you should consider when looking at dependencies between integrations. An integration solution can consist of loads of different integrations, and several of those integrations can depend on each other. For example, when looking at an Order 2 Cash process in which an order travels from system A to B, and as a result, various messages are returned in sequence (i.e., conformation, shipment, invoice). Logic dictates that, for example, when the order never arrives, the other integrations will also not receive any data. Therefore it is relevant to consider these dependencies while performing a risk assessment.
2 +In this microlearning, we will explore how to assess dependencies between integrations. When dealing with complex integration solutions, it's crucial to understand how various components interact with each other. For example, in an Order 2 Cash process, the failure of an order to arrive could impact the subsequent messages like confirmation, shipment, and invoice. We'll discuss how to identify these dependencies, evaluate their impact, and ensure that your integration solution remains robust and efficient.
3 3  
4 4  Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
... ... @@ -9,8 +9,8 @@
9 9  
10 10  == 2. Key concepts ==
11 11  
12 -This microlearning centers around considering dependencies between integration
13 -With dependencies, we mean: The matter in which the outcome of another integration dictates the working of one integration
12 +This microlearning centers around considering dependencies between integration.
13 +* With dependencies, we mean: The matter in which the outcome of another integration dictates the working of one integration
14 14  
15 15  When looking at dependencies, we ought to consider:
16 16  
... ... @@ -26,22 +26,29 @@
26 26  * Are there dependencies?
27 27  * Will the failure of integration block another?
28 28  
29 -At first, we need to consider whether there are dependencies or whether each integration can perform its job without being influenced by other integrations. In scenarios of no dependence, there is also no risk of dependencies creating a cascade of problems. However, in situations where there are dependencies, one action could impact other integrations. An excellent example in a messaging environment is asynchronous routing. All asynchronous data traffic is passing the asynchronous routing and therefore changes to the routing directly impact all asynchronous integrations. So considering how, if, and when to deploy an asynchronous routing is something worth thinking about.
29 +At first, we need to consider whether there are dependencies or whether each integration can perform its job without being influenced by other integrations. In scenarios of no dependence, there is also no risk of dependencies creating a cascade of problems. However, in situations where there are dependencies, one action could impact other integrations. An excellent example in a messaging environment is [[asynchronous routing>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.crashcourse-messaging-asynchronous-routing]]. All asynchronous data traffic is passing the asynchronous routing and therefore changes to the routing directly impact all asynchronous integrations. So considering how, if, and when to deploy an asynchronous routing is something worth thinking about.
30 30  
31 31  The same applies to when you deploy other parts of the solution that could impact different integrations. Always ask yourself whether the quality of the answer will be upheld by the action you are about to perform.
32 32  
33 -Apart from the dependencies while deploying, there can also be dependencies while running the solution. These dependencies are primarily characterized in the sense that you need to receive something first before triggering another process (i.e., Order2Cash). Or for example, in the case of the API Gateway, you might first need to retrieve each invoice and do a subsequent call to retrieve all InvoiceLines. That has the consequence that when the Invoice integration is not working, the InvoiceLines integration will probably also not function as designed. So in a sense, the failure of one integration blocks the business process as it prevents API clients from retrieving the complete invoice in this example.
33 +Apart from the dependencies while deploying, there can also be dependencies while running the solution. These dependencies are primarily characterized in the sense that you need to receive something first before triggering another process (i.e., Order2Cash). Or for example, in the case of the [[API Gateway>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]], you might first need to retrieve each invoice and do a subsequent call to retrieve all InvoiceLines. That has the consequence that when the Invoice integration is not working, the InvoiceLines integration will probably also not function as designed. So in a sense, the failure of one integration blocks the business process as it prevents API clients from retrieving the complete invoice in this example.
34 34  
35 35  Being aware of these dependencies can significantly improve the choices you and the business make in terms of risk mitigation before developing your solutions via the eMagiz platform.
36 36  
37 37  == 4. Key takeaways ==
38 38  
39 -* Dependencies are relevant when deploying and when running the model
40 -* Failure in one integration can block other integrations (or reduce its value)
39 +* Understand how different integrations are interconnected and how one integration's outcome can affect others.
40 +* Evaluate whether the failure of one integration might block or disrupt other integrations within the process.
41 +* Implement strategies to manage and minimize risks related to integration dependencies, both during deployment and in ongoing operations.
42 +* Ensure that integration solutions are designed to handle dependencies effectively, maintaining functionality and value even when issues arise.
41 41  
42 42  == 5. Suggested Additional Readings ==
43 43  
44 44  If you are interested in this topic and want more information, please check out these links:
47 +
48 +* [[Crash Courses (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]
49 +** [[Crash Course Messaging (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.WebHome||target="blank"]]
50 +*** [[Asynchronous Routing (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.crashcourse-messaging-asynchronous-routing]]
51 +** [[Crash Course API Gateway (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]]
45 45  * [[Dependencies between integrations (Search Results)>>url:https://docs.emagiz.com/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_space_facet=0%2FMain.&l_space_facet=10&f_type=DOCUMENT&f_locale=en&f_locale=&f_locale=en&text=%22dependencies+between+integrations%22||target="blank"]]
46 46  
47 47  )))((({{toc/}}))){{/container}}{{/container}}