🖥️ How We Submit EUDR DDS Statements via SAP iDocs — A Working Demo_
Introduction
With the upcoming EUDR (EU Deforestation Regulation) requirements, many SAP customers are looking for a compliant way to submit DDS (Due Diligence Statements). However, most available solutions are cloud-native, require BTP/CPI, or involve heavy integrations.
At BRIDGE, we built a lean middleware that allows SAP customers to submit DDS statements directly via iDocs. This blog gives a short technical overview and shows how we achieved this.
The Challenge
EUDR only provides a SOAP API, with strict WS-Security (PasswordDigest, WSSE headers).
SAP customers often rely on iDocs and expect minimal effort from their backend teams.
Most middleware platforms are too heavy or too expensive for simple DDS submissions.
Our Solution
We created a small Node.js-based middleware that:
Accepts a custom iDoc from SAP (Z_EUDR_DDS_SUBMIT).
Transforms it into a valid SOAP request matching the EUDR WSDL.
Handles authentication with EU Login credentials using WSSE headers.
Submits the DDS statement and writes back a response iDoc to SAP with status & any errors.
📂 Folder Structure for iDoc Processing in BRIDGE
Since BRIDGE currently uses iDocs to handle DDS submissions to the EUDR system, we’ve adopted a clean and simple folder structure to streamline processing from SAP.
To keep things efficient and easy to manage, the following structure is used:
The iDoc Structure
How BRIDGE Processes iDocs
BRIDGE is designed to keep the integration simple and robust by relying on familiar SAP technologies like iDocs. Here’s how it works behind the scenes:
🚀 Every 30 seconds, BRIDGE scans the /IN folder for new iDoc files.
Backend logging - scanning for files
📄 Each iDoc contains a specific message type (MESTYP) which determines what type of EUDR operation it represents (e.g., DDS Submit).
🔁 Based on this type, BRIDGE will:
Parse the XML iDoc
Map the data to the correct EUDR API format (SOAP)
Submit the request to the EUDR platform
📂 Once processed:
The original iDoc is moved to the /PROCESSED folder (or /FAILED if an error occurred)
A new response iDoc is generated in the /OUT folder containing:
The HTTP status
Any returned identifier (e.g. DDS ID)
Error or success messages
This approach keeps everything transparent, traceable, and easily debuggable — all without needing BTP, CPI, or custom SAP development.