iProcess Connecting to Action Processor through Proxy and JMS – Part 2

Following the first part, I explained the problem scenario and outlined the solution, in this post I present the implementation.

We need to create the following components:

1) Local Proxy – which will be the target for the Workspace Browser instead of the Action Processor which is sitting inside the ‘fence’ and therefore not accessible over HTTP.

2) Proxy for JMS – Proxy which puts the http request in a JMS message and gets the response back to the Local Proxy which returns it to the Workspace Browser.

3) JMS Queues – Queues to act like channels through the ‘fence’.

4) Service for JMS – Service to handle the requests sent over JMS inside the ‘fence’ and to send the response back over JMS.


I will group the above into three ‘work-packages’:

1) JMS Queues – TIBCO EMS based queues.

2) Proxy and Service for JMS – implemented using BusinessWorks.

3) Local Proxy – implemented using JSP.


Creating the TIBCO EMS Queues

Using the EMS administrator create two queues:

1) iPRequestQueue – to put requests from Workspace Browser.

2) iPResponseQueue – to return response from Action Processor.

Command: create queue <queue name>


Proxy and Service for JMS

For both the Proxy and Service to work we will need to store the session information and refer to it when making HTTP requests to the Action Processor. To carry through the session information we use the JMS Header field: JMSCorrelationID.

Otherwise we will get a ‘There is no node context associated with this session, a Login is required.’ error. We use a Shared-Variable resource to store the session information.

Proxy for JMS:

The logic for the proxy is simple.

1) HTTP Receiver process starter listens to requests from the Workspace Browser.

2) Upon receiving a request it sends the request content to a JMS Queue sender which inserts the request in a JMS message and puts it on the iPRequestQueue.

3) Then we wait for the JMS Message on iPResponseQueue which contains the response.

4) The response data is picked up from the JMS Message and sent as response to the Workspace Browser.

5) If the returned response is a complaint about ‘a Login is required’ then remove any currently held session information in the shared variable (so that we can get a fresh session next time).

In the HTTP Receiver we will need to add two parameters ‘action’ and ‘cachecircumvention’ with ‘action’ as a required parameter. The ‘action’ parameter value will then be sent in the body of the JMS Message through the ‘fence’.

In the HTTP Response we will put the response JMS Message’s body as ascii and binary content (convert text to base64), Session information in JMSCorrelationID to Set-Cookie HTTP Header in response, Content-Type Header in response will be “application/xml;charset=utf-8”, Date can be set to the current date and Content-Length to length of the ascii content length (using string-length function).


Service for JMS:

The logic for the Service sitting inside the fence waiting for requests from the Proxy, over JMS, is as follows:

1) JMS Queue Receiver process starter is waiting for requests on iPRequestQueue.

2) On receiving a message it sends the request from the JMS Message body to the Action Processor using Send HTTP Request activity.

3) A Get Variable activity gets us the session information to use in the request to the Action Processor.

4) The response is then sent to a JMS Queue Sender activity which sends the response out as a JMS Message on iPResponseQueue.

5) If the session information shared variable is blank then we set the session information received in the response.

The Send HTTP Request will also have two parameters: ‘action’ and ‘cachecircumvention’ (optional). We will populate the ‘action’ parameter with the contents from the received JMS Message’s body. The session information will be fetched from the shared variable and put in the Cookie header field of the request. We will also put the contents of the JMS Message’s body in PostData field of RequestActivityInput. Make sure also to populate the Host, Port and Request URI to point to the ActionProcessor.

An example, if you Action Processor is located at: http://CoreWebServer1:8080/TIBCOActProc/ActionProcessor.servlet  [using the servlet version] then the Host = CoreWebServer1, Port=8080 and RequestURI=/TIBCOActProc/ActionProcessor.servlet. If you expect these values to change, make them into global variables.


Local Proxy

This wass the most important, difficult and frustrating component to create. The reason I am using a local proxy based on JSP and not implementing the functionality in the BW Proxy was given in the first part, but to repeat it here in one line: using a Local Proxy allows us to separate the ‘behavior’ of the Action Processor from the task of sending the message through the ‘fence’.

The source jsp file can be found here.

The logic for the proxy is as follows:

1) Receive the incoming request from the Workspace Browser.

2) Forward the request received from the Workspace Browser, as it is, to the BusinessWork Proxy.

3) Receive the response from the BusinessWork Proxy also get any session information from the response.

4) Process the response:

a) Trim the request and remove any newline-carriage returns.

