FMW 12.1.3 – Invoking Enterprise Scheduler Service Web Services from SoapUI

The Fusion Middleware 12.1.3 platform contains the ESS or Enterprise Scheduler Service. This service can be used as 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 – or from any component that knows how to invoke a SOAP Web Service.

In this article I will briefly demonstrate how to invoke the ESS Web Service from SoapUI. I will not describe how to create the Job Definition – I will assume two pre existing Job Definitions: HelloWorld (of type PL/SQL job) and SendFlightUpdateNotification of type SOA composite based one way Web Service. Both Job Definitions contain application properties – parameters that can be set for every job instance and that are used in the job execution. When invoking the ESS Web Service to schedule a job, values for these properties can be passed in.

There is one tricky aspect with ESS: jobs cannot be run as anonymous users. So if ESS does not know who makes the request for scheduling a job, it will not perform the request. It returns an error such as

oracle.as.scheduler.RuntimeServiceAccessControlException: ESS-02002 User anonymous does not have sufficient privilege to perform operation submitRequest JobDefinition://oracle/apps/ess/custom/saibot/SendFlightUpdateNotification.

To ensure we do not run into this problem, we have to attach a WSM security policy to the ESS Web Service and pass a WS Security Header with valid username and password in our request. Then the job request is made in the context of a validated user and this problem goes away.

The steps to go through:

• preparation: create Job definitions in ESS that subsequently can be requested for scheduled execution (not described in this article)
• attach the WSM policy oracle/wss_username_token_service_policy to the ESS Web Service
• retrieve the WSDL (address) for the ESS Web Service
• create a new SoapUI project based on the WSDL
• create a request for the submitRequest operation
• add WS Addressing headers to request
• add WS Security header to request
• run request and check the results – the response and the newly scheduled/executed job

Attach the WSM policy to the ESS Web Service

In EM FMW Control, click on the node for the Scheduling Service | ESSAPP on the relevant managed server. From the dropdown menu on the right side of the page, selection option Web Services

You will be taken to the Web Service overview page. Click on the link for the SchedulerServiceImplPort.

This brings you to another overview page for the SchedulerServiceImplPort. Open the tab labeled WSM Policies:

Click on the icon labeled Attach/Detach. Now you find yourself on the page where policies can be attached to this Web Service (port binding). Find the security policy oracle/wss_username_token_service_policy in the list of available policies. Click on the Attach button to attach this policy to the ESS Web Service.

 

Click on OK to confirm this new policy attachment.

At this point, the ESS Scheduler Service can only be invoked by parties that provide a valid username and password. As a result, the Web Service’s operations are executed in the context of a real user – just like job related operations performed through the EM FMW Control’s UI for ESS are or actions from a client application through the Java API.

Retrieve the WSDL (address) for the ESS Web Service

Click on the link for the WSDL Document SchedulerServiceImplPort:

The WSDL opens. We can see from the WSDL that the WS Security policy has been added. We will need the URL for this WSDL document to create the SoapUI project.

 

Create a new SoapUI project

Open SoapUI and create a new project. Set the address of the WSDL document that you retrieved in the previous step as the initial WSDL in this new project:

Edit the request for the submitRequest operation

The request to the submitRequest operation is the request that will cause a new Job Request to be created (and therefore a job to be executed, one or potentially many times). Open the request that was generated by SoapUI.

You need to provide the details for the predefined job that already exists in ESS, so ESS will know what to do in processing this request. In this example, I want to run the HelloWorld job from package /oracle/apps/ess/custom through the (out of the box installed) EssNativeHostingApp application. I also provide a value for the application property mytestIntProp:

All details have been provided in the request message itself. However, trying to submit this request will fail for two reasons: no security details (a WS Security header) are passed and no WS Addressing details are provided – and the ESS Web Service requires those as well.

Let’s add the security side of things.

In the request properties palette, provide the username and password for a valid user account; it is easiest to try this out with the administrator account, probably something like weblogic/weblogic1

Then, right click on the request message and click on the option Add WSS Username Token

Specify Password Text as the password type

SoapUI will add the header to the message:

When you now try again to submit the request, you will receive a fault regarding a WS Addressing header:

This is easily remedied. Click on the WS A tab at the bottom to the request pane:

The WS Addressing header properties palette is shown. Ensure that the checkbox for enabling WS-A addressing is checked and also that the checkbox Randomly generate MessageId is checked:

 

 

Now you can submit the request once more. And this time it will succeed. The response message indicates a successful submission of the job request, and it provides an identifier for that request:

In the EM FMW Control pages for ESS, we can inspect all job requests and locate our number 409:

We can drill down to find out more details about this job request and its execution:

Note the application property value that was passed in from SoapUI to override the default value specified in the Job definition.

Whatever the PL/SQL procedure is supposed to do, has been done by now.

Resources

Documentation on ESS Web Service: http://docs.oracle.com/middleware/1213/ess/ESSDG/webservice.htm.