From time to time, you may encounter some limitations in using the integration test client. In most situations, you can successfully work around these limitations.
Some known limitations are:
These limitations are discussed in the following sections.
If you are using standalone WebSphere Process Server rather than the instance of WebSphere Process Server that is included with WebSphere Integration Developer, you will find that the integration test client will not work with WebSphere Process Server because some essential test controller JAR files are missing from the WebSphere Process Server lib directory.
To obtain and install these JAR files, complete the following steps:
After testing an application in the integration test client no errors may be shown; however, when the application is deployed to the server and tested in the Business Process Choreographer Explorer and the Web Services Explorer, it can still result in a null pointer exception (NPE).
The integration test client has different behavior than the Business Process Choreographer Explorer and the Web Services Explorer. The test client is used to unit test the components, so by default, they are sending empty strings for the data for all of the values that you leave blank.
In comparison, it appears that the Business Process Choreographer Explorer and the Web Services Explorer are sending in data only when you specify it, null or otherwise. Many of your rules or code might be accessing items that are null or undefined, resulting in errors.
During the integration test, if you receive a null pointer exception in the root exception stack, check to see if the data that was passed in (or received) is a null value.
This limitation is only applicable in cases where an XSD for a business object is created outside of the business object editor. (The editor will not allow you to create an XSD that exposes this limitation.)
The limitation manifests itself when using the test client to enter values into a business object based on an XSD that contains duplicate names. When the business object is created you will notice that all values belonging to elements with the same name, except for the last one, will be null by the time the business object is received by an operation.
This limitation results from the way that business objects are created internally. Since each property is stored by name, duplicate names are not allowed.
The solution is to ensure that XSDs created outside of the business object editor have no duplicate names.