Foundation1 / Overview / Background Processing / Batchprocessor / This page

Batch Processor

Contents

• General
• Application Message Flow
• States
• Execution Steps
• Actions on Application Message
• Message Bodies
• Scheduled Tasks
• Database Triggers

General

Batch Processor is a part of IFS Connect framework responsible for processing of Application Messages.
The process can involve both synchronous calls and background processing of messages.

Batch Processor is based on Oracle Advanced Queuing concept using PL/SQL package DBMS_AQ invoked from a database trigger in combination with JMS messaging and a dedicated Message Driven Bean in the application server deployed as a part of ifsapp.ear JEE application. For messages that have to be processed sequentially Oracle WebLogic Unit Of Order concept is used.

Note: Please note that if upgrading from IFS Applications 8 (or earlier) the old Batch Server needs to be stopped and removed. Read more about Removing Batch Server.

Application Message Flow

Whenever a new application message is created with state ‘Released’ or state of an existing massage has been changed to 'Released', a JMS message containing the ApplicationMessageId of the created/modified application message is posted by a database trigger on a JMS queue with a persistent store. The trigger changes also state of the message to 'Processing'. A Message Driven Bean (MDB) subscribing to this JMS queue is processing messages posted on this queue.

Application messages are always belong to a Message Queue (do not mix up JMS queues and message queues; read more about Message Queues). Message Queues can have different Execution Modes. For Execution Mode InOrder the above flow is slightly different. Because the messages in such queue have to be executed in strict order, the database trigger only sends a JMS message containing the Message Queue name remaining the state of the message unchanged (i.e. 'Released'). The purpose of the JMS message is only to notify the Batch Processor about existence of new application messages in the queue. The MDB is then selecting all candidates for execution and start to process them one by one in the strict order. The state of a message is changed to 'Processing' first when processing of the message has been trigged. The MDB will not process any messages if the queue is stopped or there are failed messages (which will cause the queue to be stopped).

With other words the meaning of the 'Processing' state is that the processing of the particular message has been started, which can occur already in the trigger (non InOrder queue) or first in Batch Processor (InOrder queue).

A successfully executed message will get its state changed to 'Finished' (or ‘Waiting’ for scheduled job – see chapter Scheduled Tasks below). All address lines on such message will then get state 'Transferred'.

Execution of an address line can fail in two ways: temporary or definitive failure.

A temporary failure sets address line state to 'Retry', sets a retry counter on the address line to the value specified on corresponding Connect Sender configuration (on first failure) or decreases with one, creates a one-time scheduled task that will change message state to 'Released' after a period of time specified on the Connect Sender configuration and finally sets the state of the entire message to 'Waiting'. If there are several address lines ending up in state ‘Retry’, only one scheduled task will be created with the closest execution time. The creation of the task can be affected by the background job definition – see Scheduled Tasks below.

A permanent failure sets address line state to 'Failed' and will cause the state of message to be eventually set to 'Failed' as well, but the logic will first try to resolve all address lines before setting the final state. No one-time scheduled task will be created for messages ending up in state ‘Failed’.

With other words as long as there are address lines with state 'Retry', the state of message will be 'Waiting'. If at least one address line will be in state 'Failed', the entire message will eventually also be marked as 'Failed'.

States

Application Message

An Application Message can have following states:

• Released – the initial state
• Processing – message has been picked up by the trigger or Batch Processor (depending on Execution Mode)
• Finished – message has been successfully processed
• Waiting – address execution has temporarily failed and be retried or there is a scheduled task that will trig more executions.
• Failed – message/address execution has permanently failed
• Canceled – message execution manually cancelled
• Suspended – message execution suspended

State ‘Canceled’ can only be entered manually in the client application.
A message created in a stopped, non InOrder queue will get state ‘Suspended’. A message created in a stopped InOrder queue will remain in state 'Released'.
It is also possible to temporarily suspend a message manually in the client application.

Address Line

An address line (Address Label) can have following states:

• Released – initial state
• Transferred – successfully processed address line
• Retry – address execution has temporarily failed and be retried
• Failed – address execution has permanently failed

Execution Steps

Message processing can be trigged in the background from the MDB or directly, from SOAP Gateway. In the first case the message to be processed is in state 'Processing' while in the second case the massage has not been persisted yet and is in state 'Released'.

Batch Processor performs following steps on an Application Message:

1. If there is a BizAPI defined, executes the BizAPI (outbound messages).
2. If there are no address lines, calls the Message Router.
3. In a loop process over all address lines in state ‘Released’ if the process has been initiated by the MDB (message in state 'Processing') or if it is a synchronous message (message in state 'Released' called from SOAP Gateway).
4. If necessary create a one-time scheduled task (if any of address lines ended in state ‘Retry’ and there is no other scheduled task that would execute before this one).
5. Set the final message state, which can be one of ‘Finished’, ‘Failed’ or ‘Waiting’.
6. Save the message (read about persisting synchronous messages)

There are two types of messages: inbound and outbound. Batch Processor doesn't make any difference between these two types. The only reason why the Application Message if stamped with the type flag is because of grouping of routing rules per type.

Actions on Application Message

Following actions can be performed on an Application Message in the client application:

• Reroute – removes all address lines with corresponding reply message bodies and creates new ones by rerouting the message and changes state to ‘Released’; can only be executed on messages in state ‘Failed’ and 'Released'. Message queues of those messages should be stopped.
• Restart all – sets state of all address lines and the message itself to 'Released' and removes all reply message bodies; can be executed on messages in states ‘Failed’ and ‘Canceled’
• Restart failed – sets state of failed address lines and the message itself to 'Released'; can be executed on messages in states ‘Failed’ and ‘Canceled’
• Duplicate & Release – duplicates a finished message without its address lines and reply message bodies; can only be executed on messages in state ‘Finished’
• Resume – changes message state from ‘Suspended’ to ‘Released’
• Suspend – sets message state to ‘Suspended’; can only be executed on messages in state ‘Waiting’
• Cancel – sets message state to ‘Canceled’; can be executed on messages in states ‘Failed’, ‘Waiting’ and ‘Suspended’.

Message Bodies

Typically an application message has one message body with input data. Processing of address lines will cause creation of a new message body for each successfully executed address line with response from the corresponding Connect Sender (a reply body). Attribute AddressSeqNo on Message Body points out the corresponding address line (AddressLabel.SeqNo).

In some circumstances, for example some messages created from the printing framework, the message can contain several bodies with input data, but only one body is the “main” one. The other bodies are collected as “attachments” to the corresponding Connect Sender that can handle such, typically Mail Sender.

Scheduled Tasks

A scheduled task is controlled by a database scheduler. A scheduled task in the database will periodically change the state of corresponding Application Message from ‘Waiting’ to 'Released' according to the specified agenda. It will also set state of address lines to ‘Released’ and remove reply message bodies.

The scheduled task knows if there will be more iterations or not and sets the Application Message attribute NextState to ‘Finished’ or ‘Waiting’ depending on this information. It will also set the next execution time, if any, on the message. This information is important if any of the address lines ends up in state ‘Retry’ – a “one-time” scheduled task, as described in the Application Message Flow section above, will only be created if it will start before the next execution time according to the schedule scheme.
An ordinary scheduled task will change state of all address lines to ‘Released’, while a one-time task will change state of only those address lines that are in state ‘Retry’.

If the message execution fails, the final state will be set to ‘Failed’ anyway – it can be caused by an un-repairable failure, e.g. configuration error, and will require investigation. Consequently the background job will be stopped.

Database Triggers

Following triggers are defined in the database as a part of Batch Processor solution: