Table of Contents
A BOD is made up of the combination of the Application Area, Data Area, Verb, and Noun. The name of a particular BOD is made up of the Verb and the Noun being used. For example, a Credit Application, may have several BODs that are involved to complete a business transaction. The BOD names may be:
Process CreditApplication - where Process is the Verb and CreditApplication is the name of the Noun .
Acknowledge CreditApplication - where Acknowledge is the Verb and CreditApplication is the name of the Noun .
The Verb documentation section in this guideline lists the available verbs that can be used with the Noun included in this guideline. There will be a corresponding Verb/Noun schema combination in the STAR Schema Repository.
The root element, top element, of the XML Instance will also be the Verb/Noun Combination. So for the AcknowledgeCreditApplication BOD, the root element would look like the following:
Example 3.1. Root Element Example
<AcknowledgeCreditApplication> <ApplicationArea>......</ApplicationArea> [1..1] <AcknowledgeCreditApplicationDataArea>......</AcknowledgeCreditApplicationDataArea> [1..*] </AcknowledgeCreditApplication>
All root elements of all the STAR BODs have several attributes that can be included with them. These attributes
Table 3.1. Attributes
| Name | Description | Occurrence | Type | Data Type | User Notes |
|---|---|---|---|---|---|
| releaseID |
STAR Release this BOD Instances belongs. | 1..1 | Attribute | udt:string | |
| versionID |
Deprecated. Recommended to use releaseID to identify the repository and noun. This field may be removed in the next major version of the STAR repository. Indicates the version of the given Noun. | 0..1 | Attribute | udt:string | |
| systemEnvironmentCode |
Indicates whether this BOD is being sent in a "Test" or a "Production" mode. If the BOD is being sent in a test mode, it's information should not affect the business operation. However, if the BOD is sent in "Production" mode it is assumed that all test has been complete and the contents of the BOD are to affect the operation of the receiving business application(s). | 0..1 | Code List | oacl:SystemEnvironmentCodeContentType | |
| languageCode |
Indicates the language that the contents of the BOD is in unless otherwise stated. | 0..1 | Code List | scl:LanguageEnumeratedType |
The following are the components and fields that make up the Business Object Document. The name of the Data Area will vary by BOD, and be the combination of the Verb and Noun, with the word DataArea added to the end.
Table 3.2. Fields and Components
| Name | Description | Occurrence | Type | Data Type | User Notes |
|---|---|---|---|---|---|
| ApplicationArea |
Provides the information that an application may need to know in order to communicate in an integration of two or more business applications. The ApplicationArea is used at the applications layer of communication. While the integration frameworks web services and middleware provide the communication layer that OAGIS operates on top of. | 0..1 | Component | ApplicationAreaType | |
| [Verb][Noun]DataArea |
The Data Area contains the verb and noun to be used. And is represented by the verb and noun combination for the BOD. | 1..1 | Component |
The XML Sample provided here is an approximation of the generated XML for this component. Not all of the fields are required for implementation. This sample is the same regardless of the BOD only the Root Element and the Data Area names will be different.
Example 3.2. AcknowledgeCreditApplication
<AcknowledgeCreditApplication> <ApplicationArea>......</ApplicationArea> [1..1] <AcknowledgeCreditApplicationDataArea>......</AcknowledgeCreditApplicationDataArea> [1..*] </AcknowledgeCreditApplication>
Uses the Component: ApplicationAreaType
Provides the information that an application may need to know in order to communicate in an integration of two or more business applications. The ApplicationArea is used at the applications layer of communication. While the integration frameworks web services and middleware provide the communication layer that OAGIS operates on top of.
Table 3.3. Fields and Components
| Name | Description | Occurrence | Type | Data Type | User Notes |
|---|---|---|---|---|---|
| Sender |
This identifies characteristics and control identifiers that relate to the application that created the Business Object Document. | 0..1 | Component | SenderType | |
| Intermediary |
This identifies characteristics and control identifiers that relate to an intermediary application that interacts with the Business Object Document. | 0..* | Component | IntermediaryType | |
| Receiver |
Identifies the intended receiver of the given BOD instance. | 0..* | Component | ReceiverType | |
| CreationDateTime |
is the date time stamp that the given instance of the Business Object Document was created. This date must not be modified during the life of the Business Object Document. | 1..1 | Field | oag:DateTimeType | |
| Signature |
If the BOD is to be signed the signature element is included, otherwise it is not. Signature supports any digital signature that maybe used by an implementation of OAGIS. The qualifyingAgency identifies the agency that provided the format for the signature. | 0..1 | Component | oag:SignatureType | |
| ScenarioID |
| 0..1 | Field | oag:IDType | |
| CorrelationID |
| 0..1 | Field | oag:IDType | |
| BODID |
The BODId provides a place to carry a Globally Unique Identifier (GUID) that will make each Business Object Document instance uniquely identifiable. This is a critical success factor to enable software developers to use the Globally Unique Identifier (GUID) to build services or capabilities: | 0..1 | Field | oag:IDType |
The XML Sample provided here is an approximation of the generated XML for this component. Not all of the fields are required for implementation.
Example 3.3. ApplicationArea
<ApplicationArea>
<Sender>......</Sender> [0..1]
<Intermediary>......</Intermediary> [0..*]
<Receiver>......</Receiver> [0..*]
<CreationDateTime>......</CreationDateTime> [1..1]
<oag:Signature>......</oag:Signature> [0..1]
<ScenarioID>......</ScenarioID> [0..1]
<CorrelationID>......</CorrelationID> [0..1]
<BODID>......</BODID> [0..1]
</ApplicationArea>
Uses the Component: SenderType
This identifies characteristics and control identifiers that relate to the application that created the Business Object Document.
Table 3.4. Fields and Components
| Name | Description | Occurrence | Type | Data Type | User Notes |
|---|---|---|---|---|---|
| LogicalID |
Provides the logical location of the server and applications from which the Business Object Document originated. It can be used to establish a logical to physical mapping, however its use is optional. Each system or combination of systems should maintain an external central reference table containing the logical names or logical addresses of the application systems in the integration configuration. This enables the logical names to be mapped to the physical network addresses of the resources needed on the network. Note: The technical implementation of this Domain Naming Service is not dictated by this specification. This logical to physical mapping may be done at execution time by the application itself or by a middleware transport mechanism, depending on the integration architecture used. This provides for a simple but effective directory access capability while maintaining application independence from the physical location of those resources on the network. | 0..1 | Field | oag:IDType | |
| ComponentID |
Provides a finer level of control than Logical Identifier and represents the business application that issued the Business Object Document. Its use is optional. The Open Applications Group has not constructed the list of valid Component names. A suggestion for naming is to use the application component names used in the scenario diagrams in section two of OAGIS. Example Components may be Inventory, or Payroll. | 0..1 | Field | oag:IDType | |
| TaskID |
This describes the business event that initiated the need for the Business Object Document to be created. | 0..1 | Field | oag:IDType | |
| ReferenceID |
Enables the sending application to indicate the instance identifier of the event or task that caused the BOD to be created. This is used to correlate a response BOD to an originating BOD. *The Sender of the originating application will populate the Reference Id with business level information. *Reference ID does not have to be a GUID. It must be a locally unique application value for the transaction type, for example a database sequence number. *The receiving application puts the value in Reference ID of the incoming message in the Reference ID of any acknowledgment messages. *The Reference Id will not be required to tie two collaborations together such as Parts Order and Parts Shipment. | 0..1 | Field | oag:IDType | |
| ConfirmationCodes |
Confirmation Codes. | 0..1 | Component | ConfirmationCodesType | |
| AuthorizationID |
Identifies the authorization level of the user or application that is sending the Business Object Document Message. Used as User ID. | 0..1 | Field | oag:OpenIDType | |
| ID |
Is the Identifiers of the given instance of an entity within the scope of the integration. The schemeAgencyID attribute identifies the party that provided or knows this party by the given identifier. | 0..1 | Field | oag:OpenIDType |
The XML Sample provided here is an approximation of the generated XML for this component. Not all of the fields are required for implementation.
Example 3.4. Sender
<Sender>
<LogicalID>......</LogicalID> [0..1]
<ComponentID>......</ComponentID> [0..1]
<TaskID>......</TaskID> [0..1]
<ReferenceID>......</ReferenceID> [0..1]
<ConfirmationCode>......</ConfirmationCode> [0..1]
<AuthorizationID>......</AuthorizationID> [0..1]
<ID>......</ID> [0..1]
</Sender>
Uses the Component: IntermediaryType
Identifies the intended receiver of the given BOD instance.
Table 3.5. Fields and Components
| Name | Description | Occurrence | Type | Data Type | User Notes |
|---|---|---|---|---|---|
| LogicalID |
Provides the logical location of the server and applications from which the Business Object Document originated. It can be used to establish a logical to physical mapping, however its use is optional. Each system or combination of systems should maintain an external central reference table containing the logical names or logical addresses of the application systems in the integration configuration. This enables the logical names to be mapped to the physical network addresses of the resources needed on the network. Note: The technical implementation of this Domain Naming Service is not dictated by this specification. This logical to physical mapping may be done at execution time by the application itself or by a middleware transport mechanism, depending on the integration architecture used. This provides for a simple but effective directory access capability while maintaining application independence from the physical location of those resources on the network. | 0..1 | Field | oag:IDType | |
| ComponentID |
Provides a finer level of control than Logical Identifier and represents the business application that issued the Business Object Document. Its use is optional. The Open Applications Group has not constructed the list of valid Component names. A suggestion for naming is to use the application component names used in the scenario diagrams in section two of OAGIS. Example Components may be Inventory, or Payroll. | 0..1 | Field | oag:IDType | |
| ID |
Is the Identifiers of the given instance of an entity within the scope of the integration. The schemeAgencyID attribute identifies the party that provided or knows this party by the given identifier. | 0..1 | Field | oag:OpenIDType | |
| ReceivedDateTime |
The date and time that the associated object was received. | 0..1 | Field | oag:xbt_DateTimeType | |
| SentDateTime |
The date and time that the associated object was sent. | 0..1 | Field | oag:xbt_DateTimeType |
The XML Sample provided here is an approximation of the generated XML for this component. Not all of the fields are required for implementation.
Example 3.5. Intermediary
<Intermediary>
<LogicalID>......</LogicalID> [0..1]
<ComponentID>......</ComponentID> [0..1]
<ID>......</ID> [0..*]
<ReceivedDateTime>......</TaskID> [0..1]
<SentDateTime>......</ReferenceID> [0..1]
</Intermediary>
Uses the Component: ReceiverType
Identifies the intended receiver of the given BOD instance.
Table 3.6. Fields and Components
| Name | Description | Occurrence | Type | Data Type | User Notes |
|---|---|---|---|---|---|
| LogicalID |
Provides the logical location of the server and applications from which the Business Object Document originated. It can be used to establish a logical to physical mapping, however its use is optional. Each system or combination of systems should maintain an external central reference table containing the logical names or logical addresses of the application systems in the integration configuration. This enables the logical names to be mapped to the physical network addresses of the resources needed on the network. Note: The technical implementation of this Domain Naming Service is not dictated by this specification. This logical to physical mapping may be done at execution time by the application itself or by a middleware transport mechanism, depending on the integration architecture used. This provides for a simple but effective directory access capability while maintaining application independence from the physical location of those resources on the network. | 0..1 | Field | oag:IDType | |
| ComponentID |
Provides a finer level of control than Logical Identifier and represents the business application that issued the Business Object Document. Its use is optional. The Open Applications Group has not constructed the list of valid Component names. A suggestion for naming is to use the application component names used in the scenario diagrams in section two of OAGIS. Example Components may be Inventory, or Payroll. | 0..1 | Field | oag:IDType | |
| ID |
Is the Identifiers of the given instance of an entity within the scope of the integration. The schemeAgencyID attribute identifies the party that provided or knows this party by the given identifier. | 0..1 | Field | oag:OpenIDType |
Uses the Component: ConfirmationCodesType
Confirmation Codes.
Table 3.7. Fields and Components
| Name | Description | Occurrence | Type | Data Type | User Notes |
|---|---|---|---|---|---|
| ProcessingConfirmationCode |
The processing confirmation code. | 0..1 | Field | oag:CodeType | |
| ConfirmationCode |
Is an option controlled by the Sender business application. It is a request to the receiving application to send back a confirmation BOD to the sender. The confirmation Business Object Document may indicate the successful processing of the original Business Object Document or return error conditions if the original Business Object Document was unsuccessful. The confirmation request has the following valid values:
| 0..1 | Code List | oag:ConfirmationCodeContentType |
The XML Sample provided here is an approximation of the generated XML for this component. Not all of the fields are required for implementation.
Example 3.7. ConfirmationCodes
<ConfirmationCodes>
<ProcessConfirmationCode>......</LogicalID> [0..*]
<ConfirmationCode>......</ComponentID> [0..1]
<ID>......</ID> [0..*]
</ConfirmationCodes>