Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Indholdsfortegnelse

Afgrænsning af epic

Oversigt over berørte webservices 

Manuel oversigt som er synlig for eksterne (links i listen virker kun med STAR Jira konto):

Jobnets håndtering af interne snitflader

Nr. 2 undersøges af 

Automatisk oversigt (vi arbejder på løsning på at gøre den synlig)

Beskrivelse af epic

I øjeblikket benytter STAR sig af sin egen SMSgateway ved udsendelse af SMSer.

Antal SMSer

Antallet af SMSer der ca. bliver sendt på en måned er:

254.630 stk (seneste 30 dage ved kørsel d. 23-09-2019)

Ovenstående antal er fratrukket SMSer vedr. TJOB og kvitterings frist for MinPlan som udgår ved release af 2019-4

Telefonnumre

Antallet af borger verificerede mobiltelefon numre samt borger mobiltelefon numre som er blevet oprettet af sagsbehandlere er:

Tal fundet ved eksekvering af scripts d. 23-09-2019 (Manuscript 157147)

Ovenstående skal benyttes i samtale / mail med DigitalPost (e-Boks) til begrundelse til, hvorfor STAR skal have mulighed for at tilmelde borger via Jobnet.

Efter samtale med Digital Post er det besluttet at Jobnet implementere et link til Digital Post i stedet for muligheden for tilmelding direkte i Jobnet, dette grundet at der ved tilmelding af NemSMS skal indtastes beskæftigelses kode på Digital Post.

Maksimalt indhold af en NemSMS er 160 karakterer

NemSMS

Dokumentation findes på digitaliseringensstyrelsens hjemmeside:

https://digst.dk/it-loesninger/digital-post/vejledninger/

NemSMS’er

NemSMS’er, der er korte meddelelser fra myndighed til slutbruger, kan afsendes via REST,
S/MIME og masseforsendelse snitfladerne. Da NemSMS-brugeren skal kunne modtage
beskeden som SMS, sætter dette nogle begrænsninger på indholdet. En NemSMS kan
maksimalt indeholde 160 karakterer og kan ikke sammenkædes. Se afsnittet ’Tegnsæt’ mht.
encoding.
Tidsrummet for udsendelse af NemSMS er afgrænset til kl. 8.00 – 22.00. Hvis
afsendelsestidspunktet for en NemSMS er uden for dette tidsrum korrigeres dette automatisk.
Bemærk at der kan gå op til en time før NemSMS’en forsøges sendt.
Filformatet skal altid sættes til ’TXT’ for NemSMS’er.

Tegnsæt

Alle XML dokumenter der afleveres skal være encoded i UTF8. Alle tekster må uanset hvilken
encoding der er anvendt kun indeholde karakterer, som er indeholdt i ISO 8859-1 (Latin-1,
Western European).
For samtlige snitflader forudsættes at indholdet af meddelelser, dokumenter og vedhæftninger,
hvor filtypen (FilFormatNavn) er ’TXT’ og ’HTM’, er encoded i ISO 8859-1.
Når en slutbruger oploader en fil som vedhæftes en forsendelse til en myndighed forudsættes,
at myndigheden er i stand til at håndtere filen i det format slutbrugeren har anvendt.
NemSMS’er afleveres encoded i ISO 8859-1 formatet, men karaktererne er her yderligere
begrænset til standard SMS 7-bit karaktersættet, som defineret i GSM 03.38 standarden for
’Alphabets and language-specific information (se vedhæftning)

Ud fra ovenstående er det testet at følgende karakterer kan sendes med NemSMS:

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_abcdefghijklmnopqrstuvwxyz{|}~¡£¤¥§¿ÄÅÆÇÉÑÖØÜßàäåæçèéìñòöøùü

Tiltænkt flow

Før afsendelse tjekkes om borger er tilmeldt materialet (NemSMSen), i digital post er det alt eller intet, borger kan derfor enten være tilmeldt eller ikke tilmeldt NemSMSer.

Er borger tilmeldt sendes NemSMS via enkeltforsendelse til borger.

Er borger ikke tilmeldt sendes der ikke SMSer, på Jobnet vises et link til Digital Post.

Info: Muligheden for tilmelding direkte i Jobnet bliver derved ikke implementeret, dette grundet at der ved tilmelding af NemSMS skal indtastes beskæftigelses kode på Digital Post.

Af Digital post snitflader 7.0 (Afsnit 4.1 C.)

