Some Java, JEE and WebSphere stuffs | Something about JEE and WebSphere. Java, JEE and WebSphere tips and tutorials

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.

Shared libraries are libraries that are accessible to all the applications deployed on the same node as the shared library file. To create a shared library, we need to select the Shared Libraries link from the Environment menu.

The shared libraries page will be opened.

Now click on New to create a new shared library. The new shared library page will be opened.

Now enter the Name of the library and the classpath of the library and click on Apply and OK. The shared library is ready.

To enable security in WebSphere Application Server, you need to logon to WAS admin console. The default URL for accessing WAS admin console would be http://localhost:9060/admin in your local machine. When the security is not enabled WAS would ask you for a username and you can provide any username you want. When enabling security in WAS 6.0 there are three different types of user registries available.

1. Custom User Registry
2. LDAP
3. Local OS.

Here I will be talking about enabling security using Custom User Registry as the Active User Registry. The first step in enabling security using Custom user registry is to create one user file and a group file. The group file will be of the following format.

name:gid:users:display name

For eg:
admins:1:admin,admin1:Administrative group
operators:2:operator,operator1:Operators group
users:3:user1,user2,user3,bobby:

The groups file will be saved with name groups.props in directory D:\IBM\security.

Then create a users file using the following format.

name:passwd:uid:gids:display name

admin:admin:10:1:Admin
admin1:admin1:11:1:Admin 1
user:user:12:2,3:User

The users file will be saved with name users.props in directory D:\IBM\security. (This cane be any directory)

The next fist step is to click on Global Security link under security menu.

The security configuration page opens up.

Once the security configuration page got opened click on Custom under user registries section. The custom user registry page opens.

Under general properties enter the server admin username and password you want and click on the custom properties link under Additional properties section. Click on new button in the custom properties page.

Enter groupsFile as the name and D:/IBM/security/groups.props as the value. Save the custom property value and create another custom property and enter usersFile as the name D:/IBM/security/users.props as the value. Save the values you will be returned to the custom properties page. Now the custom properties page would look like the one in the below picture.

Save the changes made and return to the security configuration page.

Now select custom user registry under active user registry and select the ‘Enable global security’ checkbox. Uncheck ‘Enforce Java 2 Security’

Save the changes. Restart your server. Once global security is enabled on the WAS server, we need to provide the admin username and password for starting and stopping the server. The command for starting the server once the security is enabled is

startServer.bat server1 -user admin -password admin

where server1 is the name of your server. If your server is integrated with an IDE like RAD, double click on the server from the server perspective and enter the username and password after selecting ‘security is enabled on this server’ checkbox under security section in your server configuration window.