--- title: "EDI in JTL: Make or Buy? Architecture and Decision Guide" description: "Technical guide to EDI integration in JTL, including architecture strategy, AS2 transport, middleware design, and cost considerations." canonical_url: "https://kickbyte.de/en/blog/edi4jtl" last_updated: "2026-08-21T17:54:07.005Z" --- # EDI in JTL: Make or Buy? Architecture and Decision Guide In a B2B environment, [EDI](/en/services/edi-integration) is not an optional add-on but an integral part of operational value creation. As soon as companies work with marketplaces, wholesalers, retail chains, or industrial partners, structured data exchange becomes a prerequisite. Typical message types such as ORDERS, DESADV, or INVOIC do not merely represent documents; they are directly linked to logistics, invoicing, accounting, and inventory availability. Faulty or unstable EDI processes have an immediate impact on revenue, delivery capability, and customer relationships. That is why the core question is not purely technical, but strategic: **Purchase a standard solution or build your own integration architecture?** In a recent client project, we implemented an EDI integration for JTL based on Mendelson (AS2) and a custom Java middleware. The ERP integration is handled via the official JTL API. This decision was justified both architecturally and economically. --- ## Technical Starting Point: JTL and EDI JTL-Wawi is an [ERP system](/en/services/erp-integration) with clearly defined business processes for purchasing, sales, warehousing, and shipping. EDI, however, is not an ERP function; it is an integration and communication layer between organizations. A complete EDI architecture consists of more than just an AS2 server. It includes several logically separated layers: - **Transport layer**: Signing, encryption, certificate management, MDN handling - **Syntax layer**: Parsing EDIFACT (e.g., ORDERS, DESADV, INVOIC) - **Semantic layer**: Validation, partner-specific rules, mandatory fields, reference checks - **Transformation and integration layer**: Mapping to the internal domain model and handover to the ERP In addition, cross-cutting technical concerns must be addressed: - Idempotent processing (no duplicate postings) - Error classification and retry strategies - Monitoring, logging, and alerting - Archiving and audit compliance This is where the real complexity arises, not in the AS2 handshake. --- ## Implemented Architecture The architecture was deliberately divided into clearly separated areas of responsibility.
Phase Component Responsibility
Transport Mendelson AS2 Protocol termination, signature verification, decryption, MDN
Persistence Message Store Storage of raw data for traceability
Processing Java Middleware Parsing, mapping, partner rules, status handling
Integration JTL API Transfer of validated data into JTL
ERP JTL-Wawi Functional processing (order, delivery, invoice)
Mendelson exclusively handles AS2 communication. This includes protocol termination, certificate validation, decryption of incoming messages, and proper transmission of MDNs. As a result, the transport layer remains clearly isolated and replaceable. After successful receipt, the raw data is persistently stored, for example in object storage or a file system. This persistence layer ensures traceability and repeatability of processing steps. The actual business logic resides in a Java-based middleware. It acts as the central integration hub. EDIFACT messages are parsed, validated, transformed into internal domain models, and enriched with partner-specific rules. Status tracking, error classification, and retry mechanisms are also implemented here. Integration with JTL is performed via the official JTL API. This ensures that all transactions run through documented and upgrade-safe interfaces. Direct database access was deliberately avoided to preserve upgrade capability and system stability. Outbound processes, such as generating and sending DESADV or INVOIC, follow a mirrored structure. JTL generates the business dataset, the middleware transforms it into EDIFACT, and Mendelson handles transport and signing. This clear layering ensures interchangeability of individual components, clean separation of responsibilities, and long-term maintainability. --- ## Why Middleware Instead of a Pure Platform Solution? Many EDI platforms bundle transport, mapping, and partner logic within a proprietary system. This can be efficient for simple scenarios, but as complexity increases it often leads to vendor lock-in and limited testability. With a dedicated middleware, integration logic becomes part of the actual system architecture. The code is versionable, testable, and CI/CD-capable. Mapping rules can be secured with automated tests. Partner-specific special cases can be modeled in a structured way instead of being configured in graphical mapping editors that are difficult to trace. Another advantage lies in technological freedom. Business logic is not tied to a specific tool. The AS2 server could be replaced without reimplementing mapping and orchestration. Likewise, the middleware can later support [additional interfaces](/en/services/system-integration) such as REST, SFTP, or API-based partners. The integration layer thus becomes a strategic asset rather than a tool configuration. --- ## Integration via the JTL API The official JTL API provides stable, documented endpoints with clearly defined transactional logic and validation mechanisms. Especially in a B2B environment, where data consistency is critical, clean error codes and transparent validation rules are essential. By exclusively using the API, the solution remains compatible with future JTL versions. Direct database manipulation or unofficial hooks were deliberately excluded, as they create long-term maintenance risks. For scalability scenarios, this API compliance is crucial. New partners or additional message types can be integrated without destabilizing JTL’s core processes. --- ## Economic Considerations: Fixed Costs vs. Platform Model EDI platforms typically operate with a mix of monthly license fees, transaction-based charges, and partner-specific additional costs. As the number of partners or the message volume grows, these costs increase proportionally. A custom middleware shifts the cost structure toward upfront investment rather than ongoing fees. There are initial implementation costs as well as ongoing infrastructure and maintenance expenses. However, transaction-based platform fees are eliminated entirely. Beyond a certain number of partners or at high message volumes, this structure can provide significant cost advantages. At the same time, expertise is built internally rather than remaining tied to a provider. Of course, this also means taking on greater technical responsibility. Monitoring, certificate management, and operations must be professionally organized. For companies with a strategic B2B focus, this is often more sustainable than long-term platform dependency. --- ## Make or Buy: Decision Criteria A standard solution is typically appropriate when: - only a few partners need to be connected - transaction volume is low - exclusively standardized EDIFACT profiles are used - rapid implementation is more important than long-term control A custom architecture becomes attractive when: - multiple partners with individual requirements must be integrated - message volume is significant - EDI is a strategic component of business processes - technological control and testability are required - long-term cost optimization is a priority The decision should not be made solely on implementation costs, but in consideration of scalability, dependencies, and strategic positioning. --- ## Conclusion AS2 is now standard and no longer a strategic differentiator. The real decision concerns the architecture of the integration layer, control over mapping and partner logic, scalability of the solution, and the long-term cost structure. EDI in JTL is not a plugin question, but a deliberate architectural and economic decision with direct impact on stability, scalability, and margin.