Afgør via online REST kald til afsendersystemet.

Via nedenstående REST kald kan det afgøres online, hvorvidt en specifik slutbruger er tilmeldt en given indholdstype (se Bilag A1 - REST - Afsendersystem).

Kaldet må kun anvendes ved enkeltforsendelser (dvs. ikke masseforsendelse).

Forespørg om en slutbruger ønsker en specifik indholdstype

GET /afsendersystem/{sysid}/Tilmeldinger/{indholdstypeid}

Pseudo kode eksempel

string param = "?cpr=1234567890"; 
string uri = "/afsendersystem/1234/tilmeldinger/4/" + param; 
 
// Afgør om afsendelse er muligt  TilmeldingTilmeldtIndikator tilmeldt = HTTP_GET(uri); 
 
bool kanFremsende = tilmeldt; 
 

XML eksempel svar på forespørgsel

GET https://api.eboks.com/dp/rest/srv.svc/2/afsendersystem/149/tilmeldinger/123456976 ?cpr=0703740001 
 
<boolean>false</boolean> 

Enkeltforsendelse / opdater afsendelse

PUT /afsendersystem/{sysid}/afsendelser/{meddelelsesid}

Anvendes til at oprette en afsendelse og opdatere en planlagt afsendelse. En afsendelse bliver til en meddelelse når den er afsendt. Afsendelsen kan indeholde både XML og binære data, når den oprettes. Det binære data er indkodet i Base64 formatet. Afsendelsen indeholder afsendelsens informationer inklusiv metadata, selve indholdet, og evt. vedhæftninger. Når en afsendelse er oprettet er den eneste ændring der kan foretages annullering eller ændring af afsendelsestidspunkt. En afsendelse bliver først afsendt, når den har status planlagt og det angivne afsendelsestidspunkt er nået. Indtil da er den planlagt eller afventer. Parameteren meddelelsesid bestemmes af afsendersystemet. Det er afsendersystemets ansvar at sikre at de anvendte id’er er unikke indenfor det pågældende afsendersystem.

Pseudo kode eksempel

//	Eksempel på opdatering af en planlagt afsendelse
string uri = ”/afsendersystem/4/afsendelser/100”;
AfsendelseOpdatering afsendelse = HTTP_GET(uri);

//	Opdater afsendelse med ny afsendelsestidspunkt
afsendelse.AfsendelseDatoTid = ”2009-10-10T12:00:00”;

HTTP_PUT(uri, afsendelse);

Pseudo kode eksempel 2
// Eksempel på besvarelse af en henvendelse
// Afssendersystem skal finde unik meddelelsesId
string meddelelseId = "000004” + GetTimeStamp();
string uri = ”/afsendersystem/4/afsendelser/” + meddelelseId;
 
// Opret HTML meddelelse til afsendelse 
String HtmlTekst = "<html><head><title>Titel</title>";
HtmlTekst += "<meta http-equiv=’Content-Type’ content=’text/html;
charset=iso-8859-1’>";
HtmlTekst += ”</head><body>”;
HtmlTekst += ”<p>Kære Tina Hansen</p>”;
HtmlTekst += ”<p>Vi sender her vores årlige”;
HtmlTekst += ”informationsskrivelse.</p>”;
HtmlTekst += ”<p>Med venlig hilsen</p>”;
HtmlTekst += ”<p>Afsender Kommune</div>”;
HtmlTekst += ”</body></html>”;

String msgISO88591 = ISO88591Encode(HtmlTekst);
string vedhaeftning = LoadFile("Adgangskort.PDF"); 
 
// Opret afsendelse
Afsendelse afsendelse = new Afsendelse() {
	AfsendelseModtager = ”CPR:0102030405”,
	MeddelelseIndholdstypeIdentifikator = 43,
	MeddelelseTitelTekst = "Informationsskrivelse",
	MeddelelseIndholdData = Base64Encode(msgISO88591),
	MeddelelseTraadIdentifikator = ”1001”,
	AfsendelseDatoTid = DateTime.Tommorow(),
	MeddelelseSvarTypeNavn = "standard",
	MeddelelseFESDmetadata = new MeddelelseFESDmetadata() {
		FESDsagIdentifikator = ”550e8400-e29b-41d4-a716-446655440000”,
		FESDsagsklassifikationIdentifikator = ”0048e045-4d14-b92e-a716-223344556600”
	}
	VedhaeftningSamling = new VedhaeftningSamling[2] = {
		new Vedhaeftning() {
			BilagIdentifikator = "1001"
		},
		new Vedhaeftning() {
			VedhaeftningNavn = "Personligt adgangskort",
			VedhaeftningIndholdData = Base64Encode(vedhaeftning),
			FilformatNavn = "HTM"
		}
	}
} 
 
