Properties

R

messageId

Unik id på UUID-format.

messageId identifiserer en AMQP melding unikt og er uavhengig av eventuell meldingsId for fagmeldingen som sendes.

R

To

Id for kø-en meldingen skal sendes til (f.eks. _sync).

Det skal oppgis full id slik den er registrert i Adresseregisteret.

R

Subject

Angir meldingsinnhold med kodeverdi fra kodeverk 8279 «Meldingens funksjon»: se Volven

R

replyTo

Id for kø-en returmelding skal sendes til (f.eks. _sync). Det skal oppgis full id slik den er registrert i Adresseregisteret.

R

correlationId

Unik id for et sett av transaksjoner som hører sammen. ID på UUID-format.

Attributtet benyttes for synkrone meldinger, for å knytte svarmelding til forespørsel.

R

contentType

Settes til

verdien:

• Signert og kryptert innehold: «application/pkcs7-mime;

• smimetype=

• signed-and-enveloped-data»

O

absoluteExpiryTime

Ikke angitt per melding. Kø har default time to live på 10 dager

Application Properties

R

cpaId

Id for CPA-avtale

R

applicationTimeStamp

Tidsstempel for generering av AMQPmeldingen. Formatet skal være i henhold til ISO 8601 (CCYY-MM-ddThh:mm:ssTZD).

Tidspunkt skal oppgis i UTC. Dersom lokal tid benyttes skal tidssone angis.

Eksempel: 2014-02-26T12:45:32+02:00.

R

fromHerId

HER-id for avsender

R

toHerId

HER-id til mottaker

R2

originalMessageId

Feltet skal inneholde messageId fra den meldingen som AMQP-transportfeilmeldingen gjelder for

R2

receiverTimeStamp

Tidsstempel for når mottaker prøvde å behandle den meldingen som feilet.

R2

errorCondition

Lesbar og maskinlesbar kode som beskriver feilårsak

R2

errorDescription

Lesbar tekst som beskriver feilårsaken

Applicationdata

R

Den krypterte fagmeldingen (tilsvarende «Payload» i ebMS) plasseres direkte i «Application Data» uten noen form for MIMEencoding/konvertering. Dvs. at en skriver/leser de krypterte dataene til/fra AMQP-meldingen på samme måte som om en skriver til/fra en fil (dataene er en byte-array, byte[]).

Time.windows.com

Standard tidsserver for Windows, krever tilgang til internett

ntp.nhn.no

Tidsserver tilgjengelig på Helsenett

1

Send fagmelding

Fagsystem oppretter melding, sendes til meldingstjener.

2

Send AMQP melding

Meldingstjener sender melding, legges på mottagers Async kø.

3

Les melding fra kø

Mottager meldingstjener leser melding fra kø

4

Valider AMQP melding

Melding valideres i henhold til beskrivelse lenger ned i “Validering av meldinger og håndterng av feil”. Dersom validering feiles skal melding sendes til avsenders Error kø

5

Send AMQP Error

Feil oppstått som følge av validering av AMQP melding og definert i “Validering av meldinger og håndterng av feil” skal sendes til AMQP Error kø. Andre interne feil eller andre feilkilder skal ikke føre til melding på Error kø.

6

Valider fagmelding

Fagmelding valideres i henhold til beskrivelse lenger ned i “Validering av meldinger og håndterng av feil”.

7

Persister i fagsystem

Dersom melding validerer OK, persisteres melding i fagsystem for videre behandling.

8

Send negativ apprec

Dersom fagmelding ikke valideres OK, sendes en negativ apprec til avsenders async kø

9

Commit lest melding

Melding commites fra kø når en av følgende er oppfylt:

• Melding persistert OK i fagsystem

• AMQP Error sendt

Hvis melding forsøkes lest 10 ganger uten at den commites vil den legges på Dead letter kø.

10

Send positiv apprec

Positiv apprec til avsenders Async kø

11

Håndter Dead letter kø

Mottager må ha en prosess for å håndtere Dead letter kø. Alle meldinger som forsøkes lest 10 ganger uten å bli commited vil legges på Dead letter kø.

Årsak til feil rettes og melding kan legges tilbake på async kø for prosessering.

12

Håndter Error kø

Prosess for å håndtere og rette opp meldinger som ikke validerer OK i henhold til spesifikasjon

13

Håndter Aprec

Prosess for å håndtere positive og negative Apprec.

14

