Batch Processor is a part of
IFS Connect framework responsible for
background 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-int.ear JEE application.
Note:
As of patch 145612 (available within Update 5) a simplified version of Batch Processor containing only one JMS Queue,
InvokeQueue, and one JMS Topic, AdminTopic, is also deployed as a part of
the ifsapp-main.ear
application. See also
Invoking Outbound Messages.
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.
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 an AQ JMS queue with a persistent store. For In-Parallel message the trigger changes also state of the message to 'Processing'.
Database triggers on configuration tables also post JMS messages to the same AQ JMS queue signaling configuration changes.
A Message Driven Bean (Forwarder MDB) subscribing to this JMS queue is processing messages posted on this queue. Depending on the type of received message the Forwarder MDB is forwarding the JMS message to another JMS queue or topic. Processing of single Application Message is performed by the Message Processor, which is called through an EJB, FndConnectHandler, in a separate transaction.
Purpose of JMS queues and topics:
DEFAULT Message Queue.Note: Behavior of all MDBs (Message Driven Beans) can be controlled by Work Managers.
The JMS flow for In-Order and In-Sequence messages is slightly different. The database
trigger doesn't change the state leaving the Application Message in state
'Released'. The JMS message sent by the trigger contains also the
Message Queue name, so Batch Processor knows the type of the queue. If the queue is an In-Order queue then the
Batch Processor will execute all application messages in state 'Released'
posted to this Message Queue in a loop sorted by ApplicationMessageId.
For In-Sequence messages Batch Processor will process up to a
number of messages defined by the THREAD_COUNT parameter at time,
but any particular order is not guaranteed (read more about how to
Configure Message Queues).
Once a single message is picked up for execution, it's state is changed to
'Processing'. The message is then saved before calling Message Processor.
Note: A failed message (in state 'Failed') in an In-Order queue will automatically stop the queue. If the message processing is finished with state 'Waiting', the Batch Processor will not stop the queue, but will not continue with other messages until the current one is finally processed, i.e. in state 'Finished' or 'Failed'.
Note:
If message processing in an In-Sequence queue is finished with state 'Waiting',
the Message Processor will create one-time scheduled task for this
message and continue with the next one. The postponed message will be processed
by Batch Processor again later on according to values of MAX_RETRIES and
RETRY_INTERVAL parameters on the actual Connect Sender.
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, 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.
Following triggers are defined in the database as a part of Batch Processor solution:
|
Trigger |
Database Table |
Description |
|---|---|---|
| Application_Message_Jms_TR | FNDCN_APPLICATION_MESSAGE_TAB | Sends a JMS message if message state is Released Changes message state to Processing (for In-Parallel) |
| Print_Job_TR | PRINT_JOB_TAB | Creates new Application Message using Task Template |
| Out_Message_TR | OUT_MESSAGE_TAB | Creates new Application Message using Task Template |
| Config_Parameter_Detail_Jms_TR | FNDCN_CONFIG_PARAM_DET_TAB |
Changed
Task Template Releases jobs/messages (JMS message) |
| Config_Parameter_Jms_TR | FNDCN_CONFIG_PARAM_TAB |
Clears configuration cache (JMS message) Stops/restarts queues (JMS message) |
| Config_Param_Distinct_Jms_TR | CONFIG_PARAM_DISTINCT_JMS_TAB | Limit duplicated JMS messages |