By Greg Jensen on Jul 30, 2014
This is part 2 of a 2 part series. In part 1, we discussed developing these web service wrappers and handling security for both the OIM credentials and web service endpoints. In part 2, we'll demonstrate how to invoke these web services from your BPEL Approval Workflow (and even how to store your web service user credentials in the CSF).
We wanted to pass along a suggestion to use Fault Policies around your web service calls to retry the operation in the event of network issues. We won't cover the use of Fault Policies in this series of posts, but may discuss it in a future post. For more information about Fault Handling in BPEL specifically, check out this document from Oracle Documents Online
Invoking the Web Service
Now that you have deployed your web service and protected it with an OWSM policy, you will need to configure your BPEL Approval workflow to invoke the web service. This is actually quite simple and JDeveloper does most of the work for you.
To start, we will assume you already have created a workflow (if not, see Oracle's How-To document for more information).
Once you have a new workflow, you must create a new partner link. To do this, open the bpel file for your workflow (such as ApprovalProcess.bpel) and drag the Partner Link activity from the Component Palette onto the Partner Links swim lane section of your workflow screen.
The Create Partner Link window will appear. Here you will specify the name of the Partner Link, as well as the WSDL URL. After typing in the WSDL URL, click the Parse WSDL button. You will see a prompt notifying you that there are no Partner Link Types defined in the current WSDL. Click Yes. This prompt may appear twice, so click Yes both times. You will see the Partner Link Type field has been populated. Finally, under Partner Role, choose the role listed and then click OK. You will see the new Partner Link appear in the Partner Links swim lane.
Now that you have a Partner Link defined, you must define an Invoke activity by dragging and dropping it from the Component Palette into the main swim lane. Double click the new Invoke activity and the properties window will appear.
Type in a name for the Invoke activity, and then choose a Partner Link using the Partner Link Chooser (select the one you just created). You will see a list of operations to choose from. In our case, we’ll select Disable User.
For Input and Output variables, you will have to create these by clicking the + icon, starting with the Input variable. When the Create Variable dialog box appears, click OK to accept the defaults. Repeat this process to create the Output variable.
Finally, click OK to close the Invoke properties box. You will see a line connecting the Invoke activity you just created to the Partner Link you created previously. Make sure you save the bpel file in JDeveloper.
Now that you have defined an Invoke activity for the new Partner Link, you must use the Assign activity to assign the proper input values to the Input variable you created in the previous step. Drag and drop an Assign activity from the Component Palette onto the BPEL workflow. As with any other BPEL assignment, simply choose the source value on the left side of the Copy Rules screen, and drag to a corresponding variable element on the right side, then click OK.
Repeat this process for the Output variable, if necessary. You have now successfully configured your BPEL workflow to invoke the custom web service. In the next section, we will cover how to pass credentials to the web service using the OWSM Client Policy.
Configure OWSM Client Policy
Previously we protected the Web Service endpoint with an OWSM Policy that required a username and password be provided along with the SOAP request, so we will have to configure our Partner Link to provide these credentials when the service is invoked. This is actually quite easy in JDeveloper. You could also this do in Enterprise Manager at runtime, but it will not persist if you redeploy the BPEL Approval workflow.
In your BPEL Workflow project, open the composite.xml file. On the right under the External Service swim lane, right click on your Partner Link and click Configure WS Policies. Beside Security, click the + sign to add a Security policy.
Choose oracle/wss_username_token_client_policy and click OK. Back on the Configure SOA WS Policies screen, select the policy under Security and click the pencil icon to edit the policy settings. For the csf-key row, you can specify a csf key name under Override Value or use the default value (basic.credentials). Here you must use a CSF key that has been defined in the oracle.wsm.security CSF map. This is very important – only keys defined in oracle.wsm.security will work. In our case, we defined a custom key called owsmUserCred that contains a valid username and password. At runtime, Weblogic will retrieve this CSF credential and use it to authenticate.
Click OK, and then click OK again to close the Configure SOA WS Policies window. Save the composite.xml file, then deploy your web service to the SOA server and associate it to an OIM Approval Policy as needed.
You now have successfully configured your BPEL Approval workflow to use the custom Web Service and to pass the credentials necessary to satisfy the OWSM policy assigned to the endpoint.
Justin Hinerman is an Identity and Access Management Engineer with IDMWORKS. As a key Oracle Partner, IDMWORKS takes a focused approach to the implementation of a Service Oriented Architecture and Identity Management-based solutions.