Håndter manglende respons

Dersom avsender har skrevet melding til kø, men ikke fått feilmelding på error kø eller applikasjonskvittering må dette håndteres. Hvordan dette løses, er implementasjonsavhengig og kan variere fra virksomhet til virksomhet

1

Send melding

Avsender sender melding, legges på mottagers Async kø

2

Les melding fra kø

Mottager leser melding fra kø

3

Valider AMQP melding

Melding valideres i henhold til beskrivelse lenger ned i “Validering av meldinger og håndterng av feil”. Dersom validering feiles skal melding sendes til avsenders Error kø.

4

Send AMQP Error

Error Feil oppstått som følge av validering av AMQP melding og definert lenger ned i “Validering av meldinger og håndterng av feil” skal sendes til AMQP Error kø. Andre interne feil eller andre feilkilder skal ikke føre til melding på Error kø.

5

Valider fagmelding

Fagmelding valideres i henhold til beskrivelse lenger ned i “Validering av meldinger og håndterng av feil”

6

Fagsystem behandler melding

Dersom melding validerer OK behandles forespørsel og svarmelding opprettes.

7

Commit melding

Melding commites fra kø når en av følgende er oppfylt:

• Svarmelding sendt

• AMQP Error sendt

Hvis melding forsøkes lest 10 ganger uten at den commites vil den leggges på Dead letter kø.

For synkrone meldinger er time to live 15 sekunder, så Dead letter kø vil i praksis ikke benyttes.

8

Send svarmelding

Svarmelding sendes til avsender av melding. Svar inneholder enten svar på forespørsel eller en feilkode dersom melding ikke kunne tolkes eller håndteres.

9

Håndter Error kø

Prosess for å håndtere og rette opp meldinger som ikke validerer OK i henhold til spesifikasjon

10

Håndter svarmelding

Prosess for å håndtere svarmeldinger.

AMQP melding

Verifisere verdiene for påkrevde felter. For å sikre at AMQP-meldinger inneholder påkrevde felter og verdier må det programmatisk gjøres en validering

AMQP-melding på Error-kø med errorCondition «transport:invalid-fieldvalue»

Kommunikasjonsprosessen er støttet, hentes fra CPA.

AMQP-melding på Error-kø med errorCondition «transport:unsupportedmessage»

Dekryptering feiler

AMQP-melding på Error-kø med errorCondtion «transport:decryptionfailed»

Avsenders sertifikat er utgått

AMQP-melding på Error-kø med errorCondition «transport:expiredcertificate»

Avsenders sertifikat er tilbaketrukket

AMQP-melding på Error-kø med errorCondition «transport:revokedcerificate»

Avsenders signatur kan ikke verifiseres

AMQP-melding på Error-kø med errorCondition «transport:invalidsignature»

Duplikat AMQP MessageID. AMQP melding har blitt sendt tidligere.

Melding logges av mottager, ingen respons på error kø og ingen apprec. Opprinnelig sendt melding forventes å gi apprec og meldingen skal ikke behandles en gang til av fagsystem.

Fagmelding header validerer ikke eller kan ikke tolkes.

AMQP-melding på Error-kø med errorCondition "transport:not-well-formedxml"

Replyto kø fins ikke

AMQP-melding på avsenders Error-kø med errorCondition «transport:invalidfield-value»

Ikke samsvar AMQP Avsender HER-Id <- > fagmelding Avsender HER-Id

AMQP-melding på Error-kø med errorCondition «abuse:spoofing-attack»

Fagmelding

Ikke samsvar AMQP mottager HER-Id <-> fagmelding mottager HER-Id

Negativ AppRec med kode «E10 Ugyldig meldingsidentifikator» fra kodeverk 8221.

Mottatt XML kan ikke tolkes

Negativ AppRec med kode «T01 – Ikke XML / ikke 'well formed' / uleselig» fra kodeverk 8221.

Krever at header i melding validerer og kan tolkes

XSD-validering

Negativ AppRec med kode «T02 – XML validerer ikke» fra kodeverk 8221.

Krever at header i melding validerer.

Validering av verdier for påkrevde felter feiler

Negativ Applikasjonskvittering med kode «T02 – XML validerer ikke» fra kodeverk 8221

Avsender mottar negativ AppRec

Avsender må manuelt følge opp mottatte feilkoder i AppRec og genere ny (feilfri) fagmelding og sende den. Resending av samme fagmelding skal ikke skje da dette forventes å føre til ny negativ AppRec.

