The Enterprise Scheduler Service that is available in Fusion Middleware 12.1.3 supports a number of administration activities around the SOA Suite. We will look at one particular use case regarding environment management using the ESS. Suppose we have an inbound database adapter. Suppose we have created the PortalSlotRequestProcessor SOA composite that uses a database poller looking for new records in a certain table PORTAL_SLOT_ALLOCATIONS (this example comes from the Oracle SOA Suite 12c Handbook, Oracle Press). The polling frequency was set to once every 20 seconds. And that polling goes on and on for as long as the SOA composite remains deployed and active.

Imagine the situation where every day during a certain period, there is a substantial load on the SOA Suite, and we would prefer to reduce the resource usage from non-crucial processes. Further suppose that the slot allocation requests arriving from the portal are considered not urgent, for example because the business service level agreed with our account managers is that these requests have to be processed within 24 hours – rather than once every 20 seconds. We do not want to create a big batch, and whenever we can, we strive to implement straight through processing. But between 1 and 2 AM on every day, we would like to pause the inbound database adapter.

In this section, we will use the Enterprise Scheduler Service to achieve this. We will create the schedules that trigger at 1 AM every day, used for deactivating the adapter, and 2 AM, used for activating the adapter. In fact, in order to make testing more fun, we will use schedules that trigger at 10 past the hour and 30 past the hour. These schedules are then associated in the Enterprise Manager Fusion Middleware Control with the inbound database adapter binding PortalSlotRequestPoller.

Create Schedules

An ESS Schedule is used to describe either one or a series of moments in time. A schedule can be associated with one or many Job definitions to come to describe when those jobs should be executed. A recurring schedule has a frequency that describes how the moments in time are distributed over time. A recurring schedule can have a start time and an end time to specify the period during which the recurrence should take place.

To create the schedules that will govern the inbound database adapter, open the EM FMW Control and select the node Scheduling Services | ESSAPP. From the dropdown list at the top of the page, select Job Requests | Define Schedules, as is shown in this figur

Click on the icon to create a new schedule. Specify the name of the schedule as At10minPastTheHour. Set the display name to “10 minutes past each hour”. The schedule has to be created in the package [/oracle/apps/ess/custom/]soa. This is a requirement for schedules used for adapter activation.

Select the frequency as Hourly/Minute, Every 1 Hour(s) 0 Minute(s) and the start date as any date not too far in the future (or even in the past) with a time set to 10 minutes past any hour.

Note that using the button Customize Times, we can have a long list of moments in time generated and subsequently manually modify them if we have a need for some exceptions to the pattern.

Click on OK to save this schedule.

Create a second schedule called At30minPastTheHour. The definition is very similar to the previous one, except for the start time that should 30 minutes past some hour.

Click OK to save this schedule definition.

Note that more sophisticated recurrence schedules can be created through the Java API exposed by ESS as well as through the IDE support in JDeveloper. These options that allow specific week days or months to be included or excluded can currently not set set through the EM FMW Control.

Apply Schedules for Activation and Deactivation of Inbound Database Adapter

Select node SOA | soa-infra | default | PortalSlotRequestProcessor – the composite we created in the previous chapter. Under Services and References, click on the PortalSlotRequestPoller, the inbound database adapter binding.

The PortalSlotRequestProcessor appears. Click on the icon for adapter schedules.

In the Adapter Schedules popup that appears, we can select the schedule that is to be used for deactivating and for activating the adapter binding. Use the At10minPastTheHour schedule for deactivation and At30minPastTheHour for activation. Press Apply Schedules to confirm the new configuration.

From this moment on, the inbound database adapter binding that polls table PORTAL_SLOT_ALLOCATIONS is active only for 40 minutes during every hour, starting at 30 minutes past the hour.

For example, at 22:14, the binding is clearly not active.

Test switching off and on of Database Adapter binding

When the schedules for activation and deactivation have been applied, they are immediately in effect. You can test this in the Dashboard page for the inbound database adapter binding, as is shown here

Here we see how a single record was processed by the adapter binding, insert at 10:09PM. Four more records were inserted into table PORTAL_SLOT_ALLOCATIONS at 10:13 and 10:14. However, because the adapter binding is currently not active, so these records have not yet been processed.

At 30 minutes past the hour – 10:30 in this case – the adapter becomes active again and starts processing the records it will then find in the table. Because the adapter was configured to pass just a single record to a SOA composite and not process more than two records in a single transaction, it will take two polling cycles to process the four records that were inserted between 10:10 and 10:30. These figures illustrate this.

The SOA composite instances that are created for these four records retrieved in two poll cycles:

and the flow trace for the instance at 10:30:09 looks like this – processing two separate database records:

When you check in the ESS UI in EM FMW Control, you will find two new Job Definitions, generic Jobs for executing SOA Suite management stuff:

In the Job Requests overview, instances of these jobs appear, every hour one of each. And the details of these job requests specify which adapter binding in which composite is the target of the SOA administrative action performed by the job.