HTTP_PUT(uri, afsendelse);


XML eksempel på oprettelse af en NemSMS-bruger

PUT https://api.e-boks.com/dp/rest/srv.svc/2/afsendersystem/149/afsendelser/000149a100 
 
<?xml version="1.0" encoding="utf-8"?>
<dkal2:Afsendelse xmlns:dkal1="urn:oio:dkal:1.0.0" xmlns:dkal2="urn:oio:dkal:2.0.0">
<dkal1:AfsendelseModtagerSamling>
<dkal2:AfsendelseModtager>
<dkal1:CPRnummerIdentifikator>2012741111</dkal1:CPRnummerIdentifikator>
</dkal2:AfsendelseModtager>
</dkal1:AfsendelseModtagerSamling>
<dkal1:MeddelelseIndholdstypeIdentifikator>123457415</dkal1:MeddelelseIndholdstypeIdentifikator>
<dkal2:MeddelelseTitelTekst>TestOverskrift</dkal2:MeddelelseTitelTekst>
<dkal1:MeddelelseIndholdData>VGVzdCBiZXNrZWQ=</dkal1:MeddelelseIndholdData>
<dkal1:FilformatNavn>TXT</dkal1:FilformatNavn>
<dkal1:MeddelelseTidsfristDato>2016-04-01</dkal1:MeddelelseTidsfristDato>
<dkal1:MeddelelseTidsfristTekst>Tidsfrist</dkal1:MeddelelseTidsfristTekst>
<dkal1:VedhaeftningSamling>
<dkal1:Vedhaeftning>
<dkal1:BilagIdentifikator>20104444</dkal1:BilagIdentifikator>
</dkal1:Vedhaeftning>
<dkal1:Vedhaeftning>
<dkal1:VedhaeftningNavn>test</dkal1:VedhaeftningNavn>
<dkal1:FilformatNavn>txt</dkal1:FilformatNavn>
<dkal1:VedhaeftningIndholdData>VGVzdA==</dkal1:VedhaeftningIndholdData>
</dkal1:Vedhaeftning>
</dkal1:VedhaeftningSamling>
</dkal2:Afsendelse> 
 
 

Konfiguration

Demo

Base endpoint: https://demo-rest.e-boks.dk/V1.svc

CertifikatSN: CVR:30808460-UID:25351738

SysID: 4290

IndholdsTypeId: 181292

Prod

Base endpoint: https://rest.e-boks.dk/V1.svc

CertifikatSN: CVR:30808460-UID:25351738

SysID: 42764 

IndholdsTypeId: 181482

Acc.kr 975.1.1 DFDG sender huskeservice SMS'er via NemSMS

Opgaver

Nedenstående huskeliste, hvad der skal gennemgås.

• Ny servicemetode i DFDG som udstiller, metode til brug for at bestemme, hvorvidt borger er tilmeldt NemSMS eller ej.

  • Jira Legacy
    server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1855

• Send til NemSMS i stedet for GateWay (Skema validering før afsendelse gøres konfigurerbar så man har mulighed for at slå dette fra efter de er kørt i ca. 3 måneder)
  • Ink Fejlhåndtering

  • Jira Legacy
    server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1863

• Hvorvidt beskeder er sendt/ikke sendt i LSS

  • Jira Legacy
    server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1872

• Oprydning
  • Gateway

    • Jira Legacy
      server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1870

  • SMSStatusService (hel service)

    • Jira Legacy
      server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1782

  • Verifikations logik /enqueue logik
  • Validering på hvad man er tilmeldt
  • Fjern validering på eksisterende telefon nummer
    

    • Jira Legacy
      server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1783

• Tekster tilpasses 160 tegn.

  • Jira Legacy
    server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1784

• Validering på CitizenMessageService.CreateMessage
  • 160 Tegn
  • Eksterne ikke kan sende på denne beskedtype

    • Jira Legacy
      server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1785

• Service ReminderService skal flyttes til NemSMS
  • Tages i afsnittet test, skulle virke out of the box.
