You are currently browsing the tag archive for the ‘Business Choreographer’ tag.

Introduction

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:

Business Space is within WebSphere Portal, user's Mozilla Firefox connects to this, and a separate WebSphere 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.

Problem

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.

Solution

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.

The "local file system" has been navigated to the WAR file and the Context Root field is set to MortgageApplicationWeb

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.

Map modules to servers page, where Server has been changed to WebSphere_Portal from server1
Restart Portal.

Thanks

Thanks to T. Schulze for his contribution to this method.

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 3 other followers

Author

I work in IBM Software Services for WebSphere and Lotus (ISSW and ISSL respectively), who do specialist work for customers. Contact ISSW or ISSL for more details. I can also be contacted through email. Any views here are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
Follow

Get every new post delivered to your Inbox.