Message Handling: Unterschied zwischen den Versionen
| Zeile 3: | Zeile 3: | ||
== The StringMessage == | == 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. [[Authentication|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 outer <StringMessage> contains the operator and agency data to route the message to the operator system and authenticate it as a valid request. [[Authentication|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 Payload Messages == | ||
| Zeile 26: | Zeile 26: | ||
=== Transaction === | === Transaction === | ||
| − | # Create StringMessage and set RoutingHeader, AuthHeader as required by the GDS system used | + | # Create <StringMessage> and set <RoutingHeader>, <AuthHeader> as required by the GDS system used |
# create entry message in the format of the version chosen, set the marshalled message as Content (payload) | # create entry message in the format of the version chosen, set the marshalled message as Content (payload) | ||
# Send the complete message to the GDS or directly to the operator endpoint as applicable | # Send the complete message to the GDS or directly to the operator endpoint as applicable | ||
== GDS workflow == | == GDS workflow == | ||
| + | |||
| + | # Check if the client is allowed to use the system and the operator, optionally check for the correct GDS agency | ||
| + | # 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 == | == Operator Workflow == | ||
| + | |||
| + | # Get the <StringMessage> from the client / GDS | ||
| + | # Optionally check authentication | ||
| + | # Check the GDS agency and map it to the internal one | ||
| + | # 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. | ||
Version vom 16. Oktober 2019, 10:12 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.
Inhaltsverzeichnis
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:
- Check the supported versions in the operator system and choose the highest common one (weekly?)
- Get the configuration data from the operator (daily)
Transaction
- Create <StringMessage> and set <RoutingHeader>, <AuthHeader> as required by the GDS system used
- create entry message in the format of the version chosen, set the marshalled message as Content (payload)
- Send the complete message to the GDS or directly to the operator endpoint as applicable
GDS workflow
- Check if the client is allowed to use the system and the operator, optionally check for the correct GDS agency
- 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
- Get the <StringMessage> from the client / GDS
- Optionally check authentication
- Check the GDS agency and map it to the internal one
- 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.
