Message Handling: Unterschied zwischen den Versionen

Version vom 16. Oktober 2019, 09:42 Uhr

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

Operator Workflow