Message Handling

The STRING message framework consists of an outer layer (StringMessage) and version-specific payload messages. Most messages are pairs of requests and responses with defined workflows.

The StringMessage

The outer <StringMessage> contains the operator and agency data to route the message to the operator system and authenticate it as a valid request. We don't require a specific form of authentication as it is implementation-dependent and might be handled on a higher level. The RoutingHeader will get the necessary operator information to identify the target system.

The Payload Messages

The actual request message goes in the Content node. You have to make sure it is valid for a version the operator supports. The standard content type is "application/xml" but systems might support other types (e.g. compression, encryption) in the future.

For the choice of the first request type in a session refer to the table of message pairs. Not all types might be supported by all operators.

Error Messages

If the request message doesn't match the stated version, is incorrect in any other way or if there is some other kind of generic error (f.i. in the transport) you will get a generic error message.

Client Workflow

Preparation

These steps should be handled by the client system on a regular basis:

1. Check the supported versions in the operator system and choose the highest common one (weekly?)
2. Get the configuration data from the operator (daily)

Transaction

1. Create <StringMessage> and set <RoutingHeader>, <AuthHeader> as required by the GDS system used
2. create entry message in the format of the version chosen, set the marshalled message as Content (payload)
3. Send the complete message to the GDS or directly to the operator endpoint as applicable

GDS workflow

1. Check if the client is allowed to use the system and the operator, optionally check for the correct GDS agency
2. Check the RoutingHeader information and choose the matching operator endpoint to pass on the message

STRING is designed in a way that the GDS doesn't have to look at the Payload. Of course there may be reasons to do so anyway (e.g. statistics).

Operator Workflow

1. Get the <StringMessage> from the client / GDS
2. Optionally check authentication
3. Check the GDS agency and map it to the internal one
4. Check if the stated version is supported and pass on the message to the matching adapter

STRING doesn't define the way how the <Payload> is processed. Systems may decide to pass on the whole message or just the <Payload> accompanied by the operator agency.