IBM BPM, V8.0.1, All platforms > Migrating and upgrading your IBM BPM environment > Migrating from other products > Migrating from WebSphere InterChange Server or WebSphere Business Integration Server Express > Troubleshooting migration from WebSphere InterChange Server or WebSphere Business Integration Server Express

New behavior for heritage APIs in IBM BPM, Version 8.0.1

In V8.0.1 of IBM BPM, heritage APIs use IBM BPM Service Data Objects to store attribute states and data that were formerly stored by the BusinessObjectInterface interface. As a result, the behavior of some method calls in the BusinessObjectInterface and CxObjectContainerInterface interfaces has changed.

The major change to the heritage APIs (HAPIs) in IBM BPM V8.0.1 is that the WebSphere InterChange Server BusinessObjectInterface interface is no longer the root storage object for HAPI. Instead, IBM BPM Service Data Objects (SDO's) are now used to store attribute states and data.

If you use the Java equivalence operator and weakly typed attribute principles, the behavior of the method calls in the BusinessObjectInterface and CxObjectContainerInterface interfaces is different, as described in the following sections:


Use the Java equivalence operator when performing a Set operation followed by a Get operation

A different BusinessObjectInterface object is returned when performing a Set operation followed by a Get operation of a BusinessObjectInterface object for one target attribute. The following table describes the previous behavior, current behavior, and an example of what to change if you previously had used the Java equivalence operator when performing a Set operation followed by a Get operation.

Behavior changes: Using the Java equivalence operator with Set and Get operations
Behavior type Description
Behavior before WebSphere Process Server V7.0

The same BusinessObjectInterface container that was set was also retrieved, and you could use the Java equivalence operator “==” to determine if they were the same.

Example:

boolean b = (JavaObjectA == JavaObjectB)

Behavior after WebSphere Process Server V7.0

The original BusinessObjectInterface container is discarded, and when you perform a Get operation to retrieve the BusinessObjectInterface object, a new container is created. The returned container is not the same object, but the root object that it wraps is the same object. A new method, isEquivalent, has been added to the BusinessObjectInterface class: BusinessObjectInterface.isEquivalent(BOI). When you want to determine if the two BusinessObjectInterface objects are equivalent, use the isEquivalent method to perform the comparison.

Example of new behavior

The following example shows the use of isEquivalent.

You have a BusinessObjectInterface object of type MasterBusinessObject with the attribute Attr_Nine, which is a BusinessObjectInterface object of type HelloWorld:

BusinessObjectInterface mboBOI, hw1BOI, hw2BOI;
hw1BOI.setAttrValue("Message", "hw1BOI_message");
hw1BOI.setVerb("Create");
mboBOI.setAttrValue("Attr_Nine", hw1BOI);
hw2BOI = mboBOI.getAttrValue("Attr_Nine");

Instead of:

boolean result = (hw1BOI == hw2BOI); assertTrue(result);

Use this:

boolean result = hw1BOI.isEquivalent(hw2BOI); assertTrue(result);


Use the Java equivalence operator when setting a BusinessObjectInterface object to more than one target attribute

Setting a BusinessObjectInterface object to more than one target attribute sets a cloned object. This applies both to elements of a BusObjArray class and to multiple target attributes. The following table describes the previous behavior, current behavior, and an example of what to change if you previously had used the Java equivalence operator when setting a BusinessObjectInterface object to more than one target attribute.

Behavior changes: Using the Java equivalence operator with more than one target attribute
Behavior type Description
Behavior before WebSphere Process Server V7.0

You could set a BusinessObjectInterface object to multiple locations, and all of the locations contained a reference to the original BusinessObjectInterface object. If you changed the attribute in one BusinessObjectInterface object, that change was reflected in all of the other references for that object.

Behavior after WebSphere Process Server V7.0

Service Data Object (SDO) rules prevent you from setting the same SDO to more than one target property. If you try to set the SDO to more than one target property, the SDO moves from one attribute to the next, leaving a "null" value at the previous attribute location. Now, instead of leaving a "null" value when the BusinessObjectInterface object is set to a second location, third location, and so on, the object is cloned into the multiple locations.

For example, you have a BusinessObjectInterface object of the type MasterBusinessObject, with the attributes Attr_Nine and Attr_Eleven that are of the type HelloWorld. If you set the same HelloWorld object to both attributes, Attr_Nine is assigned the original object and Attr_Eleven is assigned a clone. The clone is a snapshot of the object at the time that it is cloned.

If you want to determine if two BusinessObjectInterface objects are equivalent, do not use the Java equivalence operator; instead, use the isEquivalent method to perform the comparison.

Example of new behavior

The following example shows the use of isEquivalent and clones. You have a BusinessObjectInterface object of type MasterBusinessObject, with the attributes Attr_Nine and Attr_Eleven that are of type HelloWorld:

BusinessObjectInterface mboBOI;
BusinessObjectInterface hw1BOI, hw2BOI, hw3BOI;
hw1BOI.setAttrValue("Message", "hw1BOI_message");
hw1BOI.setVerb("Create");
mboBOI.setAttrValue("Attr_Nine", hw1BOI);
mboBOI.setAttrValue("Attr_Eleven", hw1BOI);
hw2BOI = mboBOI.getAttrValue("Attr_Nine"); 
hw3BOI = mboBOI.getAttrValue("Attr_ Eleven "); 

Instead of:

boolean result = hw2BOI == hw3BOI); assertTrue(result);

Use isEquivalent instead:

boolean result = hw2BOI.isEquivalent(hw3BOI); assertTrue(result);

The cloned objects do not share a reference, and changes to the original BusinessObjectInterface object are not reflected in the cloned BusinessObjectInterface object:

