Changes for page Discovery

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,5 +1,5 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
2		-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>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-intro-the-five-phases-of-emagiz||target="blank"]] microlearning. Discovery of the integration landscape is very important and should be handled by experienced staff.
	2	+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 eMagiz. The phases from eMagiz correspond with phases from Integration Lifecycle Management. More information about these phases can be found in [[this>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-intro-the-five-phases-of-emagiz||target="blank"]] microlearning. Discovery of the integration landscape is very important and should be handled by experienced staff.
3	3
4	4	Should you have any questions, please get in touch with academy@emagiz.com.
5	5
...	...	@@ -25,7 +25,7 @@
25	25
26	26	== 4. Capture ==
27	27
28		-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.
	28	+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. We recommend filling out all documentation available in this phase, because this documentation can help to ensure smooth development by means of providing the context and other supporting information to the involved team members/stakeholders, so they can make better decisions when developing or maintaining the integration in the subsequent phases.
29	29
30	30	When you want to create your systems, you need to ask yourself the following questions:
31	31	* What systems are relevant in our business case?
...	...	@@ -33,6 +33,11 @@
33	33	* What should each system be called?
34	34	* What should be the default integration pattern for each system?
35	35
	36	+In case you would like to add systems to your existing integration landscape, you need to ask yourself several questions as well:
	37	+* How does this system fit into my existing landscape?
	38	+* Does this system have similarities with existing systems?
	39	+* How should this system interact with existing systems?
	40	+
36	36	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>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-capture-configure-a-system||target="blank"]] microlearning.
37	37
38	38	When you want to create an integration, you need to ask yourself the following questions:
...	...	@@ -45,7 +45,7 @@
45	45
46	46	== 5. Design ==
47	47
48		-After the Capture phase, you will move to the Design phase. In the Design phase, the system message definitions are created, and the transformation mappings are drawn. The client infrastructure is determined in this phase, and several cloud components are specified. When you start working in the design phase, you should ask yourself the following questions:
	53	+After the Capture phase, you can proceed to the Design phase. In the Design phase, the system message definitions are created, and the transformation mappings are drawn. A message definition is a visual representation of how the elements are related to each other, whether they are mandatory and the data types they have that can be used in the message mapping. The client infrastructure is also determined in the Design phase, and several cloud components are specified. When you start working in the design phase, you should ask yourself the following questions:
49	49	* What should my data model look like?
50	50	* What message definitions are needed?
51	51	* Which message formats are required?
...	...	@@ -53,78 +53,25 @@
53	53	* What should the architecture (incl. instances, machine sizes, etc.) be like?
54	54	* What metadata needs to be stored?
55	55
56		-Several more questions may be relevant. Documentation on how to develop in the Design phase can be found in the [[Crash Courses>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.||target="blank"]].
	61	+In case you would like to expand your existing integration landscape, you need to ask yourself several questions as well:
	62	+* How does my addition to the data model fit into the current data model?
	63	+* Which entities in the current data model have overlap with the entities I wish to add?
	64	+* Are there any overlapping system messages if I add this system message?
57	57
58		-=== 3.1 What is a data model ===
	66	+Several more questions may be relevant. Documentation on how to develop in the Design phase can be found in the [[Platform Crash Courses>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.||target="blank"]].
59	59
60		-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.
	68	+== 6. Key takeaways ==
61	61
62		-[[image:Main.Images.Fundamental.WebHome@fundamental-data-models--example-structure.png]]
	70	+* Discovery concerns the design of the integration landscape.
	71	+* An establishment of technical requirements is necessary before continuing with discovery in eMagiz.
	72	+* The Capture & Design phases are used to discover the integration landscape in eMagiz.
63	63
64		-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).
	74	+== 7. Suggested Additional Readings ==
	75	+* [[Crash Courses (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]
	76	+** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]]
	77	+*** [[Technical requirements before starting in eMagiz>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-intro-technrequirements||target="blank"]]
	78	+* [[Integration Lifecycle Management>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-intro-the-five-phases-of-emagiz||target="blank"]]
	79	+* [[Platform Crash Courses>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.||target="blank"]]
65	65
66		-Lastly, data models provide information about the type of association between two entities. Within data models, there are three types of associations possible.
67	67
68		-* One-to-One
69		-* One-to-Many or Many-to-One
70		-* Many-to-Many
71		-
72		-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.
73		-
74		-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.
75		-
76		-=== 3.2 Data models in Messaging ===
77		-
78		-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.
79		-
80		-[[image:Main.Images.Fundamental.WebHome@fundamental-data-models--canonical-data-model.jpg]]
81		-
82		-For more information on further understanding the CDM please check out this [microlearning](../microlearning/crashcourse-messaging-what-is-cdm.md).
83		-
84		-=== 3.3 Data models in API Management ===
85		-
86		-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.
87		-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.
88		-
89		-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).
90		-
91		-An example of an API Data model in eMagiz is shown below.
92		-
93		-[[image:Main.Images.Fundamental.WebHome@fundamental-data-models--import-data-model-in-design-filled-in.png]]
94		-
95		-For further understanding of the API Data Model, please check out this [microlearning](../microlearning/crashcourse-api-gateway-api-data-model.md).
96		-
97		-=== 3.4 Data models in Event Streaming ===
98		-
99		-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.
100		-For Event Streaming, the data model represents the structure of messages exchanged between parties with the help of topics.
101		-
102		-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.
103		-
104		-An example of an Event Streaming Data model in eMagiz is shown below.
105		-
106		-[[image:Main.Images.Fundamental.WebHome@fundamental-data-models--data-model-in-design-filled-in.png]]
107		-
108		-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)
109		-
110		-
111		-
112		-== 4. Key takeaways ==
113		-
114		-* Data models define the structure of data related to a system or related to eMagiz itself
115		-* Within a data model, you model out the relationships between entities
116		-* Within a data model, you define all relevant attributes of an entity
117		-* eMagiz uses data models in each of the patterns to structure the data (flow)
118		-
119		-
120		-
121		-== 5. Suggested Additional Readings ==
122		-
123		-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:
124		-
125		-* [[Understanding the eMagiz CDM>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.crashcourse-messaging-what-is-cdm||target="blank"]]
126		-* [[API Data Model>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-api-data-model||target="blank"]]
127		-* [[Event Streaming Data Model>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Configuring Event Streaming.intermediate-configuring-event-streaming-data-model||target="blank"]]
128		-* [[Relationship in DBMS>>https://afteracademy.com/blog/what-are-the-different-types-of-relationships-in-dbms||target="blank"]]
129		-
130	130	)))((({{toc/}}))){{/container}}{{/container}}