b) Check the type of response and take appropriate action – if response has HTML then set content type in header to “text/html”, if response is an http address then redirect             response and if normal xml then set content type to “application/xml”.

c) Set session information in the header.

5) Pass on the response received from the BusinessWorks Proxy, back to the Workspace Browser.


Once everything is in place we need to change the Action Processor location in the Workspace Browser config.xml file. This file is located in <iProcess Workspace Browser Root>/JSXAPPS/ipc/ folder. Open up the XML file and locate the <ActionProcessor> tag. Change the ‘baseUrl’ attribute to point it to the Local Proxy. Start the BW Proxy and Service, iProcess Process Sentinels, Web-Server for the ActionProcessor and the Workspace Browser. Also test whether the Local Proxy is accessible by type out the location in a browser window.

The screenshots given below show the proxy setup in action. The Local Proxy is at: http://glyph:8080/IPR/iprocess.jsp (we would put this location in the ‘baseUrl’). We track the requests in Firefox using Firebug.

In the picture above we can see normal operation of the Workspace Browser. Above we see requests going direct to the ActionProcessor without any proxy.


Above we see the same login screen but this time the Workspace Browser is using a proxy. All requests are being sent to the Local Proxy.


Above we can the Workspace Browser showing the Work Queues and Work Items (I have blacked out the queue names and work item information on purpose). Tracking it in FireBug we see requests being sent to the Local Proxy (iprocess.jsp).


That’s all folks!




iProcess Connecting to Action Processor through Proxy and JMS – Part 1

The iProcess Workspace Browser is a web-based front-end for iProcess. The Workspace Browser is nothing but a web-application which is available in both asp and servlet versions. It does not connect directly to the iProcess engine though. It sends all requests to the iProcess Action Processor which is also a web-application (again available in a servlet and asp version). The Action Processor forwards the request (via TCP/IP) to the iProcess Objects Server which works with the iProcess Engine and processes the request. This arrangement is shown below (with both the Workspace Browser and Action Processor deployed in the same web-server).

Now this setup is fine in an ideal scenario but in most organizations web-servers are isolated (‘fenced’) from the core infrastructure (such as databases and enterprise servers). Usually the access to the core infrastructure is through a single channel (e.g. through a messaging queue server) with direct TCP/IP connections and port 80 requests from outside blocked. In that case you will need to deploy the Action Processor inside the ‘fence’ with the core infrastructure and setup a proxy system to communicate with the Workspace Browser (which will be sitting outside the ‘fence’). The proxy system will transport the HTTP request over the allowed channel (JMS in this example) and return the response. An example is shown below using JMS.

 To implement the above we need to create the following components:

1) Local Proxy – which will be the target for the Workspace Browser instead of the Action Processor which is sitting inside the ‘fence’ and therefore not accessible over HTTP.

2) Proxy for JMS – Proxy which puts the http request in a JMS message and gets the response back to the Local Proxy which returns it to the Workspace Browser.

3) JMS Queues – Queues to act like channels through the ‘fence’.

4) Service for JMS – Service to handle the requests sent over JMS inside the ‘fence’ and to send the response back over JMS.

You might ask why do we need a local proxy and why not call the BW Proxy directly. The reason is very simple. The BW Proxy and Service should be as uncluttered as possible, ideally their only task is to carry the request through the ‘fence’ and bring out the response. Any processing of the request and response should be done somewhere else (and as we shall see in the example there is a lot of processing required).

As we don’t want to fiddle with the internals of the iProcess Workspace Browser, we simply add a Local Proxy which does the processing of the request and response. Then we set the Workspace Browser to send all Action Processor requests to the Local Proxy. This means that the Local Proxy will ‘behave’ exactly like the Action Processor as far as the Workspace Browser is concerned.

To put it in one line: using a Local Proxy allows us to separate the ‘behavior’ of the Action Processor from the task of sending the message through the ‘fence’.


In the example to follow, we have:

1) JSP based Local Proxy (easy to code – no compiling required!).

2) BusinessWorks based Proxy for JMS

3) TIBCO EMS Server based queues.

4) BusinessWorks based Service for JMS


In the next part, the example!


Installing TIBCO iProcess Engine SQLServer (11.1.0) on Windows Server 2003


1) Administrator rights on the target server

2) iProcess Engine (version 11.1.0)

3) pthread.dll – POSIX thread implementation for Win32 environment. 

4) SQLServer instance with user account having the correct permissions (see below) – as we will install the SQLServer version of the iProcess Engine.

NOTE: The installation process may require several re-starts, especially if you also install SQLServer instance on the same server, so make sure that the server can be restarted without problems.

