Changes for page eMagiz State Generation

Summary

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

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-fundamental-stateful
	1	+eMagiz State Generation

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.ebakker
	1	+XWiki.CarlijnKokkeler

Content

...	...	@@ -1,9 +1,4 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
2		-
3		-
4		-
5		-= eMagiz Stateful =
6		-
7	7	In this fundamental, we'll take a look at the capability of eMagiz around storing a state of a data packet of message send across the platform.
8	8
9	9	Should you have any questions, please get in touch with academy@emagiz.com.
...	...	@@ -12,66 +12,89 @@
12	12
13	13	* Take a closer look at the Fundamentals for Messaging, API Gateway and Event Streaming
14	14
15		-== 2. Key concepts ==
	10	+== 2. Key Concepts ==
16	16
17		-All concepts are discussed in the section below..
	12	+In this microlearning, the concept of state generation will be explained.
18	18
	14	+== 3. Definition ==
19	19
	16	+State generation concerns the generation of a stateful application or service. This means that, for the application or service to function, data is stored and past states are used to derive information. Such a state may e.g. be a temperature or heartrate measure. Stateful applications or services are opposed to stateless applications or services, which do not require data to function and merely represent the current state.
20	20
21		-== 3. Introducing Stateful ==
	18	+An example of a stateful application, is an application that obtains temperature measures in a room and presents a timeline of the temperature measures. A thermostat produces the temperature in this example, after which the data needs to be put into context, including the time at which a certain temperature was measured and the room in which it was measured. Then, the data can be evaluated over time, and tested against the norm. This ensures that real time actions can be generated, e.g. a fire alert can be generated when the temperature has risen by 25 degrees Celsius in 1 minute.
22	22
23		-Within eMagiz there is a capability to store pieces of data of a specific object that is transit between systems. The basis idea of messages that are processed by eMagiz is that all of these are in transit. However, in certain cases it is very helpful to preserve a state of an object. That state can help to influence the next data packets that are passing through or trigger a certain action for another system.
	20	+[[image:Main.Images.Fundamental.WebHome@fundamental-stateful-1.png]]
24	24
25		-An example might be a situation where a sensor is submitting temperature data every 5 seconds on a data stream towards eMagiz. The interesting state of the machine where the sensor is attached to is the average temperature in the last hour. In this case the temperature that is send to the eMagiz should be used to update the state of the machine, and more specifically the average temperature. One needs a data stream from the sensor, a way to aggregate & average out all messages from the last hour, and a way to store the state. Once the temperature reaches a certain threshold, the data is submitted to a next system to raise an alert for a user.
	22	+== 4. Benefits and Operations ==
26	26
27		-Another example might be a data stream that registers a click on a specific webpage. That data stream is connected to eMagiz, whereby the state of that specific webpage is updated with the number of clicks. Once the number of clicks in the last 30 minutes reaches for instance more than 50, a specific action might be triggered. If that page contains a product, the action might be to display the number of web users active on that product in order to influence the sales of that product. One needs a data stream, a way to count the number of click, and a way to store the state of that webpage.
	24	+Benefits of real time state generation are, first of all, that data can be provided immediately and is always up-to-date. Secondly, it is possible to take real time action and take real-time decisions. Lastly, there is no need to store data unnecessarily.
28	28
29		-The example are purely illustrative to understand the concept.
	26	+Stateful data can be generated through four main operations. First of all, through enriching data. This means that information should be added to the data, so that it has more meaning. This can be achieved by storing states in a database. For example, when it is known that, if a person works from home, this is stored as A, and if a person works in the office, this is stored as B, the data can be enriched with ‘Home’ and ‘Office’. To ensure this, a database should be present storing the connection between A and Home, and B and Office.
30	30
31		-==== 3.1 State Store ====
	28	+[[image:Main.Images.Fundamental.WebHome@fundamental-stategeneration-example-enrich.png]]
