FMW 12.1.3 – Invoking Enterprise Scheduler Service Web Services from SoapUI

1
Share this on .. Tweet about this on TwitterShare on LinkedIn0Share on Facebook0Share on Google+1Email this to someoneShare on Tumblr0Buffer this page

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

image

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

image

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

image

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.

image

 

Click on OK to confirm this new policy attachment.

image

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:

image

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.

image

 

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:

SNAGHTML59dbff1

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.

image

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:

image

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.

image

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

image

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

image

Specify Password Text as the password type

SNAGHTML5abd94b

SoapUI will add the header to the message:

image

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

image

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

image

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:

 

image

 

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:

image

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

SNAGHTML5b0bcc7

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

image

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.

Share this on .. Tweet about this on TwitterShare on LinkedIn0Share on Facebook0Share on Google+1Email this to someoneShare on Tumblr0Buffer this page

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PL/SQL), Service Oriented Architecture, BPM, ADF, JavaScript, Java in various shapes and forms and many other things. Author of the Oracle Press books: Oracle SOA Suite 11g Handbook and Oracle SOA Suite 12c Handbook. Frequent presenter on conferences such as JavaOne and Oracle OpenWorld. Presenter for Oracle University Celebrity specials.

1 Comment

  1. Interesting and useful post!!
    I tried this in our DEV environment which is not clustered. It is working perfect. But in clustered environment, Status of WSM policies for this service is “Not Valid”. Could you please give some pointers to resolve this?

    Thanks,
    Ram

Leave a Reply