Architecture Overview (Magic xpi 4.14)
Magic xpi server is built over the In-Memory Middleware provided with the xpi installer and this middleware serves as an underlying messaging layer for the infrastructure. The xpi server communicates with the IMM using the IMM-Agent. There is one centralized IMM cluster and multiple host of xpi servers connected to this IMM.
Now, to understand the IMM in detail let’s look at the IMM internal layout.
Refer to Understanding IMM Architecture and Terminology to know what each of these components do.
A thorough understanding of the server architecture is very useful when defining a project’s recovery settings. The following diagram shows how the server architecture works.
|
ROOTFSID 1
|
The Root Flow Sequence ID (Root FSID) is the same for all flows and branches within the same runtime tree.
|
|
ROOTFSID 4
|
A stand-alone branch starting a new runtime tree.
|
|
ROOTFSID #
|
The number is the same as the initial FSID’s number.
|
|
FSID
|
Each new flow receives a new Flow Sequence ID (FSID). A stand-alone branch is considered a separate flow, so it gets a new FSID of its own.
|
|
1...5 = Flow Request ID
|
Each triggered flow, parallel branch, or stand-alone branch is invoked by a flow request message, which has its own ID. "Invoke flow" step and "call flow" destinations are part of a linear execution, and therefore do not have their own flow request messages.
|
|
I, II
|
For each call flow iteration, the called flow (I) is assigned a new FSID. When the called flow returns to the calling flow (II), the calling flow (II) remains with its original FSID.
|
