Accessing BPC API using web service
If we want to create our own interface for working on Human Tasks, we need to use use the Business Process Choreographer APIs. Most of the time these user interface pages will be deployed in a separate Application Server and our human tasks and business processes will be running in another WPS box. The Business Process Choreographer API can be accessed in two different ways. One is BPC EJB API calls and another is BPC API calls using web service. Here I will be explaining what are the configurations required to access BPC API using web services from a web application.
WebSphere Process Server mandates security to be turned on, for accessing BPC API using web services. If you want to know how to turn on security in WAS, read my post here. Enabling security in WAS 6.0
Once the security is turned on, we need to share the LTPA key between the WAS server and WPS server. Select Global security from security menu. Now expand the ‘Authentication mechanisms’ link under Authentication section.
Now click on LTPA. In the window opened, enter the password you want for your LTPA key. Apply and Save the changes to master configuration. Now click on Generate LTPA key and Save the changes again to master configuration. Now we need to enter the keyfile name and location where we want to store the LTPA key. Save the settings to your master configuration and click on Export Keys. A key will be generated in the location we specified. Take this key and import it into the other server using the password used for generating the key.
The next step is to download the required WSDLs from admin console. For this login to admin console of WPS and navigate to Applications -> Enterprise Applications -> BPEContainer_nodeName_serverName. Here the nodeName will be the name of your WPS installation and serverName will be the name of your WPS server installation. In my case the nodeName is widNode and server name is server1
Now click on Publish WSDL files link.
Now click on the link ending with .zip and a download popup window opens. Save it to a temporary location in your file system. Before downloading the file, if you want to change the HTTP end point url, click on ‘Provide HTTP endpoint URL information’ link from ‘BPEContainer_widNode_server1′ menu.
Repeat the same steps for TaskContainer_widNode_server1 application also.
If you don’t have the WSDL files listed in your admin console, you may need to upgrade to WID version 6.0.2.
The next step is to generate web service client from the wsdls we downloaded from admin console. For that I copied the contents of wsdl folder after extracting BPEContainer_widNode_server1_WSDLFiles.zip to a temporary directory inside my web application. Now generate the web service client as mentioned in this post. Generating web service proxy client Here I generated my web service client with no wrapped style. (Windows -> Preferences -> Web services -> Code Generation -> IBM WebSphere run time -> ‘Generate Java from WSDL using the no wrapped style’ check box is checked.). Don’t ask me why I chose no wrapped style. . I feel that is better
If the web service client generation got over. Open your web.xml go to References tab and make sure that you have a Service Reference with name ‘service/BFMWSService’.
Now we need to create a new J2EE role for representing the authorization. Go to the security tab of Deployment Descriptor and click on Add under ‘Security Roles’. Enter WIDUser as the name of the role and click on Finish.
In the ‘security constraints’ section click on add and enter a name for the security constraint.
Click on Next. Enter the resource name and the url pattern. In my case I used /* as my url pattern to protect all the pages.
Click on Finish.
Click on Add under ‘Authorized Roles’ section. Select WIDUser and click on Finish.
Save the changes to the deployment descriptor (web.xml).
Now navigate to ‘WS Extention’ tab. Select service/BFMWSService under ‘Service References’ section and select BFMWSPort under ‘Port QName Binding section’.
Under ‘Request Generator Configuration’ expand ‘Security Token’ and click on Add.
In the dialog box opened enter the details as shown in the figure.
Click on OK.
All the settings required at ‘WS Extention’ tab also over. Now click on ‘WS Binding’ tab and select service/BFMWSService under Service references and BFMWSPort under Port Qualified Name Binding section. Expand ‘Security Request Generator Binding Configuration’ and ‘Token Generator’. Click on Add. Enter the details as shown in the figure.
Save the changes to DD.
Repeat all the steps performed in WS Extension and WS Binding tab for Human Task web service reference also. When making the changes for Human Task service, make sure that you are using a different name for the token generator.
Go to Pages tab of your DD. Under Login section select BASIC as the authentication method and enter a Realm name.
Now we have done with all the changes required in the web.xml.
The next step is to add the same roles in the EAR deployment descriptor (application.xml) also.
Open the deployment descriptor of your EAR Project which contains the web module. Go to the security tab and click on Gather to get all the roles defined in web.xml. Select WIDUser under security and select ‘All authenticated users’ under WebSphere Bindings section.
Well we are ready with our configuration for a secured HTM and BFM web service call.