DCC
USER DOCUMENTATION
Version
Date
Responsible
Commentary
0.1
29/09-2011
ADS
First draft
Side 1 af 6
Table of Contents
1
Introduction ........................................................................................................ 3
1.1
Purpose ...................................................................................................... 3
2 Calling the DCC ................................................................................................. 4
2.1
The DCC header ......................................................................................... 4
2.1.1
DecouplingModel ................................................................................. 4
2.1.2
SystemID ............................................................................................. 4
2.1.3
Sequence............................................................................................. 5
2.1.4
Timeout ................................................................................................ 5
3 The responses web service ................................................................................ 6
3.1
Retrieving responses .................................................................................. 6
3.2
Acknowledging responses........................................................................... 6
Page 2 of 6
1 Introduction
The DCC is a key component in the Danish national service platform (NSP).
The DCC acts as the central hub for communication between a client and a service
provider.
Further description of the functionality of the DCC can be found in the document
‘DCC product description’.
1.1 Purpose
The purpose of the DCC is to help developers handle some of the more complex
aspects of communicating with web services.
In order to facilitate the most use cases, the DCC supports three different message
types:
- Synchronous.
- Asynchronous.
- Synchronous transformed to asynchronous. (S/Asynchronous)
Page 3 of 6
2 Calling the DCC
In order to use the DCC, a SOAP message must meet the following requirements:
- The message must conform to the Den Gode Webservice standard.
- The message must contain the DCC header enhancement.
For information regarding the Den Gode Webservice (DGWS) standard see
http://www.medcom.dk/wm110731.
2.1 The DCC header
In order to instruct the DCC a SOAP message must be enriched with a DCC header.
<xs:element name="DecouplingModel">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="synchronous_timeout" />
<xs:enumeration value="queue_after_timeout" />
<xs:enumeration value="asynchronous" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="DecouplingHeader">
<xs:complexType>
<xs:sequence>
<xs:element ref="dcc:DecouplingModel" />
<xs:element name="Timeout" type="xs:int" minOccurs="0" />
<xs:element name="SystemID" type="xs:string" minOccurs="0" />
<xs:element name="Sequence" type="xs:string" minOccurs="0" />
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
</xs:element>
The DCC header contains the following elements.
2.1.1
DecouplingModel
The decoupling model instructs the DCC how to handle the message. As specified
earlier the DCC supports three types of message flow: synchronous, asynchronous
and a synchronous which transforms into an asynchronous.
To specify a synchronous operation, the decoupling model must be set to:
“synchronous_timeout”.
To specify an asynchronous operation, the decoupling model must be se to:
“asynchronous”.
To specify a synchronous with transformation to an asynchronous, the decoupling
model must be set to: “queue_after_timeout”.
2.1.2
SystemID
The system id is used to specify a unique id for the client system. This id is
determined by the client system, and does not conform to any specific requirements.
Page 4 of 6
However the id must be unique across all the clients of the DCC in order to prevent
message clashes.
The system id must remain constant for the entire lifecycle of the client system. If
changed responses may be lost.
When handling asynchronous messages the DCC uses this id together with the CVR
number of the supplied SOSI IDCard, to determine the response storage id.
Clients in a cluster setup would usually use the same Id, whereas different
installations for of the same product would have different ids.
In order to keep messages targeted for the different services separate, clients are
advised to use a different SystemIDs for each service the client is calling.
2.1.3
Sequence
The sequence element is used to instruct the DCC, that a number of asynchronous
messages should be processed in the order they are received by the DCC.
Non sequenced messages are processed in a non-deterministic order.
However with sequenced messages the order is guaranteed.
A sequence is not limited to a certain number of messages, and a sequence can
remain active for as long as the client system uses it.
2.1.4
Timeout
The timeout element controls the maximum amount of time the DCC will wait for at
service provider to finish, before returning to the client.
If not specified, the DCC will assign a default timeout period.
Page 5 of 6
3 The responses web service
Once an asynchronous message has been processed, and a response has been
received, the DCC stores the response in storage.
In order to retrieve the asynchronous response, the client must call the DCC
response web service.
The DCC response web service is defined in the “decoupling-response.wsdl” file.
Retrieving asynchronous messages from the DCC requires two web service
invocations:
- Retrieve responses.
- Acknowledge responses.
3.1 Retrieving responses
First the client must retrieve the responses from the DCC through the
GetAsyncReplies operation.
This operation will return a limited number of responses to the client – by default a
maximum of 10 responses.
Once the client has processed these responses, the client must acknowledge them.
Together with the response, the DCC also returns a segment hash. This segment
hash identifies to the DCC the current segment, and must be used when
acknowledging responses.
Failing to do so, will prevent the DCC from returning any further responses, and a
result return the same response over and over again.
It is therefore vital, that the client remembers to acknowledge the responses.
3.2 Acknowledging responses
Once a client has successfully processed the responses, it must call the DCC web
service again invoking the SendConfirmation operation.
This operation requires the segment hash received together with responses to
perform correctly.
Once processed successfully the client may retrieve any further responses in the
storage.
Page 6 of 6