• Entries (RSS)
  • Comments (RSS)

A WebSphere Process Server implementation story

Posted by | Posted in Websphere Process Server / Integration Developer | Posted on 08-04-2009

Tagged Under : , , , ,

A WebSphere Process Server implementation story

Just thought of writing about a WPS implementation story we completed one year back. That was the first implementation of WPS Human Task in our company. The project was a workflow system developed using the WebSphere Process Server/WebSphere Integration Developer. Unlike other projects this project’s architecture was driven by the infrastructure. This was a story of challenges.

Our application was a workflow application and we had an existing WebSphere Process Server infrastructure available. So we decided to go with WebSphere Process Server for implementing the workflow part. In addition to this WPS part we had a J2EE client for business users for accessing the human tasks. Our initial design was to host both the WPS part and J2EE part in the same WPS server (The J2EE part was very simple and contains less than 10 JSP pages only. Moreover this was an intranet application). But when we contacted the WPS hosting team, their policies does not allow us to host the J2EE application in WPS environment. Everything was looking very easy till this point. However the real challenges were on its way.

The first challenge was to separate the J2EE application from the WPS module. This was not a big deal; creating two different enterprise projects will separate out J2EE client logic from workflow part. Now the question was how does the J2EE client communicate with the WPS? Our initial idea was to use the EJB APIs for the communication. Soon we came to know that the policies will not allow us to use the EJB API and we are allowed to use only the web service APIs for connecting to WPS.

The primary requirement for generic WPS Web Service API to work was to enable the Global Security in WebSphere Application Server and in our WPS security was not enabled. No problem after some discussions with the hosting team both WPS (for hosting the workflow module) and WAS (for hosting the J2EE client) agreed to enable the global security.

So the first big challenge got resolved. Everything is set to go. Security is turned on in both WAS and WPS and we started coding. This was the time for the second road blocker. When we use the generic web service, the communication has to happen in a secured way and an SSO has to happen between WPS and WAS. In our case for login to the application we had to use a corporate authentication mechanism. Corporate provides tow types of APIs for authentication. One can be used with WAS for SSO using LtpaToken and other can be used by any application and no LtpaToken will be used. In our case we needed an SSO so the only option was to use the LtpaToken. When we asked for the LtapKey, we could see that the policy does not allow us to use the LtpaKey in our WPS and WAS servers. The people who owns the corporate authentication API was not able to share the LtpaKey with us as their policy does not allow them to share the LtpaKey to a server that is not part of their server group (They call it as UWS environment). Unfortunately both our WPS and WAS servers were not part of the server farm where our corporate authentication application is hosted. Now the first option left to us were to move both the servers under the UWS. But very soon we realized that, moving the servers to UWS will not be possible. (There was lot of issues. The team that owns these servers was not ready to move these servers to UWS. Moreover these servers were managed by two different companies). Then we decided to use the corporate authentication mechanism that does not provide us the SSO. And for the SSO part we created a TAI and installed it in WAS server. Well. SSO happened very smoothly and we were able to communicate to WPS from our WAS client using web service API.

That was not an end. We started our implementation. This time the big NO was from the database team. As part of the human workflow we had to update a database from within WPS. The workflow was actually part of a legacy application. Input for our workflow was coming from a legacy application and the output also should be for the legacy application only. But the database team was not ready to open a firewall to our servers. Soon we got a solution for this problem too. The decision was to create a text file with the entire required sql query and we will place the text file in a location. The database team will pick up the text file and execute it in the db.

Suddenly the security team came into the picture, the do not want us to do the FTP. SFTP is the only allowed protocol by them. OK. We had no other option. We started searching for a free SFTP library. (Yeah we wanted a free SFTP library because we were not in a position to tell the customer to pay some more money for a commercial SFTP library.) We could find some, but each library was giving enough troubles, some will not close the connections, some will never return a response and so on. Then we started thinking about some alternatives for SFTP library and we find that there is a tool called MoveIt available for secure file transfer. Yeah, that was the solution for all our file transfer related issues.

