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.
(a) Proxy for JMS:
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.
(a) 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).
(b) Service for JMS:
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).
(b) 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 source jsp file.
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.
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 source jsp file.
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).
For training on TIBCO IProcess mail us at [email protected]
For training on TIBCO IProcess mail us at [email protected]
RSS Feed
