Message overview

Message states

On an overview, this diagram shows the message runtime states and the available actions. You define the partner agreement process steps in Partner Agreement tool and you monitor the message states in EC Management page in Grid.

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 by EC.
Received	Message payload and manifests are persisted in the file system. When a message has been fully received into EC, 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, 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	If the DocIDController is enabled, duplicated messages received by EC will be rejected and the message is put in Message Rejected state.
Detect	Received messages are identified by EC based on the message's partner agreements.
Detect Failed	If an error occurs in message detection process, for example the message did not match any configured partner agreements, EC does not know how to proceed and the message is put in Detect Failed state.
Check Order	EC checks the message order based on its primary key and variation ID. Check Order is part of the partner agreement process list. If used, 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 a message is put in Check Order Failed state.
Check Order Waiting	The message is put 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, a message will be disregarded.

The message transfer from central node to process node:

• Delegate to process

  From central node messages are transferred to process node. When the message is being transferred, it goes through delegate to process state.

• Delegate received

  After the message has been 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, the message is put in Process Failed state.
Finished	In Finished state the message has finished iterating through its partner agreement process list.
Retry	Retry refers to repeating the last failed process step. If a failure occurs during Detect or Check Order, a Retry action will restart 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 it is equivalent to sending a message from EC back into EC. In Redetect, the current message is re-detected and no further processing can be done.

Message lifecycle states

These are the message lifecycle states. You view the log of message states from EC Management page > Event > Log.

• In Running or In-Process state, you can not take any action on a message, except if the message is also an ordered message.

  For in-process and ordered messages, you can invoke Force Kill from the Ordered View. The Force Kill action will attempt to terminate the running process. Use Force Kill on a message that has been running unexpectedly longer than it should and is causing a build up of message into EC.

  You access Ordered View from EC Management page > Message > Ordered.

• For Finished OK state, messages have completed its process. You can invoke Remove on finished messages.

• For Failed messages state, you can invoke Retry, Redetect, Remove, and Verify actions.

• For Waiting messages state, after the dependencies are completed, wait for these messages to be activated before you manually invoke Resume. The Resume action puts the waiting message back into process state.

EC Management Message tasks

These are the available links in EC Management page. Depending on the state at which a message is currently at, click on a link to view the tasks.

• The Status link shows the latest messages and available options.

  From this link you can filter to view the messages by status such as All, Finished, Failed, and Disregarded states.

• The Advanced Search link allows you to run a more detailed message search by UUID and state, and run other advanced search details.

• The Manifest Filter link allows you to search for messages using the manifest filter data produced by a message.
• The In-Process link allows you to view and search messages which are being processed by Enterprise Collaborator.

• The Retry/Redetect link allows you to view and manage failed messages. All messages are sorted by Receive Time. To filter messages by Partner/Agreement in Retry/Redetect go to the Agreement Retry/Redetect Messages, then drill down to the Partner and Agreement to view, then click Show.

  In Redetect, the current message is re-detected and no further processing can be done. Redetect process step is equivalent to sending a message from EC, back into EC.

  Use these guidelines:

  • All messages (Detect, Send, Validate, XML transform) in failed state can be filtered except for Receive Failed and Message Rejected states.

  • The Redetect All, Retry All, and Verify All actions apply only to messages in current view.

• The Agreement Retry/Redetect Messages link allows you to view and manage failed messages which is grouped by Partner and Business or by Technical messages. Business messages are suppressed by the PA to summarize error messages. Technical messages are not defined in PA, but it shows more details about the error.

• The Ordered link shows a list of corresponding ordered messages through Split Redetect process.

• The Variation ID link, (VID) uses a numeric value as basis of process order.

• The Suppressed Errors Reports link displays the Suppressed Error document or the summarized Business messages. When an error occurs, run the scheduled Error Aggregation task to show the number of errors according to Error type and Agreement. Messages with error are sent back to the server for reprocessing. Reprocessed message keeps its unique identifier and no tracking information is lost.

  Reprocess helps correct message errors that might occur if messages are incorrectly configured in any of these areas:

  • Routing

  • Processing

  • Classpaths for generated transformation

  In message reprocess, incoming messages are stored persistently. In some cases you do not need to reprocess a message. For example, when a partially processed message caused an external system, such as M3, to update and commit data that has not been rolled back, then you must manually verify the message.