Message Routing To Namespace

Overview

This document outlines how the EWX Integration Platform determines the correct routing for inbound messages using the concept of ewx_namespace. This routing mechanism ensures that messages are processed, audited, and forwarded according to the specific configurations of each connected organization.

Key Concepts

Term	Description
ewx_namespace	A unique identifier for an organization, e.g., enrx_org_004.
Receiver EAN	The party identifier (EAN) used towards external systems (e.g., MMC), configured on the connection entity (connections/{connection_id}.json).
Inbound Scheduler	A scheduled job that polls external endpoints for messages.
Integration Platform	The service that manages SOAP communication, validation, and routing.

Routing Mechanism

1. Namespace Configuration

The platform is configured with a predefined list of namespaces:

ewx_namespaces = ["enrx_org_004", "enrx_org_006", ...]

Namespaces are polled according to the schedule entries in schedules/schedule_config.json; each entry groups namespaces on a connection and can carry a per-namespace fallback namespace. The connection entity (connections/{connection_id}.json) carries the receiver EAN and the enabled flag. Each namespace still has a block in the service configuration for:

• Client certificate paths

• Config set and source EAN

2. Message Retrieval (Inbound Flow)

1. The Inbound Scheduler runs periodically (e.g., every minute).
2. It loops through each configured ewx_namespace.
3. For each namespace, the platform:
   1. Resolves the schedule's connection entity (receiver EAN, enabled flag) and loads certs, etc.
   2. Builds a SOAP <ListRequest> using those credentials.
   3. Send the request to the external SOAP endpoint (e.g., MMC-Hub).
4. The external system returns any messages relevant to the provided credentials.

The namespace is not inferred from the message itself. It is implied from the context of the request.

3. Message Tagging and Publishing

If messages are received:

• They are tagged with the namespace used in the request.
• Published to the Google Pub/Sub topic (integration-service-inbound) with metadata:

{
  "namespace_id": "enrx_org_004",
  "message_type": "MeasurementSeriesNotification",
  "inbound_source": "MMC-HUB"
}

This metadata ensures that downstream components (validators, processors, file forwarders) use the correct configuration for processing.

Example

Scenario

• A MeasurementSeriesNotification message is available in a SOAP-Hub.

• The integration platform is configured with the namespace enrx_org_004 and enrx_org_006.

• The connection used for enrx_org_004 carries receiver EAN 8716867000000 (example value).

Step-by-Step Flow

1. Scheduler triggers

The InboundMessageScheduler runs every minute and begins processing the namespace enrx_org_004.

2. SOAP ListRequest is made

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header/>
    <soapenv:Body>
        <ListRequest xmlns="http://sys.svc.tennet.nl/MMCHub/v1">
            <RequestType>MeasurementSeriesNotification</RequestType>
        </ListRequest>
    </soapenv:Body>
</soapenv:Envelope>

• The request uses:

  • Client certificates belonging to the connection's receiver EAN 8716867000000

3. SOAP-Hub returns a message

SOAP-Hub responds with a list containing a correlation ID for a new message that belongs to this EAN.

4. Integration platform fetches the message

Using the correlation ID, it performs a GetRequest to fetch the full SOAP message.

5. The Message is published to Pub/Sub

The platform publishes the message to integration-service-inbound with metadata:

{
  "namespace_id": "enrx_org_004",
  "message_type": "MeasurementSeriesNotification",
  "fallback_namespace_id": "enrx_org_006",
  "inbound_source": "MMC-HUB"
}

6. Inbound Processor handles the message

• The Inbound Processor picks up the message from Pub/Sub and checks if the datasource belonging to the message exists in enrx_org_004 namespace. It finds it does not exist and routes the message to namespace enrx_org_006.
• The processor validates the XML using the schema defined for MeasurementSeriesNotification.
• The message is parsed, persisted, and optionally forwarded to an external file system or cloud bucket.

7. Acknowledgement is generated and sent

If the message requires an acknowledgment:

• An Ack SOAP message is constructed using the configuration

• It is sent back to the source system (e.g., MMC-Hub).

8. Audit logs are written

Audit records for processing, validation results, and acknowledgment are stored under enrx_org_006.

Result

The message was correctly routed, validated, processed, and acknowledged for the namespace enrx_org_006.