The metadata of the result is defined in the ResultMetaDataType, which is used in the ResultDataType and therefore also in the ResultType VariableType, which again is used in the ResultReadyEventType. The ResultDataType is also used in various methods.
If the metadata of the result is to be extended, the ResultMetaDataType has to be extended by creating a subtype. For using the Methods of the ResultManagementType, this is all that needs to be done. Those Methods returning instances of ResultDataType, now using the extended subtype in that structure. It is not allowed to change the signature of the Methods in a subtype of ResultManagementType, therefore, no subtype needs to be created.
In case, the ResultType Variables or the ResultReadyEvents are supported, additional subtypes should be created. It is not necessary to create a subtype of ResultDataType, as it is not possible to change the DataType of ResultMetaData in the DataType. Only instances of ResultDataType will use the subtype. But the ResultType VariableType is exposing the content of the ResultMetaDataType as subvariables. Therefore, a subtype of the VariableType should be created exposing those additional fields of the subtype of the ResultMetaDataType as subvariables. Since those should also be exposed as Event fields, a subtype of the ResultReadyEventType should be created using the subtype of the VariableType. In both cases, also a subtype of the ResultManagementType should be created, using the subtype of the VariableType and pointing to the subtype of the ResultReadyEventType.
In Table 39, this is summarized.
Table 39 – Required Subtypes for extending Result Metadata
|
Supported Concept |
ResultMetaDataType |
ResultDataType |
ResultType |
ResultReadyEventType |
ResultManagementType |
|
Result Methods |
Yes |
No |
No |
No |
No |
|
Result Variables |
Yes |
No |
Yes |
No |
Yes |
|
Result Events |
Yes |
No |
Yes |
Yes |
Yes |
In Figure 4, an example extending the metadata for all communication mechanisms is given.
