714.1 Modernisering af WSRM
Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
(Skabelon af dato 17/12-2015) Indholdsfortegnelse
1 Ændringslog
2 Afgrænsning af

Page Properties
STAR Projektleder (PL) Forretningsanalytiker (FA) STAR Release Epic status Eksterne snitflader 2016-3 1.0 KSS, A-kasser, alle der aftager WSRM-beskeder

Indholdsfortegnelse
1 Ændringslog
2 Afgrænsning af epic
3 Oversigt over berørte web services
4 Beskrivelse af epic
4.1 Baggrund
714.1.1 Der er udviklet en ny model for metadata på WSRM-beskeder. Modellen er dokumenteret
4.1.2 CodelistService (Version 5)
714.1.3 Den nye model for metadata anvendes på alle fremadrettede beskeder, de første beskeder anvender metadata.
5 Særlige krav til test
6 Kendte udeståender fra udviklingsfasen
7 User stories
8 Implementeringsnoter

...

Anchor
_Toc430086833 _Toc430086833

Anchor
_Toc430087178 _Toc430087178

Anchor
_Toc455408533 _Toc455408533

Afgrænsning af epic

Anchor
_Toc430086834 _Toc430086834

Anchor
_Toc430087179 _Toc430087179

Bemærk at der ikke er defineret en forretningsmæssig rækkefølge for alle WSRM-beskeder i DFDG og det ligger ikke i scope for denne epic at rette op på eventuelle uhensigtsmæssigheder i rækkefølgen. Sådanne ændringer vil skulle komme til i andre epics i efterfølgende releases.

Anchor
_Toc455408534 _Toc455408534

Oversigt over berørte web services

Anchor
_Toc430086835 _Toc430086835

Anchor
_Toc430087180 _Toc430087180

På sigt vil alle WSRM-aftagere berøres af den nye kodeliste, det er blot dette som forsøges afspejlet i ovenstående afkrydsning om berørte aftagere.

...

1. http://starwswiki.amstest.dk/RequestMetadataType-3.ashx

1. http://starwswiki.amstest.dk/RequestMetadataType-2.ashx

   Navn	Type	Detaljer
   CaseWorkerStructure	CaseWorkerStructureType	(caseworker: 3 navn-dele + RID) Forekomst: 1
   EventDate	dateTime	Hændelsesdatoen for registreringen Forekomst: 1

   
   

2. http://starwswiki.amstest.dk/RequestMetadataType.ashx

   Navn	Type	Detaljer
   CaseWorkerStructure	CaseWorkerStructureType	(caseworker: 3 navn-dele + RID) Forekomst: 1
   AuthorityStructure	AuthorityStructureType	(AuthorityCode, AuthorityName og AuthorityType. Alle strings) Forekomst: 1
   EventDate	dateTime	Hændelsesdatoen for registreringen Forekomst: 1

   
   

...

Derudover vil det være simplest for alle aftagere hvis metadata på WSRM hændelser følger samme struktur som metadata på andre webservicekald.
Der skal etableres en simplere måde at afhente på som er nemmere at forstå, og STAR vil fjerne unødvendig information som vi beder om når man henter. Denne ændring vil være bagud kompatibel.
Opgaven omfatter at udvikle en ny model for metadata og at supportere de udviklingsteams der laver nye WSRM beskeder i 2016-3. Vi skal sørge for at de WSRM beskeder der realeases bruger den nye model. Der kan stadig modtages beskeder i det gamle format, men nye beskeder er ikke bagud kompatible.

Anchor
_Toc455408537 _Toc455408537

714.1.1Der er udviklet en ny model for metadata på WSRM-beskeder. Modellen er dokumenteret

De udsendte metadata i WSRM-beskederne modelleres så de indeholder følgende:

• System ID på registrerende system
  • En ny kodeliste med aftagersystemer, ClientSystemIdentifier. Kendes ud fra det funktionscertifikat som blev benyttet ved registreringen. DFDG vil indeholde en mapningstabel.
• Den registrerende myndighed
  • Samme struktur som ActiveOrganisationHeaderType beskrevet her: http://starwswiki.amstest.dk/rep,oio,dk-ams,dk-xml-schemas-2005-09-01.ActiveOrganisationHeaderType-2.ashx
