Message Config

To make it easy to add new message types to the integration component or update and add config to an existing message type, we moved all the message config to a config file in a config directory/ storage bucket.

In the folder config you can now find the file message_config.json. This file contains all supported message types for the supported integration protocols (SOAP-Hubs and SFTP).

"messageType": {
  "mmchub_inbound_type": true, -> this is a boolean. true or false. Set to true for SOAP MMC-Hub inbound messages
  "sftp_inbound_type": true, -> this is a boolean. true or false. Set to true for SFTP inbound messages
  "xsd_schemas": {
      "code_list": [], -> optional list with XSD codelists
      "folder": "schemas", -> The folder where the XSD (and optional code_list) is.
      "file": "messageType.xsd" -> The file name of the XSD
  },
  "message_maps": {
    "folder": "maps", -> The folder where the mapping config is.
    "file": "messageType.json" -> The file name of the mapping
  },
  "rule_configs": [ -> this is a list of rule configs
    {
      "process_type_id": "ID", -> The process type id as described in the mapping
      "folder": "rules", -> The folder where the mapping config is.
      "file": "messageType_process_type_id.json" -> The file name of the mapping
    }
  ]
},

notes :

mmchub_inbound_type This indicates if it is expected to be inbound from the MMC-Hub/SOAP-Hub. If true, the inbound_message_scheduler will check for this message type.

sftp_inbound_type This indicates if it is expected to be inbound from an SFTP server. If true, the sftp_inbound_scheduler will check for this message type by matching filenames.

rule_configs This can be multiple per message type. Be aware the process_type_id has to be unique per message type.

Example 1 (SOAP Message):

"GL_MarketDocument": {
  "mmchub_inbound_type": true,
  "sftp_inbound_type": false,
  "xsd_schemas": {
      "code_list": ["urn-entsoe-eu-wgedi-codelists.xsd", "urn-entsoe-eu-local-extension-types.xsd"],
      "folder": "schemas",
      "file": "GL_MarketDocument.xsd"
  },
  "message_maps": {
    "folder": "maps",
    "file": "MarketDocument.json"
  },
  "rule_configs": [
    {
      "process_type_id": "A26",
      "folder": "rules",
      "file": "GL-MarketDocument_A26.json"
    },
    {
      "process_type_id": "A67",
      "folder": "rules",
      "file": "GL-MarketDocument_A67.json"
    }
  ]
},

Example 2 (SOAP Message):

"MeasurementSeriesNotification": {
  "mmchub_inbound_type": true,
  "sftp_inbound_type": false,
  "xsd_schemas": {
    "folder": "schemas",
    "file": "MeasurementSeriesNotification.xsd"
  },
  "message_maps": {
    "folder": "maps",
    "file": "SeriesNotification.json"
  },
  "rule_configs": [
    {
      "process_type_id": "N10",
      "folder": "rules",
      "file": "MeasurementSeriesNotification_N10.json"
    },
    {
      "process_type_id": "N20",
      "folder": "rules",
      "file": "MeasurementSeriesNotification_N20.json"
    },
    {
      "process_type_id": "N11",
      "folder": "rules",
      "file": "MeasurementSeriesNotification_N11.json"
    },
    {
      "process_type_id": "N21",
      "folder": "rules",
      "file": "MeasurementSeriesNotification_N21.json"
    }
  ]
},

Example 3 (SFTP Message):

"DRE": {
  "mmchub_inbound_type": false,
  "sftp_inbound_type": true,
  "xsd_schemas": {},
  "message_maps": {},
  "rule_configs": []
},

Note: This example shows a simple SFTP message without validation. However, SFTP messages can use XSD validation when needed, just like SOAP messages. Simply populate the xsd_schemas section as shown in The Example.

Example 4 (SFTP Message with Validation):

"METER_DATA": {
  "mmchub_inbound_type": false,
  "sftp_inbound_type": true,
  "xsd_schemas": {
    "folder": "schemas",
    "file": "MeterData.xsd"
  },
  "message_maps": {},
  "rule_configs": []
},

