Page History
...
Start med at kalde NTS direkte uden om DCC'en:
curl --data "@nts-request.xml" -H "Content-Type: application/soap+xml; charset=utf-8" -H "SOAPAction:http://nspop.dk/nts/2013/05#invoke" http://test1.ekstern-test.nspop.dk:8080/nts/service
Verificer at svaret er følgende:
...
Ændrer nu kaldet ved at tilføje URL'en til DCC foran URL'en til NTS.
curl --data "@nts-request.xml" -H "Content-Type: application/soap+xml; charset=utf-8" -H "SOAPAction:http://nspop.dk/nts/2013/05#invoke" http://localhost:8080/decoupling/http://test1.ekstern-test.nspop.dk:8080/nts/service
I dette tilfælde er DCC'en startet op lokalt vha. docker-compose setup og DCC'ens URL er "http://localhost:8080/decoupling". Svaret skal være det samme som det direkte kald bortset fra at ID'erne (FlowID, MessageID og InResponseToMessageID) er forskellige for hvert kald til NTS'en.
...
- 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.
- 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.
- Beskeden parses: Der foretages en SAX parsning af beskeden hvor relevante informationer opsamles og eventuel fjernes/modificeres (DCC og WS-addressing headere).
- 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.
- Beskeden sendes til WSPen.
- WSP svaret streames tilbage til WSC. Ved timeout i WSP kaldet returneres i stedt et fejlsvar.
...
| Anchor | ||||
|---|---|---|---|---|
|
...
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_.
...
FaultCode | Beskrivelse |
dcc_timeout | Timeout i kald til WSP. |
dcc_syntax_error | Syntaksfejl i det indkommende kald. |
dcc_access_denied | (Kun hvis DCC er konfigureret med IP whitelistening, hvilket pt. ikke er tilfældet på NSP) |
dcc_general_error | Andre typer fejl som opstår i DCC og som ikke er dækket af ovenstående, fx kald med en operation (SOAPAction) som ikke er konfigureret i komponenten, I/O fejl under videresendelse af kaldet (fx hvis WSPen ikke kan nås) etc. |
Et eksempel DCC fejlsvar ser således ud:
| Code Block | ||
|---|---|---|
| ||
<?xml version="1.0" encoding="UTF-8"?> <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> |
| Anchor | ||||
|---|---|---|---|---|
|
...