• Registrerende bruger og dennes organisation
  • Samme struktur som RequestUserMetadataType beskrevet her: http://starwswiki.amstest.dk/service,bm,dk-RequestUserMetadata-2015-01-21.RequestUserMetadataType.ashx
• Tidspunkt for hvornår beskeden er lagt på kø
  • det er dette tidspunkt der fremadrettet skal benyttes for at modtage WSRM beskeder i korrekt rækkefølge.
  • Tilføjelse af unik guid på WSRM beskeder
• Tilføjelse af sorteringsnøgle (integer) på WSRM beskeder

De eksisterende metadata der udsendes via RequestMetadata skal fjernes fra WSRM beskederne.
Der laves en ny type som samler WSRM metadata:
WSRMMetadataType

Bemærk at felterne SortKey, MessageIdentifier og EnqueueDateTime først ved 2016-4 udfyldes! Indtil 2016-4 anvendes der defaultværdier: SortKey=0, MessageIdentifier=00000000-0000-0000-0000-000000000000 og EnqueueDateTime=0001-01-01T00:00:00

Anchor
_Toc455408538 _Toc455408538

CodelistService (Version 5)

Anchor
_Ref453771461 _Ref453771461

ClientSystemTypeIdentifierType
Ny kodeliste med systemer som kalder DFDG. Implementeres delvist som intern tabel, og DFDG mapper ved modtagelse af kald til kodelistens værdier ud fra det kaldende FOCEScertifikat.Metodenavn: GetClientSystemTypeIdentifierCodeList

Bemærk dog at der er en værdi for "Andet".
nSom udgangspunkt forventes hvert system at have en entry i kodelisten. Hvis der er væsentlig fordele ved det ift. vedligehold kan man også gå over til at hvert certifikat har en entry (så fx KMD Fønix optræder med en entry for hvert a-kasse-certifikat som bruger systemet). , eller om system-type-information blot skal ligge internt i DFDG som en del af tabelgrundlaget, og dermed ikke udstilles (hvilket kan give god mening, da der på WSRM'erne er angivet systemtype i øvrige felter).
Kodelistens vedligehold skal ligeledes fastlægges i samarbejde med Systemforvalter.
Der laves en værdi der hedder "Andet" til brug i forbindelse med test, hvis systemer skal have adgang til at kalde DFDG uden en release, m.m.

...

Logikken I WsrmService forsimples sådan at TerminateSequence altid afslutter sekvensen. Det skal derfor ikke længere tjekkes at alle hændelser i kvitteret og heller ikke tjekkes at alle hændelser er forsøgt hentet. TerminateSequence vil fortsat logge om hændelser er forsøgt hentet.
Det bliver på denne måde op til aftager selv at sikre at alle hændelser hentes og herefter kalde TerminateSequence for at gå videre eller CloseSequence for at forsøge igen.
Det giver ingen ekstra sikkerhed at kvittering som i dag. Kvitteringslogikken er unødig kompleks og manglende kvittering betyder blot at WSRM modtagelsen går i stå, så aftager er tvunget til at kvittere.
Aftager kan stadig kalde CloseSequence for at opgive afhentning og lade sekvensen gå forfra. Hvis aftager får fejl under afhentning af hændelser, kan aftager enten forsøge at hente de berørte hændelser igen eller i yderste konsekvens kalde CloseSequence for at starte forfra.

Aftager kan aktivt fravælge hændelser som aftager ikke ønsker at modtage ved blot at undlade at hente disse.
Denne ændring betyder også at fejlkode 4005-"Not all messages in the WS-RM Sequence were acknowledged" udgår.
Bemærk: Den nuværende Version 2 bibeholdes, men genimplementeres så den kalder Version 3 inde bag ved. Dvs. at kald til SequenceAcknowledgement ignoreres og andre felter vil enten blive ignoreret eller sat til null hvor de returneres.

Anchor
_Toc455408539 _Toc455408539

714.1.3Den nye model for metadata anvendes på alle fremadrettede beskeder, de første beskeder anvender metadata.

...

Anchor
_Toc430086837 _Toc430086837

Anchor
_Toc430087182 _Toc430087182

Anchor
_Toc455408541 _Toc455408541

Kendte udeståender fra udviklingsfasen

...