AS2 in .NET Without Separate Java Gateway: Native EDI Exchange Directly in Application Routes

redb.Route.AS2 brings native AS2 protocol support to .NET applications, removing the requirement for separate commercial gateways or standalone Java servers. Organizations exchanging EDI documents with major retailers, 3PL operators, banks, or healthcare providers can now process signed and encrypted S/MIME messages directly inside their existing .NET integration routes.

Previously, .NET teams faced two main options: expensive commercial AS2 gateways such as Cleo, Seeburger, or BizTalk that required separate infrastructure, or open-source Java solutions like OpenAS2 and Mendelson Community that ran as additional JVM processes with inbox directories. Both approaches kept AS2 handling outside the main application logic.

AS2 (Applicability Statement 2, RFC 4130) ensures guaranteed delivery of business documents over the internet. A payload, typically X12 or EDIFACT but also XML or JSON, is optionally compressed, signed with the sender’s private key, and encrypted with the recipient’s public certificate. The resulting S/MIME envelope travels via HTTP POST, and the receiver returns a signed MDN (Message Disposition Notification) containing a cryptographic MIC hash for non-repudiation.

The library adds as2 and as2s endpoint schemes to redb.Route. Routes are defined using simple URI strings such as as2s://partner.example.com/as2?connectionFactory=walmart for outbound and as2:/inbound/orders?host=0.0.0.0&port=4080&connectionFactory=walmart for inbound traffic. Partner configurations are stored once in an As2ConnectionFactory object that holds certificates, AS2 identifiers, signing and encryption algorithms, and MDN mode settings.

Configuration supports environment-specific values through placeholders, allowing the same compiled route to run in development, staging, and production by changing only appsettings files. Secrets such as PFX passwords are supplied via environment variables or user secrets.

Outbound routes automatically compress, sign, encrypt, and transmit documents while parsing the returned MDN. Headers such as redbAs2.mdnDisposition, redbAs2.signatureValid, and redbAs2.mdnMicMatch are placed on the exchange for conditional routing logic. Inbound routes decrypt incoming messages, verify signatures, and deliver clean business documents to the pipeline along with exchange metadata.

Asynchronous MDN handling is supported through a dedicated receive endpoint that correlates receipts by Original-Message-ID. The cryptographic layer relies on MimeKit built on Bouncy Castle, ensuring interoperability with existing AS2 implementations.

Compared with external gateways, the native connector keeps documents flowing inside a single process, enables unified observability through distributed tracing, and allows full use of enterprise integration patterns without intermediate file drops or additional monitoring systems.