Standards for Technology in Automotive Retail

 Home -  News Feed 

7.4. Decisions

7.4.1. Message Logging

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.

7.4.2. Timestamp Format

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.

7.4.3. MessageID Format

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

  • 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

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.

7.4.4. Key Data Fields

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