Domibus PMode Configuration for EMSWe RIM / AS4 Messaging

Sender-side (C2) example and configuration checklist

Implementation example
This page explains the main parts of a sender-side Domibus pmode.xml used for EMSWe RIM / AS4 messaging. The example is a template, not a production-ready bilateral agreement. Replace all sender-, receiver-, endpoint-, certificate-, retention-, and environment-specific values with the values agreed during onboarding.

Domibus is used here as an example. Any eDelivery AS4 conformant Access Point can be used; the MNSW RIM (C3) runs Domibus 5.2.1. The authoritative EU-level specification is EMSA's RIM v3.3.0 Integration Guidance.

1. Scope and message directions

The PMode configures the sender's Domibus Access Point, the C2 corner in the four-corner model. It defines who can communicate, which service and actions are accepted, which security and reliability policies are used, and how payloads are represented.

Request

C2 → C3

emswe-formality-request

The sender Access Point transmits an EMSWe formality to the Member State RIM.

Response

C3 → C2

emswe-formality-response

The Member State RIM sends the corresponding technical or business response back to the sender Access Point.

Both directions use the One-Way / Push pattern. MNSW pushes its responses to your AS4 endpoint, so your Access Point must be reachable from the MNSW environment over HTTPS. AS4 receipts are returned synchronously in the HTTP response.

sequenceDiagram
    participant C2 as C2 Your Access Point
    participant C3 as C3 MNSW RIM
    C2->>C3: UserMessage, action emswe-formality-request (leg rim-leg1)
    C3-->>C2: AS4 Receipt in the HTTP response
    C3->>C2: UserMessage, action emswe-formality-response (leg rim-leg2), HTTPS push
    C2-->>C3: AS4 Receipt in the HTTP response

Do not copy environment values blindly. Party identifiers, endpoints, certificates and security policy aliases must match the bilateral configuration agreed with the receiving Member State.

2. Before importing the PMode

Prepare and verify the following information before creating the final file:

Sender Access Point party identifier and public AS4 endpoint.
Member State RIM party identifier and AS4 endpoint for the target environment.
Party identifier type agreed for the connection.
Sender private key and certificate in the Domibus keystore.
Receiver certificate and issuing CA chain in the Domibus truststore. MNSW delivers its public AS4 certificate for each environment (for DEV: mnsw-dev.mnsw.fi.cer).
Your public AS4 certificate sent to MNSW, so that it can be added to the MNSW truststore.
DNS name of your Access Point and the source IP addresses it sends from, sent to MNSW for firewall openings on both sides.
Domibus security policy alias that implements the agreed AS4 signing and encryption profile.
Message retention requirements suitable for the environment and operational support model.

3. Finland (C3) environment configuration

The Finnish Maritime National Single Window (MNSW) RIM Access Point uses a different C3 party name, party identifier and endpoint in each environment. Configure the C3 party using exactly one row from the table below.

Start with DEV. Once the AS4 message exchange works in DEV, end-to-end testing continues in STG. MNSW confirms the STG and PRD connection details when you move to those environments.

Environment	Party name and Party ID	AS4 MSH endpoint
Development (DEV)	`mnsw-dev.mnsw.fi`	`https://rim.mnsw-dev.mnsw.fi/integrations/domibus/services/msh`
Staging (STG)	`mnsw-stg.mnsw.fi`	`https://rim.mnsw-stg.mnsw.fi/domibus/services/msh`
Production (PRD)	`mnsw.mnsw.fi`	`https://rim.mnsw.mnsw.fi/domibus/services/msh`

Use matching values. The party name, nested partyId and endpoint must all belong to the same environment. Do not mix DEV, STG and PRD values in one party definition.

Development example

<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>

Staging example

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

Production example

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

4. Configuration map

Section	Purpose	RIM-specific consideration
`roles`	Defines ebMS initiator and responder roles.	Use the standard ebMS 3.0 initiator and responder URI values.
`parties`	Defines C2 and C3 party identifiers and endpoints.	Both parties are listed because the same process supports request and response directions.
`meps`	Defines the message exchange pattern and binding.	The example uses one-way push legs for each direction.
`properties`	Defines required ebMS message properties.	`originalSender` and `finalRecipient` are required by the eDelivery-style property set.
`payloadProfiles`	Constrains payload parts, MIME types and total size.	Main payload `cid:message` is mandatory and uses MIME type `application/vnd.etsi.asic-e+zip` (ASiC-E container), attachment `cid:attachment` is optional. Maximum size is 40,894,464 bytes (approx. 39 MB). Payload compression is not used.
`securities`	Selects the Domibus WS-Security policy.	The alias must exist in the installed Domibus configuration and match the bilateral certificate setup.
`services`	Defines the EMSWe RIM messaging service.	Use `rim-messaging-service` and the agreed service type.
`actions`	Defines request and response message actions.	Request: `emswe-formality-request`; response: `emswe-formality-response`.
`as4`	Defines reception awareness, duplicate detection and reliability.	Duplicate detection is enabled at MNSW, so every message needs a unique `MessageId`. Receipts are synchronous (`replyPattern="response"`). Non-repudiation is not used.
`legConfigurations`	Binds service, action, security, reliability, MPC and error handling.	One leg is defined for each direction.
`process`	Combines parties, roles, MEP, binding and legs.	C2 and C3 appear as both possible initiators and responders so that both directional legs can be resolved.
`mpcs`	Controls the message partition channel and retention.	Retention values are operational settings and must be reviewed before production use.

