Discovery
In this fundamental, we will explain the concept of discovery within eMagiz. This concerns the discovery of an integration landscape, which is mainly achieved in the Capture & Design phases from Integration Lifecycle Management. More about the Integration Lifecycle Management phases used in eMagiz can be found in this microlearning. Discovery of the integration landscape is very important and should be handled by experienced staff.
Should you have any questions, please get in touch with academy@emagiz.com.
1. Prerequisites
- Some context on the Integration Lifecycle Management phases will be helpful.
2. Key concepts
- With the discovery of an integration landscape, we mean the development of the design of the integration landscape.
- Before developing the integration landscape in eMagiz, technical requirements need to be established.
- In eMagiz, discovery concerns the Capture & Design phases.
3. Technical requirements
Before entering the Capture phase, several technical requirements need to be considered.
- First of all, it needs to be discussed who will provide data and who will consume data.
- Secondly, the exact definition of the data elements that will be exchanged has to be obtained.
- Thirdly, the size of the data packets needs to be established, as well as the frequency of the packets.
- Lastly, it has to be considered what constraints with respect to connectivity have to be in place.
A more elaborate description of the technical requirements can be found in this microlearning.
4. Capture
In the Capture phase, the involved systems and integrations are drawn into a canvas. The technical requirements as described in the previous section should be stored in this phase as well. It is recommended to fill out all documentation available in this phase, to ensure smooth development throughout the next phases.
When you want to create your systems, you need to ask yourself the following questions:
- What systems are relevant in our business case?
- What is the purpose of each system?
- What should each system be called?
- What should be the default integration pattern for each system?
Some more documentation may be relevant, and can be filled out easily while configuring a system. More information on how to configure a system can be found in this microlearning.
When you want to create an integration, you need to ask yourself the following questions:
- What is the purpose of this integration?
- What should be the direction of this integration?
- What should this integration be called?
- Which integration pattern belongs to this integration?
Some more documentation may be relevant, and can be filled out easily while configuring an integration. More information on how to configure a message type or integration can be found in the corresponding mircolearnings.
3.1 What is a data model
A data model is a visual representation of how a system has structured its data. With the help of a data model, you can show the relationships between entities and define the attributes on the entity level. See below for a small example of a data model.
As you can see above, we have several entities (i.e., Order, Invoice) related to each other in a certain way. Furthermore, we see that our entities are defined through the help of attributes. So, for example, our Order entity holds an ID, Date, and Description attribute. The data model also tells us the data types of the entity's attributes. Therefore the picture above tells us that the ID is represented as an integer, the Date is a DateTime, and the Description is defined as a String (Text).
Lastly, data models provide information about the type of association between two entities. Within data models, there are three types of associations possible.
- One-to-One
- One-to-Many or Many-to-One
- Many-to-Many
Applying this knowledge to the example above teaches us that one Invoice contains multiple orders and that one Order contains multiple OrderLines. Furthermore, it tells us that each OrderLine only holds one Address reference.
Now that we know what data models are in the conceptual sense, we will focus on how data models are used within each of the three integration patterns we support in eMagiz.
3.2 Data models in Messaging
In the messaging pattern of eMagiz, we use a Canonical Data model (CDM). Canonical data models are a type of data model that aims to present data entities and relationships in the simplest possible form to integrate processes across various systems and databases. More often than not, the data exchanged across multiple systems rely on different languages, syntax, and protocols.
For more information on further understanding the CDM please check out this [microlearning](../microlearning/crashcourse-messaging-what-is-cdm.md).
3.3 Data models in API Management
As with every integration pattern, eMagiz gives you the option to create your data model. This data model can be based on standards (i.e., OTM5), custom-made, or a combination of both.
For API, the data model represents the structure of messages that you want to publish to the outside (other parties or other internal systems) world.
With the help of this data model, you can create a uniform layer through which you expose your data to the outside world. In terms of the API Management pattern, we extend this uniform layer to include not only the data model but also the security (i.e., OAuth 2.0 * Client Credentials) and the message format (JSON).
An example of an API Data model in eMagiz is shown below.
For further understanding of the API Data Model, please check out this [microlearning](../microlearning/crashcourse-api-gateway-api-data-model.md).
3.4 Data models in Event Streaming
As with every integration pattern, eMagiz gives you the option to create your data model. This data model can be based on standards, custom-made, or a combination of both.
For Event Streaming, the data model represents the structure of messages exchanged between parties with the help of topics.
With the help of this data model, you can create a shared understanding between producers and consumers on topics of what kind of data is exchanged. This can help, especially the consumer, define what they can expect when consuming data and adapt their logic based on the provided information.
An example of an Event Streaming Data model in eMagiz is shown below.
For more information on how to further understand the Event Streaming Data Model, please check out this [microlearning](../microlearning/intermediate-configuring-event-streaming-data-model.md)
4. Key takeaways
- Data models define the structure of data related to a system or related to eMagiz itself
- Within a data model, you model out the relationships between entities
- Within a data model, you define all relevant attributes of an entity
- eMagiz uses data models in each of the patterns to structure the data (flow)
5. Suggested Additional Readings
If you are interested in this topic and want to learn how you can control your Cloud with the help of the eMagiz platform, please check out our microlearnings offering on eMagiz Cloud Management: