Batch Processor is based on Oracle Database Pipe concept using PL/SQL package DBMS_PIPE 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. In addition to these J2EE Timers are also used to read the application messages effeciently.
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.
JMS 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 BATCH_PROC_QUEUE_TAB. 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 table 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:
Used for asynchronous Application Messages posted to an In-Parallel Message Queue. A JMS message on this JMS queue will trig processing of the given Application Message.
Available as of patch 145612 (Update 5). Used for synchronous invocations from PLSQL Access Provider. Application Messages are always posted to the
Used for asynchronous Application Messages posted to an In-Order Message Queue. A JMS message on this JMS queue will start processing of all Application Messages from the given Message Queue. Application Messages will be processed according the Application Message ID and the Message Queue will be stopped on failure.
Used for asynchronous Application Messages posted to an In-Sequence Message Queue. A JMS message on this JMS queue will start processing of all Application Messages from the given Message Queue.
Used for administrative purpose by database triggers on configuration tables.
Used for administrative purpose by database triggers on configuration tables. Trigs clearing of configuration cache and synchronization of Connect Readers.
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
RETRY_INTERVALparameters 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:
|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|
|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|