Standards for Technology in Automotive Retail | ||
Key Data fields and metadata SHOULD be logged for all sent and received messages. Log information MUST be made available upon request; sharing of log information can be done “out-of-band”, meaning by some manual process outside the transport.
Timestamps for messages in-transit MUST be formatted as XML Schema Datetimes in UTC/GMT format without offsets. For example, 2003-11-05T13:15:30Z corresponds to November 5, 2003, 8:15:30am Eastern Standard Time. Logging systems must be capable of displaying message timestamp information in UTC/GMT format without offsets.
Application generated message IDs MUST be globally unique and be formatted following the specifications of the particular transport that is being used. STAR requires the following three (3) data elements within the message id:
Company name, in domain format, such as starstandards.org
Service identifier, the name of the service being invoked
A locally unique identifier (LUID), such as specified in RFC2822 section 3.6.4.
The specific format using these data elements will be outlined in both the ebMS and WS guidelines documents. Examples of each are:
ebMS: | Web Services |
Service_Name.LUID@starstandard.org | http://starstandard.org/Service_Name/LUID |
If applications do not supply a message ID, then the transport MUST generate a Globally Unique Identifier (GUID). The format of message IDs generated by transport handlers may not follow the same format, but they MUST be globally unique.
Logging systems MUST be capable of storing, displaying and being queried on key message data fields and metadata which must include:
Metadata
Time message was sent or received
Key data fields from the message
Message Timestamp
MessageID
FromParty
ToParty
Hostname of the message sender
Activity (the Service/Action name or web method)
Optional Message Disposition or Status