• Whitelist/sortlist i TMiljøerne.

  • Jira Legacy
    server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1876

• Udsendelse af beskeder via borgers beskedbakke, hvor borger ikke kunne modtage via SMS.

  • Jira Legacy
    server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1875

• DASR tekster opdateres maksimalt 160 tegn

  • Jira Legacy
    server System JIRA serverId 479d1618-4a6f-3f88-8ee1-04c6b02c448a key DS-1784

Verifikations, enqueue og validerings logik

CitizenMessageService.CreateMessage

Der ændres på validerings logik ved kanaltype SMS, CitizenMessageChannelTypeIdentifier 1, fremadrettet vil beskedlængde maksimalt kunne være 160 tegn, ydermere fjernes alle andre end STARs egne systemer som benytter af kanaltypen SMS.

Fjernelse af service SMSStatusService

Da STAR overgår til NemSMS vil denne service ikke længere blive benyttet, service er lavet til at den eksisterende SMS gateway kunne kalde for at status, hvorvidt SMS blev sendt til borger eller ej kunne opsamles.

Fjernelse af borgers mulighed for at verificere sit mobiltelefon nummer

Da eksisterende SMS gateway fjernes, fjernes samtidigt borgers mulighed for at verificere mobiltelefonnummer.

Dette gøres blandt andet grundet indtastningen af mobiltelefonnummer på Jobnet, fremadrettet ikke behøver at være det samme mobiltelefon nummer som borger har angivet som sit NemSMS mobil telefon nummer, samt at borger i forbindelse med tilmelding til NemSMS skal bekræfte mobil telefon nummer.

JobnetPersonNotificationReminderService.(v1).SavePersonContactData vil derfor ikke længere generere en bekræftelseskode til borger i from af SMS ved benyttelse af PersonContactDataTypeIdentifier ID 1 (Mobiltelefon), ligeledes vil borger ikke længere kunne verificere sit mobiltelefon nummer ved kald til JobnetPersonNotificationReminderService.(v1).VerifyPersonContactData ved benyttelse af PersonContactDataTypeIdentifier ID 1 (Mobiltelefon).

Error

Nedenstående fejlkode vil ikke længere kunne kastes af DFDG, da borger ikke længere har behov for at verificere det mobiltelefon nummer som vedkommende har indtastet på Jobnet.

Nedenstående services havde tidligere mulighed for at kaste denne fejlkode.

• JobnetPersonNotificationReminderService v1

• PersonNotificationReminderService v1

• JobnetVacationService v6

• UnemploymentEnrollmentService v6 + 7

PersonCommunicationStatusService.(v1).GetPersonNemSMSSubscription udstiller, hvorvidt borger er tilmeldt NemSMS eller ej, metoden er sat op til kun at kunne blive kaldt af STAR.

Se snitflade beskrivelse her: PersonCommunicationStatusService (Version [UDV], 2020-1 LAB)

Man skal som kalder i TMiljøerne være opmærksom på, at der skal benyttes fiktive CPR-numre, ved kald af servicemetode, liste af fiktive CPR-numre kan findes via nedenstående link:

Fiktive Test-CPR-numre

Ved kald i TMiljøerne med "rigtige" CPR-numre vil resultere i at false vil blive returneret, dette er grundet at der i TMiljøerne er implementeret sortlistning/whitelistning af CPR-numre, da Digital Post frabeder sig kald med rigtige CPR-numre.

Udsendelse af beskeder via borgers beskedbakke, hvor borger ikke kunne modtage via SMS

I afsendelses øjeblikket, vil der fremadrettet blive valideret for følgende, før udsendelse af NemSMS foretages

• Borger er ikke ment at få SMS grundet whitelistning / sortlistning
  • Se nedenstående afsnit
• Borger er tilmeldt NemSMS
• Valideres ved brug af samme logik som udstilles i afsnittet
• Ny servicemetode i DFDG som udstiller, metode til brug for at bestemme, hvorvidt borger er tilmeldt NemSMS eller ej

Hvis borger ikke modtager SMS enten grundet whitelist/sortlistning, eller grundet borger ikke er tilmeldt NemSMS, sendes samme besked som borger ellers ville have modtaget via NemSMS, via borgers beskedbakke.

Følgende foranstillede besked før besked tekst i SMSen

