...
...
...
...
Innehållsförteckning
Innehållsförteckning | ||
---|---|---|
|
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.
...
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.
...
Div | ||
---|---|---|
| ||
2.1. Övergripande flöden
...
Ett meddelande skapas i meddelandetjänsten (t.ex. ärendehanteringssystem eller meddelandeapplikation).
...
Div | ||
---|---|---|
| ||
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):
|
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 | ||
---|---|---|
| ||
3.2 Meddelandestruktur - MessageType
Samtliga fält skall hanteras och valideras av komponenterna Meddelandetjänst (MT) och Meddelandeklient/Verksamhetssystem (MK).
...
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
...
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 https://tools.ietf.org/html/rfc4122
| 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. 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.
...
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.
...
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).
...
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.
...
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).
...
Attribut | Typ | Beskrivning | Kardi-nalitet |
---|---|---|---|
../documents (DigitalDocumentType) | |||
documentID | String | Identifierare av dokument. Skapas av sändaren. | 0..1 |
documentName | String | Dokumentets namn. Om ett värde skickas skall det valideras och 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
...
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. | 1..1 |
3.2.3.3 ContentAsBase64
Base64-kodad bilaga.
Struktur
...
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.
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. 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).
...