Migrating WSIFMessage API calls to SDO APIs

IBM BPM, V8.0.1, All platforms > Migrating and upgrading your IBM BPM environment > Migrating from other products > Migrating from WebSphere Studio Application Developer Integration Edition > Additional migration information > Migrating to the SCA programming model
Migrating WSIFMessage API calls to SDO APIs

The following section details how to migrate from the old Business Integration Server Foundation Version 5.1 programming model where the data flowing through the application is represented as WSIFMessage objects with a generated interface that was strongly-typed to the new IBM Process Server programming model where the data is represented as Service Data Objects (SDOs) and no strongly-typed interface is generated.

Changes and Solutions for migrating WSIFMessage API calls to SDO APIs
Change Solution
WSIFMessage-based wrapper classes are no longer generated for WSDL message types, nor are the JavaBeans helper classes generated for complex schema types. When writing code that interacts with SCA services, the generic SDO APIs must be used to manipulate the commonj.sdo.DataObject messages that hold the data that flows through the application.
WSDL message definitions that have a single simple-typed part will now be represented by a simple Java type that directly represents the part instead of having a wrapper around the actual data. If the single message part is a complex type, then the data is represented as a DataObject that adheres to the complex type definition.
WSDL message definitions that have multiple parts now correspond to a DataObject that has properties for all of the message parts, where complexTypes are represented as "reference-type" properties of the parent DataObject, accessible via the getDataObject and setDataObject methods.
Strongly-typed getter methods for WSIFMessage parts and generated JavaBeans should not be used. Weakly-typed SDO API should be used to get the DataObject properties.
Strongly-typed setter methods for BPEL variables' message parts are no longer available. Weakly-typed SDO API must be used to set the DataObject properties.
Weakly-typed getter methods for WSIFMessage properties should no longer be used. Weakly-typed SDO API must be used to set the DataObject properties.
Weakly-typed setter methods for WSIFMessage properties should no longer be used. Weakly-typed SDO API must be used to set the DataObject properties.
All WSIFMessage API calls should be migrated to the SDO API where possible. Migrate the call to an equivalent SDO API call where possible. Redesign logic if not possible.

: Migrating to the SCA programming model

Change	Solution
WSIFMessage-based wrapper classes are no longer generated for WSDL message types, nor are the JavaBeans helper classes generated for complex schema types.	When writing code that interacts with SCA services, the generic SDO APIs must be used to manipulate the commonj.sdo.DataObject messages that hold the data that flows through the application. WSDL message definitions that have a single simple-typed part will now be represented by a simple Java type that directly represents the part instead of having a wrapper around the actual data. If the single message part is a complex type, then the data is represented as a DataObject that adheres to the complex type definition. WSDL message definitions that have multiple parts now correspond to a DataObject that has properties for all of the message parts, where complexTypes are represented as "reference-type" properties of the parent DataObject, accessible via the getDataObject and setDataObject methods.
Strongly-typed getter methods for WSIFMessage parts and generated JavaBeans should not be used.	Weakly-typed SDO API should be used to get the DataObject properties.
Strongly-typed setter methods for BPEL variables' message parts are no longer available.	Weakly-typed SDO API must be used to set the DataObject properties.
Weakly-typed getter methods for WSIFMessage properties should no longer be used.	Weakly-typed SDO API must be used to set the DataObject properties.
Weakly-typed setter methods for WSIFMessage properties should no longer be used.	Weakly-typed SDO API must be used to set the DataObject properties.
All WSIFMessage API calls should be migrated to the SDO API where possible.	Migrate the call to an equivalent SDO API call where possible. Redesign logic if not possible.