2 Job Scheduling

This topic describes the job scheduling process.

Job scheduling is the process where different tasks get executed at a pre-determined time or when the right event happens. A job scheduler is a system that can be integrated with other software systems to execute or notify other software components when a pre-determined, scheduled time arrives. The two types of job schedulers used in Oracle FLEXCUBE Universal Banking FCJ architecture are as follows:
  • Quartz - Provides a scheduler interface to enable operations such as scheduling and unscheduling of jobs and starting, stopping, and pausing the scheduler
  • Flux - Software component used for performing enterprise job scheduling

Defining Jobs

Refer to the topic unresolvable-reference.html#GUID-12719C11-64E0-44E2-9945-216AB701004A for detailed information.

Scheduling Jobs

All jobs for scheduling are stored in a static data store and each job is associated with a name indicating where the job has to execute. Jobs are created in the application server and are scheduled based on this data.

Note:

The Job Name must be unique across the schedulers available in the system.
When the application server starts, the job details from the static data store will get cached. These cached jobs will then be scheduled using either the quartz or flux scheduler. For example, the notification process can be handled by the job schedulers as follows:
  1. When a contract is created in Oracle FLEXCUBE Universal Banking, a database level trigger acting on the contract main table inserts details like base table name, primary key fields, primary key values, and branch code into a notification log table and sets the process status of the inserted record as U (Unprocessed).
  2. The scheduled job polls the notification log table for unprocessed records and validates whether notification is required.
  3. If notification is not required, then the process status is set to N (Not Required) in the notification log table.
  4. If notification is required then notifications are sent to the respective destination and the process status of the record is changed to P (Processed) in the notification log table.

Controlling Jobs

Refer to the topic unresolvable-reference.html#GUID-12CD93FB-84E6-4A8B-A698-644ED5200784 for detailed information.

Notification Process

The notification process is in two layers. In the first layer, the notification process as part of jobs in the FCJ scheduler sends minimal data required for notification to an internal JMS queue. In the second layer, the notification process is part of an MDB that listens to the internal JMS queue builds final notifications and sends them to their intended destinations. The notification process in Oracle FLEXCUBE Universal Banking using the jobs scheduler is as follows:
  1. The trigger on the base table inserts key details into a static notification log table instead of Oracle AQ.
  2. Once the Job is triggered, a request is sent to the EJB layer from the job execution class and the notification log table is polled for unprocessed records.
  3. Each unprocessed record is locked.
  4. The record is verified against the notification maintenance and checked whether the notification is to be sent or not.
  5. If a notification is to be sent, pre-notification message XML is built and it is sent to internal notify_queue(JMS queue).
  6. The job is then rescheduled to fire next time based on the previous execution.
The notification process in MDB is as follows:
  1. The Notification MDB listens on the internal notify JMS queue.
  2. On any message received, the MDB identifies which schema to connect using the JNDI name being present as part of the message XML.
  3. The Gateway notification processing package is called from MDB to build the actual notifications.
  4. In MDB the notifications built are processed and sent to the destination specified in the corresponding notification.
  5. In case of any exception, the whole transaction is rolled back.
  6. If all notifications are successfully processed then the transaction is committed.
The flow chart of the notification process in Scheduler:

Figure 2-1 Notification Process in Scheduler


Description of Figure 2-1 follows
Description of "Figure 2-1 Notification Process in Scheduler"

The flow chart of the notification process in MDB:

Figure 2-2 Notification Process in MDB


Description of Figure 2-2 follows
Description of "Figure 2-2 Notification Process in MDB"

Viewing Notification Parameters

Refer to the topic unresolvable-reference.html#GUID-2C602EAC-E4FD-4441-8188-27DBA231FB0C for detailed information.

EMS Process with Scheduling Architecture

  • Incoming EMS Process

    A job is scheduled to poll the incoming folder on a timely basis. Once a message is received in the folder, the job picks the message and sends it to an internal JMS queue. An MDB listening in the queue will read the message and identifies the media and process the message.

  • Outgoing EMS Process

    A job is scheduled to poll the outgoing messages that are generated but not handed off. Each message polled will be sent to an internal JMS queue. An MDB, acting upon the internal JMS queue will pick the message from the queue and sends the message to the appropriate destination (Folder, e-mail, or JMS queue).

Approach

The Outgoing EMS Process happens in two layers. The EMS process as part of jobs in the FCJ scheduler polls the outgoing message table of Oracle FLEXCUBE Universal Banking for generated and un-send messages. The job then sends minimal data about the message to be handed off, to an internal JMS queue. The EMS process as part of an MDB that listens to the internal JMS queue to build the final message and to send to their intended destinations.

The Incoming EMS process happens in two layers. The EMS process as part of jobs in the FCJ scheduler, which polls the pre-configured folder for messages and sends the messages read, to the EMS internal queue. The EMS process as part of an MDB, that listens to the internal JMS queue identifies the message from the queue and calls the incoming messages service package in the backend to process the message. Additionally, the MDB can be made an independent unit to listen on external JMS to process incoming messages.

The Incoming EMS process as part of the jobs scheduler is as follows:
  1. Once the job is triggered, it polls for messages in a folder (Configured for Incoming messages).
  2. Each message is then sent to an internal JMS queue.
  3. The job is then rescheduled to fire next time.
EMS processes in MDB are as follows:
  1. An MDB that listens on the internal EMS incoming queue will receive the message.
  2. The media details are identified and the incoming message processing package in the backend is called to process the message.
  3. In case of any exception, while processing, the message will be sent to a deferred queue.
  4. In case of messages directly arrive in the JMS queue instead of a folder; the same MDB will be configured to listen on a specific queue.