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

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.

CNTR0031W: Error starting CMP bean wcfull#WebSphereCommerceServerExtensionsData.jar#XXXX: 
 javax.naming.NameNotFoundException: Context: localhost/nodes/localhost/servers/server1, name: jdbc/Default: First component in name Default not found.  Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0
	at com.ibm.ws.naming.ipcos.WsnOptimizedNamingImpl.do_resolve_complete_info(WsnOptimizedNamingImpl.java:968)
	at com.ibm.ws.naming.cosbase.WsnOptimizedNamingImplBase.resolve_complete_info(WsnOptimizedNamingImplBase.java:1431)
	at com.ibm.WsnOptimizedNaming._NamingContextStub.resolve_complete_info(Unknown Source)
	at com.ibm.ws.naming.jndicos.CNContextImpl.cosResolve(CNContextImpl.java:3493)
	at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1521)
	..............................
 
JDBCPersister W CNTR0032W: Error creating CMP persister using datasource: jdbc/Default
BeanMetaData  E CNTR0035E: EJB container caught com.ibm.ejs.container.ContainerException: ; nested exception is: 
	com.ibm.websphere.cpi.CPIException: Persister creation failed.The bean's J2EEName is wcfull#WebSphereCommerceServerExtensionsData.jar#XXXX. The data source name is jdbc/Default.; nested exception is: 
	javax.naming.NameNotFoundException: Context: localhost/nodes/localhost/servers/server1, name: jdbc/Default: First component in name Default not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
	at com.ibm.ejs.container.BeanMetaData.completeInitialization(BeanMetaData.java:1299)
	at com.ibm.ws.runtime.component.EJBContainerImpl.createBeanMetaData(EJBContainerImpl.java:1039)
	at com.ibm.ws.runtime.component.EJBContainerImpl.createModuleMetaData(EJBContainerImpl.java:830)
	at com.ibm.ws.runtime.component.EJBContainerImpl.createMetaData(EJBContainerImpl.java:1575)
	at com.ibm.ws.runtime.component.MetaDataMgrImpl.createFactoryMetaData(MetaDataMgrImpl.java:115)
	......................

This was the exception I got when I tried to start my WebSphere Commerce Full Test environment after creating a new EJB. Even though the solution was very simple, for me it took some time to figure it out what exactly went wrong. If any of you facing the same problem, then here is the fix.

Open your ibm-ejb-jar-bnd.xmi file. Search for jdbc/Default. Here jdbc/Default is the name of the data source that was not found by the server. You will be able to see an entry like

	<defaultDatasource xmi:id="ResourceRefBinding_1242722240919" jndiName="jdbc/Default"/>

Just to remove the above line and your server will again start properly.