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.
Element information
Namespace: http://www.openapplications.org/oagis/10
Schema document: Common.xsd
Type: SenderType
Properties: Global, Qualified, ID: oagis-id-a8120509be244a8e819cd744c07400ce
Content
- Sequence [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
- 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.
- 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.
- 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.
- ConfirmationCodes [0..1]
- 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
Name | Occ | Type | Description | Notes |
---|---|---|---|---|
typeCode | [0..1] | CodeType_1E7368 | ||
partyRoleCode | [0..1] | CodeType_1E7368 |
Used in
- Type ApplicationAreaBaseType
- Type ApplicationAreaType via extension of ApplicationAreaBaseType (Elements ApplicationArea, OriginalApplicationArea)
Sample instance
<Sender> <LogicalID>normalizedString</LogicalID> <ComponentID>normalizedString</ComponentID> <TaskID>normalizedString</TaskID> <ReferenceID>normalizedString</ReferenceID> <ConfirmationCodes> <ProcessingConfirmationCode>normalizedString</ProcessingConfirmationCode> <ConfirmationCode>token</ConfirmationCode> </ConfirmationCodes> <AuthorizationID>normalizedString</AuthorizationID> </Sender>