SOSI-DCC anvenderguide

Indledning
Målgruppe
Webservice snitfladen
Processering af indkommende kald
Fejlsituationer
Referencer

Indledning

Nærværende dokument udgør anvenderguiden for SOSI-DCC komponenten, også kendt som SOSI Afkoblingskomponenten. SOSI-DCC fungerer som webservice gateway og dens hovedfunktioner er routing af requests og håndhævelse af timeout-grænser på webservice kald Komponenten tilbyder i princippet også funktionalitet til asynkron afkobling af webservice kald. Denne funktionalitet er ikke implementeret på den Nationale Service Platform (NSP) og er derfor udeladt fra denne anvenderguide.. Timeout-grænser er på operationsniveau konfigureret i komponenten, men kan overrides af klienter til afkoblingskomponenten som en del af web service kaldet. 

Som webservice gateway er komponenten placeret mellem en klient – som kaldes en webservice consumer (WSC) – og en service udbyder, kaldet en webservice provider (WSP). 
Som illustreret på nedenstående figur sender WSCen webservice requests til WSPen igennem SOSI-DCC og modtager responsen direkte ved synkron kommunikation. 

SOSI-DCC understøtter [SOAP 1.1] kald (og dermed også Den Gode Webservice [DGWS]) samt [MTOM], men ikke [SOAP 1.2]. 
Afhængig af konfiguration af komponenten gør SOSI-DCC brug af [WS-addressing]. 

Målgruppe

Denne anvenderguide henvender sig til arkitekter og udviklere, der skal kalde webservices i gennem SOSI-DCC.

Webservice snitfladen

SOSI-DCC har én proxy webservice snitflade, som router kald på baggrund af den operation der kaldes – angivet som 'SOAPAction' HTTP header En angivelse af 'SOAPAction' HTTP headeren er påkrævet for HTTP bundne SOAP kald. .
\\
For hver operation, der skal kunne kaldes i gennem DCC, er komponenten konfigureret med et WSP endpoint, en timeout-grænse og en eventuel proxy endpoint som kaldet skal routes i gennem (fx en SOSI-Gateway). 
\\
Klienter kan override den i DCC konfigurerede timeoutgrænse ved at tilføje følgende SOAP header i DCC namespacet (http://www.sosi.dk/2007/07/decoupling-component-1.0.xsd) til kaldet, hvor det ønskede timeout angives i millisekunder (her 500 ms):
\\
<dcc:DecouplingHeader 
     xmlns:dcc="http://www.sosi.dk/2007/07/decoupling-component-1.0.xsd">
<dcc:DecouplingModel>synchronous_timeout</dcc:DecouplingModel>
 <dcc:Timeout>500</dcc:Timeout>
</dcc:DecouplingHeader>
\\
SOSI-DCC fjerner denne DecouplingHeader i kald der viderestilles.
\\
Komponenten konfigureres – igen på operationsniveau – til enten at ignorere eller videreføre _URL path_ _suffikset_ i kaldet, hvor der med _URL path_ _suffiks_ menes den del af endpoint URLen efter SOSI-DCCens endpoint URL (typisk noget i stil med http\[s\]://<host>:<port>/decoupling/).
\\
Fx udgør someService/someID URL path suffikset i følgende URL (her fra det ene eksterne NSP testmiljø som eksempel):
\\
http://test2.ekstern-test.nspop.dk:8080/decoupling/someService/someID
\\

Processering af indkommende kald

Når en besked modtages fra en WSC til videreforsendelse til en WSP, gennemløbes følgende flow i komponenten:

1. Whitelistning checkes Der bemærkes, at IP-whitelistning ikke er implementeret på NSP.: Hvis ikke WSCens IP adresse optræder i komponentens whitelist, afbrydes kaldet og et fejlsvar returneres til WSCen.
2. Routing slås op i komponentens konfiguration: På baggrund af SOAPAction i HTTP headeren afgøres hvorhen beskeden skal routes. Hvis routingsinformation ikke findes i komponentens konfiguration afbrydes kaldet og der returneres et fejlsvar.
3. Beskeden parses: Der foretages en SAX parsning af beskeden hvor relevante informationer opsamles og eventuel fjernes/modificeres (DCC og WS-addressing headere).
4. Afkoblingsmodel identificeres: Hvis ikke WSCen har specificeret en timeoutgrænse i beskeden, benyttes default timeout for den pågældende operation som er angivet i komponentens konfiguration.
5. Beskeden sendes til WSPen.
6. WSP svaret streames tilbage til WSC. Ved timeout i WSP kaldet returneres i stedt et fejlsvar.

\\
Der bemærkes, at komponenten ikke er bundet til \[DGWS\] og ikke foretager nogen form for validering af at \[DGWS\] overholdes og dermed heller ikke validerer et eventuel indlejret SOSI Idkort.
\\
Afhængig af hvordan den enkelte operation (SOAPAction) er konfigureret, _erstatter, fjerner_ eller _bevarer_ SOSI-DCC \[WS-addressing\] headere i kaldet der viderestilles.
\\
For oplysninger om den konkrete konfiguration (og dermed semantik) for de enkelte operationer på NSP instanserne henvises til NSP operatøren.

Fejlsituationer

Fejlsvar fra WSPen som kaldet blev viderestillet til returneres af SOSI-DCC i uforandret form.
\\
Ved fejlsituationer der opstår i SOSI-DCC returnerer komponenten et fejlsvar der følger \[DGWS\] formatet for SOAP faults.
\\
Nedenstående tabel lister de mulige fejlkoder og beskriver hvornår typen af fejlen opstår. 
\\
Alle fejlkoder som DCC generer er præfikset med dcc_.
\\

Et eksempel DCC fejlsvar ser således ud:
<soapenv:Envelope id="Envelope">
<soapenv:Header>
<wsse:Security>
<wsu:Timestamp>
<wsu:Created>2016-12-14T09:22:26Z</wsu:Created>
</wsu:Timestamp>
</wsse:Security>
<medcom:Header>
<medcom:SecurityLevel>1</medcom:SecurityLevel>
<medcom:Linking>
<medcom:FlowID>unknown</medcom:FlowID>
<medcom:MessageID>AAABWPyj23gwaMH/cmFafFNPU0k=</medcom:MessageID>
<medcom:InResponseToMessageID>unknown</medcom:InResponseToMessageID>
</medcom:Linking>
</medcom:Header>
</soapenv:Header>
<soapenv:Body>
<soapenv:Fault>
<faultcode>Server</faultcode>
<detail>
<medcom:FaultCode>dcc_syntax_error</medcom:FaultCode>
</detail>
<faultstring>No SOAPAction specified in http header!</faultstring>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>

Referencer