Processing messages in queues
The various messages are sequentually processed for further integration into and processing by the Planon application.
To ensure that the communication to the client initiating these messages happens quickly, they are queued in between the processing stages.
Once a message is on a queue, this is acknowledged to the client, which means the client does not have to wait until it is processed. Queuing ensures that messages will not get lost and will be processed in the right order.
Before picking up items from the queue, the respective component finds the corresponding transformer or processor and carries that out.
The queueing mechanism ensures that the processing takes place correctly. Each step is either successful (receiving, transformation, processing) and is committed to a subsequent queue and database, or fails and is put on the queue again.
 | Persistent failures will be put on the queue and retried 9 times before finally being logged as failed. |
When the transformation, processing or transmission fails, the Comment field of the respective Inbound/Outbound raw messages or Inbound/outbound messages business object is updated with an error message.
| | The error will be logged in the business object preceding the step in which the error occurred. For example, if inbound processing fails, the error is logged in the transformation step. |
Inbound
• When a raw message is received, it is put on the Inbound raw message queue for transformation.
• After transformation, it is put on the Inbound message queue for processing.
Outbound
• When a specific SX context is detected, an outbound message is put on the outbound message queue for transformation.
• After transformation, the outbound raw message is put on the outbound raw message queue for transmission.
Queue is full
When the queue is full, if possible, the user will receive a prompt. In any case, Queue statistics will be added to the server log (Wildfly). This will help analyze and troubleshoot issues if they occur:
Logging queue statistics information for queue: 'jms.queue.RawInboundMessageQueue.1'
Consumer Count (The number of consumers consuming messages from this queue) = 15
Delivering Count (The number of messages that this queue is currently delivering to its consumers) = 19437
Message Count (The number of messages currently in this queue) = 19437
Scheduled Count (The number of scheduled messages in this queue) = 0
Messages Added (The number of messages added to this queue since it was created) = 19437
Server uptime (The amount of time this server/JVM is up and running) = 1 hr
Message inflow (The average message inflow speed for this queue since it was created) = 19437 msg/hr
Consumer Count (The number of consumers consuming messages from this queue) = 15
Delivering Count (The number of messages that this queue is currently delivering to its consumers) = 19437
Message Count (The number of messages currently in this queue) = 19437
Scheduled Count (The number of scheduled messages in this queue) = 0
Messages Added (The number of messages added to this queue since it was created) = 19437
Server uptime (The amount of time this server/JVM is up and running) = 1 hr
Message inflow (The average message inflow speed for this queue since it was created) = 19437 msg/hr
Timeouts
Timeouts have been added to Event Connector to prevent queue blockages. If a Processor, Transformer, or Transmitter requires more time than the set timeout, the action is aborted, and the message status is set to Failed. Event Connector will then continue to process the next message and stay operational.
You can set timeouts in General (System Settings).