Operational data ownership

The FTM operational data model is derived from the OBJ_BASE table. The column OWNER_ID has been added and is used to assign a party to be the owner to an object. This column is a foreign key reference that ties any object in OBJ_BASE with an involved party as defined in the PARTY table. This column is populated at runtime and ownership is determined according to the following rules:
  • This column is populated at runtime with the ID that belongs to the lowest possible element of the hierarchy that has access to that operational data. For example, in Sample bank hierarchy, DepartmentA11 owns each transaction that it creates, even though CorporateA1 and BankA also have access to that operation.
  • The ownership of an inbound message can often be established from the party owning the inbound channel. In other cases, that information might not be enough and some logic might be required, for example, logic based on values in an MQ header, message header, or the body. In such cases, ownership must be set inside an action called from the FSM that manages the lifecycle of the object.
  • Outbound messages are created with the same owning party that created the inbound object that originated the message.
  • Response messages are created with the same owning party as the request message they respond to. For example, in the FTM Sample application this could be done inside the A_CorrelateAndUpdateRel action.
This gives you control over the ownership of the different objects through their lifecycle within the application.
Figure 1. Sample bank hierarchy
Sample bank hierarchy