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
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
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 /JSXAPPS/ipc/ folder. Open up the XML file and locate the 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).
For training on TIBCO IProcess mail us at [email protected]
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
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
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 /JSXAPPS/ipc/ folder. Open up the XML file and locate the 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).
For training on TIBCO IProcess mail us at [email protected]
RSS Feed
