Skip to Content

Changes for page Exercises

Last modified by Carlijn Kokkeler on 2022/10/19 13:32
From version 16.1
edited by Carlijn Kokkeler
on 2022/10/19 12:30
Change comment: There is no comment for this version
To version 1.1
edited by Carlijn Kokkeler
on 2022/09/30 09:23
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -9,235 +9,71 @@
9 9  
10 10  == 2. Key concepts ==
11 11  
12 -This microlearning centers around understanding the concept data modeling in design.
12 +This microlearning centers around understanding the concept of the message definition.
13 13  
14 -== 3. CDM, CDM & system message, message mapping ==
15 -By following the steps below, you should gain a better understanding of the differences between CDM, CDM messages, and system messages.
14 +With message definition we mean: 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
16 16  
17 -* Creating a CDM
18 - Please import the file Order.xsd in your CDM. The code for this file can be found in section 4. Code for xsd files.
19 -* Creating a CDM message
20 - Now, go to your CDM message and select Order as root entity.
21 - Add all other entities and attributes from Order.xsd, which were imported into the CDM, to your CDM message definition.
22 -* Creating a system message
23 - In one of your System messages, import the file TransportOrder.xsd. The code for this file can be found at the bottom of this page.
24 -* Creating a CDM message
25 - Select CreateOrder as root entity and add all other entities and attributes to your system definition.
26 -* Complete message mapping
27 - Now that you have completed these steps, go to Message mapping and complete the mapping.
16 +In other words, the message definition defines the structure of the data that will be sent or received.
28 28  
29 -The solutions to these exercises can be found [[here>>doc:Main.eMagiz Academy.Use Cases.Data modeling in Design.Exercises.Solutions.WebHome||target="blank"]].
18 +== 3. What is a message definition ==
30 30  
31 -== 4. Code for xsd files ==
32 -Code for Order.xsd:
33 -{{code language="xml"}}
34 -<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
35 - xmlns="http://www.carlijnsplatform.com/ns/capetms/cdm/1.0/"
36 - attributeFormDefault="unqualified"
37 - elementFormDefault="qualified"
38 - targetNamespace="http://www.carlijnsplatform.com/ns/capetms/cdm/1.0/">
39 - <xs:complexType name="Order">
40 - <xs:sequence>
41 - <xs:element name="Date" type="xs:dateTime"/>
42 - <xs:element name="OrderId" type="nonEmptyString"/>
43 - <xs:element name="Customer" type="Customer"/>
44 - <xs:element name="PickupAddress" type="PickupAddress"/>
45 - <xs:element name="DeliveryAddress" type="DeliveryAddress"/>
46 - <xs:element maxOccurs="unbounded" name="OrderLine" type="OrderLine"/>
47 - </xs:sequence>
48 - </xs:complexType>
49 - <xs:complexType name="Customer">
50 - <xs:sequence>
51 - <xs:element name="Name" type="nonEmptyString"/>
52 - <xs:element name="Email" type="nonEmptyString"/>
53 - </xs:sequence>
54 - </xs:complexType>
55 - <xs:complexType name="PickupAddress">
56 - <xs:sequence>
57 - <xs:element name="Name" type="nonEmptyString"/>
58 - <xs:element name="Street" type="nonEmptyString"/>
59 - <xs:element name="StreetNumber" type="nonEmptyString"/>
60 - <xs:element name="PostalCode" type="nonEmptyString"/>
61 - <xs:element name="City" type="nonEmptyString"/>
62 - <xs:element name="Country" type="nonEmptyString"/>
63 - </xs:sequence>
64 - </xs:complexType>
65 - <xs:complexType name="DeliveryAddress">
66 - <xs:sequence>
67 - <xs:element name="Name" type="nonEmptyString"/>
68 - <xs:element name="Street" type="nonEmptyString"/>
69 - <xs:element name="StreetNumber" type="nonEmptyString"/>
70 - <xs:element name="PostalCode" type="nonEmptyString"/>
71 - <xs:element name="City" type="nonEmptyString"/>
72 - <xs:element name="Country" type="nonEmptyString"/>
73 - </xs:sequence>
74 - </xs:complexType>
75 - <xs:complexType name="OrderLine">
76 - <xs:sequence>
77 - <xs:element name="PackageUnit" type="nonEmptyString"/>
78 - <xs:element name="Quantity" type="xs:long"/>
79 - <xs:element name="Description" type="nonEmptyString"/>
80 - <xs:element name="Weight" type="xs:decimal"/>
81 - </xs:sequence>
82 - </xs:complexType>
83 - <xs:simpleType name="nonEmptyString">
84 - <xs:restriction base="xs:string">
85 - <xs:minLength value="1"/>
86 - </xs:restriction>
87 - </xs:simpleType>
88 - <xs:element name="Order" type="Order"/>
89 -</xs:schema>
90 -{{/code}}
20 +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.
21 +In all integration patterns (Messaging, API Gateway, and Event Streaming) we have message definitions.
91 91  
92 -Code for TransportOrder.xsd:
93 -{{code language="xml"}}
94 -<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
95 - xmlns="https://transportinc.nl/ns/tms/1.0/"
96 - attributeFormDefault="unqualified"
97 - elementFormDefault="unqualified"
98 - targetNamespace="https://transportinc.nl/ns/tms/1.0/">
99 - <xs:complexType name="CreateOrder">
100 - <xs:sequence>
101 - <xs:element name="Order" type="Order"/>
102 - </xs:sequence>
103 - </xs:complexType>
104 - <xs:complexType name="Order">
105 - <xs:sequence>
106 - <xs:element name="OrderID">
107 - <xs:simpleType>
108 - <xs:restriction base="xs:string">
109 - <xs:maxLength value="200"/>
110 - </xs:restriction>
111 - </xs:simpleType>
112 - </xs:element>
113 - <xs:element name="OrderDate" type="xs:dateTime"/>
114 - <xs:element minOccurs="0" name="Order_Customer" type="Order_Customer"/>
115 - <xs:element name="Address" type="Address"/>
116 - <xs:element name="PartnerInfo_Order" type="PartnerInfo_Order"/>
117 - <xs:element name="OrderLine_Order" type="OrderLine_Order"/>
118 - </xs:sequence>
119 - </xs:complexType>
120 - <xs:complexType name="Order_Customer">
121 - <xs:sequence>
122 - <xs:element minOccurs="0" name="Customer" type="Customer"/>
123 - </xs:sequence>
124 - </xs:complexType>
125 - <xs:complexType name="Customer">
126 - <xs:sequence>
127 - <xs:element name="Name">
128 - <xs:simpleType>
129 - <xs:restriction base="xs:string">
130 - <xs:maxLength value="200"/>
131 - </xs:restriction>
132 - </xs:simpleType>
133 - </xs:element>
134 - <xs:element minOccurs="0" name="Contact_Customer" type="Contact_Customer"/>
135 - </xs:sequence>
136 - </xs:complexType>
137 - <xs:complexType name="Contact_Customer">
138 - <xs:sequence>
139 - <xs:element maxOccurs="unbounded"
140 - minOccurs="0"
141 - name="Contact"
142 - type="Contact"/>
143 - </xs:sequence>
144 - </xs:complexType>
145 - <xs:complexType name="Contact">
146 - <xs:sequence>
147 - <xs:element name="eMail">
148 - <xs:simpleType>
149 - <xs:restriction base="xs:string">
150 - <xs:maxLength value="200"/>
151 - </xs:restriction>
152 - </xs:simpleType>
153 - </xs:element>
154 - <xs:element minOccurs="0" name="Name">
155 - <xs:simpleType>
156 - <xs:restriction base="xs:string">
157 - <xs:maxLength value="200"/>
158 - </xs:restriction>
159 - </xs:simpleType>
160 - </xs:element>
161 - </xs:sequence>
162 - </xs:complexType>
163 - <xs:complexType name="Address">
164 - <xs:sequence>
165 - <xs:element name="Type" type="nonEmptyString"/>
166 - <xs:element name="Name" type="nonEmptyString"/>
167 - <xs:element name="Street" type="nonEmptyString"/>
168 - <xs:element name="PostalCode" type="nonEmptyString"/>
169 - <xs:element name="City" type="nonEmptyString"/>
170 - <xs:element name="Country" type="nonEmptyString"/>
171 - </xs:sequence>
172 - </xs:complexType>
173 - <xs:complexType name="PartnerInfo_Order">
174 - <xs:sequence>
175 - <xs:element maxOccurs="unbounded"
176 - minOccurs="0"
177 - name="PartnerInfo"
178 - type="PartnerInfo"/>
179 - </xs:sequence>
180 - </xs:complexType>
181 - <xs:complexType name="PartnerInfo">
182 - <xs:sequence>
183 - <xs:element name="UUID">
184 - <xs:simpleType>
185 - <xs:restriction base="xs:string">
186 - <xs:maxLength value="64"/>
187 - </xs:restriction>
188 - </xs:simpleType>
189 - </xs:element>
190 - </xs:sequence>
191 - </xs:complexType>
192 - <xs:complexType name="OrderLine_Order">
193 - <xs:sequence>
194 - <xs:element maxOccurs="unbounded"
195 - minOccurs="0"
196 - name="OrderLine"
197 - type="OrderLine"/>
198 - </xs:sequence>
199 - </xs:complexType>
200 - <xs:complexType name="OrderLine">
201 - <xs:sequence>
202 - <xs:element name="Description">
203 - <xs:simpleType>
204 - <xs:restriction base="xs:string">
205 - <xs:maxLength value="200"/>
206 - </xs:restriction>
207 - </xs:simpleType>
208 - </xs:element>
209 - <xs:element name="Quantity" type="xs:long"/>
210 - <xs:element name="Unit" type="Enum"/>
211 - <xs:element minOccurs="0" name="Weight" type="xs:double"/>
212 - </xs:sequence>
213 - </xs:complexType>
214 - <xs:simpleType name="nonEmptyString">
215 - <xs:restriction base="xs:string">
216 - <xs:minLength value="1"/>
217 - </xs:restriction>
218 - </xs:simpleType>
219 - <xs:simpleType name="Enum">
220 - <xs:restriction base="xs:string">
221 - <xs:enumeration value="COLLI"/>
222 - <xs:enumeration value="EURO"/>
223 - <xs:enumeration value="BOX"/>
224 - <xs:enumeration value="SACK"/>
225 - </xs:restriction>
226 - </xs:simpleType>
227 - <xs:element name="CreateOrder" type="CreateOrder"/>
228 -</xs:schema>
229 -{{/code}}
23 +On one hand, we have message definitions that relate to a system.
24 +These definitions tell us something about how the system will send or wants to receive messages (data).
25 +On the other hand, we have message definitions that relate to eMagiz.
26 +These are generic and consistent across systems (i.e. CDM messages, Gateway messages, Topic messages).
27 +
28 +[[image:Main.Images.Microlearning.WebHome@crashcourse-platform-design-what-is-a-message-definition--design-overview.png]]
29 +
30 +In this phase, you can open the context menu on the integration level (remember, that is a line between eMagiz and an external system).
31 +The context menu will look slightly different based on the integration pattern. These differ as the use cases for each pattern differ slightly.
32 +
33 +[[image:Main.Images.Microlearning.WebHome@crashcourse-platform-design-what-is-a-message-definition--context-menu-messaging-definition.png]]
34 +
35 +[[image:Main.Images.Microlearning.WebHome@crashcourse-platform-design-what-is-a-message-definition--context-menu-api-definition.png]]
36 +
37 +[[image:Main.Images.Microlearning.WebHome@crashcourse-platform-design-what-is-a-message-definition--context-menu-es-definition.png]]
38 +
39 +Selecting one of the above options will lead you to an overview similar to the one that is shown below.
40 +
41 +[[image:Main.Images.Microlearning.WebHome@crashcourse-platform-design-what-is-a-message-definition--message-definition.png]]
42 +
43 +In this overview, you can import a definition or create one yourself.
44 +
45 +=== 3.1 eMagiz datamodels ===
46 +
47 +Above the focus was on the system messages (i.e. the definitions as defined by the external system). Within each of the patterns eMagiz supports (Messaging, API Management, and Event Streaming) we support an eMagiz data model. In these data models you can define how the messages should look like when they pass through the system of eMagiz. When creating a message transformation you always have atleast one eMagiz part that is based on an eMagiz data model. This is needed as you need to transform from the external system to the eMagiz data model for example.
48 +
49 +In messaging terms we call this eMagiz data model a CDM for example. Based on the pattern you are implementing the naming can change slightly but the conceptual idea is the same. For more information on the various data models we support for the patterns please check out the suggested additional readings section below.
50 +
51 +
52 +
53 +== 4. Assignment ==
54 +
55 +Navigate to Design and open the message definition option of at least one integration within your project.
56 +This assignment can be completed within the (Academy) project that you have created/used in the previous assignment.
57 +
230 230  == 5. Key takeaways ==
231 231  
232 -* The CDM holds all entities and attributes that are relevant within the context of your complete integration landscape.
233 -* The CDM message is tailor-made for a specific piece of data and only holds the entities and attributes relevant for that piece of data.
234 -* A system message is specific to a system.
60 +* 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
61 +* Some message definitions are specific to a system. Others are generic across systems
235 235  
236 236  
64 +
237 237  == 6. Suggested Additional Readings ==
238 238  
239 -If you are interested in this topic and want more information on it please read the help text provided by eMagiz.
67 +If you are interested in this topic and want more information on it please read the help text provided by eMagiz. Furthermore check out these links if you want a more in-depth knowledge of the eMagiz data models:
240 240  
69 +* [API Gateway model](crashcourse-api-gateway-api-data-model.md)
70 +* [Understanding the eMagiz CDM](crashcourse-messaging-what-is-cdm.md)
71 +* [Event Streaming data model](intermediate-configuring-event-streaming-data-model.md)
241 241  
73 +== 7. Silent demonstration video ==
242 242  
75 +This video demonstrates a working solution and how you can validate whether you have successfully completed the assignment.
76 +
77 +{{video attachment="crashcourse-platform-design-what-is-a-message-definition.mp4" reference="Main.Videos.Microlearning.WebHome"/}}
78 +
243 243  )))((({{toc/}}))){{/container}}{{/container}}