...
I de fall tjänstekonsument och tjänsteproducent kommunicerar utan mellanliggande tjänsteplattform behövs inte denna http header då tjänsteproducenten i det fallet kan hämta avsändarens identitet direkt från tjänstekonsumentens klient certifikat, se regel #6 i RIV TA Basic Profile 2.1 [R3]. Detta illustreras av följande bild:
I de fall tjänstekonsument och tjänsteproducent kommunicerar via en eller flera mellanliggande tjänsteplattformar har samtliga tjänsteplattformar till ansvar att sätta denna http header om den inte redan är satt av en tjänsteplattform tidigare i anropskedjan. Är http header redan satt ansvarar respektive tjänsteplattform för att föra http headern vidare i anropet till tjänsteproducenten alternativt till nästa tjänsteplattform.
...
Följande bild visar hur ursprungsidentiteten förs via den nationella tjänsteplattformen från anropande tjänstekonsuments klient certifikat till tjänsteproducenten via http headern:
Nedan ett mer komplext exempel med tre tjänsteplattformar inblandade i anropet, dels en applikationslokal tjänsteplattform (också känd som Applikation Service Bus, ASB), dels en regional samt den nationella tjänsteplattformen. I detta exempel så är det den applikationslokala tjänsteplattformen som fångar upp identiteten från tjänstekonsumentens klient certifikat och sätter det i http headern. Den regionala och den nationella tjänsteplattormen för bara vidare inkommande http header till sitt utgående anrop:
Till sist ett exempel där vi vänder på anropskedjan för att visa hur det ser ut med en tjänsteproducent som sitter bakom en applikationslokal tjänsteplattform som i sin tur anropas av en regional tjänsteplattform. Tjänstekonsumenten i detta exempel anropar den nationella tjänsteplattformen som i sin tur anropar den regionala. Det blir nu den nationella tjänste-plattformen som fångar upp identiteten från tjänstekonsumentens klient certifikat och sätter det i http headern. Den regionala och den applikationslokala tjänsteplattormen för bara vidare inkommande http header till sitt utgående anrop:
2.2 Beskrivning av namnregler
...
Nedan ett exempel där en tjänstekonsument anropar en aggregerande tjänst som via engagemangsindex får reda på att det finns information att hämta i två olika källsystem. Den aggregerande tjänsten anropar de två källsystemen (parallellt) och sätter samman ett aggregerat svar till tjänstekonsumenten där SOAP header ”ProcessingStatus” ingår. Detta illustreras av följande bild:
Givet att båda källsystemen svarar korrekt så kommer ProcessingStatus – SOAP headern se ut något i stil med följande:
...
Om däremot något av de anropade källsystemen inte svarar inom en föreskriven tid eller returnerar ett fel så kommer ProcessingStatus-SOAP headern innehålla information om att svaret inte är komplett utan bara partiellt samt information om vilket fel som uppstod. I bilden nedan illustreras ett exempel där tre källsystem anropas men bara två ger svar, det tredje orsakar en timeout (dvs svarar inte inom föreskriven maxtid):
SOAP-headern ProcessingStatus kommer då se ut något i stil med följande:
...