...
...
...
...
...
Innehållsförteckning | ||
---|---|---|
|
Revisionshistorik
...
Version
...
Datum
...
Kommentar
...
3.0.6 RC2 (2022)
...
2021-09-28
Specifikation uppdaterad utifrån DIGGs uppdaterade specifiktioner version 0.97.
...
Innehållsförteckning
Table of Contents
Revisionshistorik
Expandera | ||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1. Inledning
Syfte: Specifikationen SDK Innehållsspecifikation meddelande reglerar hur ett s.k. ostrukturerat SDK-meddelande skall utformas för att kunna utbytas mellan användarorganisationer som är anslutna till SDK-federationen.
...
Utbyte av ostrukturerad information – fritext/dokument - PDFfiler
Utbyte mellan (många) organisationer (B2B)
Känslig information (personuppgifter, uppgifter som kan omfattas av sekretess)
Domänöverskridande (hälso- och sjukvård, socialtjänst, skola, arbetsmarknad, osv.)
Interoperabilitet – främst teknisk och legal
Målet är att ge kunskap om hur SDK-komponenter som meddelandetjänst och meddelandeklient/verksamhetssystem skall anpassas för att kunna hantera SDK-meddelanden.
1.1 Referenser
I följande avsnitt anges länkar till ytterligare relevant dokumentation och en sammanställning av samtliga referenser som förekommer i dokumentet.
1.1.1. Stödjande externa dokument
Expandera | |||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1.1.2. Stödjande SDK-dokument
Expandera | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
2. Övergripande arkitektur för informationsöverföring inom SDK
Detta kapitel refererar till flöden som är relevanta för informationsöverföring inom SDK.
Bilden illustrerar var i arkitekturen som SDK Innehållsspecifikation används. SDK-meddelandet paketeras i "nyttolast" och består av två element; XHE och MessageType (SDK Nyttolast).
...
Div | style
...
= page-break-before: always
2.1. Övergripande flöden
...
Ett meddelande skapas i meddelandetjänsten (t.ex. ärendehanteringssystem eller meddelandeapplikation).
...
Steg | Aktör | Beskrivning | Kommentar |
---|---|---|---|
1.Skapa meddelande | Organisation A
| I meddelandetjänsten skapas en meddelandestruktur enligt schema (XHE, MessageType) och paketeras i AS4.
| Meddelandet skapas i en meddelandetjänst. Steg 1 och steg 2 (steg 3) kan ske samtidigt. |
2.Adressera | Organisation A
| Användare(avsändaren) inom organisationen med tillgång till en SDK funktionsadress söker i en adressbok för att hitta anslutna organisationer och dess funktionsadresser. Meddelandetjänsten kompletterar meddelandet med adressuppgifter (organisations-id, funktions-id). Transportadressering:
Verksamhetsadressering:
| Användaren söker i en adressbok för att hitta anslutna organisationer och dess funktionsadresser. Detta kan ske antingen genom integration mot SDK Adressboks Sök-API eller genom en lokal läskopia. Specifikationer:
|
3.Kryptera och signera | Organisation A
| Avsändande användarorganisation krypterar och signerar meddelandet.
| Specifikationer:
|
4.Skicka meddelande | Organisation A
| Avsändande Accesspunkt skickar meddelande enligt eDelivery-protokoll.
| |
Organisation B
| Mottagande Accesspunkt tar emot meddelande för vidare leverans. Intern routing skall baseras på:
| ||
5.Status | Organisation B
| Transportkvittering: Mottagande Accesspunkt bekräftar överföring synkront enligt eDelivery-protokoll.
| |
6.Validering och kvittering | Organisation B
| Meddelandekvittering: Mottagande organisations meddelandetjänst validerar meddelande samt kvitterar meddelande.
Observera att kvittensmeddelande skall skapas enligt DIGGs specifikation Meddelandekvittens (R7). | Överföring till mottagande organisations meddelandetjänst är nu garanterad. Specifikationer:
|
...
7.Meddelandestatus | Organisation A | Meddelandekvittens mottages |
Div | style = page-break-before: always
2.2 AS4 och XHE-profilering
Avsnittet beskriver vilken information som skall anges i AS4 och XHE för denna meddelandetyp (dokumenttyp).
...
Följande anpassning skall göras för SDK Meddelande
2.2.1 Transportprofilering med AS4
Konfigurering | AS4 | |
---|---|---|
Dokumenttyp | Messaging
Värde: busdox-docid-qns::urn:riv:infrastructure:messaging:MessageWithAttachments:3::messagePayload##3.0::tm-base-ext-sigenc
|
| ||
Service (Process) | Messaging
Type = urn:fdc:digg.se:edelivery:process Värde =bdx:noprocess
|
|
2.2.3 Meddelandekuvertering med XHE
SDK Meddelanden skall kuverteras i enlighet med DIGGs XHE specifikation
Konfigurering | XHE | |
---|---|---|
| Unikt identifierare av meddelandet/nyttolast.
|
| ||||
| FromParty.PartyIdentification
ToParty.PartyIdentification
|
| ||
Meddelandets struktur | Payloads.Payload.DocumentTypeCode
Payloads.Payload.ContentTypeCode
|
| ||
Funktionsadress (egen identifierare) | Payloads.Payload.HandlingServiceID Nyttolastens funktionsadress, kan används för att underlätta meddelandehantering i meddelandetjänst/meddelandeväxel. SDK Meddelande och Meddelandekvittens (OBS! Meddelandekvittens är ett separat meddelande som har en egen specifikation. Se R7 Meddelandespecifikation: Meddelandekvittensavser):
|
|
Detaljkod: not-found
Detaljtext: Wrong or unknown xha:HandlingServiceID
3 Meddelandemodeller
3.1 Övergripande beskrivning
SDK Innehållsspecifikation definierar metadata samt innehållet (nyttolast) för SDK-meddelanden som skickas mellan anslutna användarorganisationer.
...
style | page-break-before: always |
---|
...
|
3 Meddelandemodeller
3.1 Övergripande beskrivning
SDK Innehållsspecifikation definierar metadata samt innehållet (nyttolast) för SDK-meddelanden som skickas mellan anslutna användarorganisationer.
Div | style = page-break-before: always
Lucidchart Diagrams
Div | style = page-break-before: always
3.2 Meddelandestruktur - MessageType
Samtliga fält skall hanteras och valideras av komponenterna Meddelandetjänst (MT) och Meddelandeklient/Verksamhetssystem (MK).
...
Bilden illustrerar hur SDK Innehållsspecifikation är strukturerad.
...
SDK meddelande exempel:
Kodblock | ||
---|---|---|
| ||
<tns:messagePayload> <tns:Message xmlns:tns="urn:riv:infrastructure:messaging:MessageWithAttachments:3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:riv:infrastructure:messaging:MessageWithAttachments:3 ../core_components/infra_messaging_MessageWithAttachments_3.0.xsd "> <tns:messageHeader> <tns:creationDateTime>2019-08-15T17:52:58.1Z</tns:creationDateTime> <tns:messageId>ff325210-0690-42fe-b86f-95ecab821223</tns:messageId> <tns:conversationId>a8480ada-6a1f-44a3-a960-9acaf4efcdcd</tns:conversationId> <tns:label>Rubrik: Kallelse till SIP möte</tns:label> <tns:confidentiality>false</tns:confidentiality> <tns:generatingSystem> <tns:root>kodverk-id</tns:root> <tns:extension>system-id-123456789</tns:extension> </tns:generatingSystem> <tns:recipient> <tns:recipientID> <tns:root>iso6523-actorid-upis</tns:root> <tns:extension>0203:arbetsformedlingen.se</tns:extension> </tns:recipientID> <tns:label>Arbetsförmedlingen</tns:label> <tns:attention> <tns:subOrganization> <tns:organizationId> <tns:root>urn:riv:infrastructure:messaging:functionalAddress</tns:root> <tns:extension>sub-funktion-org-id</tns:extension> </tns:organizationId> <tns:label>Avdelningen för Arbetsträning</tns:label> </tns:subOrganization> </tns:attention> </tns:recipient> <tns:sender> <tns:senderID> <tns:root>iso6523-actorid-upis</tns:root> <tns:extension>0203:habo.se</tns:extension> </tns:senderID> <tns:label>Håbo kommun</tns:label> <tns:attention> <tns:person> <tns:personId> <tns:root>1.2.752.29.6.2.1</tns:root> <tns:extension>SE2321000016-person</tns:extension> </tns:personId> <tns:label>Karin Svensson</tns:label> </tns:person> <tns:subOrganization> <tns:organizationId> <tns:root>urn:riv:infrastructure:messaging:functionalAddress</tns:root> <tns:extension>SE2321000016-SubOrgUnit-id</tns:extension> </tns:organizationId> <tns:label>Socialtjänsten Håbo kommun</tns:label> </tns:subOrganization> </tns:attention> </tns:sender> </tns:messageHeader> <tns:messageBody> <tns:documents> <tns:documentID>SDK meddelande</tns:documentID> <tns:documentName>Rubrik: Kallelse till SIP möte</tns:documentName> <tns:index>1</tns:index> <tns:ContentText> <tns:characterSequence>Textmeddelande. Vi bör diskutera hur formatering skall ske. T.ex. markdown eller html.</tns:characterSequence> </tns:ContentText> </tns:documents> </tns:messageBody> </tns:Message> <messagePayload> |
3.2 MessagePayloadType
MessagePayloadType utgör meddelandets container.
3.2.1 MessageType
MessageType utgör meddelandet. Typen innehåller metadata samt meddelande och dess bilagor.
Attribut | typ | Beskrivning | Kardinalitet |
---|---|---|---|
../message (MessageType) | MessageType | ||
messageHeader | MessageHeaderType | Bärare av metadata | 1..1 |
messageBody | MessageBodyType | Bärare av innehåll (text, bilaga) | 1..1 |
3.2.2 MessageHeaderType
Används för meddelande-id och adresseringsinformation
...
MessageType
MessageHeaderType 1..1
Exempel:
Kodblock | language | xml
---|
<tns:messageHeader> <tns:creationDateTime>2019-08-15T17:52:58.1Z</tns:creationDateTime> <tns:messageId>ff325210-0690-42fe-b86f-95ecab821223</tns:messageId> <tns:conversationId>a8480ada-6a1f-44a3-a960-9acaf4efcdcd</tns:conversationId> <tns:refToMessageId>ff325210-0690-42fe-b86f-95ecab821223</tns:refToMessageId> <tns:label>Rubrik: Kallelse till SIP möte</tns:label> <tns:confidentiality>false</tns:confidentiality> <tns:generatingSystem> <tns:root>kodverk-id</tns:root> <tns:extension>system-id-123456789</tns:extension> </tns:generatingSystem> <tns:recipient> .. </tns:recipient> <tns:sender> .. </tns:sender> </tns:messageHeader> |
Attribut | Typ | Beskrivning | Kardina-litet | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
../messageHeader (MessageHeaderType) | |||||||||||||
creationDateTime | dateTime | Tidsstämpel för när meddelandet skapades. Tidszon UTC skall användas. T.ex. 2018-09-12T15:06:00Z
| 1..1 | ||||||||||
messageId | String | Unik identifierare (UUID) av meddelande.
Ska följa RFC4122. Se |
| 1..1 | ||||||||||||
conversationId | String | Skapas av sändande system. Unik identifierare (UUID). Notera att även AS4 eb:CollaborationInfo.ConversationId SKA sättas till samma värde som ConversationId. “ConversationId” används för att koppla meddelanden i en konversation. Ett “ConversationId“ kan återanvändas i meddelandeutbyte mellan olika mottagare. T.ex. om sändaren vill skicka samma meddelande till flera mottagare. Vid ny konversation/nytt meddelande:
Besvara meddelade:
Komplettera meddelande
Meddelandeklient(MK) skall hantera värdet. | 1..1 | ||||||||||
refToMessageId | String | Används inte för meddelanden som inte är svar på annat meddelande. RefToMessageId sätts av sändande system när ett meddelande besvaras. RefToMessageId ska sättas till messageId för meddelandet som besvaras/kompletteras. Ger stöd för att se ordningsföljd i konversationstrådar, samt att koppla samman meddelandekvittenser med meddelandet.
| 0..1 | ||||||||||
label | String | Meddelandets rubrik. Max 256 tecken.
| 1..1 | ||||||||||
confidentiality | Boolean | Kommunicerar sändande organisations sekretessbedömning. Syftet med markeringen är att upplysa mottagande organisation om att meddelandet innehåller sekretessbelagd information och/eller känsliga personuppgifter. Meddelandeklient(MK) skall hantera och synliggöra fältet.
| 1..1 | ||||||||||
generatingSystem | IIType | Identifierare för systemet som skapade/genererade meddelandet. Id kan användas för felsökning/support. Regelverk IIType:
| 0..1 | ||||||||||
recipient | recipientType | Bärare av metadata för mottagande organisation | 1..1 | ||||||||||
sender | senderType | Bärare av metadata för sändande organisation | 1..1 |
3.2.2.1 RecipientType
Innehåller innehåller information om mottagande organisation.
...
MessageType
MessageHeaderType 1..
RecipientType 1..1
Exempel:
Kodblock | language | xml
---|
<tns:recipient> <tns:recipientId> <tns:root>iso6523-actorid-upis</tns:root> <tns:extension>0203:arbetsformedlingen.se</tns:extension> </tns:recipientId> <tns:label>Arbetsförmedlingen</tns:label> <tns:attention> .. </tns:attention> </tns:recipient> |
Attribut | Typ | Beskrivning | Kardina-litet |
---|---|---|---|
../recipient (RecipientType) | |||
recipientId | IIType | Mottagande organisation (organisations-id). Tillämpas enligt specifikation.
Regelverk IIType:
|
| 1..1 | ||||||||||
label | String | Tillämpas enligt specifikation. Organisationens namn. Max 256 tecken.
| 0..1 | ||||||||
attention | attentionDataType | Bärare av metadata för funktionsadress och refererad person. Se avsnitt "3.3.2.3 AttentionDataType" för detaljerad information. | 1..1 |
3.2.2.2 SenderType
Innehåller information om sändande organisation.
...
MessageType
MessageHeaderType 1..1
SenderType 1..1
Exempel:
Kodblock | |
---|---|
xml | <tns:sender> <tns:senderId> <tns:root>iso6523-actorid-upis</tns:root> <tns:extension>0203:habo.se</tns:extension> </tns:senderId> <tns:label>Håbo kommun</tns:label> <tns:attention> .. </tns:attention> </tns:sender> |
Attribut | Typ | Beskrivning | Kardi-nalitet |
---|---|---|---|
../sender (SenderType) | |||
senderId | IIType | Sändande organisation. Tillämpas enligt specifikation.
Regelverk IIType:
|
Validering:
| 1..1 | |||||||||||||||
label | String | Tillämpas enligt specifikation. Max 256 tecken
| 0..1 | |||||||||||||
attention | attentionDataType | Bärare av metadata för funktionsadress och refererad person. Se avsnitt "3.3.2.3 AttentionDataType" för detaljerad information. | 1..1 |
3.2.2.3 AttentionDataType
Används för att adressera funktion/enhet och referera person (Sändare/mottagare).
...
MessageType
MessageHeaderType 1..1
SenderType/RecipientType 1..1
AttentionType 0..1
Exempel:
Kodblock | language | xml
---|
<tns:attention> <tns:person> <tns:personId> <tns:root>1.2.752.29.6.2.1</tns:root> <tns:extension>SE2321000016-person</tns:extension> </tns:personId> <tns:label>Karin Svensson</tns:label> </tns:person> <tns:subOrganization> <tns:OrganizationId> <tns:root>urn:riv:infrastructure:messaging:functionalAddress</tns:root> <tns:extension>SE2321000016-SubOrgUnit-id</tns:extension> </tns:OrganizationId> <tns:label>Socialtjänsten Håbo kommun</tns:label> </tns:subOrganization> <tns:reference> <tns:referenceId> <tns:root>37.3.818.dummy</tns:root> <tns:extension>02ae6023-658c-43e7-bb5c-4d79ecddf20e</tns:extension> </tns:referenceId> <tns:label>Recipient Or Sender reference-id</tns:label> </tns:reference> </tns:attention> |
Attribut | Typ | Beskrivning | Kardi-nalitet | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
../attention (AttentionDataType) | ||||||||||||||||||
../attention/person/PersonId (AttentionPersonType) | AttentionPersonType | identifierare för refererad person (sender eller recipient). Attributet utelämnas om det saknas en unik identifierare. Regelverk IIType:
Övrigt
| 0..* | |||||||||||||||
../attention/person/label | String | Refererad personen fullständiga namn (fullname). Max 256 tecken T.ex. Karin Svensson
| 0..1 | |||||||||||||||
../attention/subOrganization (SubOrganizationType) | SubOrganizationType | Funktion/Enhet | 1..1 | |||||||||||||||
../attention/subOrganization/organizationId | IIType | Id för att identifiera funktion/enheter.
Regelverk IIType:
| 1..1 | |||||||||||||||
../attention/subOrganization/label | String | Funktion/enhetens namn. Max 256 tecken T.ex. Socialtjänsten i Håbo
Om ett värde skickas skall Meddelandeklient(MK) hantera värdet.
| 0..1 | |||||||||||||||
../attention/reference (ReferenceType) | 0..* | |||||||||||||||||
../attention/reference/referenceId | IIType | Referens-id. T.ex. ärende-id eller diarienummer eller personnummer. Referens-id underlättar för sändare och mottagare att koppla meddelandet till lokala ärenden/handlingar eller en specifik invånare/patient. Max 256 tecken. Regelverk IIType:
Om referens-id används för Sender
Om referens-id används för recipient
Om ett värde skickas skall Meddelandeklient(MK) hantera värdet. | 1..1 | |||||||||||||||
../attention/reference/label | String | Namn/etikett på internt referens-id. Om ett värde skickas skall Meddelandeklient(MK) hantera värdet. | 0..1 |
3.2.3 MessageBodyType
Innehåller nyttolasten i form av meddelandetext och bilagor.
...
MessageType
MessageBodyType 1..1
Exempel:
Kodblock | language | xml
---|
<tns:messageBody> <tns:documents> .. </tns:documents> </tns:messageBody> |
Attribut | Typ | Beskrivning | Kardi-nalitet |
---|---|---|---|
../messageBody (MessageBodyType) | |||
./Documents | DigitalDocumentType | Bärare av textmeddelande och bilaga. | 1..* |
3.2.3.1 DigitalDocumentType
Innehåller en eller flera dokument (fritext eller bilaga).
...
MessageType
MessageBodyType 1..1
DigitalDocumentType 1..*
Exempel:
Kodblock | |
---|---|
xml | <tns:documents>
<tns:documentID>SDK meddelande</tns:documentID>
<tns:documentName>Rubrik: Kallelse till SIP möte</tns:documentName>
<tns:index>1</tns:index>
<tns:ContentFiles>
..
<tns:ContentFiles>
<tns:ContentText>
..
</tns:ContentText>
</tns:documents>
|
Attribut | Typ | Beskrivning | Kardi-nalitet |
---|---|---|---|
../documents (DigitalDocumentType) |
Ett meddelande (documents) SKA innehålla minst ett textmeddelande (contentext) och eller en bifogad fil(contentFiles). | ||
documentID | String | Identifierare av dokument. Skapas av sändaren. |
1..1 | ||
documentName | String | Dokumentets namn. Om ett värde skickas skall det |
hanteras i klient. | 0..1 | ||
Index | String | Sorteringsordning. Om flera documents(DigitalDocumentType) skickas skall sorteringsordning sättas. Detta för att underlätta informationsutbyte då presentationsordning. Siffror skall användas. 1 representerar den första. | 0..1 |
../contentFiles | contentAsBase64Type | Bärare av filer | 0..* |
../contentText | contentAsTextType | Bärare av textmeddelande | 0..* |
3.2.3.2 ContentAsTextType
Fritextmeddelande.
Struktur
MessageType
MessageBodyType 1..1
DigitalDocumentType 1..*
contentAsTextType 0..*
Exempel:
Kodblock | ||
---|---|---|
| ||
<tns:ContentText>
<tns:characterSequence>Textmeddelande. Formateras med markdown.</tns:characterSequence>
</tns:ContentText>
|
Attribut | Typ | Beskrivning | Kardi-nalitet | ||
---|---|---|---|---|---|
../contentText (ContentAsText) | |||||
characterSequence | 1..1 | Fritext (UTF-8). Text kan formateras med följande MarkDown koder enligt RFC 7763. Headers:
Grafiskt gränssnitt i meddelandeklient (verksamhetssystem) tjänst skall rendera ovanstående MarkDown-koder. Om ett värde skickas skall Meddelandeklient(MK) hantera värdet. Meddelandet inklusive bifogade filer får ej överstiga 30 MB. | 1..1 |
3.2.3.3 ContentAsBase64
Base64-kodad bilaga.
Struktur
MessageType
MessageBodyType 1..1
DigitalDocumentType 0..*
contentAsBase64Type 0..*
Exempel:
Kodblock | ||
---|---|---|
| ||
<tns:ContentFiles>
<tns:fileName>testpdf.pdf</tns:fileName>
<tns:contentType>application/pdf</tns:contentType>
<tns:content>AkbCRUEBoI5wj9hBHCNFGBqE90IoYQecRcYimxj....
</tns:ContentFiles>
|
Attribut | Typ | Beskrivning | Kardi-nalitet |
---|---|---|---|
../ContentFiles (ContentAsBase64Type) | Bifogas flera element skall dessa hanteras enligt valfri sortering. | ||
fileName | String | Bilagans filnamn. Filnamnet bör visas i meddelandetjänsten. | 1..1 |
contentType | String | Typ av bilaga som överförs/bifogas. MIME-typ för bifogad fil skall anges. |
Endast PDF får användas dvs: application/pdf
|
Endast arkivbeständig PDF får överföras (PDF version 1.4 eller senare)
Arkivbeständigt format skall användas, Enligt riksarkivet:PDF-A1PDF-A2
Filtyper som inte stöds av mottagaren skall kvitteras(REJECTED) enligt följande.
|
| 1..1 | |
content | String | Base64-kodad bilaga (UTF-8). Den binära informationen skall kodas med base64 enligt RFC 4648. |
Meddelandet inklusive bifogade filer får ej överstiga 30 |
MB.
| 1..1 |
4 Innehållsvalidering
Innehållsvalidering finns för att i så stor mån som möjligt säkerställa problemfri kommunikation mellan samtliga parter i SDK federationen. Schema och Schematron bilagorna till detta dokument realiserar dom gemensamma valideringsregler som finns. Valideringsreglerna är framtagna utifrån dom regler som är specificerat i meddelandemodeller.
...
SDK-Meddelande skall valideras med bifogade schema och schematron filer.
SDK-Meddelande skall valideras på utgående försändelse.
SDK-Meddelande skall valideras på inkommande meddelanden.
Avsändaren SKA valideras
4.1 Schematronregler
Schematron är ett regelbaserat valideringsspråk för att göra påståenden om förekomsten eller frånvaron av mönster i XML-träd. Schematron reglerna är en utökning av schemat och validerar meddelandeinnehållet utifrån innehållsspecifikation.
4.3 Felhantering och kvittens
Vid inkommande meddelande skall meddelandetjänst hantera valideringsfel genom att i retur skicka ett kvittensmeddelande enligt DIGGs specifikation DIGG eDelivery – Meddelandespecifikation: Meddelandekvittens (Se R7).
4.4 Exempel på valideringskoder - Meddelandetjänst (Validering av mottaget meddelande)
Tabellen avser exempel på händelser som primärt behöver hanteras av meddelandetjänst (meddelandelagret).
Aktör skapar kvittensmeddelandet och felhanteringsmeddelandet enligt DIGG eDelivery – Meddelandespecifikation: Meddelandekvittens (R7).
1
2
3
4
5
6
7
8
9
10
11
12
Händelse (exempel) | Kvittenskod | Orsakskod | Detaljkod | Kommentar | |
---|---|---|---|---|---|
1 | Meddelandet mottaget och validerat utan avvikelser | ACCEPTED | - | - | Meddelandet mottaget, kvitterat och validerat utan avvikelser. |
2 | Meddelandekuvertets struktur och i förekommande fall innehåll kodverksregler etc. | REJECTED | SV | structure | Meddelandet är strukturellt (xsd) felaktigt eller är korrupt.
|
3 | Kontroll mot skadlig kod i nyttolast. | REJECTED | BV | forbidden | Felkod REJECTED skall genereras av mottagaren i de fall det är möjligt. En incident behöver skapas om skadlig kod upptäcks. Skalskydd i form av antivirussystem kan förhindra filhantering genom t.ex. att sätta meddelande i "karantän". |
4 | Storleksvalidering (storlek) | REJECTED | BV | too-long | Storleksöverträdelse över fastställd storlek (f.n. > 30mb för hela meddelandet) skall generera ett stoppande fel (REJECTED) |
5 | Logisk schema validering (schematron) | REJECTED | BV | invariant | Logiska regler eller kodverk följs ej (schematron)
|
6 | MessageId är ej unikt | REJECTED | BV | duplicate multiple-matches | |
7 | refToMessageId finns ej | ACCEPTED | - | - | Meddelandet kvitteras med ACCEPTED. |
8 | Filtyp (SDK Innehållsspecifikation - contentAsBase64) | REJECTED | BV | Not-supported | Meddelandet skall ej kvitteras, felkod REJECTED. |
Filtyp stödjs ej. | |||||
9 | Funktionsadress finns ej | REJECTED | BV | Not-found | Funktionsadress finns ej eller är felaktigt |
10 |
Meddelande kan ej levereras
REJECTED
BV
exception
Meddelandet kan ej levereras till mottagare av funktionsadress.
referens till meddelande (refToMessageId) som är markerat som REJECTED. | REJECTED | BV | not-supported | Meddelandet kan ej levereras och kvitteras pga att meddelandet är marketat som felaktigt (t.ex. pga sändarens time-out). |
11 | Felaktig avsändare - Sändarens XHE signatur | REJECTED | SIG | security | Avsändarinformation (organisations-id) är felaktig eller matchar ej XHE-signatur. |
12 | Felaktig avsändare - Angiven avsändare felaktig | REJECTED | BV | security | Avsändarinformation är felaktig eller matchar ej.
|