So all the infrastructure related issues got resolved. But by this time our design was totally changed. Lot of new systems got introduced to our application and the complexity of the design got increased too much. This leads our application to lot of new application related issues. For eg: Since the database updation was happening offline, we had to suspend our workflow till we get a response back from the database side (this also will come as a text file with .error and .success suffixes in the filename). Anyway finally we were able to complete the project successfully.

This was a good learning experience. So the moral of the story is:-

1. If you are a Project manager or an architect make sure that you understand all the policies of all the systems involved. A simple policy may screw your entire design and the cost may shoot up. When working in a big enterprise each department or each system may have different policies.

2. Talk to all the stake holders involved in the project. Otherwise you will end up in changing your design very often and all your estimates will go wrong.

3. Never ever assume things when you are in an integration project. Never your assumption will be true.


Read More


14 comments posted onA WebSphere Process Server implementation story

  1. [...] has posted a great article showing how difficult integration projects can be when you need to work with …. A relatively straightforward project turns into a Frankenstein of text files and workarounds. It [...]

  2. I’m in a similar situation as the one you described and am pulling my hair out. Well not anymore since it is all gone.

    I also have an application deployed in WAS which now needs to execute BPC API remotely in WPS. I am using the EJB API. I found out the hard way that when I accessed the BFM and HTM APIs from within my application, the “user context” that was communicated in the method invocations on the EJB was non existent. For example, I claim a human task activity, its owner shows up as “UNAUTHENTICATED”.

    Perhaps I should use the Web Service API then and do what you are doing. But how? I have found no clear documentation anywhere on how to do this. Could you please point me in the right direction?

    First, if I want each invocation on a BPC Api method to execute in the context of the user that is logged on to my application running in WAS, do I have to use Web Service API? Or can I also use the EJB API in similar fashion? Bottom line, the “user” or I should say “principal id” needs to get remotely communicated somehow over SOAP / IIOP to the remote service / session bean receiving the request in WPS.

    How ?!?!?!?!

    P.S. My job might be at stake here. Please help.

  3. For a tutorial on connecting to WPS using web service please follow the below link. If you have some questions on this please let me know. I might be able to help you.



  4. I have an issue while migrating a client application from websphere to JBoss. there is an security mechanism LTPA has been used for secured webservice call from WAS to WPS. Have to know how LTPA can be used in JBoss to make the secure webservice call to WPS.

  5. Raj, What you need is an SSO between JBoss and WAS. I have not configured an SSO between JBoss and WAS yet. However I can give you some pointers which will help you.

    I do not think LTPAToken is going to work for you as JBoss does not understand what an LTPAToken is. You may need to write a JAAS module for making this happen. or you can even think about different alternates like SAML or certificate based SSO.

    Please let me know if this helps.

  6. I believe we can secure the WS call using WSS4J. You can check the info at http://ws.apache.org/wss4j/.A simple example is also given.
    However, I am not sure how the username/pwd sent from ur client in Jboss will be authenticated at WPS side as I haven’t worked with WPS.
    I believe WPS must have a user registry configured and if the user name exists there it should authenticate .
    If someone with knowledge of WPS can clarify this, then you got the answer. Usually applications must have LDAP, if you get the uid/pwd authenticated in ur client using a LDAP, make sure to give the same LDAP in the user registry of webservice server (WPS in ur case).

  7. Thank you. I had already read your article before I asked the question.

    The solution I used was EJB/RMI security. It is easier to explain through code than in English

    LoginContext context = new LoginContext(“system.RMI_INBOUND”,
    WSCallbackHandlerFactory.getInstance().getCallbackHandler(userId, (String)null));

    We execute this code BEFORE I create instance of BFM or HTM session bean. The thread of invocation transfers the necessary credentials over the wire, effectively “trusting” the caller. Notice, no password for creating the login context. Not that I have it anyways. Needless to say, communication between my Web Application (deployed in WebSphere) and my Process Model (deployed in WebSphere Process Server) happens in the “trusted” layer.

    We muddled through configuration of RMI security on both WebSphere and WebSphere Process Server to get this working. Perhaps you or someone else will create a guide for mere mortals in simple English (IBM documentation is Greek, maybe Latin, certainly French, all of which I don’t speak).

    Best Regards.
    P.S. I did keep my job. For now :-)

  8. IBM does provide a “web service” invocation route to BFM / HTM service instead of Session Bean. But I found the configuration overly complicated. Configuring RMI security proved to be the lesser evil.

    In any event, my basic problem is that IBM solution are unnecessarily complicated. I have to live with their products. But I would like to believe I don’t have to live with their remoting solutions. I earned my stripes in distributed computing. I learned – as someone else has so eloquently put – the effort spent in designing something is inversely proportional to the simplicity of the result. A fact lost on IBM, conveniently, because if they make things simple, they lose consulting dollars. But I’m digressing.

    I love, like and understand Web Service technology very well. After getting things to work using the EJB route, I delved into exactly what was happening. Without going into too much details, 3 types of “tokens” aka credentials are getting serialized over the wire through the EJB Proxy. I figured out how to do the same thing manually, confirmed that the serialized payload was identical to what was being generated by the EJB proxy. I then proceeded to ASCII encode it as a SOAP Header and send it over the wire using a CXF service. The idea was to deserialize and get the credentials back.

    When I tried to deserialize the payload over the wire, I got a serializeVersionUID error. Fact of the matter is I know I got the security credentials right. I know because I dumped them into a file, read them at the other end of the wire, and was able to invoke the BFM session bean on behalf of whatever user I wanted.

    Sorry for the long drawn out response. I’m sorry but WebSphere Process Server sucks. Someday, maybe I’ll start my own blog. I’m sure I’ve bored yawl enough.


  9. Albin,
    I work for a large manufacturing company and have had the exact same experiences. Everyone has challenges within their corporate culture. What I would also be interested in hearing are the “challenges” with the tools (WPS/WID). I’ve worked on several projects now to implement very simple integrations with WID/WESB/WPS and I’m extremely unhappy with the toolset. The idea’s behind the tools are sound, but the struggles you go through to get simple things to work is astounding.

  10. I wouldn’t say I am unhappy with WID. I feel it is the best tool available in the market now. However to make some simple things to work we need to struggle a lot. I think IBM could have give a better documentation for this product covering all the scenarios.

  11. Albin,
    Thanks for the article .But I am kind of stuck in deciding wihich interface to use EJb or Webservice or rest ,I tried to look into the comaprision for these in http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.bpc.z.620.doc/doc/bpc/cbpcapi_compare.html but still not able tp decide please guide.

  12. It depends on your requirement. WebService is the easiest way. However the number of methods you can use will be less compared to EJB API.

  13. Hi Albin,

    I have a scenario where in I have a web application on was 7.0 and WPS server 6.2 is on other sytem.I want to invoke process from the client .to use EJB interface I will have to install WPS client 6.2 on my client side i.e over was 7.0 .I dont think it is going to work and for this kind of scenario I will have to use webservices api for invoking the process ?Please suggest if I am right on this ?

  14. As I alluded to above, write an EJB on WPS 6.2. Invoke the EJB from WAS 7.0. WPS 6.2 supports EJB 2.* unfortunately and not EJB 3.0, so it is a little bit harder than it has to be.

    Locally on WPS 6.2 invoke the “local” EJBs from Business Flow Manager and Human Task Manager.

    You CAN use Web Service version of BFM and HTM. I personally found it too cumbersome to configure than the EJB. Which is a testament to how difficult IBM makes its solutions.


Post a Comment