Job scheduling is the process where different tasks get executed atpre-determined time or when the right event happens. A job scheduleris a system that can be integrated with other software systems for thepurpose of executing or notifying other software components when a pre-determined,scheduled time arrives. The two types of job schedulers used in OracleFLEXCUBE FCJ architecture are as follows:
- Quartz - provides scheduler interface to enable operations such asscheduling and un-scheduling of jobs and starting, stopping, pausingthe scheduler
- Flux - software component used for performing enterprise job scheduling
This chapter contains the following sections
- Section 2.1, "Defining Jobs"
- Section 2.2, "Scheduling Jobs"
- Section 2.3, "Controlling Jobs"
- Section 2.4, "Notification Process"
- Section 2.5, "Viewing Notification Parameters"
- Section 2.6, "EMS Process with Scheduling Architecture"
- Section 2.7, "Approach"
2.1 Defining Jobs
A job is a business activity which the system performs repeatedlyon timely basis. Oracle FLEXCUBE enables you to define a job and scheduleit using ‘Job Maintenance’ screen. You can invoke this screenby typing ‘STDJOBMT’ in the field at the top right cornerof the Application tool bar and clicking on the adjoining arrow button.
You can specify thefollowing fields in this screen.
Job Code
Specify the unique code to identify the Job.
Job Description
Specify a brief description of what the job is supposed to do.
Job Group
Specify the job group name to represent the same group of jobs foridentification.
Job Type
Select the type of job from the drop-down list. The following optionsare available for selection:
- PL/SQL
- JAVA
Max Number Instances
Specify the maximum number of instances that needs to be queued up.
Example
If a job runs for more than the duration defined, the next instanceof the same job will be ready for processing. This parameter definesthe job’s behavior in such cases,
If you maintain the job as ‘STATEFUL’, then the numberof such missed instances will be queued up so that it would start executingonce this long running job ends. This field specifies the number of suchjob instances that needs to be queued up.
If you maintain the job as ‘STATELESS’, it indicates thenumber of threads that can be executed in parallel.
If you maintain the max number instances as ‘0’,no instancesare queued or parallel processed till the current running instance iscompleted.
Scheduler
Specify the name of the scheduler. The system defaults the name to‘SchedulerFactory’. However, you can modify this name. Thissignifies the scheduler name which is configured as part of infra.
Trigger Type
Select the type of the trigger from the drop-down list. The followingoptions are available:
- Simple - Interval based jobs.(i.e., every one hour)
- Cron - Time based jobs.(i.e., Friday 4:30PM)
Note
When scheduler trigger type is set to ‘CRON’,and the parameter is ‘TIMEZONE’, then the system triggersthe jobs based on the time zone set. If the ‘TIMEZONE’ propertyis not available, then the server time zone will be used to trigger thescheduler job.
Scheduler Type
Select the type of scheduler from the drop-down list. The followingoptions are available:
- Quartz
- Flux
Priority
Select the priority on which the system should execute the jobs inthe scheduler from the drop-down list. The following options are available.
- Normal
- High
If two jobs with different priorities fire at the same time, thensystem gives preference to the job with higher priority.
Message Queue
Specify the default JMS queue to which a job needs to send message.You can specify this only if the job has to send messages to JMS.
Cron Expression
Specify the corresponding Cron expression for a job with trigger typeas ‘Cron’. You need to do this to determine the time andinterval of job firing.
Class or Procedure
Specify the Java class file name if job type is ‘Java’or the PL/SQL procedure name if the job type is ‘PL/SQL’.This denotes which java class or pl/sql procedure the system should callwhen a job fires.
Number of Submissions
Specify the number of times a job can fire before it is unscheduledfrom scheduler. This applies only to trigger types maintained as ‘Simple’.
Interval
Specify the time interval between jobs. This applies only to triggertypes maintained as ‘Simple’.
Trigger Listener
Specify a java class as a trigger listener which will be notifiedof events such as before job fired, after job completed, misfired jobs.
Active
Check this box to set the job as active. The scheduler does not pickthe inactive jobs for scheduling.
Ds Name
Specify the name of the database schema to which the job has to connect.This attribute is used in case of multi instance deployment of OracleFLEXCUBE application.
Logging Required
Check this box to indicate that system should log each firing of job.This helps in logging the firing time of job and key log info as partof that firing. This also enables tracking of each job’s firingtimes and helps in identifying miss-fired jobs.
Startup Mode
Specify start up mode of the job from the drop-down list. The followingoptions are available:
- Auto - The job starts automatically when Oracle FLEXCUBE applicationstarts
- Manual - You should start the job manually in job controller by resumingthe job.
Parameter Details
You can specify the job specific parameters, which are passed to jobclass or procedure at runtime. The following details are captured here:
Parameter Name
Specify the name of the job parameter. The parameter name you specifyhere is passed to job class or procedure at run time.
Data Type
Specify the data type of the parameter.
Parameter Value
Specify the value of the parameter.
2.2 Scheduling Jobs
All jobs for scheduling are stored in a static data store and eachjob is associated with a name indicating where the job has to execute.Jobs are created in the Application Server and are scheduled based onthis data.
Note
The job name should be unique across the schedulersavailable in the system.
When the application server starts, the job details from static datastore will get cached. These cached jobs will then be scheduled usingeither the quartz or flux scheduler.
For example, the notification process can be handled by the job schedulersas follows:
- When a contract is created in Oracle FLEXCUBE, a databaselevel trigger acting on the contract main table inserts details likebase table name, primary key fields, primary key values and branch codeinto a notification log table and sets the process status of the insertedrecord as ‘U’ (unprocessed).
- The scheduled job polls the notification log table forunprocessed records and validates whether notification is required.
- If notification is not required, then the process statusis set to ‘N’ (not required) in notification log table.
- If notification is required then notifications are sentto the respective destination and the process status of the record ischanged to ‘P’ (Processed) in notification log table.
2.3 Controlling Jobs
The details of jobs that are scheduled can be viewed using the ‘JobDetails’ screen. In this screen you can pause or resume a job thathas been scheduled. You can submit the records as a job for replicationin the branch database through this screen. You can invoke the ‘JobDetails’ screen by typing ‘SMSJOBBR’ in the field at the top right cornerof the Application tool bar and clicking the adjoining arrow button.
You can search fora scheduled job by specifying any of the following:
Job Name
Select the name of the job that you want to search for from the optionlist provided.
State
Select the state of the job you want to search for from the optionlist provided. The following options are possible for Quartz schedulers:
- Acquired
- Waiting
- Blocked
- Paused
Scheduler
Select the scheduler to which the job you want to search for has beenassigned.
Job Group
Select the group to which the job you want to search for belongs,from the option list provided.
Next Fire Time
Select the time when the job is scheduled to be run next.
Click ‘Search’ button to view the details related to thejob. You can pause a job by selecting it and clicking the ‘Pause’button.
You can resume a paused job by clicking ‘Resume’ buttonand the job is scheduled for its next fire time.
A job can take any of the following states.
- SCHEDULED -This indicates that the message is processed.
- NOT SCHEDULED -This indicates that the message processing is notscheduled.
- PAUSED - This indicates that the job is manually paused from executing.
- ERROR - A job trigger arrives at the ‘Internal Server Error’state when the scheduler attempts to fire it, but cannot due to an errorcreating and executing its related job, hence pausing the job. Also,a job arrives at ERROR state for the following reasons.:
- When the associated class for the job is not present in class path
- If during setup, the queue has not been created, but a job has beencreated for that queue.
- If call to the Scheduler EJB has failed.
- If job related pooling tables are invalid.
Note
Each job is created with the location code maintainedin the table sttm_flexbranch_loc runs for the respective branch location.
If a new branch is added to the bank for branch replicationthen the application should be restarted to add that particular branchin the ‘Job Details’ screen.
2.4 Notification Process
The notification process is in two layers. In the first layer thenotification process as part of jobs in FCJ scheduler sends minimal datarequired for notification to an internal JMS queue. In the second layerthe notification process as part of an MDB that listens on internal JMSqueue builds final notifications and sends them to their intended destinations.
The Notification Process in Oracle FLEXCUBE using the jobs scheduleris as follows:
- The trigger on the base table inserts key details intoa static notification log table instead of Oracle AQ.
- Once Job is triggered, a request is sent to EJB layer fromjob execution class and the notification log table is polled for unprocessedrecords.
- Each unprocessed record is locked.
- The record is verified against the notification maintenanceand checked whether notification is to be sent or not.
- If notification is to be sent, pre notification messagexml is built and it is sent to internal notify_queue(JMS queue).
- The job is then rescheduled to fire next time based onthe previous execution.
The notification process in MDB is as follows:
- The Notification MDB listens on the internal notify JMSqueue.
- On any message received, the MDB identifies which schemato connect using the JNDI name being present as part of the message xml.
- Gateway notification processing package is called fromMDB in order to build the actual notifications.
- In MDB the notifications built is processed and sent tothe destination specified in corresponding notification.
- In case of any exception the whole transaction is rolledback.
- If all notifications are successfully processed then transactionis committed.
The flow chart of notification process in scheduler:
The flow chart for notification process in MDB:
2.5 Viewing Notification Parameters
You can view and amend certain notification parameters in Oracle FLEXCUBEusing ‘Gateway Notification Maintenance’ screen. You caninvoke this screen by typing ‘IFDNOTIF’ in the field at the top right cornerof the Application tool bar and clicking on the adjoining arrow button.
NotificationCode
The system displays a unique code to identify a notification.
Description
The system displays a brief description of the notification. However,you can modify the description in this screen.
Operation
Select the type of operation for the notification from the following.
- Insert - to indicate a new operation of notification function
- Update - To indicate a modification operation of notification
Gateway Operation
Specify the gateway operation name to execute query for the mentionedservice.
Gateway Service
Specify the gateway service to be used to get the full screen response.
IO Request Node
Specify the gateway IO request node to be used in querying operation.
Specific Notification
Check this box to indicate the system to send specific notification.The system handles any deviation from generic notification process bycreating specific triggers once you check this field.
Full Screen Reply Required
Check this box to indicate that the full screen notification responsehas to be sent. Otherwise, the primary key response notification is sent.
Head Office
Check this box to send notification only from head office.
2.6 EMS Process with Scheduling Architecture
2.6.1 EMS Process:
Incoming EMS Process
A job is scheduled to poll the incoming folder on timely basis. Oncea message is received in the folder, the job picks the message and sendsit to an internal JMS queue. An MDB listening on the queue will readthe message and identifies the media and processes the message.
Outgoing EMS Process
A job is scheduled to poll the outgoing messages that are generatedbut not handed off. Each messages polled will be sent to an internalJMS queue.
A MDB, acting upon the internal JMS queue will pick the message fromqueue and sends the message to appropriate destination (Folder, or e-mail,or JMS queue).
2.7 Approach
The Outgoing EMS Process happens in two layers.
The EMS process as part of jobs in FCJ scheduler, polls the outgoingmessage table of FLEXCUBE for generated and un-send messages. The jobthen sends minimal data about the message to be handed off, to an internalJMS queue.
The EMS process as part of an MDB that listens on internal JMS queueto build 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 FCJ scheduler, which polls thepre configured folder for messages and sends the messages read, to EMSinternal queue.
The EMS process as part of an MDB, that listens on internal JMS queueidentifies the message from queue and calls the incoming messages servicepackage in backend to process the message. Additionally, the MDB canbe made an independent unit to listen on external JMS to process incomingmessages.
The Incoming EMS Process as part of jobs scheduler is as follows:
Once job is triggered, it polls for messages in a folder (Configuredfor incoming messages).
Each message is then sent to an internal JMS queue.
The job is then rescheduled to fire next time.
EMS processes in MDB are as follows:
An MDB that listens on the internal EMS incoming queue will receivethe message.
The media details are identified and incoming message processing packagein backend is called to process the message.
In case of any exception while processing, message will be sent toa deferred queue.
In case of messages directly arrive to JMS queue instead of a folder;the same MDB will be configured to listen on specific queue.