32	32
33		-The state store refers to the storage location of the states of the specific objects in the environment. That storage location is part of the eMagiz platform, and embedded in the eMagiz runtime for now. The user needs to define what objects and the attributes of that object are to be stored. Several different objects and states of the objects can be be defined & stored. A state store can be shared across multiple processes that are allowed to update the state of an object.
	30	+Secondly, stateful data can be obtained through aggregating data. Aggregation concerns a computation over a certain range of time, such as an average, minimum or maximum. For example, when the number of people working from home, or working at the office is stored, the average number of people working at home or at the office during the past 30 minutes can be determined.
34	34
35		-==== 3.2 State Operations ====
	32	+[[image:Main.Images.Fundamental.WebHome@fundamental-stategeneration-example-aggregation.png]]
36	36
37		-Once the state store is defined, one needs different operations in order to update the state effectively.
	34	+Thirdly, change detection can be applied. This means that a change in the data can be detected. For example, when the temperature at home rises to more than 30 degrees, this can be detected. It can then be defined that, when the temperature at home is more than 30 degrees and the heating is on, the heating should be turned off. In this example, the data is enriched with the last state of the air conditioning.
38	38
39		-* Retrieve - get the values of an object and the attributes
40		-* Aggregate - Increment a attribute in a state store to +1
41		-* Enrich - add new attribute of an object in the state store based on joining several streams
42		-* Transform - filter data or translate formats
43		-* Time-window - to aggregate data over time
	36	+[[image:Main.Images.Fundamental.WebHome@fundamental-stategeneration-example-change-detection.png]]
44	44
45		-==== 3.3 State Action & networks ====
	38	+Lastly, duplicate detection can be applied, meaning that duplicate data can be detected. For example, if the number of people working from home is recorded twice at a certain moment, this can be detected, and the data can be adapted accordingly.
46	46
47		-Once the state store has values stored, certain triggers can be defined to cause action. For instance, when the temperature is higher than 20 in the example above. These actions can be defined/modeled by the eMagiz user inside flows, whereby the evaluation of state would send a data point to the system that manages the action. For instance, the support team that manages the server park and needs to verify of the airconditioning of the server room is working properly (case high temperature).
	40	+[[image:Main.Images.Fundamental.WebHome@fundamental-stategeneration-example-duplicate-detection.png]]
48	48
49		-One can imagine that a certain action would be to update the state of another object. Or that there are several other data streams are update several states. In that way, you can imagine a complete network of data that work intertwined for you to detect rolling reality of data that can be used for data analysis and real-time decision-making.
	42	+== 5. State Generation in eMagiz ==
50	50
51		-==== 3.4 Speed and throughput ====
	44	+State Generation components can be used in all eMagiz patterns. The enrich and aggregate functionalities are likely more fitting to Messaging and API Gateway as opposed to Event Streaming. For Event Streaming, the other two operations, change and duplicate detection, are more relevant.
52	52
53		-Many organizations hold lots of data which can be leveraged for such use cases, and often include IoT like data. Therefore, the data is usually put on event streams that are geared towards speed and throughput. In eMagiz you will find these data points usually in topics that are processed by Event Processor flows.
	46	+A state can most logically be created in a central place through which the data flows. The reason for this, is that such a place has all the required information flowing through its processes to generate stateful data.
54	54
55		-==== 3.5 Pattern specifics ====
	48	+The state store is implemented inside the eMagiz runtime using the H2 database for now. For time related operations another technology is used (Esper), and the functionality is only available on Docker based runtimes (to be release end Q2 2022). You wil find the specific Stateful components inside the Flow Designer as we use in eMagiz to model the flow. Aligned with the general concept of low-code developnment in eMagiz. For State store models, the current data modeling capabilities will be used.
56	56
57		-At first hand it looks as if these concepts would only apply to Event Streaming. But capturing & storing a state of an object would also be handy in other patterns such as Messaging. For instance, when the order of the messages being send matters, or when there is dependency between messages that is needed to determine when a message needs to be send in time.
	50	+== 6. Use Cases ==
58	58
59		-==== 3.6 eMagiz specifics ====
	52	+In the following, real-life implementations are given on how eMagiz State Generation has been realized through (i) enrichment, (ii) aggregation, (iii) change detection, and (iv) duplicate detection.
