Flyt for meldingsutveksling

Når du bruker API-et til meldingsutveksling samarbeider API-et med meldingstjeneren for å ivareta utvekslingen. Meldingstjeneren vet om mottaker er en EDI-bruker eller en annen API-bruker og kan dermed kryptere og signere for sending over EDI, eller tilgjengeliggjøre meldingen for en annen API-bruker.

Man kan se for seg tre scenarier i en utveksling mellom API-brukere og EDI-brukere. API til EDI, EDI til API og API til API. EDI til EDI håndteres av dagens EDI-løsning og er ikke relevant for API eller EDI 2.0.

API til EDI

Figuren illustrerer en API-bruker A1 som sender en fagmelding til EDI-bruker E1. Meldingstjeneren står for EbXml-kommunikasjonen med E1, og tilgjengeliggjør en Applikasjonskvittering til A1.

API til EDI

1. API-bruker bruker POST /Messages for å sende en fagmelding. Meldingstjeneren, som ved hjelp av Adresseregisteret vet at mottakeren er en EDI-bruker, starter en normal EDI meldingsutveksling med E1 med transportkvitteringer og Applikasjonskvittering.
2. Fagmelding overleveres til E1 via EDI
3. Meldingstjeneren mottar en transportkvittering og oppdaterer status på fagmeldingen
   1. A1 kan om ønskelig spørre etter status på en melding ved å bruke GET /Messages/{id}/Status
4. Applikasjonskvittering mottas og persisteres
5. Transportkvittering (leveres umiddelbart)
6. A1 mottar applikasjonskvittering.
   1. Merk at dette ikke er en push, men at API-brukeren først bruker GET /Messages for å få en liste over uleste meldinger etterfulgt av GET /Messages/{id}/BusinessDocument for å hente ned fagmeldingen. Denne bør igjen følges opp med en PUT /Messages/{id}/Read når meldingen er persistert hos A1 slik at den ikke hentes på nytt ved neste kall til GET /Messages
   2. API-brukeren kan velge å bare motta fagmeldinger med GET /Messages endepunktet. Status på en fagmelding (GET /Messages/{id}/Status) TEST inneholder også status på applikasjonskvitteringen og dette kan brukes som en enklere implementasjon for API-brukere som ikke ønsker å forholde seg til en XML i denne sammenhengen.

EDI til API

Figuren illustrerer en EDI-bruker E1 som sender en fagmelding til API-bruker A1.

EDI til API

1. E1 sender en fagmelding til A1. Denne mottas av Meldingstjeneren ettersom A1 er endret til denne adressen i Adresseregisteret
2. Meldingstjeneren svarer med transportkvittering så snart meldingen er persistert
3. A1 mottar fagmeldingen ved å bruke GET /Messages for å få tilbake Id på den uleste meldingen og deretter GET /Messages/{id}/BusinessDocument for å hente fagmeldingen
4. A1 leverer en applikasjonskvittering med POST /Messages, alternativt med POST /Messages/{id}/Apprec
5. Meldingstjeneren videreformidler applikasjonskvitteringen
6. Meldingstjeneren mottar transportkvittering og oppdaterer status på applikasjonskvitteringen

API til API

Figuren illustrerer en API-bruker A1 som sender en fagmelding til API-bruker A2.

Api til Api

1. A1 sender en fagmelding med POST /Messages til A2 som persisteres i meldingstjeneren
2. A2 henter ID til den uleste medlingen med GET /Messages og deretter fagmeldingen med GET /Messages/{id}/BusinessDocument
3. A2 sender en applikasjonskvittering med POST /Messages til A1, alternativt med POST /Messages/{id}/Apprec
4. A1 henter applikasjonskvitteringen enten

1. som en XML med GET /Messages og GET /Messages/{id}/BusinessDocument
2. som en Status-json med GET /Messages/{id}/Status