<p> DCC</p><p>USER DOCUMENTATION</p><p>Version Date Responsible Commentary 0.1 29/09-2011 ADS First draft</p><p>Side 1 af 6 Table of Contents</p><p>Page 2 of 6 1 Introduction</p><p>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’.</p><p>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)</p><p>Page 3 of 6 2 Calling the DCC</p><p>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.</p><p>For information regarding the Den Gode Webservice (DGWS) standard see http://www.medcom.dk/wm110731.</p><p>2.1 The DCC header In order to instruct the DCC a SOAP message must be enriched with a DCC header.</p><p><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></p><p>The DCC header contains the following elements.</p><p>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.</p><p>To specify a synchronous operation, the decoupling model must be set to: “synchronous_timeout”.</p><p>To specify an asynchronous operation, the decoupling model must be se to: “asynchronous”.</p><p>To specify a synchronous with transformation to an asynchronous, the decoupling model must be set to: “queue_after_timeout”.</p><p>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.</p><p>Page 4 of 6 However the id must be unique across all the clients of the DCC in order to prevent message clashes.</p><p>The system id must remain constant for the entire lifecycle of the client system. If changed responses may be lost.</p><p>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.</p><p>Clients in a cluster setup would usually use the same Id, whereas different installations for of the same product would have different ids.</p><p>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. </p><p>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.</p><p>Non sequenced messages are processed in a non-deterministic order.</p><p>However with sequenced messages the order is guaranteed.</p><p>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.</p><p>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.</p><p>Page 5 of 6 3 The responses web service</p><p>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.</p><p>The DCC response web service is defined in the “decoupling-response.wsdl” file.</p><p>Retrieving asynchronous messages from the DCC requires two web service invocations: - Retrieve responses. - Acknowledge responses.</p><p>3.1 Retrieving responses First the client must retrieve the responses from the DCC through the GetAsyncReplies operation.</p><p>This operation will return a limited number of responses to the client – by default a maximum of 10 responses.</p><p>Once the client has processed these responses, the client must acknowledge them.</p><p>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.</p><p>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.</p><p>3.2 Acknowledging responses Once a client has successfully processed the responses, it must call the DCC web service again invoking the SendConfirmation operation.</p><p>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.</p><p>Page 6 of 6</p>