Message states
This diagram shows the message runtime states and the available actions. Standard BOD agreements are delivered automatically.
This table shows the description for each message state:
Runtime Message states | Description |
---|---|
Receive |
When a communication channel receives a message, the message is put in Receive state before any action is done to the message. A message stays in Receive state until it is fully received or downloaded in IEC. |
Received |
Message payload and manifests are persisted in the file system. When a message is fully received in IEC, the message is put in Received state. Messages in Received state are ready for detection. |
Receive Failed |
If an error occurs while a communication channel receives a message, then the message is put in Received Failed state. Most errors in this state are caused in the communication between the message sender and communication channel receiver. |
Message Rejected |
The duplicate messages received in IEC are rejected and they are put in Message Rejected state. |
Detect |
Received messages are identified in IEC based on the message's partner agreements. |
Detect Failed |
If an error occurs in message detection process, for example, then the message does not match any configured partner agreements. The message is put in Detect Failed state. |
Check Order |
The message order is checked in IEC based on its primary key and variation ID. Check Order is part of the partner agreement process list. If used, then a Check Order is recommended to be added only once for ordered messages and it must be the first process in the process list. |
Check Order Failed |
If a failure occurs in retrieving the message primary keys or variation ID, then a message is set in Check Order Failed state. |
Check Order Waiting |
The message is set in waiting state based on the ordered primary key value. |
Message Disregarded |
If the variation ID value of a message is lower than the current variation ID value, then the message is disregarded. |
The message is transferred from central node to process node:
-
Delegate to process
From the central node, messages are transferred to the process node. When the message is being transferred, it goes through delegate to process state.
-
Delegate received
After the message is received in the process node, the message state becomes delegate received state.
Runtime Message states | Description |
---|---|
Process |
In Process state, the message is iterating through the agreement process list. This state is a composite of different steps that are dependent on the partner agreement. In a partner agreement, there must be at least one process step. Then, a process counter is used to determine at which step in the process list a message is placed. The process counter is stored in the manifest file. |
Process Failed |
If an error occurs in a specific process step, then the message is put in Process Failed state. |
Finished |
In Finished state, the message is finished iterating through its partner agreement process list. |
Retry |
Retry means repetition of the last failed process step. If a failure occurs during Detect or Check Order, then a Retry action restarts processing a message from Detection point. |
Redetect |
Redetect resets the manifest, sets the state to Received, and starts from Detection point. If Redetect process is used in Partner Admin tool process steps, then it is equivalent to sending a message from IEC back into IEC. In Redetect, the current message is redetected and no further processing is done. |