• Du modtager nedenstående besked her på Jobnet, da det ikke var muligt at sende den via NemSMS, da du
  • ikke er tilmeldt NemSMS. Tilmeld dig NemSMS hos Digital Post for at modtage beskeder fra Jobnet via NemSMS. For at undgå beskeder af denne type kan du slå dit abonnement fra vedr. SMSer fra Jobnet - det kan gøres her på Jobnet.
  • er sortlistet.

• Titel er ligeledes
  • Sortlistet
  • Tilmeld dig NemSMS

Whitelist / sortlistning i TMiljøerne

Sortlistning / whitelistning i TMiljøer er bygget op så det sikres, at der ikke på noget tidspunkt, kan sendes SMSer til slutbruger uden at slutbruger er på whitelisten.

Tidligere var det således, at det var telefonnumre som var whitelistet, det var således en konfigurationsændring at få sit telefonnummer på whitelisten, dette ændres i forbindelse med implementeringen af NemSMS, grundet registeret med telefonnummere til brug for SMSer ikke længere er placeret hos STAR.

Ved afsendelse af NemSMS kender STAR, således ikke det telefonnummer SMSen vil blive sendt til hvorfor sortlistning / whitelistning i stedet vil virke på CPR-nummer.

Ved færdig implmentering er det følgende liste af fiktive CPR-numre der kan benyttes:

Fiktive Test-CPR-numre

Acc.kr 975.1.2 Passende tekst- og funktionsændringer på Jobnet ift. brugen af NemSMS

Acc.kr 975.1.3 Import af fiktive test CPR numre, hvor der er mulighed for NemSMS afsendelse

Af NemSMS digitalpost afsendersystem i demo er der listet en lsite fiktive CPR numre som vi kan sende ud på, disse CPR numre ønskes importeret som i epic 917.1 via BI.

Listen af fiktive CPR numre er:

• 0101600354
• 0101610354
• 0101620354
• 0101630354
• 0101640354
• 0101650354
• 0101660354
• 0101670354
• 0101680354
• 0101690354

Acc. kr. 975.1.4 STAR tilpasser antal tegn i SMS'er (max 160 tegn pr. sms)

Tekster er opdateret på siden:

Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:

• DFDG
  • Services
  • WSRMer
  • Kodelister
  • PersonStatusService (PSS)
  • PersonHistoryService (PHS)
  • LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)
• Jobnet
• VITAS
• JobKon
• JobAG
• BI integrationsplatform
• Alle områder
  • Nye batchjobs
    • Dokumentation af jobbet til SF (jf. skabelon: xxx link til skabelon) 
  • Dataløft
    • Hvis der i Databaser tilføjes eller fjernes kolonner med personfølsomme data (f.eks. person navne, adresser, email, telefonumre etc.), så skal SF informeres så disse data fremadrettet tilføjes eller fjernes fra scrambling.
• Kommunalt sagsbehandlingssystem
• A-kasse sagsbehandlingssystem
• Kommunalt bookingsystem
  • JobcenterPlanner (JCP)
  • WorkForcePlanner (WFP)
• Kommunalt ydelsessystem

Særlige krav til test

I TMiljøerne er det følgende liste af Fiktive CPR-numre der skal benyttes, da Digital Post har frabedt sig kald med "rigtige" CPR-numre på deres demo miljø.

• Fiktive Test-CPR-numre

Vejledning af brug af de fiktive Test-CPR-numre kan findes her

• Testvejledning til brug for NemSMS

NB: Vær opmærksom på ved test mod Digital Post i deres Demo miljø, kan det tage op til et par minutter for at NemSMSen når frem.

* Batchjobs

• bør testes både med delta og fuldt load,
• bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden
• bør testes i samarbejde med teams som har afhængigheder
• kørselstid, særligt hvis det er en del af NightlyBatch

Konsekvenser for drift/idriftsættelse

I forbindelse med idriftsættelse:

• Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres
• Skal der køres konvertering
• Skal der køres databasescripts for opdatering af tabeller i databasen

Efter idriftsættelse:

Arkitektur- og implementeringsnoter 

Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:

• Nye dataområder: Nej
• Nye snitflader: Ja, NemSMS
• Nye komponenter: ?
• Nye miljøer: ?
• Nye teknologier: ?
• Nye aftagertyper: Nej
• Eller afvigelser fra principperne: Nej
• Eventuelle behov for reduktion af teknisk gæld skal afdækkes: ?

Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.