Introduction
In many enterprise integration scenarios there is a requirement to initiate tasks at scheduled times or at user defined intervals. The Oracle Integration Cloud Service (ICS) provides scheduling functionality via the Oracle Enterprise Scheduler to satisfy these types of requirements. The Oracle Enterprise Scheduler Service (ESS) is primarily a Java EE application that provides time-based and schedule-based callbacks to other applications to run their jobs. Oracle ESS applications define jobs and specify when those jobs need to be executed and then gives these applications a callback at the scheduled time or when a particular event arrives. Oracle ESS does not execute the jobs itself, it generates a callback to the application and the application actually executes the job request. This implies that Oracle Enterprise Scheduler Service is not aware of the details of the job request; all the job request details are owned and managed by the application.
What follows will be a discussion as to how ICS utilizes the ESS feature. The document will cover how the ESS threads are allocated and the internal preparation completed for file processing.
Quick ICS Overview
The Integration Cloud Service deployment topology consists of one cluster. The cluster has two managed servers along with one administration server. This bit of information is relevant to the discussion of how the Enterprise Scheduler Service works and how it is used by applications like an ICS flow that runs in a clustered HA environment.
A common use case for leveraging ESS is to setup a schedule to poll for files on an FTP server at regular intervals. At the time files are found and then selected for processing, the ESS does some internal scheduling of these files to ensure the managed servers are not overloaded. Understanding how this file processing works and how throttling might be applied automatically is valuable information as you take advantage of this ICS feature.
An integration can be scheduled using the ICS scheduling user interface (UI). The UI provides a basic and an advanced option. The basic option provides UI controls to schedule when to execute the integration.
The advanced option allows one to enter an iCal expression for the scheduling of the integration.
The ESS allows for two jobs to be executed at a time per JVM. This equates to a maximum of four files being processed concurrently in a 2 instance ICS cluster. So how does ICS process these files, especially, if multiple integrations could pick up twenty-five files at a time?
As previously stated, there are two asynchronous worker resources per managed server. These asynchronous worker resources are known as an ICSFlowJob or AsyncBatchWorkerJob. At the scheduled time, the ESS reserves one of the asynchronous worker resources, if one is available. The initial asynchronous worker is the ICSFlowJob. This is what we call the parent job.
It is important to digress at this point to make mention of the database that backs the ICS product. The ICS product has a backing store of an Oracle database. This database hosts the metadata for the ICS integrations, BPEL instances that are created during the execution of orchestration flows, and the AsyncBatchWorker metadata. There is no need for the customer to maintain this database – no purging, tuning, or sizing. ICS will only keep three days of BPEL instances in the database. The purging is automatically handled by the ICS infrastructure.
The ICSFlowJob invokes the static ScheduledProcessFlow BPEL. This process does the file listing, creates batches with one file per batch, and submits AsyncBatchWorker jobs to process the files. The AsyncBatchWorker jobs are stored within a database table. These worker jobs will eventually be picked up by one of the two threads available to execute on the JVM. The graphic below demonstrates the parent and subprocess flows that have successfully completed.
Each scheduled integration will have at most ten batch workers (AsyncWorkerJob) created and stored within the database table. The batch workers will have one or more batches assigned. A batch is equivalent to one file. After the batch workers are submitted, the asynchronous worker resource, held by the ICSFlowJob, is released so it can be used by other requests.
Scenario One
- 1.One integration that is scheduled to run every 10 minutes
- 2.Ten files are placed on the FTP server location all with the same timestamp
At the scheduled time, the ICSFlowJob request is assigned one of the four available threads (from two JVMs) to begin the process of file listing and assigning the batches. In the database there will be ten rows stored, since there are ten files. Each row will reference a file for processing. These batches will be processed at a maximum of four at a time. Recall that there are only two threads per JVM for processing batches.
At the conclusion of processing all of the AsyncWorkerJob subrequests one of the batch processing threads notifies the parent request, ICSFlowJob, that all of the subrequests have completed.
Scenario Two
- 1. Two Integrations are scheduled to run every 10 minutes
- 2. There are 25 files, per integration, at each integration’s specified FTP server location
This scenario will behave just as in scenario one; however, since each integration has more than ten files to process, the subrequests, AsyncWorkerJob, must each process more than one file. Each integration will assign and schedule the file processing as follows:
5 AsyncWorkerJob subrequests will process 2 files each
5 AsyncWorkerJob subrequests will process 3 files each
At the conclusion of the assignment and scheduling of the AsyncWorkerJob subrequests there will be 20 rows in the database; 10 rows per integration.
The execution of the AsyncWorkJobs is based upon a first-come first-serve basis. Therefore, the 20 subrequests will more than likely be interleaved between each other and the processing of all of the files will take longer than if the integrations had not been kicked off at the same time. The number of scheduler threads to process the batch integrations does not change. There will only be a maximum of two scheduler threads per JVM.
Summary
The ESS scheduler provides useful features for having batch processes kicked off at scheduled intervals. These intervals are user defined providing great flexibility as to when to execute these batch jobs. However, care must be taken to prevent batch jobs from consuming all of the system resources, especially when there are real-time integrations being run through this same system.
The Integration Cloud Service has a built in feature to prevent batch jobs from overwhelming the service. This is done by only allowing two scheduler threads to process files at a time per JVM. This may mean that some batch integrations take longer; however, it prevents the system from being overwhelmed and negatively impacting other ICS flows not related to batch file processing with the ESS.
As we have discussed in this article, the use case here is all about polling for files that ICS needs to process at specified times or intervals; however, the ESS may also be used to trigger integrations such as REST and SOAP-based web services. When using ESS to initiate file processing, the system is limited to two scheduler threads per JVM.
The polling approach may not always be the best approach, since the delivery of the file may not be on a regularly scheduled cycle. When the delivery of the file, from the source, is not on a regular schedule then it is probably better to implement a push model. In a coming blog, I will demonstrate how to implement the push model. With the push model the system is no longer under the constraints of the two scheduler threads per JVM.
To learn more about the Enterprise Service Scheduler one should reference the Oracle documentation.
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission