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.

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

One of our project was developed and supported by an external vendor and due to some reasons (of course not known to me) our company decided to do all the future enhancements and support by our self. The project uses WebSphere Process Server as the middle ware and WebSphere portal server as the front end. All the communications between the portal and process server was using web service export. During the knowledge transfer session I noticed that for setting the endpoint url for different environments in their proxy client, they were editing the ServieLocator class. So I just want to post a small note on how to set the endpoint URL without changing the generated proxy classes.

To change the endpoint url for a web service we have a setEndpoint method in our proxy class. By default I guess the endpoint url will be pointing to localhost. By passing the new endpoint url to the setEndpoint method we can change it to a new host. For eg: in our hello world web service client, to change the end point url, change the code as shown below.

	HelloWorldProxy proxy = new HelloWorldProxy();
	proxy.setEndpoint(endPointurl);

That’s it. We are done with changing the endpoint url. We can store this endpoint url as part of our properties file and read it from there. This will ensure that, we get different endpoint urls for different environments

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.

javax.net.ssl.SSLHandshakeException: certificate expired

javax.net.ssl.SSLHandshakeException: certificate expired. We get this exception when we try to invoke a web service from WebSphere Application Server 5.1. (In fact you will get this exception if your java version is 1.4.2_02 and earlier.) The complete stack trace of the exception is

WebServicesFault
 faultCode: Server.generalException
 faultString: javax.net.ssl.SSLHandshakeException: certificate expired
 faultActor: null
 faultDetail:
 
javax.net.ssl.SSLHandshakeException: certificate expired
        at com.ibm.ws.webservices.engine.WebServicesFault.makeFault(WebServicesFault.java:158)
        at com.ibm.ws.webservices.engine.transport.http.HTTP11Sender.invoke(HTTP11Sender.java:330)
        at com.ibm.ws.webservices.engine.transport.http.HTTPSender.invoke(HTTPSender.java:87)
        at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:212)

We get this exception because our trust store contains an expired Class 2 and Class 3 certificates. The Class 3 root certificate is used for authenticating web sites, signed code, SSL, OFX, and Administrator certificates. Class 2 root certificates are used for authenticating users and individuals.

The solution to this problem is to update the Class 2 and Class 3 certificates in our trust store. To do this either download the latest certificates from http://www.verisign.com/support/roots.html or extract the Class 2 and Class 3 certificates from a newer version of Java.

To import the latest certificates follow the below steps. The default password for sun cacerts is changeit

1. Delete the existing certificates by issing the following commands.
%JAVA_HOME%/bin/keytool -delete -alias verisignclass2ca -keystore %JAVA_HOME%/jre/lib/security/cacerts
%JAVA_HOME%/bin/keytool -delete -alias verisignclass3ca -keystore %JAVA_HOME%/jre/lib/security/cacerts

2. Import the new certificates by issuing the following command
%JAVA_HOME%/bin/keytool -import -v -keystore %JAVA_HOME%/jre/lib/security/cacerts -alias verisignclass2ca -file /home/Albin/certs/verisignclass2ca.arm

%JAVA_HOME%/bin/keytool -import -v -keystore %JAVA_HOME%/jre/lib/security/cacerts -alias verisignclass3ca -file /home/Albin/certs/verisignclass3ca.arm

Here verisignclass2ca.arm and verisignclass3ca.arm are the two new Class 2 and Class 3 certificates we imported. The above commands assume that your trust store is pointing to %JAVA_HOME%/jre/lib/security/cacerts, if it points to a different file, change the location.

For those who are facing difficulties in extracting the new certificates, download it from here. verisignclass2ca and verisignclass3ca. This is the certificates I have used when I encountered this issue.