VERY IMPORTANT NOTE: During the install process you will be required to supply a lot of information including usernames, passwords, node names, port numbers etc. Make sure you note these down as you complete each screen of the install wizard. It is very easy to forget a password or username when you really need it!

Space requirements:

iProcess Engine ~ 370 – 400 MB

Installation process:

The installation process is quite straight forward with a wizard like interface.


1) Copy pthread.dll to the windows/system32 folder. This is required and the installation process will not start till the pthread.dll file is in the right place. On Windows 7 the folder to use for pthread.dll is windows/SysWOW64.

2) SQLServer access – make sure you can connect to the SQLServer instance and make a careful note of the connection parameters, username and password to be used. Also make sure the username you use has permission to create new databases/tables.

The installer will ask you for this information as the iProcess engine stores all its information in a database. The installer creates the main iProcess database and various tables, within it, as a part of the installation process. The easiest way of messing up the install is to give it a username which doesn’t have the required permissions to perform the table creation activity.

3) Log in as administrator.


The install section is fairly straight forward and is well covered in the TIBCO iProcess documentation. I will, therefore, not do a step by step description here but give an overall picture of the install process.

The install process starts off with various iProcess Engine related settings such as the node name (default: staffw_nod1).

NOTE: If you change the iProcess node name MAKE SURE you record it as you will be needing it almost everywhere.

Things done during the install process:

1) Define node name.

2) Define licensee name, which for some strange reason has to be at least 4 characters long.  

3) Define a new iProcess administrator account (username and password).

4) Option to require users to login using a password (it is a hard to miss checkbox at the bottom of the screen).

5) Setup a SQLServer connection and create two new SQLServer user accounts (usernames and passwords): swpro and swuser 

6) Setup Business Studio deployment (WebDAV), JMS connectivity, Email server as well as the iProcess web-server.


iProcess Objects Server Configuration –

This is where the fun really begins. Now is the time to configure the iProcess Objects Server. This bit is specially important if you are planning to install the TIBCO BusinessWorks iProcess plugin. Basically the plugin needs DB connection information. So you might want to select ‘ENABLED’ here.

A very important thing that you will need to do during this step is to setup the port for TCP. Open up the ‘services’ file in windows/system32/drivers/etc and scroll all the way to the bottom. There you should see two entries for iProcess similar to:

NODENAME_worker    PORTNUMBER/tcp      # Entry inserted by installer
NODENAME_watcher  PORTNUMBER/tcp      # Entry inserted by installer
Below the last entry add your own entry to define the TCP port to be used by the iProcess Objects Server (replace CAPPED entried with your values):

PORTNAME       PORTNUMBER/tcp               #Your comments

Copy-paste the PORTNAME to the TCP port textbox in TCP Settings tab in the iProcess Objects Server Configuration. 

Save all settings and close the Configuration panel. Then restart the server.

After restart go to the ‘Services’ section of the Administrative Tools panel and locate the iProcess service (there will be two services if you also installed the iProcess web server).

NOTE: Make sure the SQLServer on which the iProcess database was created is up and running.

Start up the ‘iProcess Process Sentinals’ service. 

 If everything has been installed properly then the service will start up normally (it takes some time to do so, don’t be worried if you don’t see the progress bar moving for some time).

In case the service does not start up normally (Windows will throw up an error message) the FIRST thing to check is whether the SQLServer instance, you created the database on, is reachable and you can login with the same credentials you provided (swpro) during the install.

Testing the install:

The best way to test the install (ONLY if you are the administrator AND you have studied the documentation) is to play around with ‘swadm’  in the ‘swserver/NODENAME/util’ directory.

One of the things you might want to do is allow addition of non-OS users to iProcess, especially important if you have enabled external authentication (e.g. through LDAP). 

Open up command line interface and go to the ‘util’ directory. Type in and press enter the following command:

swadm set_attribute 0 ALL 0 DISABLE_USER_CHECK 1

The above command sets up a new attribute called DISABLE_USER_CHECK with the value of ‘1’. It will allow the addition of non-OS users for all processes. 0 is the Logical Machine ID, ALL signifies do it for all processes (otherwise add process name) and 0 is for the process instance.

An easier way to check it is to install the Windows-based Workspace Browser (11.1.0) and point it to the new iProcess engine.

NOTE: I have done a similar install on Windows 7 – 64bit edition. While TIBCO does not support iProcess Engine SQLServer (11.1.0) on Windows 7, there were no problems in the installation and the performance was up to the mark.