Saturday, 22 November 2014

Help - The Proxy Ate My Process Designer

This is a problem that I recently saw with a client, and was able to reproduce, and more importantly, fix on my own environment.

But first some background, one of the IBM BPM's major features is the Eclipse-based development, Process Designer. This interacts directly with Process Center, and provides a collaborative rich-client integrated development environment.

Unlike other development tools, Process Designer can NOT function with a constant connection to the Process Center run-time, and this connectivity is predominantly via an HTTP connection.

It's also worth emphasising that, almost uniquely, Process Center "wraps" around Microsoft Internet Explorer, which is an absolutely crucial point ( and also explains why PD isn't available on any platform other than Microsoft Windows ).

The issue described here relates to the fact that Process Designer was unable to connect to Process Center.

Here I was using IBM BPM Advanced 8.5.5, but I'd previously seen it at my client's site using

The most obvious symptom is this dialogue box: -

even though it is absolutely possible to access, and log into, Process Center via a web browser.

I also validated the eclipse.ini configuration file, which contained: -


which ties up with the URL used from within the web browser.

Process Designer does have a nifty log file. For me, this was located here: -

C:\IBM\Process Designer\V8.5\workspace\.metadata\.log

The path may vary from case to case. It's also worth noting the precise directory ( .metadata ) and file ( .log ) names, as they include preceding period characters.

Anyway, the log showed this: -

!SESSION 2014-11-22 08:55:49.490 -----------------------------------------------
java.fullversion=JRE 1.6.0 IBM J9 2.6 Windows Server 2008 R2 x86-32 20131230_180580 (JIT enabled, AOT enabled)
J9VM - R26_Java626_SR7_20131230_1725_B180580
JIT  - r11.b05_20131003_47443.02
GC   - R26_Java626_SR7_20131230_1725_B180580
J9CL - 20131230_180580
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en
Framework arguments:  -dir ltr
Command-line arguments:  -os win32 -ws win32 -arch x86 -consoleLog -dir ltr -clean

!ENTRY teamworks.appserver.websphere 1 0 2014-11-22 08:55:59.271
!MESSAGE [ retrieveSystemHTTPProxies] found system HTTPS proxy ---  host: port: 80

!ENTRY 1 0 2014-11-22 08:55:59.443
!MESSAGE [InteractiveSplashHandler] Starting Authoring Environment. Bundle: Version: BPMRepo Prefix:

