Background Jobs

[HAETSE: Too much information. Split into more detailed concepts.]

Executing methods in the application core tier is often performed in direct response to user activities. It is also common however, that larger jobs are submitted to be executed without any need for direct user interaction. The mechanisms utilized in the Application Core tier and provided by Foundation1 are described on this page.

Contents

• Dbms Scheduler
• Background Jobs
• Scheduled Tasks
• The relationship between the scheduler, background jobs and schedules
• Batch Queues
• Security

Dbms_Scheduler

Oracle’s way of managing background jobs is to register them first as programs and then schedule them as jobs, through the system service dbms_scheduler. This Oracle feature is mainly known as the scheduler, so when we talk about the scheduler we refer to Oracle’s concept for background jobs. If setting the initialization parameter job_queue_processes to 10, then the database can start up till 10 SNP processes (if needed) that execute jobs scheduled in dbms_scheduler. IFS Applications uses the scheduler to execute its own background jobs and scheduled tasks through the system services Batch_SYS and Transaction_SYS.

Batch_SYS holds an API for submitting IFS Applications (or Foundation1's) driving processes into dbms_scheduler through New_Job.

Background Jobs

In IFS Applications the concept for executing server methods in the background without any contact with the client, is simply called Background jobs. The reasons for running server methods in the background are many, for example the server job may take a long time to complete, the load and the things the job does may require executing in off-peak hours, and the user may want to do something else while the server job executes.

Transactions_SYS holds an API for submitting background jobs into Batch Queues through Deferred_Call.

Schedules

Schedules are a special type of background job. A new background job is submitted every time a schedule has passed its next execution date. This background job is executed like any other background job and ends up in the background job log. Schedules lets the server run the scheduled job after a predefined execution plan. To be able to schedule a task you must define a task or a chain in the schedule task repository. When the stop date is passed, a schedule is complete. If no stop date exists, the schedule will remain active forever, unless you manually deactivate it.

Batch_SYS holds an API for registering and scheduling Scheduled Tasks through Register_Batch_Schedule_Method, Register_Batch_Schedule_Chain  and New_Batch_Schedule.

Schedules are divided into three groups:

• Scheduled Tasks
  These are normal background jobs without any printed output
• Scheduled Chains
  This is one or more background jobs running in sequence, with a possibility to stop the chain if one step goes wrong.
• Scheduled Reports
  These are scheduled operational reports that produce report output

The relationship between the scheduler, background jobs and schedules

• The scheduler (Dbms_Scheduler) should be used for processes that drive IFS Applications. An example of such a process is the Data Archiving process that checks for Data Archive Objects to file to the archive. It is only the framework Foundation1 that should create such processes.
• Background Jobs are intended to be executed once, as soon as possible, so that an end-user can do something else while the background job finishes.
• Schedules are intended to execute once or more at a specified time. End users can check the result of a schedule when the job has finished. When a schedule is executing it is considered to be instantiated as a background job.

Batch Queues

The main purpose of Batch Queues is to spread the job load, mainly between different Batch Queues which means between different scheduler processes.

When you initiate a Batch Queue, a job called Transaction_SYS.Process_All_Pending is submitted into the scheduler. This scheduler job executes all background jobs that match the criteria for the Background Queue.

When defining a Batch Queue, an execution plan has to be set up; that is specifying the number of processes, the language and if necessary, server methods to execute. The number of processes determines how many Batch Queue processes should be possible to start for the scheduler for this queue. The language is used to be able to execute language dependent background jobs in different queues. The method name is used to determine in which queue the submitted background job should be executed. If the method isn’t registered in any Batch Queue it will be registered in the Batch Queue chosen the first time it is executed.

Also remember that if you want jobs to be executed sequentially per Batch Queue you can't have more than one process per Batch Queue.

The parameter in Oracle Server (JOB_QUEUE_PROCESSES in Init.ora) must be increased to get full use of multithreaded batch queues, e.g. this Oracle parameter should not be lower than the total number of processes for all active queues in the system. Too many activated processes can use a great amount of server memory and processor resources.
The relation between the scheduler and JOB_QUEUE_PROCESSES is a bit hard to understand, you can read more about the relationship here.

Security

A user can only see the background jobs that the user has submitted, except users that have been granted System Privilege ADMINISTRATOR.

Only server methods granted to the user are available for the user to schedule as a task.

Schematic view of jobs and queues

Oracle SNP Processes were originally created for replication purposes and SNP stands for Snapshot. SNP processes are used more in a general sense today.