Me consultant, you "Jane"
I recently consulted for a talented Java™ developer who was working on a research project. "Jane" was under a deadline to build applications for both WebSphere ESB and WebSphere Process Server. Although she was not familiar with WebSphere Integration Developer, she was pretty familiar with Java and other development environments, and confident enough to set out to meet her deadline using WebSphere Integration Developer, with the intention of learning whatever she needed to know about this new integration development environment along the way. But after about a half-dozen projects ended up not building, she came to me for help. I estimated that she was taking about five times longer to complete this development than someone at her skill level should be taking. What was the problem? Was it the product or the way it was installed? Was it Jane or her inability to apply her prior experience?
Simply put, Jane ran into a handful of common snags that I have seen customers and colleagues run into countless times before her. Once these issues were resolved, Jane was not only relieved, but significantly more productive to boot. Now she debugs quickly, builds projects successfully, and her integrated test environment runs smoothly.
And so I am using this space to share a handful of tips you should know about working with WebSphere Integration Developer that may just improve the quality of your (development) life too. In a nutshell, these are my tips:
- Modify the installation path
- Check for product updates
- Employ code versioning
- Add libraries with the dependency editor
- Ensure the server starts clean
- Check the administration console for installed projects
- Remove emulators from the test component wizard
- Become familiar with the XML representation of components
Continue below for more information on each item.
Modify the installation path
There is a 259 character limit for Windows® path lengths. If WebSphere Integration Developer is installed under Program Files, errors such as the following can occur:
Listing 1. URI Length Error
[7/23/06 16:59:14:500 EDT] 0000009f WorkSpaceMast E The URI length is greater than the Windows limit of 259 characters. Unable to create or update file: C:\Program Files\IBM\WebSphere\ID\6.0\pf\wps\wstemp\10c9d2da4bb\ workspace\cells\widCell\applications\inEnergyProcessApp.ear\deployments\ inEnergyProcessApp\inEnergyProcessEJB.jar\META-INF\wsdl\com\ibm\extremeblue\ inenergy\process\outageprocess\OutageProcess.wsdl
The solution is to use a shorter install path such as C:\WID, rather than the full product name. As a temporary fix, you can also use shorter business integration module names, which is what Jane did initially to fix this error (Figure 1).
Figure 1. Shorter installation path
Check for product updates
Really, I cannot emphasize this enough. This is back-to-basics, but very necessary. I have seen countless situations where an unpatched development environment was the root cause of show-stopping issues. The fact is that WebSphere Integration Developer is our newest business integration development environment, so new updates are introduced frequently. At the time of this article's publication, the latest version of WebSphere Integration Developer is V126.96.36.199 with interim fix 9. You can check for updates when you're in the product by selecting Help => Welcome => IBM Rational Product Updater (Figure 2).
Figure 2. WebSphere Integration Developer product update menu
It is equally important to patch your integrated test server (WebSphere Process Server), which is separate from the WebSphere Integration Developer update process. To determine your server version, open the administration console with a browser, which is located at http://localhost:9060/admin by default. The initial screen shows the version number. At the time of this article's publication, the latest version for WebSphere Process Server is 188.8.131.52 (Figure 3).
Figure 3. Determine WebSphere Process Server version
If needed, you can download WebSphere Process Server and WebSphere ESB patches from the WebSphere support site (see Resources).
Employ code versioning
Jane did not have source control, which significantly affected her productivity. WebSphere Integration Developer has a CVS view so you can setup source control quickly. This will save you countless hours in the end, even if you only setup a CVS repository on the same machine as WebSphere Integration Developer. For instance, should you find a bug in your assembly, with proper versioning you can check back to previous versions to see when the bug was introduced.
On Jane's smaller projects, we used project interchanges to backup her workspace periodically. A project interchange file is a ZIP file that can backup any number of projects in your workspace. You can create one by selecting File => Export.. => Project Interchange. (Figure 4)
Figure 4. Project Interchange Export
I recommend creating a project interchange or a new source control version after each SCA component you build. Make sure you use descriptive filenames for interchange ZIP files. For example, I like to name them by date.
Add libraries with the dependency editor
Using WebSphere Integration Developer libraries is almost always a good idea so you can reuse business objects and WSDL interfaces. I have seen problems surrounding libraries that produce errors similar to the following:
Listing 2. Library-related errors
CWSCA8025E: The WSDL PortType defined in the interface is invalid. CWSCA8011E: Operation checkCredit cannot be resolved.
These errors indicate that a WSDL interface can't be found. A common cause for this is an undefined library dependency for a module. Libraries should be added by right-clicking the module and selecting Dependency Editor (Figure 5).
Figure 5. Library dependency editor
Ensure the server starts clean
Jane asked me to help her decipher an exception she was running into while invoking the component test wizard on a WebSphere Integration Developer assembly. The stack trace did not include any of the code in her workspace; it was a runtime exception by the business process container. When I see this type of error, I often look to the WebSphere Process Server test server itself to ensure it is patched and running normally. Sure enough, when I looked at the server startup logs (which are automatically displayed on the WebSphere Integration Developer console when you restart the server), there were some SIBus errors. When you run into a WebSphere Process Server or ESB runtime exception while testing your applications, restart the server and make sure that it comes up clean. It is important to distinguish a problem with your application from a server runtime problem. You should see a message like "Server server1 open for e-business" when the test environment is up. (Figure 6)
Figure 6. Normal test Server Startup
Check the administration console for installed projects
I was able to isolate Jane's issue to an SIBus exception. WebSphere Integration Developer business integration applications make use of the WebSphere Application Server SIBus (system integration bus) heavily. The root cause of her problem was that she had too many versions of the same application installed on the test server and the SIBus destinations (or JMS plumbing used by WebSphere Process Server and ESB assemblies) started to conflict.
What made this problem exasperating for Jane was that she didn't even know she had more than one application deployed on the server! The server view in Eclipse-based development environments only shows you the projects deployed on the server that are in the current workspace (Figure 7).
Figure 7. Server view of deployed applications in WebSphere Integration Developer
While attempting to develop her first WebSphere Integration Developer applications, Jane used over a dozen workspaces. This is usually good; I often create completely new workspaces for each project. When faced with a debugging problem, Jane would create a new workspace and try things a different way. Each time, she left a module deployed on the server from the previous workspace.
The best way to determine what is deployed in your test environment is to use the WebSphere Application Server administration console which, again, can be accessed with a Web browser at the default address: http://localhost:9060/admin (Figure 8).
Figure 8. Enterprise application page in the administration console
As you can see in Figure 8, you can view deployed enterprise applications by selecting Applications => Enterprise Applications. Use the Uninstall button to remove redundant or old modules.
Important: Do not remove runtime-related enterprise modules, such as BPEContainer. Figure 8 shows the default applications installed on the integrated test server. Your application would appear in this same list. Removing any of these default applications is strongly discouraged.
Once we removed several unneeded variants of Jane's application, the server started cleanly and without any SIBus conflicts.
Remove emulators from the test component wizard
Excited to have resolved her problems, Jane continued to test her assembly -- but something strange happened. Her tests did not return errors, but they also did not seem to execute any behavior. I immediately asked if she knew about the emulator functionality of the test component wizard. (Figure 9)
Figure 9. Emulator removal from component test wizard
Consider Figure 9, which shows the Configurations tab of the test component wizard. By default, WebSphere Integration Developer unit tests only the component you have right-clicked to test and emulates the others: it stubs out the interface associated with downstream components and returns default values. The assumption that the wizard unit tests all the components in an assembly is such a common misconception that I've seen customers claim that the component test wizard is actually broken!
Jane wanted to test all the components in her assembly, and so we removed all the emulators. What happened next? Success! A BPEL component orchestrated the other SCA components and returned the result she expected.
Become familiar with the XML representation of components
If you really want to become more productive with WebSphere Integration Developer, then one of the most valuable investments of your time is to pay attention to the underlying XML representations of WSDL interfaces, business process components, and business objects. All of these components use XML standards such as XML Schema Definitions (XSD) for business objects, Business Process Execution Language (BPEL) for business processes, and Web Services Definition Language (WSDL) for interfaces.
To show you why this can be helpful, consider the following error:
Listing 3. WebSphere Integration Developer interface problem
cvc-attribute.3: The value 'myObject:Report' of attribute 'type' on element 'xsd:element' is not valid with respect to its type, 'QName'.
To fix this, your first instinct would likely be to find out what file in your workspace is causing the error. This is usually quite obvious in an Eclipse IDE, because little Xs mark the spot. In this case, the culprit is an interface called SimpleInterface. After double-clicking on the file we get the interface editor shown in Figure 10.
Figure 10. Interface editor
As you can see, the interface editor provides no way to debug the problem. To really get to the root cause, you need to look at the underlying XML representation of the interface which is a *.wsdl XML document. You can edit the XML by right-clicking the interface and selecting Open With => XML Source Page Editor. The contents of SimpleInterface.wsdl are as follows:
Listing 4. SimpleInterface.wsdl
<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions xmlns:myObjects="http://MyLibrary/MyBusinessObjects"  xmlns:tns="http://MyLibrary/SimpleInterface" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="SimpleInterface" targetNamespace="http://MyLibrary/SimpleInterface"> <wsdl:types> <xsd:schema targetNamespace="http://MyLibrary/SimpleInterface" xmlns:bons1="http://MyLibrary" xmlns:tns="http://MyLibrary/SimpleInterface" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://MyLibrary/MyBusinessObjects" schemaLocation="Report.xsd"/> <xsd:element name="checkCredit"> <xsd:complexType> <xsd:sequence> <xsd:element name="code" nillable="true" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="checkCreditResponse"> <xsd:complexType> <xsd:sequence> <xsd:element name="report" nillable="true" type="myObject:Report"/>  </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name="checkCreditRequestMsg"> <wsdl:part element="tns:checkCredit" name="checkCreditParameters"/> </wsdl:message> <wsdl:message name="checkCreditResponseMsg"> <wsdl:part element="tns:checkCreditResponse" name="checkCreditResult"/> </wsdl:message> <wsdl:portType name="SimpleInterface"> <wsdl:operation name="checkCredit"> <wsdl:input message="tns:checkCreditRequestMsg" name="checkCreditRequest"/> <wsdl:output message="tns:checkCreditResponseMsg" name="checkCreditResponse"/> </wsdl:operation> </wsdl:portType> </wsdl:definitions>
Since the error in Listing 3 mentions "myObject:Report" the line marked with  immediately stands out. Report is a complex XML Schema type which is defined in another file (probably called Resport.xsd). In order to reference external complex types, a namespace identifier is used. On line  the namespace identifier is myObject. However, if we look at line , the namespace was declared as myObjects with an extra letter "s " Changing either of them so that they are consistent resolves the error.
As you can see, debugging the above problem without looking at the *.wsdl file would have likely involved completely recreating the SCA interface component. Taking a peek at the underlying XML representation enabled us to fix the problem much more effectively and efficiently. The WebSphere Process Server and ESB runtimes honor the underlying XML files for the components you build in WebSphere Integration Developer. In fact, the underlying XML files can be thought of as the instructions that the runtime executes. If you can debug problems at the XML level, you can be far more productive than attempting to debug at the graphical level in WebSphere Integration Developer.
We have all been in Jane's position. Few IT practitioners have the time to go through the latest Redbooks, product tours, and Information Center documentation to really get the most productivity out of a development tool. Besides, it's often a lot more fun to get in the driver's seat and pave your own path. Hopefully, this information will help you hit the ground running quickly -- and safely.
- WebSphere Software Support
- WebSphere Integration Developer product information
- WebSphere Process Server product information
- WebSphere ESB product information
- developerWorks WebSphere
- Patterns: Building Serial and Parallel Processes for IBM WebSphere Process Server V6
- WebSphere Process Server and WebSphere Integration Developer resources