AS2 Nodes for n8n

Requirements: /n software Adapters for Microsoft BizTalk

Introduction

The /n software n8n nodes extend n8n with powerful integration capabilities backed by the /n software node library. This guide provides an overview of the following nodes:

• The AS2 Sender node implements a complete AS2 client within an n8n workflow and may be used to upload files to a remote AS2 server.
• The AS2 Trigger node implements a fully-functional AS2 server, allowing n8n workflows to receive and process inbound AS2 messages through a webhook endpoint.

These nodes enable secure AS2-based EDI exchanges directly within an n8n workflow. This article provides an overview of both AS2 nodes, their basic configuration, and common usage patterns.

Node Installation

Before proceeding, please ensure that the /n software n8n nodes have been installed successfully. For instructions on how to install the /n software n8n nodes, please refer to the installation guide here. Afterwards, assuming the mentioned node location is populated, simply restart your n8n server instance, and the /n software nodes should be searchable via the n8n UI.

Certificate Properties

Before discussing each node, the AS2 Sender and AS2 Trigger contain many properties that are used to specify certificates (whether they be public keys or private keys). When setting a certificate, there are five properties that may be utilized. As an example, we can look at the SigningCert* properties that are available in the AS2 Sender node, which are used to specify the private key certificate used to sign the outgoing AS2 request:

• SigningCertStore - This property specifies the name of the signing certificate. Depending on the certificate type (see below setting), this may be set to User and Machine certificate stores on Windows (e.g., MY, CA, ROOT, SPC), or a path to a local PFX file (C:\certs\test.pfx), for example.
• SigningCertStorePassword - This property specifies the password of the signing certificate, if one is applicable. In this case, since the signing certificate requires a private key, this property is usually required, though for properties using the public key (e.g., RecipientCertStorePassword), the password is not necessary.
• SigningCertStoreType - This property specifies the type of certificate used for signing. For a full list of supported properties, please refer to the product documentation; however, some possible types are "PFX File", "Machine", "PEMKeyFile", etc.
• SigningCertSubject - This property specifies the subject of the signing certificate, where the subject is a comma-separated list of distinguished name fields and values. This is especially useful if multiple certificates are contained within the store. The special value "*" picks a random certificate in the store.
• SigningCertThumbprint - This property specifies the thumbprint of the signing certificate. In the event that there are multiple certificates in the store with the same subject, this property can be specified to distinguish between those certificates. Assuming unique subjects amongst certificates in the same store, this property is not necessary to set.

AS2 Sender Node

The AS2 Sender node implements an AS2 client within an n8n workflow and is used to transmit files to a trading partner's AS2 server. At a minimum, the node must be configured with the identifiers of both trading partners and the destination URL.

The AS2From property specifies the identity of the sending system. This value represents your organization's AS2 identifier and may be a company name, DUNS number, or any identifier agreed upon by the trading partners.

The AS2To property specifies the identity of the receiving system, which corresponds to the trading partner's AS2 identifier.

The URL property specifies the HTTP endpoint where the AS2 messages will be delivered. When the URL uses the "https" scheme, the message will be transmitted over SSL/TLS.

In addition to these required properties, several other settings are commonly configured to support message security, integrity, and delivery confirmation. When the MDNTo property is set, the node will request a Message Disposition Notification (MDN) from the receiving server. The value may be an email address, URL, or other identifier. Many AS2 implementations ignore the actual value. The presence of the property ensures that the Disposition-Notification-To header is included in the outgoing request.

When setting the MDNTo property, by default, the receipt will be delivered synchronously, within the HTTP context that is established with the server. However, it is possible to request the MDN receipt to be sent asynchronously, i.e., outside of the established HTTP context. This is done by setting the "MDNDeliveryOption" config to a URL, which may be set by adding a line to the Other property. The URL indicates the destination for the reply, and may start with "mailto", "http", or "https". For example, the following line could be added via the Other property to request the MDN be sent to a separate HTTPS URL:

MDNDeliveryOption=https://mdn.test.local:1234

Certificates may also be configured to enable encryption, message signing, and signature validation. The RecipientCert properties specify the public key certificate of the receiving partner and are used to encrypt outgoing messages. The SigningCert properties specify the private key certificate used to sign outgoing AS2 messages, allowing the receiving partner to verify the authenticity and integrity of the transmitted data. The ReceiptSignerCert* properties specify the certificate used to verify the signatures on the returned MDN receipts. This configuration is recommended when MDNs are requested.

After ensuring the above properties are set (if necessary), the data to upload still needs to be set. The node may reference a file located on disk by specifying the EDIFileName property. In this case, the node reads the file and sends its contents as the AS2 payload.

Alternatively, the payload may be supplied as binary data produced by a previous node in the workflow. When binary input is used, the node reads the specified binary field and sends it as the message body. In this case, the EDIFileName property can be set as well, to attach a particular filename to the outgoing data. In this case, the component will not read data from the specified filename due to the presence of binary data.

