SOA Suite 12c: Invoke Enterprise Scheduler Service from a BPEL process to submit a job request image130

SOA Suite 12c: Invoke Enterprise Scheduler Service from a BPEL process to submit a job request

The Fusion Middleware 12.1.3 platform contains the ESS or Enterprise Scheduler Service. This service can be used as an asynchronous, schedule based job orchestrator. It can execute jobs that are Operating System jobs, Java calls (local Java or EJB), PL/SQL calls, and Web Service calls (synchronous, asynchronous and one-way) including SOA composite, Service Bus and ADF BC web services.

Jobs and schedules can be defined from client applications through a  Java API or through the Enterprise Manager FMW Control user interface. Additionally, ESS exposes a web service through which (pre defined) jobs can be scheduled. This web service can be invoked from BPEL processes in SOA composites. In this article I will briefly demonstrate how to do the latter: submit a request to the Enterprise Scheduler Service to execute a job according to a specified schedule.

Because the job cannot be executed anonymously, the ESS Scheduler Service has an attached WSM policy to enforce credentials to be passed in. As a consequence, the SOA composite that invokes the service needs to have a WSM policy attached to the reference binding for the ESS Service in order to provide those required credentials. This article explains how to do that.

Steps:

  • Preparation: create an ESS Job Definition and a Schedule – in my example these are SendFlightUpdateNotification (which invokes a SOA composite to send an email) and Every5Minutes
  • Ensure that the ESS Scheduler Web Service has a WSM security policy attached to enforce authentication details to be provided (see description in this article: FMW 12.1.3 – Invoking Enterprise Scheduler Service Web Services from SoapUI)
  • Create a SOA composite application with a one way BPEL process exposed as a SOAP Web Service
  • Add a Schedule Job activity to the BPEL process and configure it to request the SendFlightUpdateNotification according to the Every5Minutes schedule; pass the input to the BPEL process as the application property for the job
  • Set a WSDL URL for a concrete WSDL – instead of the abstract one that is configured by default for the ESS Service
  • Attach a WSM security policy to the Reference Binding for the ESS Scheduler Web Service
  • Configure username and password as properties in composite.xml file – to provide the authentication details used by the policy and passed in security headers
  • Deploy and Test

 

Preparation: create an ESS Job Definition and a Schedule

in my example these are SendFlightUpdateNotification (which invokes a SOA composite to send an email)

image

and Every5Minutes

image

 

Ensure that the ESS Scheduler Web Service has a WSM security policy attached

to enforce authentication details to be provided (see description in this article: FMW 12.1.3 – Invoking Enterprise Scheduler Service Web Services from SoapUI)

image

Create a SOA composite application

with a one way BPEL process exposed as a SOAP Web Service

image

Add a Schedule Job activity to the BPEL process

image

and configure it to request the SendFlightUpdateNotification according to the Every5Minutes schedule;

image

image

Leave open the start time and end time (these are inherited now from the schedule)

SNAGHTML62b8333

Open the tab application properties.

SNAGHTML62bc65a
Here we can override the default values for Job application properties with values taken for example from the BPEL process instance variables:

image

SNAGHTML62ce36c

 

note: in order to select the Job and Schedule, you need to create a database MDS connection to the MDS partition with the ESS User Meta Data

SNAGHTML62abfb6

 

When you close the Schedule Job definition, you will probably see this warning:

image

Click OK to acknowledge the message. We will soon replace the WSDL URL on the reference binding to correct this problem.

The BPEL process now looks like this:

image

Set a concrete WSDL URL on the Reference Binding for the ESS Service

Get hold of the URL for the WSDL for the live ESS Web Service.

image

image

image

image

Then right click the ESS Service Reference Binding and select Edit from the menu. Set the WSDL URL in the field in the Update Reference dialog.

 

image

Attach a WSM security policy to the Reference Binding for the ESS Scheduler Web Service

Because the ESS Scheduler Web Service is protected by a WSM Security Policy, it requires callers to pass the appropriate WS Security Header. We can simply attach a WSM policy [of our own] to achieve that effect. We can even do so through EM FMW Control, in the run time environment, rather than right here at design time. But this time we will go for the design time, developer route.

Right click the EssService reference binding. Select Configure SOA WS Policies | For Request from the menu.

image

The dialog for configuring SOA WS Policies appears. Click on the plus icon for the Security category. From the list of security policies, select oracle/wss_username_token_client_policy. Then press OK.

image

The policy is attached to the reference binding.

SNAGHTML66e5071

Press OK again.

What we have configured at this point will cause the OWSM framework to intercept the call from our SOA composite to the EssService and inject WS Security policies into it. Or at least, that is what it would like to do. But the policy framework needs access to credentials to put in the WS Security header. The normal approach with this is for the policy framework to inspect the configured credential store for the username and password to use. The default credential store is called basic.credentials,  but you can specify on the policy that it should a different credential store. See this article for more details: http://biemond.blogspot.nl/2010/08/http-basic-authentication-with-soa.html .

There is a short cut however, that we will use here. Instead of using a credential store, our security policy can also simply use a username and password that are configured as properties on the reference binding to which the policy is attached. For the purpose of this article, that is far more convenient.

Click on the reference binding once more. Locate the section Composite Properties | Binding Properties in the properties palette, as shown here.

image

Click on the green plus icon to add a new property. Its name is oracle.webservices.auth.username and the value is for example weblogic. Then add a second property, called oracle.webservices.auth.password and set its value:

SNAGHTML6760e82

You will notice that these two properties are not displayed in the property palette. However annoying that is, it is not a problem: the properties are added to the composite.xml file all the same:

image

Deploy and Test

The work is done. Time to deploy the SOA composite to the run time.

Then invoke the service it exposes:

image

Wait for the response

image

and inspect the audit trail:

image

When we drill down into the flow trace and inspect the BPEL audit details, we will find the response from the ESS service – that contains the request identifier:

image

At this point apparently a successful job request submission has taken place with ESS. Let’s check in the ESS console:

image

Job request 605 has spawned 606 that is currently waiting:

image

A little later, the job request 606 is executed:

image

We can inspect the flow trace that was the result of this job execution:

image

Note that there no link with the original SOA composite that invoked the scheduler service to start the job that now result in this second SOA composite instance.

After making two calls to the SOA composite that makes the call to the scheduler and waiting a little, the effects are visible of a job that executes every five minutes (and that is started twice):

image

2 Comments

  1. Francesco Savino July 8, 2016
  2. gargvivek2008 September 19, 2014