Differences

This shows you the differences between two versions of the page.

--- fmk:1.6.0:xml-elementer:kombineret_loesning [2026-08-14 12:38] – [Kombineret løsning for request-/response headers] andm
+++ fmk:1.6.0:xml-elementer:kombineret_loesning [2026-09-24 14:26] (current) – andm
@@ Line 1: / Line 1: @@
-======= Kombineret løsning for request-/response headers =======
+======= Beskrivelse af de to parallelle skema-strukturer =======
-Det har vist sig kompliceret at implementere [[fmk:1.6.0:xml-elementer:request_response_headers|det tidligere forslag til FMK headere]] som en del af soap-headeren. Som følge her af har der været ønske om at implementere en løsning, hvor FMK-headerne kun indeholder en begrænset, udvalgt gruppe elementer ifht. den oprindelige løsning.
+====== Oprindeligt forslag ======
-Derudover flyttes FMK-headerne ned i hhv. requestet/responset i soap-body. [[fmk:1.6.0:xml-elementer:alternativ_request_response_header| Det nye forslag kan ses her]].
+I starten af 1.6.0 udviklingen besluttedes at placere diverse headerelementer i en samlet FMKRequestHeader i SOAP-headeren:
-Da den originale løsning allerede er ved at blive implementeret flere steder, så er der et behov for, at FMK kan acceptere begge løsninger i overgangsperioden.
+<code xml>
-Det løses ved at udvide det samlede request og response til at indeholde begge dele. Obligatoriske elementer gøres valgfri for nu.
+  <soap:Header>
+    <FMKHeader>
+    ...
+    </FMKHeader>
+  </soap:Header>
+  <soap:Body>
+    <Request>
+  </soap:Body>
+</code>
-Der indføres en validering, der bekræfter at
+Det samme gjorde sig gældende for det tilsvarende response.
-  * obligatoriske elementer eksisterer på én af de to former (Eksempel: Whitelisting findes enten som en del af FMKRequestHeader ELLER som et frit element i soapheaderen)
+Detaljer kan ses på xxx
-  * requestet holder sig til én form, og ikke blander de to løsninger (Eksempel: Hvis whitelistheaderen er defineret som en del af FMKRequestHeader, så er OnBehalfOfHeader ikke defineret som frit element).
-  * responset gives tilbage med samme opbygning som requestet (Eksempel: Hvis FMKRequestHeader er placeret i soapheaderen, så returneres det tiltænkte FMKResponseHeader-elementer også i soapheader som beskrevet i den originale løsning, og ikke som en del af responset som den nye løsning).
-De sidste to punkter bør sikre, at klienter ikke kommer til at implementere en hybrid mellem de to.
+====== Nyt forslag ======
-===== Request header =====
+Det har efterfølgende vist sig kompliceret at implementere løsningen for mange klienter.
-==== For original løsning: ====
+FMK-headeren er derfor blevet begrænset i sit indhold og flyttet til selve request-elementet i soap-bodyen:
-  * Alle elementer i FMKRequestHeader i soapheader
-==== For ny løsning ====
-Elementer "frit" i soapHeader:
-  * OnBehalfOfHeader
-  * WhitelistingHeader
-  * ConsentHeader
-  * MinLogSessionId
-  * PreflightOnly
-  * PartOfBatchOperation
-Elementer i FMKRequestHeader i request:
-  * Paging
-  * ExtendedValidationHeader
 <code xml>
-<soap:Header  ... >
+  <soap:Header>
-    <!-- Valgfri FMKRequestHeader for original løsning-->
+    <!-- Løse elementer, der tidligere var i FMKHeaderen-->
-    <FMKRequestHeader minOccurs="0">
+  </soap:Header>
-        <OnBehalfOfHeader> ... </OnBehalfOfHeader>
+  <soap:Body>
-        <WhitelistingHeader> ... </WhitelistingHeader>
+    <Request>
-        <ConsentHeader> ... </ConsentHeader>
+      <FMKHeader>
-        <MinLogSessionId>...</MinLogSessionId>
-        <PreflightOnly/>
-        <PartOfBatchOperation/>
-        <Paging> ... </Paging>
-        <ExtendedValidationHeader> ... </ExtendedValidationHeader>
-    </FMKRequestHeader>
-    <!-- Frie elementer for ny løsning, del 1 -->
-    <OnBehalfOfHeader minOccurs="0"> ... </OnBehalfOfHeader>
-    <WhitelistingHeader minOccurs="0"> ... </WhitelistingHeader>
-    <ConsentHeader minOccurs="0"> ... </ConsentHeader>
-    <MinLogSessionId minOccurs="0">...</MinLogSessionId>
-    <PreflightOnly/ minOccurs="0">
-    <PartOfBatchOperation/ minOccurs="0">
-</soap:Header>
-<soap:Body>
-    <Request-body>
-        <!-- FMKRequestHeader for ny løsning, del 2 -->
-        <FMKRequestHeader minOccurs="0">
-            <Paging minOccurs="0"> ... </Paging>
-            <ExtendedValidationHeader minOccurs="0"> ... </ExtendedValidationHeader>
-        </FMKRequestHeader>
         ...
-        <!-- Resterende request -->
+      </FMKHeader>
-        ...
+      <!-- Resterende request>
-    </Request-body>
+    </Request>
-</soap:Body>
+  </soap:Body>
 </code>
+====== Transition ======
+Da den originale løsning allerede er ved at blive implementeret flere steder, så er der et behov for, at FMK kan acceptere begge løsninger i overgangsperioden. Dette skulle muliggøre en smidig overgang fra den gamle til den nye udgave i testmiljøerne.
+Det løses ved at udstille 1.6.0 wsdl'en i begge udgaver. De kan fortsat hentes fra (indsæt link).
+Da den nye løsning er den blivende, er denne navngivet uden præ- eller suffix, mens den originale version kaldes "old". Denne navngivning gælder kun distinktion af folderne.
+Endpoints og namespace vil forblive uændrede i alt indhold, og skemaerne divergerer ikke i andet indhold.
+FMK vil internt tillade at begge skemaversioner anvendes. Hvis et klientsystem kalder med et request, der overholder det originale skema, så vil responset ligeledes blive givet på samme form. Ditto kald med det nye skema.
+====== Fremtiden for headers og ny implementering ======
+Bemærk, at det vil være udgave 2, der bliver den anvendte når FMK 1.6.0 aktiveres i produktion.
+Det er derfor den, der skal implementeres, hvis man endnu ikke er påbegyndt.
+Den originale/"old"-version er KUN tiltænkt de udviklere, der allerede HAR implementeret den originale løsning, frem til implementering af den nye løsning.
+Denne version vil fortsat fungere i en længere overgangsperiode i testmiljøerne. Den nye løsning vil dog blive et krav på længere sigt.