You can define new entities in the module model to be used as request or response objects in a custom transaction.
The request type for a custom Tx style transaction can be any persistent entity (data addition) or a transient data object. Transient data objects are used to pass data into a transaction, but are not directly persisted in the database. Transient data objects are often used to wrap multiple persistent entities into a single request object.
Transient data objects can also be used as the response types of Tx or Inquiry style transactions.
You can add attributes to a transient data object in the same way as you would for a persistent entity. You can also define reference and code type fields and containment relationships for the transient data object.
The generated code for a transient data object is similar to the code generated for a persistent entity, but without any of the code relating to persistence. Default Add, Update, and Get Record transactions are not generated for transient data objects.
If you are using InfoSphere® MDM version 9.0 Web services, then note that Web services are created based on the transactions that have been defined, not the data objects, so when you create a transient data object, you must also create a transaction that uses it within the same module.
Beginning with InfoSphere MDM version 10.0, the request and response schemas are merged, including all the elements for both, which accommodates all of the requests and responses that were possible before.
| Merged schema: | Replaces: |
|---|---|
| MDMDomains.xsd |
|
| MDMCommon.xsd |
|
InfoSphere MDM uses the OSGi framework, which uses a modular method for deploying extensions. OSGi allows code to be deployed in discrete modules called bundles; each bundle declares its dependencies and contributions to the main application.
Hub module projects from v10.x are now bundles in v11.x. Rather than deploying the schema for the whole application, the schemas are deployed in the same modular as the code is deployed.
In version 11.0, xsd-fragment files are generated in each bundle. These files are declared as contributions by the bundle and are assembled dynamically by the server at runtime to create the complete schema against which requests and responses are validated. However, this is only done for the new unified schema.
Legacy schemas are generated into a single bundle project called MDMLegacySchemas, and this bundle project must be added to the CBA in order to be deployed and used.
Because the legacy schemas with separate request and response XSDs are now deprecated, they have not been converted to the same modular format as used in the OSGi framework. It's still possible to create and use these deprecated schemas in InfoSphere MDM version 11.0, but this requires more work.
Although the changes are relatively small, they may be incompatible with existing clients. For this reason, legacy schemas were left in place so that these existing clients would continue to work as they did before.
In the MDM Workbench, prior to version 11, updated schema files were generated for both the legacy and new schemas so that you could use either the new, simpler schema, or you could maintain compatibility with a client still using the separate legacy request and response schemas.
| legacySchema setting in the mdmgen.properties file | schemas generated |
|---|---|
| legacySchemas=true |
|
| legacySchemas=false This is the default setting for new projects in version 11.0 and later. |
|
| legacySchemas property not
present This applies to projects migrated from versions earlier than version 11.0. |
|
If you have migrated a project from a version of InfoSphere MDM earlier than version 11.0.x, the legacySchemas property does not appear in the will not be present in the mdmgen.properties file.