October 11, 2011 - added key to trace attributes.
August 8 - added HostCommand to system specific results.
May 25, 2011 - version 1.1.1 - dmh - moved ApplicationResults and Results to STL namespace
Created: April 21, 2011
Description: This schema is a standalone schema that defines Header metadata
structures that are independent of the payload schema.
Copyright Sabre 2011
The copyright to the computer program(s) hereinis the property of Sabre. The program(s) may be used and/or copied only
with the written permission of Sabre or in accordance with the terms and conditions stipulated in
theagreement/contract under which the program(s) have been supplied.
Describes the level of diagnostic data requested or provided.
Block of diagnostic data included in request or returned in the response.
Diagnostic data. Must be defined in a differrent namespace as the header.
The Identification metadata uniquely identify each message instance.
The ConversationId element is a string identifying the set of related messages that make up a
conversation between two or more Parties. The Party initiating a conversation determines the value of
the ConversationId element that shall be reflected in all messages pertaining to that
conversation. It remains constant for all messages within a conversation.
Service providers are expected to increment the optional TrackingID integer attribute when present.
System identifier used to uniquily identify the specific system.
"Source" is used to return the application name responsible for fulfilling the particular request transaction.
"ApplicationInstance" is used to return the application instance responsible for fulfilling the particular request transaction.
"Cluster" is used to return the application cluster responsible for fulfilling the particular request transaction.
"HostName" is used to return the particular server name responsible for fulfilling the particular request transaction.
Example: Source ApplicationInstance="PROD1" Cluster="PROD TPF SCC" HostName="PSS" TPF Source
The uri representing the endpoint reference by which this system can be accessed.
Free text and code provided by the application or system that detected the condition.
Contents may be anything the system detecting the error chooses to convey. Used by service consumers.
Codes and/or messages should be agreed upon by service users.
Do not use for structured data, use parameters instead.
An indication of the source of error when processing the request.
Impact of the error on process completion.
The system that the reporting system deemed to be the cause of the problem. If omitted, the
reporting system is also the source of the problem. For application errors, the element may
identify a system the application is dependent upon that failed to respond. For validation
errors this may identify the service consumer.
The system that created the results record. If the Source system identifier is omitted, the
system identified here both was the cause of the problem and created the result record.
An informative code and message that describes the results. Note: the message code and text must
NOT be required to process to understand retry/compensate status.
This value should be the same as in the SystemSpecificResults in the body.
An abbreviated version of the error in textual format.
This value should be the same as in the SystemSpecificResults in the body.
An indication of the source of error when processing the request.
Impact of the error on process completion.
Success indicates that the request was
processed successfully.
Header records no longer contain user credentials (username/password) as these are needed only for
SessionCreateRQ in which the credentials should be in the payload.
Record for all systems (consumer, proxies and gateways, providers) to use to trace the message.
The value is the common system name.
The key attribute is similar to ConversationID but is provided by the service requestor or entrypoint gateway and
must be unique across all Sabre gateways. Each gateway instance must prepend the ID value with its unique system identifier.
Internal service consumers must provide this value which may be their unique system identifier concantanated
with the ConversationID.
When the system stated processing the message.
When the system completed processing the message.
Example: 2002-10-10T12:00:00+05:00.
The application instance involved in the particular transaction.
For example: PROD1
The application server cluster involved in the particular transaction.
Example: PROD TPFC SCC
The server name involved in the particular transaction.
Example: PSS
The targetURI is the endpoint address this system sent the message to.
For ServiceProviders it should be the abstract service address which is the address used by
registries to look up the actual service endpoint URI. The endpoint address may be a queue
name (MOM service name).
Tracking Identifier is an identifier intended for use to a set of related items and provide an
optional sequence number for the items.
Return a sample message without invoking service logic.
Compute response without making changes to service data, state or status.
Elements of this type are used for indicators whose presense denotes the
condition described by their name. They have no content nor any attributes.
For example, an empty Success element denote that the process was successfully completed.
Transport errors occur when the infrastructure systems are unable to deliver the request message
to the service provider or the service response is not delivered within the allotted time frame.
These errors are always detected by the transport infrastructure systems. The detecting system
should indicate the need for compensation in Severity and Status values. These errors may be
transient and consumers may choose to retry their request.
Validation errors occur when the message is determined to not conform to the interface
specifications. For example, it is an validation error when the request violates security
requirements or the message is not schema valid according to the service interface schema. These
errors may be detected by either the transport or application systems. Applications must not
make changes that will require compensation when validation errors are detected. These errors
are caused by the structure or content of the request and consumers should not attempt to retry
their unmodified request.
Application errors occur when a valid message is delivered to the service provider yet the
request cannot be completely processed. This can occur when the provider has technical issues
such as internal exceptions, database locks, or connectivity failure to a system it is dependent
upon. These errors are always detected by the application system. The application should
indicate the need for compensation in Severity and Status values. These errors may be transient
and consumers may choose to retry their request.
Business logic errors occur when a service provider is able to process the request message but
the request violates pre-condition or internal application business logic. Example business
logic errors are a request for flight information but the flight does not exist or a request to
reserve more seats than are on the aircraft. The response message will likely provide details
about the error condition and may or may not use a standard error response record. Business
logic errors are always detected by the application system. Applications must not make changes
that will require compensation when business logic errors are detected. These errors are caused
by content of the request; consumers should only attempt to retry their unmodified request if
the business condition described in the application specific response indicates the condition
may be transient. Service providers should use the ErrorMessage and code attribute to describe
the business condition and document those conditions in their service contract.
Customer Identifier assigned to office or agency or location. Commonly use values are
Psuedo City Code - 3 to 16 characters or the Sabre Office accounting code (OAC) which can be upto 25 characters.
Same as STL Text.Long - A field text characters and no other constraints.
Same as STL Text.Short - A field of text characters and no other constraints.
the system that initiated the service request and will be the ultimate consumer
of the service results.
System that performs the service operation defined in the service interface.
For RQ/RS exchange patterns, the provider reads the request message, applies business logic and
returns a response.