DB-to-JMS works by intercepting messages sent to the IBM Cúram Social Program Management JMS queues in batch processing mode, and instead writing them to a database table. This means that the standard transactional behavior of messages (they are not delivered until the originating transaction completes) is maintained. Once the batch program transaction has been committed1, the application server must be triggered to transfer the messages from the database table to their JMS queue(s).
The application server can be triggered by a call from within the application server, or by a call from a source outside the application server i.e. from the Batch Launcher or a batch program. The call from outside the application server consists of a single HTTP/HTTPS request which is handled by a servlet deployed in the server. This means that the external source must know the host name of the application server and the port number. This information is specified using application properties which are detailed below.
The application server does not need to be running in order for batch programs to use workflow or deferred processes. However it does need to be running in order to trigger the transfer of messages from the database table to the JMS queue(s).
This triggering can be performed in a number of ways:
Depending on how this property is configured, this means that the application server must be running when a batch job completes execution, or when the batch launcher finishes processing all queued batch jobs.
Any work completed by the batch program must be committed and the application server must be running at the time of calling this method.
Since this is an online program, the application server is guaranteed to be already running and will therefore be capable of being triggered.
Once the application server has been triggered, it will start a deferred process to transfer all messages from the database table to their target queues. To ensure that the deferred process does not take too long and cause a transaction timeout when processing a large number of messages, it will only process a fixed number of messages per transaction. If, at the end of the transaction there are still messages remaining, it will automatically start another deferred process to handle these, and so on. The optimal number of messages which can be processed within the duration of an EJB transaction is dependent on many factors such as hardware configuration, machine load, etc and is therefore specified by means of an application property: curam.batchlauncher.dbtojms.messagespertransaction. If server tracing is switched on, messages will be written to the server log showing the activities of the DB-to-JMS transactions complete with timings, which can be used to determine the optimal number of messages per transaction.
Only one triggering is required to cause all messages to be processed. Multiple triggering will result in multiple threads attempting to convert the same records which is harmless apart from wasting resources. In the event of a two threads attempting to process the same message, one of the threads will proceed, the other will skip (or back-off from) the record and, if tracing is enabled, a message will be written to the application log to this effect.