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. | 1..1 | Component | SenderType | |
| CreationDateTime |
This is used as the creation moment of this Business Object Document. | 1..1 | Field | udt:DateTimeType | |
| oagis: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 | xsd:any | |
| 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 | udt:IdentifierType | |
| Destination |
This identifies characteristics and control identifiers that relate to the application that receives the Business Object Document. | 1..1 | Component | DestinationType |
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> [1..1]
<CreationDateTime>......</CreationDateTime> [1..1]
<oagis:Signature>......</oagis:Signature> [0..1]
<BODID>......</BODID> [0..1]
<Destination>......</Destination> [1..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 |
This is the logical location of the server and application from which the Business Object Document originated. | 0..1 | Field | udt:IdentifierType | |
| ComponentID |
DCS software code name. | 0..1 | Field | udt:IdentifierType | |
| TaskID |
This describes the business event that initiated the need for the Business Object Document to be created. | 0..1 | Field | udt:IdentifierType | |
| 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 | udt:IdentifierType | |
| 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 | oagis:ConfirmationResponseCodeType | |
| 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 | udt:IdentifierType | |
| CreatorNameCode |
DCS Software Creator Code | 1..1 | Field | udt:CodeType | |
| SenderNameCode |
Additional information about the sending platform (i.e., Short Manufacturer or DSP code). | 1..1 | Field | udt:CodeType | |
| URI |
Physical address of the sender | 0..1 | Field | qdt:URIType | |
| DealerNumberID |
Dealer Code of source of information | 0..1 | Field | udt:IdentifierType | |
| StoreNumber |
Dealer code store number (DMS assigned) | 0..1 | Field | udt:TextType | |
| AreaNumber |
Dealer code area number (DMS vendor assigned) | 0..1 | Field | udt:TextType | |
| DealerCountryCode |
Source Dealer country location | 0..1 | Code List | sqdt:CountryCodeType | |
| LanguageCode |
This code is used to define the language of the data used in this transaction | 0..1 | Code List | sqdt:CountryCodeType | |
| DeliverPendingMailIndicator |
Indicates if the user requests to receive pending mail that has been stored and has yet not been delivered yet. By selecting 0, the user will only receive the response for the current transaction the user is performing. | 0..1 | Field | udt:IndiciatorType | |
| Password |
Token for application specific authentication. Used to authenticate dealership/users through application specific security | 0..1 | Field | udt:TextType | |
| SystemVersion |
The sender's software version number. | 0..1 | Field | udt:TextType | |
| PartyID |
The Party Id field uniquely identifies the Sender of the message. This element can be used for parties within the Automotive Community as well as external parties. Party Id is not intended as a replacement for the Dealer Number. Suggested formats for OEMs or other large institutions include: DUNs Number, ShortMfgCode + DUNs, or ShortMfgCode. The suggested format for Dealers is: ShortMfgCode+Dealer Number. | 0..1 | Field | udt:IdentifierType | |
| LocationID |
The Location Id field uniquely identifies the location of the Sender of a message. This Id may be aligned with a physical address or data centers. This field provides an additional level of granularity beyond the usage of the Party Id for additional routing and deliver of data. | 0..1 | Field | udt:IdentifierType | |
| ServiceID |
The Service Id field identifies the particular service from which a message is being sent, e.g., an inventory service. | 0..1 | Field | udt:IdentifierType | |
| NounCountNumeric | Specifies the number of nouns carried in the BOD. | 0..1 | Field | udt:NumericType |
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]
<CreatorNameCode>......</CreatorNameCode> [1..1]
<SenderNameCode>......</SenderNameCode> [1..1]
<URI>......</URI> [0..1]
<DealerNumberID>......</DealerNumberID> [0..1]
<StoreNumber>......</StoreNumber> [0..1]
<AreaNumber>......</AreaNumber> [0..1]
<DealerCountryCode>......</DealerCountryCode> [0..1]
<LanguageCode>......</LanguageCode> [0..1]
<DeliverPendingMailIndicator>......</DeliverPendingMailIndicator> [0..1]
<Password>......</Password> [0..1]
<SystemVersion>......</SystemVersion> [0..1]
<PartyID>......</PartyID> [0..1]
<LocationID>......</LocationID> [0..1]
<ServiceID>......</ServiceID> [0..1]
<NounCountNumeric>......</NounCountNumeric> [0..1]
</Sender>
Uses the Component: DestinationType
Destination
Table 3.5. Fields and Components
| Name | Description | Occurrence | Type | Data Type | User Notes |
|---|---|---|---|---|---|
| DestinationNameCode |
Code for destination of file (i.e.Short Manufacturer or DSP code) | 0..1 | Field | udt:CodeType | |
| DestinationURI |
Physical address of the destination | 0..1 | field | qdt:URIType | |
| DestinationSoftwareCode |
Additional information about the destination application | 0..1 | Field | udt:CodeType | |
| DestinationSoftware |
The software that the file is intended (may not be known). | 0..1 | Field | udt:TextType | |
| DealerNumberID |
Target Dealer Code receiving information | 0..1 | Field | udt:IdentifierType | |
| StoreNumber |
Dealer code store number (DMS assigned) | 0..1 | Field | udt:TextType | |
| AreaNumber |
Dealer code area number (DMS vendor assigned) | 0..1 | Field | udt:TextType | |
| DealerTargetCountry |
Target Dealer country location | 0..1 | Code List | scl:CountryEnumeratedType | |
| PartyReceiverID |
The Party Receiver Id field uniquely identifies the Receiver of the message. This element can be used for parties within the Automotive Community as well as external parties. Party Id is not intended as a replacement for the Dealer Number. Suggested formats for OEMs or other large institutions include: DUNs Number, ShortMfgCode + DUNs, or ShortMfgCode. The suggested format for Dealers is: ShortMfgCode+Dealer Number. | 0..1 | Field | udt:IdentifierType | |
| LocationReceiverID |
The Location Receiver Id field uniquely identifies the location of the Receiver of a message. This Id may be aligned with a physical address or data centers. This field provides an additional level of granularity beyond the usage of the Party Id for additional routing and deliver of data. | 0..1 | Field | udt:IdentifierType | |
| ServiceMessageID |
The Service Message Id field identifies the particular service to which a message is being sent, e.g., an inventory service. | 0..1 | Field | udt:IdentifierType |
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. Destination
<Destination>
<DestinationNameCode>......</DestinationNameCode> [0..1]
<DestinationURI>......</DestinationURI> [0..1]
<DestinationSoftwareCode>......</DestinationSoftwareCode> [0..1]
<DestinationSoftware>......</DestinationSoftware> [0..1]
<DealerNumberID>......</DealerNumberID> [0..1]
<StoreNumber>......</StoreNumber> [0..1]
<AreaNumber>......</AreaNumber> [0..1]
<DealerTargetCountry>......</DealerTargetCountry> [0..1]
<PartyReceiverID>......</PartyReceiverID> [0..1]
<LocationReceiverID>......</LocationReceiverID> [0..1]
<ServiceMessageID>......</ServiceMessageID> [0..1]
</Destination>