!ENTRY teamworks.appserver.websphere 1 0 2014-11-22 08:56:07.758
!MESSAGE [org.apache.commons.httpclient.HttpMethodDirector executeWithRetry] I/O exception ( caught when processing request: Connection refused: connect

!ENTRY teamworks.appserver.websphere 1 0 2014-11-22 08:56:07.758
!MESSAGE [org.apache.commons.httpclient.HttpMethodDirector executeWithRetry] Retrying request

!ENTRY teamworks.appserver.websphere 1 0 2014-11-22 08:56:08.787
!MESSAGE [org.apache.commons.httpclient.HttpMethodDirector executeWithRetry] I/O exception ( caught when processing request: Connection refused: connect

!ENTRY teamworks.appserver.websphere 1 0 2014-11-22 08:56:08.787
!MESSAGE [org.apache.commons.httpclient.HttpMethodDirector executeWithRetry] Retrying request

!ENTRY teamworks.appserver.websphere 1 0 2014-11-22 08:56:09.817
!MESSAGE [org.apache.commons.httpclient.HttpMethodDirector executeWithRetry] I/O exception ( caught when processing request: Connection refused: connect

!ENTRY teamworks.appserver.websphere 1 0 2014-11-22 08:56:09.817
!MESSAGE [org.apache.commons.httpclient.HttpMethodDirector executeWithRetry] Retrying request

!ENTRY 4 0 2014-11-22 08:56:10.815
!MESSAGE [InteractiveSplashHandler] Attempt to connect to the Process Center at URL: failed.  Verify that the server is running.
!STACK 0 Connection refused: connect
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(
at org.apache.commons.httpclient.HttpClient.executeMethod(
at org.apache.commons.httpclient.HttpClient.executeMethod(
at org.eclipse.swt.widgets.TypedListener.handleEvent(
at org.eclipse.swt.widgets.EventTable.sendEvent(
at org.eclipse.swt.widgets.Widget.sendEvent(
at org.eclipse.swt.widgets.Widget.sendEvent(
at org.eclipse.swt.widgets.Widget.sendEvent(
at org.eclipse.swt.widgets.Control.traverse(
at org.eclipse.swt.widgets.Control.translateTraversal(
at org.eclipse.swt.widgets.Display.translateTraversal(
at org.eclipse.swt.widgets.Display.filterMessage(
at org.eclipse.swt.widgets.Display.readAndDispatch(
at org.eclipse.ui.internal.Workbench$
at org.eclipse.ui.internal.Workbench.createSplashWrapper(
at org.eclipse.ui.internal.Workbench.runUI(
at org.eclipse.ui.internal.Workbench.access$4(
at org.eclipse.ui.internal.Workbench$
at org.eclipse.core.databinding.observable.Realm.runWithDefault(
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at org.eclipse.equinox.launcher.Main.invokeFramework(
at org.eclipse.equinox.launcher.Main.basicRun(
at org.eclipse.equinox.launcher.Main.main(

and I have highlighted the most interesting exceptions.

Of these, this one: -

!MESSAGE [ retrieveSystemHTTPProxies] found system HTTPS proxy ---  host: port: 80

is absolutely crucial, as it led me to my initial hypothesis.

Now I first saw this issue on-site in August, but it took a very long time to get into a position to prove it.

I believed that the issue was that, in accordance with the underlying Microsoft Windows OS and Microsoft Internet Explorer browser, Process Designer is trying to leverage the system's default configuration to use a HTTP proxy server.

Now proxy servers usually sit at the edge of a network, and are used to protect network users from threats from external servers. We've had proxy servers almost as long as we have had the internet, and many corporations use the HTTP proxy to ensure that their staff do not access prohibited content ( often including so-called personal sites such as social networks, blogs, discussion services etc. ).

Anyway, back to the problem in hand.

It was my belief that Process Designer was being directed to the HTTP proxy, by an OS default setting ( typically controlled by Microsoft Active Directory via a Group Policy Object ), and that the proxy was blocking access to Process Center.

Due to access to the proxy configuration being tightly controlled, by AD GPO, I had no way to prove this on-site, leastways not until quite recently.

Therefore, on my own BPM 8.5.5 environment, I configured Windows/IE to use a ( admittedly non-existent ) proxy server: -

using the same configuration as my client ( port 80 ).

At my client, I'm guessing that there's actually some HTTP proxy software running locally ( perhaps part of an anti-virus solution ).

Regardless, I've told Windows to send all traffic to

Guess what, Process Designer fails exactly as expected, even though Process Center is most definitely up-and-running.

Once I disabled the proxy, PD > PC again worked.

Now whilst it's perfectly acceptable to have a HTTP proxy, as outlined above, it seems illogical to have intranet traffic ( PC > PD ) going via the proxy, partly for inconvenience ( it doesn't work ! ) and party for performance ( putting intranet and internet traffic through a proxy server may not be a great idea, performance-wise ).

Again, it may NOT be a proxy server per se, but a local client-side application.

However, it's also possible to tell Windows/IE to avoid the proxy for certain given hosts, so I added the hostname of Process Center into the relevant configuration field: -

This time around, Process Designer worked like a dream.

It took a while ( mainly in order to get the right level of access to modify the Windows/IE configuration at my client's site ), but my hypothesis proved true there as well, and we were again able to get PD > PC working.

On a related note, a few days ago, we hit almost the same issue with IBM Rational Team Concert, where the RTC client was also trying to go via the proxy. Again, the same resolution ( adding the RTC server to the Exceptions dialogue, as outlined above ) worked a treat.

Simple when one knows how .....

Finally, in case it helps, in BPM, it was possible to force Process Designer to only use HTTP/HTTPS, rather than HTTP/HTTPS *and* RMI via JMS. It appears that, with, this is now the default.

Either way, one can check whether this is configured or not, as follows: -

/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/ -lang jython -user wasadmin -password passw0rd

WASX7209I: Connected to process "dmgr" on node bpm85Node1 using SOAP connector;  The type of process is: DeploymentManager
WASX7031I: For help, enter: "print"
wsadmin>print AdminConfig.showAttribute(b,'httpProtocolOnly')

This made no difference, either with or, but, if needed, one can toggle the setting on: -


or off: -


as documented here: -


If one ever needs to know how to configure the Windows Registry to enable the Connections/Proxy tab in IE to be edited, here you go: -

Registry keys that you will need to tweak, Change value from 1 (Disabled) to 0 (Enabled)

HKLM\Software\Policies\Microsoft\Internet Explorer\Control Panel

“Connection Settings”

No comments: