• Entries (RSS)
  • Comments (RSS)

Selectors in WebSphere Integration Developer

Posted by | Posted in Websphere Process Server / Integration Developer | Posted on 04-05-2010

Tagged Under : , , , ,

Selectors in WebSphere Integration Developer

A selector is a component that determines which implementation of a component should be invoked at run time based on a set of selection criteria. Every selector will have a default destination. When a selector is invoked it determines which component to invoke based on the date range entries and the selection criteria. A selector can route to any service component at run time.

Creating a Selector
Follow the below steps to create a selector

1. Right click on the module and select New ->Selector.

2. This will open the New Selector window. Enter the name for your selector. I have named it as MySelector. Click on Next.

3. In this page, we need to select the interface for the selector. I have used HelloInterface for this purpose.

4. Click Finish

Configuring the selector
Once we created our selector, we need to configure the selector. Open the selector in selector editor. Follow the below steps to configure the selector.

1. Click on ‘Enter SCA Component’ to configure the Default Component. This will list all the components available. (This will list only components that are having a matching interface). Select the component you want as the default component.

It is very important to provide the default component as an exception will be thrown if no selection criteria matches and no default component present.

2. Click on ‘Add Date selection entry’ icon (the + icon marked in the image).

3. Configure the dates.

My selector is configured to select component2 if the date range is May 01, 2010 to may 04, 2010.

4. Configure the ‘Selection Criteria’. Here we have three options to configure. Current Date, Java, and XPath. This should return a date.

Now add this selector to the assembly diagram and invoke when you want to route a service call dynamically to a component.

For those who want to try this, here is the PI for this example. HelloSelector


Bindings in WebSphere Integration Developer

Posted by | Posted in Websphere Process Server / Integration Developer | Posted on 16-12-2009

Tagged Under : , , , ,

Bindings in WebSphere Integration Developer

Imports and exports in WebSphere Integration Developer need binding information. This binding information will contain the protocol or any other data required by other modules to use this export/import. The meaning of import binding is different from export binding.

Import binding talks about how to access an external service. The default binding method for import is SCA bindings.

An export binding talks about how the service will be published to other modules or other services. An export binding can be HTTP Binding, Messaging Binding(MQ Binding, JMS bindings, MQ JMS etc), SCA Binding and Web Service binding. If the modules are running in same server, it is recommended to use an SCA binding instead of web service or JMS bindings. It is more easy and fast.


com.ibm.wbit.comptest.common.utils.TestException: Could not find module

Posted by | Posted in Websphere Process Server / Integration Developer | Posted on 29-11-2009

Tagged Under : , , , ,

Today I was trying to test a business process using the Integration Test client. First I right clicked on my module in the assembly diagram and clicked on Test Component to test my module. It showed me a message, its publishing the module and it gave me an error in my test client. The error was

com.ibm.wbit.comptest.common.utils.TestException: Could not find module XXX
	at com.ibm.wbit.comptest.controller.util.GeneralUtils.getModuleFor(Unknown Source)
	at com.ibm.wbit.comptest.controller.invocation.impl.Invoker.getModule(Unknown Source)
	at com.ibm.wbit.comptest.controller.invocation.impl.Invoker.managedRun(Unknown Source)
	at com.ibm.wbit.comptest.controller.invocation.impl.Invoker.run(Unknown Source)
	at com.ibm.wbit.comptest.controller.invocation.impl.BaseInvocationHandler.invoke(Unknown Source)

I was not sure what the issue was. My module was there and it was showing as published. After few minutes search I got the solution. If your module is little big, first make sure that you have published your module and then start the test client. I think the test client does not have patience to wait for the module to be published and that was causing the problem :-)


Receive choice activity or pick activity in WebSphere Process Server

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

Tagged Under : , , , ,

Receive choice activity or pick activity in WebSphere Process Server

A receive choice activity or pick activity is used for receiving different messages (or operations). This activity is extremely useful if you have an interface with more than one operation and you want this interface as the Interface partner for a business process. If you pass an interface with more than one operation to a normal receive activity it would throw you an error message saying “The process does not implement the operation ‘xxx’ of the port type ‘xxx’”. In this case the only option for us to use the interface is to use receive choice activity. To use a receive activity, follow the below steps.

1. Delete the existing receive activity
2. Drag and drop receive choice activity to your business process. A receive choice activity will be created with one choice in it.


3. Add a new receive by right click on receive choice activity and select ‘Add Receive’.


4. Select the first receive and go to Details tab in your properties window. Select your interface partner, operation and the input parameters. (Change the display name of receive if you want.).


5. Add a reply activity.

6. Repeat these steps for all the operation you have in your interface.

In my case I had two operations in my interface and after configuring receive choice activity my business process look like the one shown below.


If you are getting an error message saying, “The process is not startable. No receive choice or receive activity was found that creates a new process instance and does not have incoming links or preceding basic activities.”, make sure that you have checked the “Create a new process instance if one does not already exist” checkbox in the details tab of Receive choice properties window.



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.