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 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

Ændringslog

Afgrænsning af epic

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.

Oversigt over berørte web services

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.

Beskrivelse af epic

ISB 714 som er rammen for denne Epic er under udarbejdelse.
Denne Epic beskriver en ensretning og lidt oprydning i WSRM understøttelsen. Ændringen vil kun ramme

Baggrund

WSRM hændelser udsendes når der enten registreres data i DFDG eller når der sker en forretningsmæssig hændelse. WSRM beskederne indeholder hver især en specifik datastruktur som indeholder data der beskriver hændelsen.
Udover selv hændelsen er det også vigtigt for aftager at vide hvem der har foretaget registreringen og hvornår. I dag medsendes disse metadata i de fleste tilfælde i form af datastrukturen RequestMetadata. RequestMetadata findes i forskellige varianter med varierende dataindhold:

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

3. 
   

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

Fælles for disse typer er dog en række mangler, det er ikke muligt som aftager at se:

1. Hvilket system der har foretaget registreringen
2. Den registrerende organisation
3. Et sikkert tidsstempel for hvornår hændelsen blev genereret

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.

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
CodelistService (Version 5)
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.

714.1.2Der er etableret en simplere måde at afhente WSRM-beskeder, som kun efterspørger relevant information

Den nuværende snitflade til afhentning af WSRM beskeder udstilles via WsrmService (Version 2).
Der oprettes en Version 3 af samme service hvor der foretages følgende ændringer:

• Header-elementet OcesCertHeaderInput fjernes fra alle operationer
• Operationen SequenceAcknowledgement fjernes helt
• I operationen TerninateSequence fjernes følgende response-elementer:
  • MissingRangeCollection
• I operationen CreateSequenceResponse fjernes følgende response-elementer:
  • Expires
  • AcknowledgementInterval
  • Accept

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.

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

De nye metadata lægges i første omgang på:

• GetCitizen Message EventVersion3
• GetJoblogEventVersion2 er kandidat til en følgende pilot

Særlige krav til test

Kendte udeståender fra udviklingsfasen

Link til søgeresultat fra FogBugz på epic-nummer:

User stories

User stories er kun til interne brug for STAR's leverandører.

Implementeringsnoter

Elementerne EnqueueDateTime og SortKey tilføjes i databasen til WSRM køen.
Felterne sætte til NULL eller lignende når beskeden enqueues. Når WSRM beskederne dequeues læses de to felter fra databasen og skrives ind i beskederne inden de returneres til aftagerne.