Transactions are atomic operations which can retrieve and manipulate data held by InfoSphere® MDM.
When an entity is created in the operational server module editor, the MDM Workbench will automatically add an add, an update, and a get transaction to the new entity in the operational server module model. The implementation of these transactions will be generated automatically by the MDM Workbench and will provide basic lifecycle operations for the entity.
The names of the default transactions reflect the type of entity that they operate on as well as the operation they perform. For example, an entity named Sample will have the default transactions addSample, updateSample and getSample. The addSample transaction will add a new Sample entity; updateSample will update an existing Sample entity; and getSample will retrieve a Sample entity that is identified by its primary key.
Get Record transactions are a form of custom transaction that the MDM Workbench can generate automatically. When a Get Record transaction is added to an entity in the operational server module model, a list of non-primary attributes are specified. The generated transaction will query the operational server and retrieve entities based on these attributes.
Custom transactions allow arbitrary business logic beyond the scope of default transactions or get records to be included in an operational server module.
When a custom transaction is added to the operational server model, some basic information must be provided, including the arguments, the type of entity returned, the style of implementation that should be generated and the cardinality of the response. From this information, the MDM Workbench will create a skeleton implementation in the operational server module when code generation is performed.
Basic transaction information (see Custom transactions) allows the MDM Workbench to create request and response processing logic within the implementation. An MDM_TODO task is included to indicate where custom business logic should be added manually. For more information, see MDM_TODO task completion.
To facilitate the development of this business logic, a series of these base transactions can be added to the model. Skeleton code will be created during code generation to invoke these services. This step is described in more detail under
If the required base transactions are specified in the operational server module editor, the MDM Workbench will generate the required code to call each base transaction in turn. Custom logic should be added between the calls to each base transaction as required.
The MDM Workbench will also attempt to generate code to automatically pass data from one transaction to the next. Where the result type from one transaction is the same as the input type for the next transaction, the MDM Workbench will generate code to pass the object in the response from the first transaction to the second transaction. Where the types do not match, this is not possible and no extra code will be generated. In either case, an MDM_TODO comment will be generated to highlight the need either (1) to check whether passing the result on is the desired behavior, or (2) to construct the input to the second transaction.
The MDM Workbench will also try to link up the first and last base transactions to the request and response of the custom transaction. If the input type of the custom transaction is the same as the input type of the first base transaction, the MDM Workbench will generate code to pass the input to the custom transaction to the first base transaction. If the response type of the final base transaction is the same as the response type of the custom transaction, the MDM Workbench will generate code to return the response of the base transaction as the return value for the custom transaction.
Custom transactions can be implemented in two different ways, either as a business proxy transactions or as component transactions. These styles correspond to adding the custom logic at different points in the InfoSphere MDM request handling process.
Business proxy transactions add logic just before the controller level. They call other transactions at the controller level, but they cannot call other business proxies. Business proxy transactions can only call other transactions at the controller level and cannot call other business proxies.
Component transactions are called at the component level. Component transactions can only call other transactions at the component level and can call other custom component transactions.
The distinction between calling transactions at the controller level and the component level is important when calling the out-of-the-box transactions since some of them have different semantics at the controller level. In general, for transactions with both coarse-grained and fine-grained variants, the coarse-grained variant is only available at the controller level.