Protocol Feature Comparison

Feature	SOAP	SFTP	Notes
XSD Validation	Yes	Yes (Optional)	Both protocols support schema validation
Custom Validation Rules	Yes	No	Shared validation rule engine
Message Mapping	Yes	Yes	SOAP uses maps/, SFTP uses field_map_configs/
Acknowledgements	Yes	No	SFTP is fire-and-forget
Message Signing	Yes	No	SOAP supports digital signatures
Sequence Validation	Yes	No	SOAP tracks message sequences
File Tags	Yes	Yes	Both support FileManager tags
Audit Logging	Yes	Yes	Shared audit infrastructure
Multi-Response	Yes	No	SOAP can handle multiple responses
Archive Support	N/A	Yes	SFTP moves files to archive folder

SFTP-Specific Configuration

For SFTP message types, additional configuration files are required beyond the standard message_config.json:

Field Map Configs

SFTP messages require field mapping configurations stored in field_map_configs/<message_type>.json. These define how to extract or generate message fields since SFTP files don't have SOAP headers.

Example (field_map_configs/DRE.json):

{
    "field_maps": {
        "inbound_filename": {
            "function": "concat_hyphen",
            "args": [
                {"function": "return_string", "args": "dre"},
                {"function": "current_date_time", "args": ""}
            ]
        },
        "message_id": {
            "function": "concat_hyphen",
            "args": [
                {"function": "return_string", "args": "dre"},
                {"function": "current_date_time", "args": ""}
            ]
        },
        "sender_id": {
            "function": "return_string",
            "args": "Acme"
        }
    }
}

File Tags

File tags configuration stored in file_tags/<message_type>.json defines which tags to apply in the FileManager. This file is optional: when it is absent and the message map defines no inbound_file_tags, files are stored with only the default MessageType and MessageStatus tags.

Example (file_tags/DRE.json):

{
    "inbound_file_tags": {
        "Source": "sender_id",
        "MessageID": "message_id",
        "ProcessType": "process_type",
        "CreationTimestamp": "creation_timestamp",
        "CreationDate": "process_date"
    }
}

Response Configs

Response configuration stored in response_configs/<message_type>.json defines archive settings and response behavior:

Example (response_configs/DRE.json):

{
    "msg_type": "dre",
    "ns": "",
    "default_reason_code": "00",
    "default_reason_text": "Message fully accepted",
    "archive_location": "archive"
}

• default_reason_code: the Reason/code used for a positive acknowledgement.
• default_reason_text (optional): the Reason/text emitted for a positive acknowledgement. Rejection texts are not configured here — they come from the error_msg of the failing rule in the rules config (see Validation Rules). When empty, no text element is added. For SOAP this lives under ack_maps; see Message Mapper. (Deprecated: the former reason_texts map is still read for one release, but only its entry for default_reason_code.)

GLDPM (soap_hub.service_name = "gldpm"): the acknowledgement additionally requires received_MarketDocument.type (from the document_type field map) and Reason/text (from default_reason_text or the failing rule's error_msg) — both optional in the XSD but mandatory per the dependency table. See the GLDPM acknowledgement section in Message Mapper.

Connection Configuration

SFTP connections are configured in connections/<connection_name>.json:

Example (connections/local_sftp_test.json):

{
    "id": "local_sftp_test",
    "host": "127.0.0.1",
    "auth": {
        "type": "basic",
        "username": "developer",
        "pw_secret_key": "projects/<project-id>/secrets/<secret-name>"
    },
    "port": 2222,
    "source_folder": "upload",
    "allowed_extensions": ["txt", "csv", "xml"]
}

Note: The password is stored in Google Secret Manager; pw_secret_key holds the full resource path of the secret (projects/<project-id>/secrets/<secret-name>).

For a complete field-by-field description of every configuration file, see the Configuration Reference.