60	60
61		-The state store is implemented inside the eMagiz runtime using the H2 database for now. For time related operations another technology is used (Esper), and the functionality is only available on Docker based runtimes (to be release end Q2 2022). You wil find the specific Stateful components inside the Flow Designer as we use in eMagiz to model the flow. Aligned with the general concept of low-code developnment in eMagiz. For State store models, the current data modeling capabilities will be used.
	54	+==== 6.1 Enrich ====
62	62
	56	+Company A works with a backend system based on ID/Name combinations. These are different for each implementation, and can be retrieved through a unique API. A difficulty that arises, is that some APIs initially only return the IDs. To prevent multiple calls to our backend system, the key/value pairs (ID/Name) need to be stored, such that these can be used in subsequent calls.
63	63
	58	+The eMagiz solution for Company A can be viewed below.
64	64
65		-== 4. Key takeaways ==
	60	+[[image:Main.Images.Fundamental.WebHome@fundamental-stategeneration-usecase-enrich.png]]
66	66
67		-* Stateful refers to the concept of storing a state of an object
68		-* Storing a state is different compared to data in transit which is often refered as stateless data (eMagiz doesn't store or update the data when sending across)
69		-* Stateful can be applied across all patterns in eMagiz and is embedded into the platform in such a way that it provided the same user experience
	62	+==== 6.2 Aggregation ====
70	70
71		-[[image:Main.Images.Fundamental.WebHome@ffundamental-stateful-1.png]]
	64	+Company B provides contracts and files for their customers. Their customers manually upload contracts (one by one) to their files, which may take some time. It is desired by Company B that their customers receive a push notification once their files have been uploaded successfully. However, they do not wish to spam their customers by sending a push notification after each file upload when they are uploading several files. So, the push notification should be retained for some time, and should be sent once it is (almost) certain that no additional file will be uploaded.
72	72
	66	+In the figure below, the eMagiz solution for Company B can be viewed.
73	73
	68	+[[image:Main.Images.Fundamental.WebHome@fundamental-stategeneration-usecase-aggregation.png]]
74	74
	70	+==== 6.3 Change Detection ====
	71	+
	72	+Company C tracks packages and parcels that have been ordered by their customers. When a package is not received within its expected timeframe, an exception occurs. It can happen that such an exception resolves itself, e.g. after rendering for some time, the package is not ‘stuck’ anymore, and is being processed. Before implementing state generation, such a change was never sent to the Alert Manager, because no new exception was triggered. As a result, the employees from Company C were still working under the assumption that the exception is valid, meaning that they could still be searching for a packet that had already been received.
	73	+
	74	+With state generation, changes in package statuses are sent to the Alert Manager, so that they are aware of any (resolved) exceptions. In the figure below, the eMagiz solution for Company C can be viewed.
	75	+
	76	+[[image:Main.Images.Fundamental.WebHome@fundamental-stategeneration-usecase-change-detection.png]]
	77	+
	78	+==== 6.4 Duplicate Detection ====
	79	+
	80	+Company D is concerned with receiving meter readings. From an external system, new meter readings, or corrected meter readings are received. To protect underlying applications, it needs to be checked whether a duplicate between the external system and their own internal system exists. This can be achieved through a check for each type of meter reading. When a duplicate is found, the meter reading is marked, such that it can be checked later in the process.
	81	+The eMagiz solution for Company D can be viewed below.
	82	+
	83	+[[image:Main.Images.Fundamental.WebHome@fundamental-stategeneration-usecase-duplicate-detection.png]]
	84	+
	85	+== 4. Key Takeaways ==
	86	+
	87	+* State generation concerns the generation of a stateful application or service
	88	+ Stateful refers to the concept of storing a state of an object
	89	+* Storing a state is different compared to data in transit which is often refered as stateless data (eMagiz doesn't store or update the data when sending across)
	90	+* Stateful can be applied across all patterns in eMagiz and is embedded into the platform in such a way that it provided the same user experience
	91	+* Stateful data can be generated through four main operations: enrich, aggregation, change detection, duplicate detection
	92	+
75	75	== 5. Suggested Additional Readings ==
76	76
77	77	N/A