EMSWe RIM Sender Integration – Access Point Setup Guide

Who this is for. Declarants and Data Service Providers who want to submit EMSWe formalities to the Finnish Maritime National Single Window (MNSW) through the Reporting Interface Module (RIM) over eDelivery AS4.

This page gives the Finland-specific values you need to get started. The authoritative EU-level specification is EMSA's RIM v3.3.0 Integration Guidance. Finland's detailed requirements are in the Finland EMSWe Domibus Sender Integration Guide (PDF).

1. Onboarding at a glance

Connectivity is established step by step. You first connect to our DEV RIM. Once the AS4 message exchange works there, end-to-end testing continues in Staging (STG), and only after that in production.

flowchart LR
    A["1. Exchange details
Party ID, endpoint, DNS,
IP addresses, AS4 certificates"] --> B["2. URAM registration
MNSW registers your
organisation"]
    B --> C["3. DEV connectivity
AS4 request, receipt
and response work"]
    C --> D["4. STG end-to-end
Real formalities,
business validation"]
    D --> E["5. Production
Own eIDAS certificate,
PRD values"]
    

Contact the MNSW team to start onboarding. The full list of what we need is in section 11.

2. Architecture and responsibilities

EMSWe RIM messaging follows the eDelivery four-corner model. You own and operate corners C1 and C2. MNSW operates C3 and C4.

flowchart LR
    subgraph Sender["Sender side (your responsibility)"]
        C1["C1: Sender backend
creates and signs
ASiC-E container"]
        C2["C2: Your AS4 Access Point
e.g. Domibus + WS plugin"]
    end
    subgraph MNSW["Finnish MNSW"]
        C3["C3: MNSW RIM
Domibus 5.2.1"]
        C4["C4: MNSW backend"]
    end
    C1 -->|ASiC-E + metadata| C2
    C2 -->|"AS4 UserMessage
emswe-formality-request"| C3
    C3 -->|"AS4 UserMessage
emswe-formality-response"| C2
    C3 --> C4
    

A Data Service Provider (DSP) may operate C2 on behalf of one or more declarants. This is a commercial arrangement between the sender and the DSP. MNSW does not provide a shared Access Point.

3. Test environments: DEV first, then STG

Start by establishing AS4 connectivity with the MNSW DEV RIM. Use the party definition below in your Access Point configuration (in Domibus, the parties section of the PMode).

<party name="mnsw-dev.mnsw.fi"
       endpoint="https://rim.mnsw-dev.mnsw.fi/integrations/domibus/services/msh">
    <identifier partyId="mnsw-dev.mnsw.fi" partyIdType="rimParty"/>
</party>

STG and production party details are delivered once DEV connectivity works. See also the Finland C3 environment table in the PMode guide.

4. Access and URAM registration

Access to the platform is always granted at the organisation level. Individual user accounts are not used, so you do not need separate access for each developer or contact person.

MNSW registers your organisation in the Finnish URAM sub-domain on your behalf. In testing, the registration uses the shared test eIDAS certificate described in section 5.2. To complete the registration, send us:

• Organisation name
• EORI number
• Address and country
• Contact person(s): name, email and phone number

5. Certificates and security

Three different certificates are involved, and they have different purposes.

5.1 AS4 certificate exchange

1. Add the MNSW DEV public certificate (mnsw-dev.mnsw.fi.cer, delivered by MNSW) to your Access Point truststore. If it was delivered with a .txt extension for email transport, remove the extension first.
2. Send us your public AS4 certificate so that we can add it to our truststore.

Encryption is mandatory. As specified in EMSA's guidance, RSA-based signing and encryption is used, with the security policy eDeliveryAS4Policy_BST_PKIP_RIM and profile rsa. MNSW uses Domibus 5.2.1.

5.2 eIDAS certificate

For testing, EMSA has provided Finland with a test eIDAS certificate that MNSW distributes to its test senders as a keystore (FI1059876543.zip). The keystore alias is FI1059876543; the passphrase is delivered together with the keystore.

EMSA's samples use the Belgian test certificate and EORI BE01234567895. When you use them, replace those with the Finnish test certificate FI1059876543 and your own values.

6. AS4 collaboration parameters

7. Building the AS4 UserMessage

Creating the signed ASiC-E container is the responsibility of the declarant's backend (C1); the sender-side Access Point (C2), whether operated by the declarant or a DSP, creates the AS4 message. EMSA's guidance contains sample messages; chapter 6 has a complete AS4 UserMessage example using the Domibus WS plugin.

7.1 Three levels of metadata

The UserMessage carries metadata on three levels. Keeping them apart avoids the most common configuration errors.

flowchart TB
    subgraph UM["AS4 UserMessage"]
        L1["Level 1: PartyInfo
Access Points C2 → C3
From: your Party ID / To: mnsw-dev.mnsw.fi"]
        L2["Level 2: MessageProperties
Business sender C1 and recipient C4
originalSender = your EORI / finalRecipient = FI"]
        L3["Level 3: PartProperties of cid:message
RIM metadata and URAM authentication
Authorization.* / FormalityInfo.* / MimeType"]
        P["Payload cid:message
Signed ASiC-E container"]
    end
    L1 --- L2 --- L3 --- P
    

7.2 Party and message properties

7.3 Example UserMessage (Domibus WS plugin)

This illustrative example is based on chapter 6 of EMSA's guidance, adapted to the Finnish DEV environment. Values in {curly brackets} are placeholders to be replaced with your own values.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
               xmlns:ns="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/"
               xmlns:eu="http://eu.domibus.wsplugin/">
  <soap:Header>
    <ns:Messaging>
      <ns:UserMessage mpc="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC">
        <ns:MessageInfo>
          <ns:Timestamp>{yyyy-MM-ddTHH:mm:ss.SSSZ}</ns:Timestamp>
          <!-- Must be unique for every message (duplicate detection is enabled) -->
          <ns:MessageId>{UNIQUE_MESSAGE_ID}</ns:MessageId>
        </ns:MessageInfo>

        <!-- Level 1: PartyInfo = access points (C2 -> C3) -->
        <ns:PartyInfo>
          <ns:From>
            <ns:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:unregistered">{SENDER_PARTY_ID}</ns:PartyId>
            <ns:Role>http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator</ns:Role>
          </ns:From>
          <ns:To>
            <ns:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:unregistered">mnsw-dev.mnsw.fi</ns:PartyId>
            <ns:Role>http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder</ns:Role>
          </ns:To>
        </ns:PartyInfo>

        <ns:CollaborationInfo>
          <ns:Service type="rim-process-schema">rim-messaging-service</ns:Service>
          <ns:Action>emswe-formality-request</ns:Action>
          <ns:ConversationId>{CONVERSATION_ID}</ns:ConversationId>
        </ns:CollaborationInfo>

        <!-- Level 2: MessageProperties = business sender (C1) and recipient (C4) -->
        <ns:MessageProperties>
          <ns:Property name="originalSender" type="emswe-sender-eori">{SENDER_EORI}</ns:Property>
          <ns:Property name="finalRecipient" type="emswe-ms-rim">FI</ns:Property>
        </ns:MessageProperties>

        <!-- Level 3: PartProperties = RIM metadata and URAM authentication -->
        <ns:PayloadInfo>
          <ns:PartInfo href="cid:message">
            <ns:PartProperties>
              <ns:Property name="Authorization.Identifier">{IDENTIFIER_REGISTERED_IN_URAM}</ns:Property>
              <ns:Property name="Authorization.SubDomain">FI</ns:Property>
              <ns:Property name="Authorization.Type">{DECL_OR_OTHER}</ns:Property>
              <ns:Property name="FormalityInfo.Formality.TypeUrn">{FORMALITY_TYPE_URN}</ns:Property>
              <ns:Property name="FormalityInfo.Formality.FileName">{FORMALITY_FILE_NAME}.xml</ns:Property>
              <ns:Property name="FormalityInfo.FormalityVersion">{FORMALITY_VERSION}</ns:Property>
              <ns:Property name="FormalityInfo.CorrelationId">{CORRELATION_ID}</ns:Property>
              <ns:Property name="FormalityInfo.CreationDateAndTime">{yyyy-MM-ddTHH:mm:ss.SSSZ}</ns:Property>
              <!-- Only if the container includes attachments -->
              <ns:Property name="FormalityInfo.AttachmentCount">{N}</ns:Property>
              <ns:Property name="FormalityInfo.FormalityBody.Attachment1">{ATTACHMENT_1_FILE_NAME}</ns:Property>
              <ns:Property name="MimeType">application/vnd.etsi.asic-e+zip</ns:Property>
              <ns:Property name="FormalityInfo.MimeType">application/vnd.etsi.asic-e+zip</ns:Property>
            </ns:PartProperties>
          </ns:PartInfo>
        </ns:PayloadInfo>
      </ns:UserMessage>
    </ns:Messaging>
  </soap:Header>
  <soap:Body>
    <eu:submitRequest>
      <!-- Signed ASiC-E container, sent as an MTOM attachment -->
      <payload payloadId="cid:message" contentType="application/vnd.etsi.asic-e+zip">
        <value>cid:{ASIC_E_CONTAINER_FILE_NAME}</value>
      </payload>
    </eu:submitRequest>
  </soap:Body>
</soap:Envelope>

The FormalityInfo.AttachmentCount and FormalityInfo.FormalityBody.Attachment* properties are only included when the ASiC-E container has attachments. Keep MimeType, FormalityInfo.MimeType, and the WS-plugin payload contentType aligned as application/vnd.etsi.asic-e+zip so Domibus resolves the message to the intended PMode leg.

8. Message flow and responses

Both directions use One-Way / Push. MNSW pushes its responses to your AS4 endpoint, so your Access Point must also act as a receiver.

sequenceDiagram
    participant C1 as C1 Sender backend
    participant C2 as C2 Your Access Point
    participant C3 as C3 MNSW RIM
    participant C4 as C4 MNSW backend
    C1->>C2: Signed ASiC-E + metadata
    C2->>C3: AS4 UserMessage (emswe-formality-request)
    C3-->>C2: AS4 Receipt (synchronous, in HTTP response)
    C3->>C4: Validated formality
    C4->>C3: Result
    C3->>C2: AS4 UserMessage (emswe-formality-response), HTTPS push
    C2-->>C3: AS4 Receipt
    C2->>C1: Response delivered to backend
    

9. PMode reference

The excerpt below shows the relevant parts of the MNSW PMode. Your own PMode must use matching values.

<roles>
    <role name="senderRole" value="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator"/>
    <role name="recipientRole" value="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder"/>
</roles>
<partyIdTypes>
    <partyIdType name="rimParty" value="urn:oasis:names:tc:ebcore:partyid-type:unregistered"/>
</partyIdTypes>
<agreement name="agreementEmpty" value="" type=""/>
<service name="rim-service" value="rim-messaging-service" type="rim-process-schema"/>
<action name="b2sw-action" value="emswe-formality-request"/>
<action name="sw2b-action" value="emswe-formality-response"/>
<security name="eDeliveryAS4Policy_BST_PKIP_RIM" profile="rsa"/>
<property name="originalSenderProperty" key="originalSender" datatype="string" required="true"/>
<property name="finalRecipientProperty" key="finalRecipient" datatype="string" required="true"/>

For a complete sender-side PMode with explanations, see the Domibus PMode Configuration Guide.

10. Moving to production and changes

Before production, replace the shared test eIDAS certificate with your organisation's own qualified or advanced eIDAS certificate, and switch to the production party details delivered by MNSW.

Any later change to your Access Point (certificate, endpoint, key or IP addresses) requires advance notification, certificate exchange, a PMode update, testing in STG and a coordinated production activation.

11. What to send us

• Party ID and AS4 endpoint URL
• Public AS4 certificate
• DNS name of your Access Point
• Source IP addresses of your Access Point
• Organisation details for URAM registration (section 4)

12. References

• EMSA – RIM v3.3.0 Integration Guidance (chapter 6: AS4 UserMessage example with the Domibus WS plugin)
• Finland EMSWe Domibus Sender Integration Guide (PDF)
• Domibus PMode Configuration Guide
• European Commission – Domibus
• OASIS AS4 Profile of ebMS 3.0 v1.0
• OASIS ebMS 3.0 Core Specification