As you may be aware, the primary way that data is represented within WebSphere Process Server is as a Business Object (BO). This is essentially a container that houses all the values of your data and can be manipulated or inspected within the various components that exist in WebSphere Process Server. This blog entry is to break down what needs to be understood about these Business Objects and how they are handled by WebSphere Process Server specifically. Please note, this entry is only directly applicable to EMF style BOs, not Lazy parsing style (this is new in version 7 of WebSphere Process Server).
The first thing to know is that Business Objects are represented as XML Schemas in WebSphere Process Server. For instance, if you are using the WebSphere Integration Developer (WID) to create your object, you can observe that once you have finished modeling your BO in the BO Editor, it has created an xsd file for you within the module. This is nothing more than an XML schema containing element and attribute declarations. These schemas can also exist directly in a wsdl file as well.
Regardless of where the schemas are defined (wsdls and xsds), the important aspect that differentiates the elements is their name as well as the namespace in which they are defined. What this means in the WebSphere Process Server world is that if there are multiple elements defined that have the same name and are defined in the same namespace this has potential to cause problems, even if the elements are defined in totally different actual files.
The reasoning for this is that when all these elements are loaded into the EMF system, which is what the BO as modeled in at runtime, these two things are what tells them apart. You can essentially think of a namespace as a big bucket in EMF. Every element and attribute that is defined in a namespace is tossed into a common bucket and is known from then on as a "feature" (more on this in a moment). The only caveat, is that there can only be one element or attribute with a specific name existing in this namespace bucket. So what essentially happens is that if you have defined two different elements with the same name in the same namespace, at runtime, only one of these will be usable. When a component attempts to use the other one, it will instead load the unexpected element and this is where problems can arise since this element may actually have distinct structures in each case. This them becomes a guessing game on which element will actually be loaded and used (and this ultimately will depend on the classloading policy in place).
There is a good technote that describes this behavior and a sample of how to remedy it:
EMF FeatureNotFoundException with multiple schemas sharing namespace that have global elements
Whether the root cause is something as mentioned above or some other problem related to your schemas, the exceptions in WebSphere Process Server can be confusing since the data is stored in EMF and the terminology is slightly different. In EMF, the elements and attributes you would see in your xml schema are referred to as "features". So when you receive an exception of FeatureNotFound, this correlates to the system being unable to find a particular element or attribute within the object it is searching. The first place to check, of course, is if there even exists such as element and if so, you can move on to ensuring that no duplicates exist.
WebSphere Integration Developer provides a good warning if duplicates do exist in the modules or a modules dependency, so this should help to catch most instances. However, when adding in shared libraries or other schemas just sitting in the server's classpath, this would need to be investigated manually. SCA and ArtifactLoader trace may be enabled to help in finding what is loaded and from where as needed.