If you're preparing to fully migrate to WebPD from desktop Process Designer (eclipse) or already migrated and lacking some of the functionality that many IBM BPM/BAW clients had been waiting for, specifically - debugging of runtime instances in Runtime (Workflow/Process servers) then there's good news for you. IBM has introduced this new functionality in WebPD as of IBM BAW 20x/21x Product releases that allows you to connect to online Runtime Workflow services from WebPD to debug process instances.
In order to be able to debug Runtime process instances you'd have to go through a number of steps documented in the following Infocenter article -
I have tried to follow the same steps and at first did not succeed hence I decided to write this article in order to explain some of the steps in more details.
Per IBM article: "If the IBM Business Automation Workflow server and the remote Workflow Server are in the same domain, set up LTPA token security by selecting Global Security > LTPA > Cross-cell single sign-on. For more information, see How to configure single sign-on (cross-cell SSO)."
Both of my BAW 20002 servers (PC/DEV and Runtime) were in the same domain and so, I have tried to follow the steps of configuring LTPA Cross-cell single sign-on which was an easy set up. I had to export LTPA keys into a file on one server and import the same keys on another server. And that should be it (sync nodes, restart environment) but to my regret this didn't seem to work. When I tried to login to WebPD and open one of the snapshots that was deployed to my online Runtime server and try to start an instance I did see a selection of servers in the list including my TEST Runtime server -
But after selecting it and clicking "Run" I received an error -
There was nothing at all in the PC/DEV logs and nothing in Runtime/Workflow server logs either.
The only valuable information that helped to understand what the problem is can be seen in network logs gathered in the browser. There I see that the target Runtime server is "blocked:csp". I won't be going into much details of what that means but basically servers do not trust each other and hence redirect from DEV to Runtime fails since it's blocked by browser security policy. I tried multiple browser (Chrome, FF) with the same result.
CSP stands for Content Security Policy, and it is a browser security mechanism. If we go back to IBM instructions page again we can see that the step suggested when your IBM BAW Workflow Center and the remote Workflow Server are in different domains involve setting the CSP header value using wsadmin. I went ahead and applied the rest of the steps from the article including restart of both environments at the end.
Unfortunately, it still didn't work. In WebPD I was getting the same error but in the network trace I could see that the error changed to "CORS error" -
After consulting with IBM BAW support turns out that on step 2 where it says:
To ensure the remote Workflow Server points to the correct Workflow Center host name, add the following lines to the 100Custom.xml file from Workflow Server:
<server> <rest> <allowed-origins merge="replace">Workflow Center host name:Workflow Center port</allowed-origins> </rest> </server>
<server> <rest> <allowed-origins merge="replace">https://my-pc-hostname.domain.com:9444</allowed-origins> </rest> </server>
- As already mentioned it looks like even if your PC/DEV and Runtime servers are in the same domain the LTPA Cross-site SSO would not work in this particular scenario. I did open a Case with IBM and have not received an answer whether this had been tested or not. They did mention that in their own Labs environments they configured following all the steps from the article. So, you may skip LTPA SSO portion of instructions from the start and follow the steps as if your IBM Business Automation Workflow server and the remote Workflow Server are in different domains.
- Pay attention to step #2 from the instructions and make sure you add "https://" protocol in your XML stanza as shown above in this article.
- When running "wsadmin" commands you'd have to connect to DMGR profile and use "-lang jython" parameter because command are written in jython language
- In wsadmin commands you run on PC/DEV server replace all occurrences of "WS_defaulthost:WS_defaulthost_secure" with corresponding hostname and port of Runtime server (it says WS_defaulthost_secure but that is actually port!). For example -
- In wsadmin commands you run on Runtime/Workflow Server replace all occurrences of "WC_defaulthost:WC_defaulthost_secure" with corresponding hostname and port of PC/DEV server (it says WC_defaulthost_secure but that is actually port!). For example -
- After completing all the steps make sure you perform a sync of nodes on both env's and restart of both Deployment Environments.