The diagram shows how the PMode sections reference each other. The process ties the parties to two legs, and each leg binds one action to the shared service, security policy and reliability settings.

flowchart LR
    PR["process
rim-process"] --> PA["parties
senderap, mnsw-dev.mnsw.fi"]
    PR --> RO["roles
senderRole, recipientRole"]
    PR --> ME["meps
oneway + push"]
    PR --> AG["agreements
agreementEmpty"]
    PR --> L1["leg rim-leg1
C2 to C3"]
    PR --> L2["leg rim-leg2
C3 to C2"]
    L1 --> A1["action b2sw-action
emswe-formality-request"]
    L2 --> A2["action sw2b-action
emswe-formality-response"]
    L1 --> SV["service rim-service
rim-messaging-service"]
    L2 --> SV
    L1 --> SE["security
eDeliveryAS4Policy_BST_PKIP_RIM"]
    L2 --> SE
    L1 --> AS["as4
receptionAwareness, noReliability"]
    L2 --> AS
    L1 --> MP["mpc defaultMpc"]
    L2 --> MP

5. Complete sender-side (C2) example

The following example uses senderap as the sender C2 party and the Finnish MNSW development RIM as the receiver C3 party. Replace the sender values with the values assigned to your Access Point. For STG or PRD, replace all three C3 environment values consistently using the table above.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:configuration xmlns:ns2="http://domibus.eu/configuration" party="senderap">
    <businessProcesses>
        <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>
        <parties>
            <partyIdTypes>
                <partyIdType name="rimParty" value="urn:oasis:names:tc:ebcore:partyid-type:unregistered"/>
            </partyIdTypes>

            <party name="senderap" endpoint="https://localhost:8444/domibus/services/msh">
                <identifier partyId="senderap" partyIdType="rimParty"/>
            </party>
            <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>
        </parties>
        <meps>
            <mep name="oneway" value="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay" legs="0"/>
            <binding name="push" value="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/push"/>
        </meps>
        <properties>
            <property name="originalSenderProperty" key="originalSender" datatype="string" required="true"/>
            <property name="finalRecipientProperty" key="finalRecipient" datatype="string" required="true"/>
            <propertySet name="eDeliveryPropertySet">
                <propertyRef property="finalRecipientProperty"/>
                <propertyRef property="originalSenderProperty"/>
            </propertySet>
        </properties>
        <payloadProfiles>
            <payload name="businessContentPayload" cid="cid:message" mimeType="application/vnd.etsi.asic-e+zip" maxSize="0" required="true" inBody="false"/>
            <payload name="businessContentAttachment" cid="cid:attachment" mimeType="application/octet-stream" maxSize="0" required="false" inBody="false"/>
            <payloadProfile name="rimProfile" maxSize="40894464">
                <attachment name="businessContentPayload"/>
                <attachment name="businessContentAttachment"/>
            </payloadProfile>
        </payloadProfiles>
        <securities>
            <security name="eDeliveryAS4Policy_BST_PKIP_RIM" profile="rsa"/>
        </securities>
        <errorHandlings>
            <errorHandling name="defaultErrorHandling" default="true" errorAsResponse="true" businessErrorNotifyProducer="true" businessErrorNotifyConsumer="true" deliveryFailureNotifyProducer="true"/>
        </errorHandlings>
        <agreements>
            <agreement name="agreementEmpty" value="" type=""/>
        </agreements>
        <services>
            <service name="rim-service" value="rim-messaging-service" type="rim-process-schema"/>
        </services>
        <actions>
            <action name="b2sw-action" value="emswe-formality-request"/>
            <action name="sw2b-action" value="emswe-formality-response"/>
        </actions>
        <as4>
            <receptionAwareness name="receptionAwareness" retry="5;5;CONSTANT" duplicateDetection="true"/>
            <reliability name="noReliability" replyPattern="response" nonRepudiation="false"/>
        </as4>
        <legConfigurations>
            <legConfiguration name="rim-leg1" reliability="noReliability" security="eDeliveryAS4Policy_BST_PKIP_RIM" receptionAwareness="receptionAwareness" service="rim-service" action="b2sw-action" defaultMpc="defaultMpc" propertySet="eDeliveryPropertySet" payloadProfile="rimProfile" errorHandling="defaultErrorHandling" compressPayloads="false"/>
            <legConfiguration name="rim-leg2" reliability="noReliability" security="eDeliveryAS4Policy_BST_PKIP_RIM" receptionAwareness="receptionAwareness" service="rim-service" action="sw2b-action" defaultMpc="defaultMpc" propertySet="eDeliveryPropertySet" payloadProfile="rimProfile" errorHandling="defaultErrorHandling" compressPayloads="false"/>
        </legConfigurations>
        <process name="rim-process" initiatorRole="senderRole" responderRole="recipientRole" agreement="agreementEmpty" mep="oneway" binding="push">
            <initiatorParties>
                <initiatorParty name="senderap"/>
                <initiatorParty name="mnsw-dev.mnsw.fi"/>
            </initiatorParties>
            <responderParties>
                <responderParty name="senderap"/>
                <responderParty name="mnsw-dev.mnsw.fi"/>
            </responderParties>
            <legs>
                <leg name="rim-leg1"/>
                <leg name="rim-leg2"/>
            </legs>
        </process>
    </businessProcesses>
    <mpcs>
        <mpc name="defaultMpc" retention_downloaded="10" retention_undownloaded="240" retention_sent_success="10" retention_sent_failure="10" delete_message_metadata="false" max_batch_delete="-1" default="true" enabled="true" qualifiedName="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC"/>
    </mpcs>
</ns2:configuration>

6. Values that must be replaced

Example value	Replace with	Why it matters
`party="senderap"`	The local Domibus party name.	Identifies which configured party represents this Domibus instance.
`senderap`	The agreed C2 party ID and matching internal party name.	Must match the identifier used in outbound and inbound AS4 headers.
`mnsw-dev.mnsw.fi`	The Finnish C3 party name and Party ID for the selected environment.	Use the DEV, STG or PRD value consistently in the party definition and process party references.
`https://localhost:8444/...`	The externally reachable sender AS4 MSH endpoint.	The receiver must be able to deliver response messages to C2.
`https://rim.mnsw-dev.mnsw.fi/...`	The Finnish C3 endpoint for DEV, STG or PRD.	Each environment has a distinct hostname and trust setup.
`rimParty` / unregistered URI	The bilateral party ID type, when different.	The type forms part of the ebMS party identity.
`eDeliveryAS4Policy_BST_PKIP_RIM`	The installed Domibus security policy alias.	The alias must resolve to a policy supported by both Access Points.
`40894464`	The approved maximum message size.	Oversized messages are rejected before business processing.
Retention values	Values approved for operations, audit and storage capacity.	Very short retention can hinder incident investigation; excessive retention consumes storage.

Values normally kept unchanged

Standard ebMS role, one-way MEP, push binding and default MPC URIs.
Service value rim-messaging-service, unless a newer bilateral specification explicitly replaces it.
Actions emswe-formality-request and emswe-formality-response, unless a newer RIM profile explicitly replaces them.
Required message property keys originalSender and finalRecipient.

7. Import and test

Back up the current Domibus PMode and certificate stores.
Validate that every referenced party, leg, service, action, MPC and security alias is internally consistent.
Import the XML through the supported Domibus administration mechanism for the installed version.
Verify that the PMode becomes active and inspect the Domibus log for schema or reference errors.
Send a controlled request to the DEV environment, using a unique MessageId. Continue with end-to-end tests in STG once DEV works.
Confirm the synchronous AS4 receipt and that the emswe-formality-response pushed by MNSW reaches your endpoint.
Test negative cases, including an unknown party, invalid certificate, invalid action and a duplicate MessageId (duplicate detection is enabled at MNSW).
Promote the reviewed environment-specific configuration to production using change control.

Expected result: Domibus resolves the outbound request to rim-leg1, signs and encrypts it with the configured policy, sends it to the C3 endpoint, and resolves the inbound emswe-formality-response to rim-leg2.

8. Production readiness checklist

C2 and C3 party IDs and party ID types match the bilateral agreement.
STG and PRD endpoints are not mixed.
The sender MSH endpoint is reachable from the receiver network.
The private key alias, certificate and security policy are aligned.
The complete receiver CA chain is trusted.
The receiver trusts the sender certificate and CA chain.
Certificate validity dates, fingerprints and planned renewal dates are recorded.
Request and response actions have been tested end to end.
originalSender and finalRecipient are populated by the C1-to-C2 integration.
Payload MIME types and maximum size match the submitted ASiC-E packaging contract (cid:message uses application/vnd.etsi.asic-e+zip).
Duplicate detection, retry behaviour and error notifications have been exercised.
Retention and backup settings support incident investigation and audit needs.
Monitoring covers failed messages, certificate expiry, queue growth and endpoint availability.
The final PMode is version-controlled without private keys, passwords or other secrets.

1. Scope and message directions

C2 → C3

C3 → C2

2. Before importing the PMode

3. Finland (C3) environment configuration

Development example

Staging example

Production example

4. Configuration map

5. Complete sender-side (C2) example

6. Values that must be replaced

Values normally kept unchanged

7. Import and test

8. Production readiness checklist

Related documentation