Some Java, JEE and WebSphere stuffs | Something about JEE and WebSphere. Java, JEE and WebSphere tips and tutorials

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.

Dynamically assign web service endpoint urls

How do we assign an end point URL dynamically to a web service in WebSphere Process Server? Or how do we change the endpoint URL of the web service. If any our business process invokes an external web service, we may need to change the web service URLs for different environments. For e.g.: for DEV WPS server we will have one web service end point URL where for PROD there will be a different one. So in this case we should be able to set the endpoint urls dynamically depending on the environment so that we do not need to change our EAR file for each environment.

To assign a dynamic end point url for an external web service we have two different ways. One needs some administrative effort and one needs some programmatic effect.

To change the endpoint url from the admin console follow the below steps.

1. Login to your admin console

2. Click on Applications -> SCA Modules from the left hand Menu

3. This will list all the SCA Modules installed in your server.

4. Now click on your module.

5. Now from Module components click on Imports. It will display all the imports present in your module. Expand the import for which you want to change the end point url. Once expanded, expand Binding which will display your service.

6. Now click on the web service import.

7. Enter the new endpoint url and click on Apply and OK.

I will blog about the second way of assigning a dynamic end point url for a webservice import in the next post.

Business spaces in WebSphere Process Server.

Starting from version 6.1.2 IBM introduced a new feature in WebSphere Process Server called business spaces. A business space is a collection of content related to a business process which has the capability to act on that process. Basically it is a web based user interface for a business user to interact with a process. In business space we can have many different business space widgets for different actions like work on a task, monitor key performance indicators etc. This feature is very helpful when we have some human tasks associated with a process. Instead of writing custom client pages, business users can login to business space and start working on the task assigned to him

The business space manager can be opened using the url http://localhost:9080/BusinessSpace

Business space manager that comes with business spaces is used for managing your business space. Business space manager allows a user to create/edit/delete business space, page etc. You can open Business Space Manager by clicking on the Manage Business Spaces link which is present in the top right corner of your business space.

Yesterday one of my readers ping me in Google talk and said that he is facing some issues in WebSphere Integration Developer. He was getting an exception while trying to call a WID web service from a web application. The exception was

com.ibm.websphere.csi.CSIAccessException: SECJ0053E: Authorization failed for /UNAUTHENTICATED while invoking (Bean)ejb/com/ibm/events/bus/EventBus createEvent(org.eclipse.hyades.logging.events.cbe.CommonBaseEvent):3 securityName: /UNAUTHENTICATED;accessID: UNAUTHENTICATED is not granted any of the required roles: eventAdministrator eventCreator catalogAdministrator
	at com.ibm.ws.monitoring.core.EventPointImpl$1.run(EventPointImpl.java:388)
	at java.security.AccessController.doPrivileged(AccessController.java:197)
	at com.ibm.ws.monitoring.core.EventPointImpl.fire(EventPointImpl.java:386)
	at com.ibm.bpe.monitor.EventEvaluationResult.fireEvent(EventEvaluationResult.java:148)
	at com.ibm.bpe.engine.observer.ProcessInstanceEventTypeHandler.processBPELEvent(ProcessInstanceEventTypeHandler.java:240)
	at com.ibm.bpe.engine.observer.CEMSOPContextRestored.processInstanceEvent(CEMSOPContextRestored.java:188)
	at com.ibm.bpe.engine.observer.BpelStateObserverContextImpl.restoreContextAndFireProcessInstanceEvent(BpelStateObserverContextImpl.java:1024)
	at com.ibm.bpe.engine.observer.CEMStateObserverPlugin.processInstanceEvent(CEMStateObserverPlugin.java:212)
	at com.ibm.bpe.engine.observer.BpelStateObserver.observe(BpelStateObserver.java:989)
	... 71 more
Caused by: com.ibm.ws.monitoring.core.CEIEmitRuntimeException: com.ibm.events.emitter.SendFailureException: CEIEM0025E The emitter failed to send the events to the event server. The local event bus enterprise bean on the event server failed during event processing.

This is because the user is not authenticated and hence he does not have any required roles to invoke the specified service. To resolve this exception either authenticates your user who is trying to call the web service or logon to admin console and make the following changes.

Click on Service Integration from Left hand side menu of admin console. Click on Common Event Infrastructure -> Event service -> Map security roles to users or groups and select the ‘Everyone’ checkbox for all the required roles. Save the changes and restart your server. You are done.

Yesterday I came across a new exception while invoking my web service using WebSphere Process Server. I was trying to invoke an external web service from WID. The exception or web service fault message I was getting was

CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "transactionNotSupportedActivitySessionNotSupported" on bean "BeanId(CustomerProfileApp#CustomerProfileEJB.jar#Module, null)". Exception data: com.ibm.websphere.sca.ServiceRuntimeException: <soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Fault><faultcode>soapenv:Server.generalException</faultcode><faultstring>org.xml.sax.SAXException: WSWS3047E: Error: Cannot deserialize element elementName of bean beanName. To see the message containing the parsing error in the log, either enable web service engine tracing or set MessageContext.setHighFidelity(true).</faultstring></soapenv:Fault></soapenv:Body>
	at com.ibm.wsspi.sca.webservice.jaxrpc.ServiceImportHandler.handleFault(ServiceImportHandler.java:313)
	at com.ibm.ws.webservices.engine.handlers.jaxrpc.HandlerProxy.handleFault(HandlerProxy.java:159)
	at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandlerChain.oneHandleFault(JAXRPCHandlerChain.java:869)
	at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandlerChain.handleFault(JAXRPCHandlerChain.java:846)
	at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandlerChain.handleFault(JAXRPCHandlerChain.java:839)
	at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler.invokeClientFaultHandler(JAXRPCHandler.java:535)
	at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler$3.onFault(JAXRPCHandler.java:453)
	at com.ibm.ws.webservices.engine.PivotHandlerWrapper.onFault(PivotHandlerWrapper.java:516)
	at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:317)
	at com.ibm.ws.webservices.engine.WebServicesEngine.invoke(WebServicesEngine.java:336)
	at com.ibm.ws.webservices.engine.client.Connection.invokeEngine(Connection.java:929)
	at com.ibm.ws.webservices.engine.client.Connection.invoke(Connection.java:722)

This usually happens when you have an array of complex types. There is a technote available from IBM and they are providing three different solution. I just followed one of the solutions given by that technote. So to resolve this issue follow the below steps.

1. Open your WSDL file
2. Search for the elementName that cannot be serialized.
3. If you found an entry like

	<element name="elementName" nillable="true" type="someComplexType" />

4. Add ‘ xmlns=”"‘ to that element.

5. Now your element definition will look like

	<element name="elementName" nillable="true" type="someComplexType"  xmlns="" />

This will resolve the issue. At least it solved my problem. However the IBM recommended solution is to use the proper namespace.