This topic applies only to the IBM Business Automation Workflow Advanced
configuration.

Duplicate business objects

Duplicate business objects are caused when more than one complexType elements with the same namespace are present in multiple XML Schema Definition (XSD) or Web Services Description Language (WSDL) files in the same module or library. As a result, the business object that is created at run time might have the wrong definition.

Duplicate XML schema definitions

Multiple complexType elements that are defined in various XSD files and WSDL files with the same name and target namespace create duplicate XML element types. Business objects are saved in XSD files, and during application design, they are referred to by their related XML element type and namespace.

Imported XSD and WSDL files can contain duplicate XML element type schema definitions. At run time, these duplicate definitions are treated as different Java™ object types, even though they are referenced by the same business object type and namespace.

When you have duplicate business object definitions that are defined in your application and related libraries, you might have issues with object comparison at run time. Because interface settings and other component settings are described by business object types, a runtime business object instance might reference the wrong schema definition when matching with an interface input, output, or fault. You might see similar problems with WSDL interface operation types. The type matching might fail, even if the two definitions are identical in the XSD file. When the definitions are different, and the wrong type is associated with the object, errors might occur during serializing or deserializing between an XML data stream and a business object.

You might not notice the duplicates if they are in another library or module in the application, in a business level application (BLA), or in shared libraries.

To avoid problems with duplicate XML element types, ensure that your XSD and WSDL files from different libraries and applications use unique target namespaces.

By default, duplicate business objects will produce a warning in the Problems view. You can configure whether duplicates produce a warning or error by selecting Window > Preferences > Business Integration > Errors/Warnings and then selecting either Warning or Error next to Duplicate business objects.

Note: Although changing warnings to be reported as errors means you're more likely to notice them, errors on a project prevent it from being deployed.

The following example shows part of an XSD file schema definition that includes the definition of an XML element type (which is a complexType). In the following example, the name of the XML element type is defined by name="IDType", and its namespace is defined by targetNamespace="http://Arrays" in the xsd:schema tag.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://Arrays" xmlns:tns="http://Arrays">
	<xsd:complexType name="IDType">
		<xsd:sequence>
			<xsd:element minOccurs="0" name="id_type" type="xsd:int"></xsd:element>
		</xsd:sequence>
	</xsd:complexType>

Duplicate business objects and the business object programming model

When you are using the BOFactory.create() API, consider the following recommendations to ensure that the correct definition is chosen:

Create the business object by referencing its parent data object when the child object is not unique.
Ensure that the parent object is unique.
Use the correct schemaLocation values in XSD and WSDL files when you include and import namespaces.

This scenario is of concern when multiple copies of the same complexType or global element with the same namespace have different definitions. It is good practice to avoid having duplicate business object definitions for top-level business objects in the same module. If you must have duplicate business objects at the child level, then do not create the business objects by using the BOFactory.create() API with a direct reference to the target namespace. Instead, create the business objects by referencing the parent data object so that you remove the ambiguity of which definition to select.

Example

Customer.xsd has an import for {http://address}Address (located under the root/customer folder of the module)

Order.xsd has an import for {http://address}Address (located under the root/order folder of the same module)

Note: The two Address.xsd files in module root/order and module root/customer have different definitions. Using the methods in the following example causes one of the definitions to be chosen at random.

BOFactory.create("http://address", "Address") 
BOType.getType("http://address", "Address")

Solution

To solve the issue, use a DataObject as described in the following example to choose the correct definition that is based on the reference to the Customer type.

DataObject customer = BOFactory.create("http://customer", "Customer");          
address = customer.createDataObject("address");

Similarly, the correct definition is chosen based on the reference to the Order type.

DataObject order = BOFactory.create("http://order", "Order");          
orderAddress = order.createDataObject("address");