Sender

Identifies characteristics and control identifiers that relate to the application that created the Business Object Document.  The sender area can indicate the logical location of the application and/or database server, the application, and the task that was processing to create the BOD.

See http://www.openapplications.org/platform/1.

Element information

Content

• Sequence [1..1]
  1. LogicalID [0..1]    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
  2. ComponentID [0..1]    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.
  3. TaskID [0..1]    Describes the business event that initiated the need for the Business Object Document to be created. Its use is optional. Although the Task may differ depending on the specific implementation, it is important to enable drill back capability. Example Tasks may be Receipt or Adjustment.
  4. ReferenceID [0..1]    Enables the sending application to indicate the instance identifier of the event or task that caused the BOD to be created. This allows drill back from the BOD message into the sending application. The may be required in environments where an audit trail must be maintained for all transactions.
  5. ConfirmationCode [0..1]    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: Never - No confirmation Business Object Document requested OnError - OnError send back a confirmation Business Object Document only if an error has occurred Always - Always send a confirmation Business Object Document regardless
  6. AuthorizationID [0..1]    Identifyies the authorization level of the user or application that is sending the Business Object Document Message. This authorization level being recognized be the receiving system indicates what can be done on the receiving system(s).

Attributes

None

Used in

• Type ApplicationAreaType (Elements ApplicationArea, OriginalApplicationArea)

Sample instance

<Sender>
   <LogicalID>normalizedString</LogicalID>
   <ComponentID>normalizedString</ComponentID>
   <TaskID>normalizedString</TaskID>
   <ReferenceID>normalizedString</ReferenceID>
   <ConfirmationCode>Always</ConfirmationCode>
   <AuthorizationID>normalizedString</AuthorizationID>
</Sender>