Mottaker får ikke sendt AppRec i forbindelse med feil i sentral infrastruktur

Mottakers system sender automatisk AppRec på nytt etter et egendefinert tidsrom, eller gjør brukeren oppmerksom på feilsituasjonen med sentral infrastruktur slik at brukeren kan forsøke å generere/sende meldingen på nytt.

Avsender får ikke sendt melding i forbindelse med feil i sentral infrastruktur

Avsender sender melding på nytt automatisk etter et egendefinert tidsrom eller gjør brukeren oppmerksom på feilsituasjonen med sentral kø slik at brukeren kan forsøke å generere/sende meldingen på nytt.

Mottaker mottar samme fagmelding to ganger

Forkaste duplikat meldingen og sørge for at AppRec sendes kun én gang for forespørselen med tilsvarende fagmelding sin MsgId. En duplikat melding er en melding med samme verdi i MsgHead/MsgInfo/MsgId som en tidligere mottatt melding.

Avsender av fagmelding mottar ikke AppRec innen forventet tid

Forventet tid for mottak av apprec vil variere avhengig av bruken og hvilke aktører meldingen utveksles med. Helsenorge.no kan forventes å sende applikasjonskvittering innen et fåtall timer og normalt innen et fåtall minutter.

Avsender bør manuelt sjekke at melding er ok og kan sende melding på nytt. Ikke mottatt AppRec kan være feil hos mottaker og bør følges opp med mottaker for verifisering. Identisk fagmelding bør ikke resendes mer enn én gang.

NHN har sporbarhet på meldinger og overvåkning av køer og meldinger.

Helsenorge vil sende et varsel til innbygger om manglende kvittering etter et definert tidsrom. Denne funksjonen er nærmere beskrevet her: Varsel til innbygger ved manglende applikasjonskvittering

Systemet resender meldingen på nytt etter å ha mottatt en feil på AMQP Error-kø og rettet feil.

Ny

OriginalId

Systemet resender en melding etter å ha mottatt negativ AppRec og rettet feil.

Ny

Ny

Systemet resender en melding pga. at man ikke fikk lagt meldingen på køen (og derfor aldri har blitt behandlet av mottaker)

OriginalId

OriginalId

amqp:messageId

Ny unik verdi

originalMessageId

Settes til opprinnelige amqp:messageId

receiverTimeStamp

Tidspunkt da meldingen ble forsøkt behandlet av mottaker

errorCondition

Lesbar og maskinlesbar kode som beskriver feilårsak. Se tabell under for detaljering.

errorDescription

Lesbar tekst som beskriver feilårsaken. Se tabell under for detaljering.

errorConditionData

Inneholder tilleggsdata i forbindelse med feilmelding. F.eks. i forbindelse med manglende påkrevde felter kan man gjengi manglende felter på en maskinlesbar måte.

transport:invalid-cmspkcs

Could not decrypt message because of invalid format to CMS/PKCS.

transport:invalidcertificate

Could not decrypt message because of unknown/incorrect certificate

{ "thumbprint" : { "expected": "streng", "actual": "streng" } Thumbprint til sertifikater, for å lette feilsøking

transport:expiredcertificate

Could not decrypt message because of certificate expired.

Thumbprint til sertifikat, for å lette feilsøking

transport:revokedcertificate

Could not decrypt message because of certificate added to CRL (Certificate Revocation List).

Thumbprint til sertifikat, for å lette feilsøking

transport:decryptionfailed

Could not decrypt message because of unknown reason.

Thumbprint til sertifikat, for å lette feilsøking

transport:invalidsignature

Digital signature could not be verified.

Thumbprint til sertifikat, for å lette feilsøking

transport:requiredfield-missing

Missing or invalid value in field: 'AnyField'.

Array med navn på felter som mangler

transport:invalid-fieldvalue

Invalid value in field: 'AnyField'.

Array med navn på felter hvor verdier mangler eller ikke er satt riktig

transport:invalidencoding

Error occurred during decoding message. Expecting message encoded as ‘Unicode’.

En streng med IANA/MIME-navnet på encoding forventet http://www.iana.org/assignments/charactersets/character-sets.xhtml

abuse:spoofing-attack

Possible spoofing attack detected.

Array med to elementer { amqp:[herId], application:[herId] }

transport:xml-notinterpretable

XML cannot be interpreted