hw1BOI.setAttrValue("Message", "hw1BOI_message changed");
boolean result = hw1BOI.isEquivalent(hw2BOI);
assertTrue(result);
boolean result = hw1BOI.isEquivalent(hw3BOI);
assertFalse(result);
boolean result = hw2BOI.isEquivalent(hw3BOI);
assertFalse(result);


Use the Java equivalence operator when you set and retrieve a BusinessObjectInterface object from the CxObjectContainerInterface interface

The following table describes the previous behavior, current behavior, and an example of what to change if you previously had used the Java equivalence operator when setting and retrieving a BusinessObjectInterface object from the CxObjectContainerInterface interface.

Behavior changes: Using the Java equivalence operator with the CxObjectContainerInterface interface
Behavior type Description
Behavior before WebSphere Process Server V7.0

When you set and then retrieved a BusinessObjectInterface object from the CxObjectContainerInterface interface, you could use the Java equivalence operator “==”because the BusinessObjectInterface container that was retrieved was the same BusinessObjectInterface container that was set.

Behavior after WebSphere Process Server V7.0

You must use the BusinessObjectInterface.isEquivalent(BOI) method.

Example of new behavior

The following JUnit test code demonstrates the old and new behavior.

CxObjectContainerInterface testCxObjectContainerInt;
BusinessObjectInterface mB01, mB02, mB03;

testCxObjectContainerInt.insertBusinessObject(mB01);
testCxObjectContainerInt.setBusinessObject(1, mB01);
BusinessObjectInterface mB02 = testCxObjectContainerInt.
getBusinessObject(0));
BusinessObjectInterface mB03 = testCxObjectContainerInt.
getBusinessObject(1));
assertTrue(mB01 == mB02);
assertTrue(mB01 == mB03);
assertTrue(mB02 == mB03);

This Java equivalence operator no longer works because the BusinessObjectInterface object that is returned by CxObjectContainerInterface.getBusinessObject(int index) is not the same Java object that was set to CxObjectContainerInterface.

In the following code, the equivalence operator is replaced by the method BusinessObjectInterface.isEquivalent(BOI):

boolean result1 = mB01.isEquivalent(mB02)
assertTrue(result1);
boolean result2 = mB01.isEquivalent(mB03)
assertFalse(result2);
boolean result3 = mB02.isEquivalent(mB03)
assertFalse(result3);

The cloned objects do not share a reference, and changes to the original BusinessObjectInterface object are not reflected in the cloned BusinessObjectInterface object:

hw1BOI.setAttrValue("Message", "hw1BOI_message changed");
boolean result = mB01.isEquivalent(mB02;
assertTrue(result);
boolean result = mB01.isEquivalent(mB02;
assertFalse(result);
boolean result = mB02.isEquivalent(hw3BOI);
assertFalse(result);


Use weakly typed attribute data types for the BusObj class validData methods

The following table describes the previous behavior, current behavior, and an example of what to change if you previously had used weakly typed attribute data types in WebSphere InterChange Server or WebSphere Business Integration Server Express for the BusObj class validData methods.

Behavior changes: Using weakly typed attribute data types for BusObj class validData methods
Behavior type Description
Behavior before WebSphere Process Server V7.0

For the BusObj class validData methods, attribute data types were weakly typed in WebSphere InterChange Server or WebSphere Business Integration Server Express. This allowed some odd data-type combinations.

For example, if a business object had an attribute that was of type boolean but you used a set method that had a string parameter, you were able to set the string “not a boolean” into an attribute that was type boolean. As long as you used the getString method, they could get the string “not a boolean” back.

Behavior after WebSphere Process Server V7.0

These attribute data types are now strongly typed. If a data type was valid but now is not valid, a CollaborationException exception is thrown, with message number 1802. Because WebSphere Process Server is strongly typed, you cannot put a String value into an Attribute of type boolean. Even if you used the Java conversions for strings into the boolean values of true and false, there is no way to return the original value of “not a boolean”. The only possible returned value is true or false.

Therefore, attributes are now strongly typed for doubles-floats or int-long; these can be used interchangeably where Java provides automatic casting. However, as with any casting of types, you can expect some loss of precision when fields are demoted. If a type is not valid for the attribute to which it is set, but it used to be valid in WebSphere InterChange Server or WebSphere Business Integration Server Express, then a CollaborationException exception is thrown, with message number 1802. This is a new message number; the message definition is located in the InterchangeSystem.txt message file.

Example of new behavior

If a type is not valid for the Attribute to which it is set, but it used to be valid in WebSphere InterChange Server, a CollaborationException with message number 1802 will be thrown. This is a new message number, the Message definition is located in the InterchangeSystem.txt message file:

try
{
BusObj mBO = new BusObj("MasterBusinessObject");
mBO.set(“Attr_Two”, "xxx");
fail("Expected CollaborationException not thrown");} catch (CollaborationException e)
{
int a = e.getMsgNumber();
String b = e.getSubType();
String c = e.getMessage();
String d = e.toString();
assertEquals("exception_msgNumber", 1802, a);
assertEquals("exception_type", "AttributeException", b);
assertEquals("exception_message", "Error 1802 The attribute \"Attr_Two\" in SDO MasterBusinessObject
is of type boolean and is not allowed to be set with a value 
\"xxx\" of type String. Error1802", c);

assertEquals("exception_toString", "AttributeException: Error 1802
The attribute \"Attr_Two\" in SDO MasterBusinessObject is of type 
boolean and is not allowed to be set with a value \"xxx\" of type 
String. Error1802", d);} 

: Troubleshooting migration from WebSphere InterChange Server or WebSphere Business Integration Server Express