Ændringer til retransmission i FMK v1.2.6.3

[Ulrik Skyt]

I det følgende forklares baggrunden for den ændring, vi har implementeret vedr. retransmission, samt nogle flere detaljer omkring, hvad der rent faktisk er implementeret. Der er blandt andet indført en ny fejlkode.

Den Gode WebService (DGWS) stiller nogle krav til klienter og serviceudbydere for at muliggøre retransmission. Følgende er hvad der står i standarden (v1.0 / v1.0.1) om retransmission:

Den Gode Webservice anvender HTTP som transportmekanisme mellem klientsystem og
serviceudbyder. Desværre kan HTTP fejle, og det er udefineret, hvad der skal ske, hvis
f.eks. klientsystemet aldrig får svar på en forespørgsel.

For at forebygge at dette sker, skal både klientsystem og webserviceudbyder forsyne hver
request og response med et unikt id for den pågældende meddelelse og med et FlowID,
der er unikt for hele den pågældende session.

   
• Alle afsendte meddelelser skal forsynes med et unikt MessageID, der aldrig må
  bruges til andre meddelelser igen af den pågældende afsender – heller ikke efter en
  geninstallation. Dog skal meddelelsen ved genfremsendelse bruge samme
  MessageID.
• Serviceudbyderen skal i første response i sessionen forsyne meddelelsen med et
  unikt FlowID (løbenummer) for den pågældende session.
• Klientsystem og webserviceudbyder skal genbruge FlowID'et i efterfølgende
  meddelelser i samme session.

For yderligere at sikre en robust kommunikation genfremsendes sikkerhedsoplysninger i
alle kald i den pågældende session.

Ved hjælp af disse mekanismer er det muligt for et klientsystem:

   
• at genfremsende tidligere fremsendte requests uændret, hvis et kald skulle blive
  afbrudt
• at springe et kald over, hvis klientsystemet allerede har de informationer, der er
  nødvendige for at benytte senere eller andre kald i webservicen.

Det er således serviceudbyderens ansvar at sortere dubletter fra og returnere svaret igen,
hvis en request med samme MessageID modtages.

I FMK har dette været tolket således, at det har været klienternes ansvar at anvende unikke MessageID's, og FMK har derfor gemt RequestXML og ResponseXML i en database under en nøgle bestående af klientens IP-adresse og MessageID. Dvs. hvis et nyt request kom fra samme IP-adresse og anvendte samme MessageID som et andet request der er mindre end 14 dage gammelt, så ville ResponseXML fra det tidligere request blive sendt som svar.

Dette er desværre sårbart overfor klienter, som anvender MessageID's der ikke er tilstrækkeligt unikke. Hvis samme et MessageID ved et uheld genbruges indenfor en 14 dages periode har man således fået et response retur, som kan stamme fra en anden bruger, patient og en anden type request!

Det er ikke ualmindeligt, at klienter fra samme leverandør rent netværksmæssigt tilgår FMK via leverandørens adgang til Sundhedsdatanettet, og dermed vil potentielt en stor mængde klienter fremstå for FMK som havende samme klient-IP-adresse. Dette forværrer problemet idét sandsynligheden for sammenfald af MessageID's forøges når der er flere requests i spil. Desuden kan man dermed også modtage responses der stammer fra fx en anden lægepraksis, der anvender samme systemleverandør.

Fra FMK v1.2.6.3 er praksis ændret med hensyn til retransmission, således at et request betragtes som en retransmission hvis:

(1) IP-adresse + MessageID svarer til et kendt request fra de sidste 14 dage
(2) SOAP Body er identisk i det gamle og det nye request

Hvis kriterie (1) er opfyldt men kriterie (2) fejler, så har klienten ikke overholdt sin forpligtelse om at anvende unikke MessageID's, og FMK kan rent teknisk ikke gemme et nyt request med samme IP-adresse + MessageID, da det er den betydningsbærende nøgle. Derfor er der indført en ny fejlkode i FMK til denne situation.

Den nye fejlkode har medcom:FaultCode=3002 og faultstring="Requestet genbruger msgId {0} som allerede er brugt i et ikke identisk request".