Threads and Workers (Magic xpi 4.13)

Magic xpi 4.x has two distinct types of threads:

• Flow threads

• Trigger threads

Flow Threads (Flow Workers)

These are also called "flow workers"; that is, threads that can execute flows. A flow worker performs flow steps. Flow workers start and wait for flow invocation requests (messages) whose status in the Space is READY_FOR_USE. Once a flow invocation request (message) is created, an available flow worker changes its status in the Space to IN_PROCESS. It does this within a transaction to prevent two workers from executing the same message, and runs the requested flow defined in the message using the data available in the message payload.

The flow worker maintains detailed status information in the Space during its operation to enable detailed monitoring, troubleshooting, and maintenance. Before running each step in the flow, the worker updates the Space with the current flow status and then, according to the project metadata, it checks if it needs to:

• Abort due to reaching its user defined timeout

• Abort due to recovery or error handling

• Abort due to server/project shutdown

• Pause before continuing to the next step (in debug state)

When the flow is complete, the worker updates the flow invocation request message’s status in the Space to DONE, and starts waiting for additional new messages to handle.

The Magic.ini file's WorkerReadDeeperMessagesfirst= flag tells Magic xpi to prioritize messages with a higher depth when reading messages from the Space, ensuring that a business process is completed before a new one starts.

Trigger Threads (Trigger Workers)

These are threads that are responsible for polling or “listening” to external events and initiating flows by creating flow invocation requests in the Space. Trigger threads start and wait for external events to occur. Once such an event occurs, the trigger creates a flow invocation request (message) with the event data (payload), to be handled by available flow workers. Triggers can be synchronous or asynchronous:

• Synchronous Triggers: While some triggers invoke flow requests asynchronously, other triggers have a synchronous working mode. In this mode, after the trigger creates an invoke flow request, it will wait for a response message. The flow worker that handles a synchronous request is responsible for creating the response message with the payload once the flow is complete.

• Asynchronous Triggers: These triggers create flow request messages and immediately continue to check for new events in the external system, without waiting for a response. To prevent asynchronous triggers from flooding the Space with unhandled flow request messages, each trigger has a predefined queue buffer size that will be used to throttle the creation of new events if the queue exceeds the predefined size. This trigger buffer size has a default value of 10. You can adjust this value by changing the TriggersBufferSize= flag's value. Click here for more information about this flag. Just like flow workers, triggers maintain their state in the Space, to ensure maintainability and visibility.