Wiki source code of eMagiz Messaging
Last modified by Erik Bakker on 2024/08/19 21:27
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
15.1 | 1 | {{container}}{{container layoutStyle="columns"}}((( |
| |
29.1 | 2 | This microlearning introduces the eMagiz Messaging pattern. This messaging integration consists of five layers and is based on the VETRO architectural pattern, which stands for Validate, Enrich, Transform, Route, and Operate. The microlearning covers various aspects such as the canonical data model (CDM), transformation, queueing, and error handling within eMagiz. It provides a comprehensive overview of how messaging integration works in eMagiz and the crucial components involved in the process. |
| |
1.1 | 3 | |
| 4 | Should you have any questions, please get in touch with academy@emagiz.com. | ||
| 5 | |||
| 6 | == 1. Prerequisites == | ||
| |
2.1 | 7 | |
| |
1.1 | 8 | * Some context on messaging will be helpful. |
| 9 | |||
| |
2.1 | 10 | == 2. Key concepts == |
| |
1.1 | 11 | |
| 12 | All concepts are discussed in the section below. | ||
| 13 | |||
| 14 | == 3. Introducing Messaging == | ||
| 15 | |||
| |
29.1 | 16 | eMagiz Messaging is the pattern in which you can connect various parties via various connectivity mechanisms to the eMagiz messaging engine. These external applications can connect in the most appropriate way (e.g., REST, SOAP, SFTP, and many more) to eMagiz. eMagiz will subsequently place the input messages on a specific queue. For example, you can distribute the message to various other external applications and deliver the messages via the connectivity method most desirable for each external application. |
| |
1.1 | 17 | |
| |
15.1 | 18 | [[image:Main.Images.Fundamental.WebHome@fundamental-messaging-introduction--logical-view-landscape.png]] |
| |
1.1 | 19 | |
| |
29.1 | 20 | Any messaging integration in eMagiz consists of five layers. The message starts in the entry and moves to the other application via the onramp, routing, offramp, and exit. |
| |
1.1 | 21 | |
| |
15.1 | 22 | [[image:Main.Images.Fundamental.WebHome@fundamental-messaging-introduction--five-layers.png]] |
| |
1.1 | 23 | |
| 24 | === 3.1 The five layers of eMagiz Messaging === | ||
| 25 | |||
| |
29.1 | 26 | eMagiz has implemented a five-layered model based on the integration architectural pattern VETRO, which stands for Validate, Enrich, Transform, Route, and Operate. Each of these layers plays a role in the pattern. Below is an explanation of these five layers. Each layer will result in integration components referred to as flows in eMagiz. These flows will run strategically across the integration landscape in a specific runtime position (see section "Architectural components" in this document). |
| |
1.1 | 27 | |
| |
29.1 | 28 | * Entry |
| 29 | ** In the entry flow, you can configure the system's connectivity, which will send a message to eMagiz. It can be a push from the external system or a pull from eMagiz to the external system. Once the message is received, the message will be queued directly to the next step in the model | ||
| 30 | * Onramp | ||
| 31 | ** In this part, the message will be transformed and validated, preparing it for the following steps to send to the external system. Specific elements exist here also to enrich the message where needed with additional attributes | ||
| 32 | * Routing | ||
| 33 | ** Using specific header information, the message can be routed to one or more offramps for further processing | ||
| 34 | * Offramp | ||
| 35 | ** In this process, the message passed on from the routing can be validated if it meets the expected structure and then transformed to the target system. Once processed, the message is put in the exit queue. | ||
| 36 | * Exit | ||
| 37 | ** The exit will read the message from the queue and then connect to the target system | ||
| |
1.1 | 38 | |
| 39 | === 3.2 Canonical Data Model (CDM) === | ||
| |
2.1 | 40 | |
| |
29.1 | 41 | The Canonical Data Model is a crucial part of the messaging pattern, which we call the CDM in layman's terms. The CDM is the data model at the heart of all your messaging integration and defines how a specific message should look from your point of view. For example, when you have an Order and Invoice integration, the CDM will explain what an Order looks like, how an Invoice looks, and how the two are related (or not). Based on this model, you can select portions of the CDM to act as the CDM message for a specific message type (i.e., Order). |
| |
1.1 | 42 | |
| |
15.1 | 43 | [[image:Main.Images.Fundamental.WebHome@fundamental-messaging-introduction--cdm-example.png]] |
| |
1.1 | 44 | |
| 45 | Critical considerations in setting up a CDM are: | ||
| 46 | |||
| 47 | * Clarity | ||
| 48 | * Consistency | ||
| 49 | * Logical | ||
| 50 | |||
| 51 | === 3.3 Transformation === | ||
| |
2.1 | 52 | |
| |
1.1 | 53 | As the external parties will most likely not adhere to this standard you defined in the CDM, a crucial part of messaging integration is transforming the structure as supplied (or requested) by the external party to and from the CDM. You can quickly transform this data with the help of the eMagiz tooling in the Design phase of eMagiz. See below for an illustration. |
| 54 | |||
| |
15.1 | 55 | [[image:Main.Images.Fundamental.WebHome@fundamental-messaging-introduction--transformation-example.png]] |
| |
1.1 | 56 | |
| 57 | === 3.3 Queueing === | ||
| |
29.1 | 58 | Within eMagiz, we use the queueing mechanism to transport messages from one queue to the other. The JMS orchestrates this mechanism of queues. The JMS registers and deregisters queues dynamically when there is a need for the queue to be created or destroyed. For example, customers must be registered on any queue to pick up messages. Once the message is delivered to the next queue and the transaction is finished, the message leaves the previous queue. For a more in-depth analysis of how queues work within the platform, please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Orchestration of data packets.intermediate-orchestration-of-data-packets-queues-how-do-they-work||target="blank"]]. |
| |
1.1 | 59 | |
| 60 | === 3.4 Error Handling === | ||
| |
2.1 | 61 | |
| |
29.1 | 62 | Each messaging flow related to a messaging queue (i.e., onramp, routing, offramp, exit) contains a subprocess that will send the error to the error flow if the operational process fails. As a result, the error will appear in the Dashboard in the Manage phase of eMagiz so the user can analyze it. An example of what this Dashboard looks like can be found below. |
| |
1.1 | 63 | |
| |
15.1 | 64 | [[image:Main.Images.Fundamental.WebHome@fundamental-messaging-introduction--error-handling-manage-dashboard.png]] |
| |
1.1 | 65 | |
| |
29.1 | 66 | This information can help you easily determine the origin of an error message. For more information, please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-manage-determining-origin-of-error-message||target="blank"]]. |
| |
1.1 | 67 | |
| 68 | === 3.5 Architectural components === | ||
| 69 | |||
| |
29.1 | 70 | Connecting various systems via the messaging pattern allows you to deploy parts of your architecture as close to the system. This means you can deploy part of the solution in the eMagiz Cloud and part of the runtimes that hold the entries and exits on-premise if the system you want to connect to is also deployed on-premise. This makes the connection between the entry or exit and the system in question more stable. |
| |
1.1 | 71 | |
| 72 | An example of such a hybrid setup is depicted below. | ||
| 73 | |||
| |
15.1 | 74 | [[image:Main.Images.Fundamental.WebHome@fundamental-messaging-introduction--hybrid-architectural-setup.png]] |
| |
1.1 | 75 | |
| |
29.1 | 76 | Logically, if all your systems are cloud systems, the most logical choice would be to deploy the complete eMagiz model within the eMagiz Cloud. An example of such a cloud setup is depicted below. |
| |
1.1 | 77 | |
| |
15.1 | 78 | [[image:Main.Images.Fundamental.WebHome@fundamental-messaging-introduction--cloud-architectural-setup.png]] |
| |
1.1 | 79 | |
| 80 | == 4. Key takeaways == | ||
| 81 | |||
| 82 | * Messaging uses five layers to transport data between systems | ||
| 83 | * The CDM is a crucial component within messaging | ||
| 84 | * To transport the messages, we use the queueing mechanism | ||
| 85 | * Errors from the messaging flows show up in the manage dashboard | ||
| 86 | * Messaging runtimes should be deployed as close to the system as possible | ||
| 87 | |||
| 88 | == 5. Suggested Additional Readings == | ||
| 89 | |||
| |
30.1 | 90 | * [[Messaging Introduction (External)>>https://www.emagiz.com/en/messaging-en/||target="blank"]] |
| 91 | * [[Crash Course Messaging (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.WebHome||target="blank"]] | ||
| 92 | * [[Intermediate Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]] | ||
| |
31.1 | 93 | ** [[Orchestration of Data Packets (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Orchestration of data packets.WebHome||target="blank"]] |
| 94 | ** [[Key Concepts Messaging (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Key concepts eMagiz Messaging.WebHome||target="blank"]] | ||
| |
30.1 | 95 | * [[Support (Menu)>>doc:Main.eMagiz Support.WebHome||target="blank"]] |
| 96 | ** [[Migration Paths (Navigation)>>doc:Main.eMagiz Support.Migration Paths.WebHome||target="blank"]] | ||
| 97 | *** [[Message Redelivery (Explanation)>>doc:Main.eMagiz Support.Migration Paths.migration-path-message-redelivery||target="blank"]] | ||
| 98 | *** [[Error Handling Synchronous Flows (Explanation)>>doc:Main.eMagiz Support.Migration Paths.migration-path-error-handling-synchronous-messaging-flows||target="blank"]] | ||
| 99 | *** [[eMagiz Runtime Generation 3 (Explanation)>>doc:Main.eMagiz Support.Migration Paths.migration-path-emagiz-runtime-generation-3||target="blank"]] | ||
| 100 | *** [[Custom Error Handling (Explanation)>>doc:Main.eMagiz Support.Migration Paths.migration-path-custom-error-handling-runtime-generation-3||target="blank"]] | ||
| 101 | ** [[RCA Knowledge Base (Navigation)>>doc:Main.eMagiz Support.RCA Knowledge Base.WebHome||target="blank"]] | ||
| 102 | * [[Release Information (Menu)>>doc:Main.Release Information.WebHome||target="blank"]] | ||
| 103 | ** [[Release Notes (Navigation)>>doc:Main.Release Information.Portal.WebHome||target="blank"]] | ||
| 104 | ** [[Release Blogs (Navigation)>>doc:Main.Release Information.Release Blogs.WebHome||target="blank"]] | ||
| |
32.1 | 105 | * [[Messaging (Search Results)>>url:https://docs.emagiz.com/bin/view/Main/Search?text=%22messaging%22&f_type=DOCUMENT&f_space_facet=0%2FMain.&f_locale=en&f_locale=&f_locale=en&r=1||target="blank"]] |
| |
27.1 | 106 | |
| |
1.1 | 107 | == 6. Silent demonstration video == |
| 108 | |||
| |
15.1 | 109 | {{video attachment="fundamental-messaging-introduction.mp4" reference="Main.Videos.Fundamental.WebHome"/}} |
| 110 | )))((({{toc/}}))){{/container}}{{/container}} |