Business processes that are developed for WebSphere Process Server (or, in my case, WebSphere Dynamic Process Edition), often involve what is known as “Human Tasks” – steps for the mankind.
Human Tasks can be executed through the web browser, e.g., by filling in a form. They are often presented through what is known as “iWidgets” deployed to a mashup portal called “Business Space”. The iWidgets and Business Space are linked to the Process Server backend using RESTful API’s.
A scenario may be where the Process Server and Business Space are deployed to two separate servers – in my case, Business Space is deployed on WebSphere Portal, which is separate to the Process Server:
A properly configured Portal would use the remote Process Server for Human Tasks stuff through their RESTful API’s which is explained on the Information Center.
If the Human Tasks use web forms then there is however one more step that needs to be performed.
When a Human Task is brought up, for example, in the Task Information widget, a 404 error will show – that the form could not be found. The problem here is that the web projects are deployed as part of their enterprise applications on the Process Server, rather than on the Portal.
What can be done is to deploy the web applications separately to the Portal. Here’s how…
1. Get the WAR files
Bring up WebSphere Integration Developer (or a JEE-based tooling), switch to the “Web” perspective, and the web projects should appear in the “Enterprise Explorer” list – usually their names end with “web”. Look in the “WebContentt” of each project to see what forms there are – if there are, export the web project as a WAR file.
2. Find out the Context Roots
In each of the web projects, open the “Deployment Descriptor”. In the “Overview” tab, on the right, under “Usage”, there should be text saying “The following Enterprise Applications use this web module” – click on the link that is shown as the enterprise application using this web module.
In the “Deployment Descriptor” of the enterprise application, switch to the “Module” tab from “Overview”, under “Modules” list, select the web module that we’ve exported, and on the right, there is the “Context root” field, which we would want to take note of.
Repeat for the other web projects.
3. Install WAR files to Portal set to their Context Roots
The WAR files can be installed through Portal’s WebSphere Application Server console the usual way – using the WAR from Step 1 above and the Context Root from Step 2.
and, with the common standalone Portal deployment, don’t forget to change from server1 to WebSphere_Portal in the “Map modules to servers” step of the WAR installation process.
Thanks to T. Schulze for his contribution to this method.