After the component has successfully sent the data and optionally verified the received MDN receipt, information regarding the request and receipt will be provided by the node. For example, this may look like (assuming an MDN is requested):

[ { "ReceiptMDN": "Original-Recipient: ...", "ReceiptMessage": "The incoming message from...", "ReceiptHeaders": "Content-Length: 557\r\n...", "ReceiptMessageId": "10075e4a-1234-..." "Etag": "", "ReceiptAS2To": "Test To Organization", "ReceiptAS2From": "Test From Organization", "ReceiptLogFile": "", "AS2MessageId": "10075e4a-1234-..." } ]

AS2 Trigger Node

The AS2 Trigger node implements a fully functional AS2 server that can communicate with your n8n workflow. To use the node, you must configure the AS2SiteURL where the AS2 endpoint is hosted.

The TradingPartner property specifies the identity of the sending system, i.e., the trading partner's AS2 identifier.

The ReceivingPartner property specifies the identity of the receiving system, i.e., your AS2 identifier.

The node will read all incoming AS2 requests and verify these values to ensure that the message originates from a known trading partner and is intended for the correct receiving entity.

Note that the node listens for inbound HTTP requests through an n8n webhook endpoint and processes incoming AS2 messages before passing the data to the workflow. The AS2SiteURL property must be set to the URL assigned to the node's webhook endpoint.

Certificates may also be configured to enable decryption, signature validation, and signing of outgoing MDN receipts (if needed by the client). The EncryptionCert properties specify the private key certificate used to decrypt the incoming message. The SignerCert properties specify the public key certificate of the trading partner and is used to verify the signature of the incoming AS2 message. In the event that the trading partner requests a synchronous MDN receipt, the MDNSigningCert* properties should be set to your private key, which is used to sign the outgoing receipt. In the event the trading partner requests an asynchronous MDN receipt, the component will automatically handle this, and the receipt will be sent to the URL specified by the client.

After the component has successfully received data and optionally, sent an MDN receipt, the information regarding the request and receipt will be provided by the node. For example, this may look like (assuming an MDN receipt was returned to the client):

[ { "MessageType": "AS2Message", "AS2MessageId": "<c211597c-e3fe...>", "AS2RequestTo": "Test To Organization", "AS2RequestFrom": "Test From Organization", "AS2RequestSubject": "", "AS2RequestLogFile": "", "AS2RequestScanResult": 0, "AS2RequestId": "<c211597c-e3fe...>", "AS2RequestEDIType": "application/edi-x12", "ReceivedFileName": "test.edi", "MDNMICValue": "ibzZFTc7...", "MDNReceipt": "--boundary7p2u8A==\r\nContent-Type:...", "MDNReceiptHeaders": "AS2-From: Test From Organization\r\n", "MDNReceiptMessage": "The incoming message from...", "MDNReceiptDeliveryOption": "" } ]

In the event that an incoming AS2 message has any attachments, information regarding these attachments will also be provided by the node. For example, this may look like:

[ { "MessageType": "AS2Attachment", "ReceivedFileName": "attachment.txt", "ContentType": "text/plain", "AS2Message": "<c211597c-e3fe...>", "AS2RequestTo": "Test To Organization", "AS2RequestFrom": "Test From Organization", "AS2RequestFileName": "test.edi" } ]

In either case, the file content associated with the AS2 message is provided to the output as binary data.

Receiving MDN Receipts

The default mode of the AS2 Trigger node is to receive AS2 messages. However, the node can also act as an endpoint for receiving asynchronous MDN receipts, i.e., receipts that are sent asynchronously, outside of the HTTP context of an external AS2 sender/receiver. The specific mode of operation is determined by the ReceiveMode property, which may be set to MDN in order to accept incoming MDN receipts. In this case, the typical order of operations would look like:

1. An AS2 client sends a request to an external AS2 server, indicating they would like an asynchronous MDN receipt sent to a separate URL.
2. An AS2 server, after performing expected operations, sends an MDN receipt to the separate URL specified by the client.
3. The AS2 Trigger node, configured to accept MDN receipts, receives and verifies the receipt, sending the verification status to the AS2 server.

Note that this flow implies the AS2 client in (1) specifies the URL the AS2 Trigger node is listening at (i.e., the HTTP endpoint hosted by n8n) as the expected recipient of the MDN receipt.

In this case, the ReceiptSignerCert* properties should be set to the public key certificate of the endpoint sending us the receipt (i.e., the AS2 server in (2) above), in order to verify the receipt.

Once a receipt has been verified (regardless of whether it was successful or not), the verification status is sent back to the AS2 server. Information regarding the MDN and verification status will be provided by the node. For example, this may look like:

[ { "AS2MessageId": "<c211597c-e3fe...>", "LogDirectory": "", "MDNMICValue": "", "MDNSignatureStatus": "Valid", "MDNDisposition": "automatic-action/MDN-sent-automatically; processed" } ]