Queues - How do they work

{{container}}{{container layoutStyle="columns"}}(((

In this microlearning, we will explore how queues work and how they work with the JMS. This method ensures that data is data delivered via the messaging pattern in eMagiz.

4

5

Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].

6

7

== 1. Prerequisites ==

8

9

* Intermediate knowledge of the eMagiz platform

10

11

== 2. Key concepts ==

12

13

This microlearning centers on the concept of how queues work and how they work with the JMS.

14

15

* The key aspects are:

16

** Queues are part of the messaging layer

17

** The queues reside on infra level (JMS)

18

** Endpoint of the entry is the first queue in the messaging layer

19

** Consumers subscribe to queues to process data

20

21

== 3. Queues - How do they work ==

22

23

In this microlearning, we will explore how queues work and how they work with the JMS. This method ensures that data is data delivered via the messaging pattern in eMagiz.

24

25

* The key aspects are:

26

** Queues are part of the messaging layer

27

** The queues reside on infra level (JMS)

28

** Endpoint of the entry is the first queue in the messaging layer

29

** Consumers subscribe to queues to process data

30

31

When you use the messaging engine in eMagiz, you will use the queue mechanism inside the messaging engine to transport data between the various processes. In the picture shown below, we clarified this method.

32

33

[[image:Main.Images.Microlearning.WebHome@intermediate-orchestration-of-data-packets-queues-how-do-they-work--concept.png]]

34

35

This picture tells us a lot about how the messaging engine in eMagiz works. First, it tells us that we discern five layers in eMagiz to process data from one system to another. The five layers we distinguish are the entry, the onramp, the routing, the offramp, and the exit. We also see in the picture that the messaging engine consists of a process layer (the top part) and a messaging layer (the infra part on the bottom). If we zoom in on the infra part, we see four queues involved in this process.

36

37

Why not five, you ask? That is because the entry (that ensures that data comes in) does not have a queue. For a more in-depth analysis of why this is, please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Key concepts eMagiz Messaging.intermediate-key-concepts-emagiz-messaging-entry-not-a-queue||target="blank"]]. The picture also tells us that the queue acts as the bridge between two processes. For example, if we zoom in on the left part of the picture that depicts the offramp and the exit, we see that the offramp process is done when it successfully delivers the message on the next queue in line (the exit). This queue is automatically the starting point of the following process (the exit).

38

39

So in a sense, the responsibilities of each process are separated from each other. Another thing to notice about this picture is that the depicting of the entry and the exit differs. This difference stems from the fact that the starting point of your process and the endpoint of your process will be something else. This connection can be a REST endpoint, or a database, or an SFTP server. The entry ensures the data is received (or retrieved) from an external system. The exit makes sure to deliver the data to an external system.

40

41

The last thing to notice about this picture is the background color. We have blue, green, blue in this picture. In eMagiz, we use blue to depict that those processes are related to a specific system. As we explained before, this holds for the entry and the exit. The green portion is happening internally in the eMagiz engine, and since the start and the end are eMagiz queues and eMagiz structures, the background color is green. This distinction also allows you to deploy your entries and exit on a separate machine compared to your onramp, offramp, and routing processes.

42

43

When stepping outside of the confines of the picture, we have one last thing to discuss before we wrap up this microlearning. As we learned previously, the queues are part of the messaging layer (i.e., the infra). The JMS process within eMagiz governs the messaging layer and will dynamically create or drop queues based on what you deploy with the help of your release. This functionality makes the process of adding and removing processes from your integration data model dynamic in nature.

44

45

This explanation concludes how eMagiz uses queues to split the functional process into five steps, each with its function.

46

47

== 4. Key takeaways ==

48

49

* The key aspects are:

50

** Queues are part of the messaging layer

51