From EDI Processing to Supply Chain Visibility: Integrating webMethods B2B with Syncrofy, Part II

This post is the second entry of a two-part series on integrating IBM webMethods B2B with Syncrofy, “The AI-enabled supply chain platform.” Part I focused on the business drivers, target users, and high-level architecture behind the integration. In Part II, we walk through a demo-based implementation of the integration and discuss key design considerations based on the solution that was built.

If you’re running EDI through IBM webMethods B2B, you already have the transactions handled.

But what about giving your business teams real visibility into what those transactions actually mean?

In this post, we walk through a practical, demo-based integration showing how to forward EDI data to Syncrofy without disrupting your core EDI operations.

End-to-end integration flow

Reference architecture

The following diagram is reused from Part I and is included here for reference. The numbered steps in the diagram correspond directly to the integration flow described in the sections below.

Scope and assumptions

Several assumptions guided the design of the demo and the integration pattern described in this article:

• The demo implementation based exclusively on SaaS components within IBM webMethods Hybrid Integration: webMethods B2B and webMethods Integration
• The integration forwards a copy of the EDI payload to Syncrofy for visibility and analytics purposes
• No transformation, enrichment, or persistence of EDI data occurs beyond what is required for transport to Syncrofy
• webMethods B2B remains the authoritative system of record for EDI processing and compliance

Although this article focuses on a SaaS-based implementation using webMethods B2B and webMethods Integration, the same architectural pattern can be applied in on-premises environments using webMethods Trading Networks in combination with webMethods Integration Server. In such scenarios, processing rules, flow services, and error-handling constructs follow equivalent conceptual models, with differences primarily in deployment model and operational management rather than integration design.

These assumptions help keep the architecture simple, decoupled, and scalable while meeting the primary goal of enabling business-facing visibility into EDI-driven supply chain data.

End-to-end integration steps

This section describes the end-to-end integration flow used in the demo to forward EDI payloads processed by webMethods B2B to Syncrofy using webMethods Integration. The goal of this flow is to provide Syncrofy with a copy of the EDI data for visibility and analytics purposes, without disrupting or altering the core EDI processing within webMethods B2B.

The steps below follow the logical sequence illustrated in the architecture diagram and reflect the actual demo configuration.

Step 1: EDI document submission to webMethods B2B

The integration begins when an EDI document is submitted to webMethods B2B through a configured inbound partner channel.

Figure 1. Inbound channel associated with the sending partner, used by external clients to submit EDI payloads 

In the demo scenario:

• The business document type is X12 4010 850 (Purchase Order)
• The sending partner is defined in webMethods B2B as WayneTestPartner (ID 567893456)
• The receiving partner is defined as CoEnterprise (ID 123456789)
• A test client (Postman) is used to submit the EDI payload via HTTP POST to the inbound channel URL associated with the sending partner

Upon receipt, webMethods B2B validates the incoming document, applies the appropriate partner agreement, and records the transaction for monitoring and audit purposes.

Step 2: Processing rule evaluation in webMethods B2B

After successful ingestion, webMethods B2B evaluates configured Processing Rules to determine whether additional actions should be taken for the transaction.

Processing Rules are evaluated in configured order, and only the first rule whose criteria evaluates to true is executed. Once a rule’s Action runs, further Processing Rule evaluation stops for that document.

In the demo, a Processing Rule is defined with the following criteria:

• Sending Partner = WayneTestPartner
• Receiving Partner = CoEnterprise
• Business Document Type = X12 4010 850

If the rule conditions are met, the Processing Rule executes an associated Action. This Action is responsible for invoking a Flow Service in webMethods Integration and passing a copy of the EDI payload along with relevant metadata.

It is important to note that this Processing Rule is intentionally specific for demo purposes. 

• Processing Rules can be generalized to support multiple partners, document types, or routing scenarios
• It all comes down to which EDI document types do you want to route to Syncrofy AND for which Senders/Receivers; the criteria logic can be very specific or more general

Step 3: Invocation of webMethods integration flow service to Orchestrate and process the EDI Document 

When the Processing Rule Action is triggered, webMethods B2B invokes a Flow Service hosted in webMethods Integration. In this demo, Reliable Execution mode is used to ensure controlled and reliable invocation. 

In the demo implementation: 

• The Processing Rule invokes a webMethods Integration Flow Service named ProcessPurchaseOrder, which serves as the primary orchestration and processing entry point for inbound PO 850 documents
• This Flow Service represents a logical handoff point where EDI processing moves from webMethods B2B into webMethods Integration for customer-specific handling
• This approach ensures that webMethods B2B remains the authoritative system for EDI processing while allowing downstream systems to consume the data independently

Step 4: EDI payload extraction and mapping 

The flow service ProcessPurchaseOrder is implemented within a demo project named wMB2B_to_Syncrofy, which contains supporting assets such as connector configurations and document type definitions. 

Figure 2. Service invoked by webMethods B2B to process PO 850 and then call Flow Svc to send copy to Syncrofy

This flow service:

• Represents where customer-specific EDI processing logic is implemented, such as parsing the EDI payload, applying business rules, transforming data, and integrating with backend applications or endpoints
• For demonstration purposes, the processing logic is intentionally simplified: the inbound PO 850 is parsed, mapped into an XML structure, and written to an inbound directory on an SFTP server
• In real-world implementations, this processing flow service would typically perform more advanced transformations and integrations, such as sending the processed data to an ERP system, order management application, database, or API

As part of the overall orchestration, this flow service also invokes a reusable utility flow service (sendCopyOfEDItoSF) to forward a copy of the original EDI payload to Syncrofy for analytics and visibility purposes (described in Step 5).

Step 5: Transmission to Syncrofy

Within the reusable utility flow service sendCopyOfEDItoSF, the EDI payload is prepared for transmission to Syncrofy.

Key activities performed by the flow service include:

• Mapping the EDI payload to the HTTP request format expected by Syncrofy; preserving the original EDI structure to ensure accurate downstream processing and analytics
• Setting required HTTP headers, including authentication credentials (for example, a bearer token)

The flow service transmits the EDI payload to Syncrofy using an HTTPS POST request via the built-in HTTP connector provided by webMethods Integration.

This synchronous call allows the flow service to:

• Submit the EDI data for immediate processing by Syncrofy
• Receive a response indicating whether the payload was accepted or rejected
• Relay the response status back to the caller

While HTTPS POST is used in the demo, Syncrofy also supports SFTP-based ingestion. The choice between HTTPS and SFTP depends on architectural preferences, operational requirements, and data transfer patterns. The overall integration flow remains consistent regardless of the transport mechanism used.

Note: An API for Syncrofy is on the roadmap.

Step 6: Processing and visibility in Syncrofy

Once received, Syncrofy processes the EDI payload and makes the data available through its web-based user interface.

At this stage:

• The EDI document becomes part of Syncrofy’s order lifecycle views
• Business users can access transaction details, analyze discrepancies, and monitor performance metrics
• The data is correlated with related documents and events as applicable

This step represents the handoff from technical transaction processing to business-facing visibility and analytics.

Step 7: Response handling and error management

Both flow services use standard Try/Catch constructs to manage normal processing and error handling.

• All primary business and integration logic executes within the Try block, while any runtime exceptions are captured by the Catch block
• The utility Flow Service sendCopyOfEDItoSF propagates its execution outcome (success or failure) back to its caller, which in this demo is ProcessPurchaseOrder
• This approach ensures that errors encountered during downstream processing are clearly surfaced to the primary processing flow service and can be handled in a consistent manner

Note: Error-handling behavior should be confirmed and designed according to customer requirements. In real-world implementations, the Catch block may invoke a centralized or global error-handling Flow Service responsible for activities such as creating support tickets, sending notifications to collaboration tools (for example, Slack or Microsoft Teams), sending alert emails, or triggering other operational workflows.

Summary of the integration flow

This end-to-end flow demonstrates how webMethods B2B, webMethods Integration, and Syncrofy can be combined to deliver business visibility over EDI transactions without compromising the integrity of the EDI platform.

Key characteristics of the flow include:

• Non-intrusive forwarding of EDI payloads
• Clear separation of responsibilities across platforms
• Support for synchronous feedback and error handling
• Flexibility to extend the pattern to additional document types and partners

The next section discusses design considerations, including transport options and large document handling, that should be evaluated when adapting this pattern for production use.

Design considerations

This section outlines key design considerations that should be evaluated when adapting the integration pattern described in this article for production use. These considerations are based on the demo implementation and on practical constraints observed across webMethods B2B, webMethods Integration, and Syncrofy.

The intent of this section is to clarify assumptions, document limitations, and highlight areas that may require additional planning depending on customer requirements.

Transport Options: HTTPS vs. SFTP

In the demo implementation described in this article, webMethods Integration forwards EDI payloads to Syncrofy using an HTTPS POST request. This approach aligns well with an event-driven integration model in which webMethods B2B remains the authoritative system for EDI processing, and Syncrofy consumes a copy of the data for visibility and analytics purposes.

Syncrofy also supports SFTP-based ingestion. However, it is important to clarify that the use of SFTP often implies a different architectural pattern and, in many cases, a different role for webMethods B2B.

Note: An API for Syncrofy is on the roadmap.

When webMethods B2B is used as the system of record for EDI processing – handling partner identification, agreement enforcement, validation, and transaction governance -the choice between HTTPS and SFTP typically applies only to the final transport mechanism between webMethods Integration and Syncrofy. In this scenario, SFTP can be used as an alternative to HTTPS for forwarding EDI payloads downstream, without changing the overall responsibility of each platform.

In contrast, architectures in which EDI files are delivered directly to Syncrofy via SFTP from upstream systems or trading partners often do not include webMethods B2B in the solution. In such cases, Syncrofy becomes the first platform to receive the EDI data, and responsibilities such as partner management, agreement validation, and EDI governance are either handled upstream or omitted entirely. These scenarios represent a different integration model and are outside the scope of this article.

The demo and integration pattern described here assumes that:

• webMethods B2B remains the authoritative EDI platform
• Syncrofy is a downstream consumer of EDI data for visibility and analytics
• HTTPS is used for simplicity and synchronous feedback

Large document and file handling considerations

The demo integration does not explicitly implement large file or large document handling logic. This was a deliberate design choice based on the nature of the EDI payloads being forwarded and the behavior of the underlying platforms.

Key observations from the demo and platform behavior include:

• webMethods B2B may internally flag certain inbound EDI payloads as large documents, but this behavior is abstracted away from downstream Flow Services
• webMethods Integration Flow Services receive document content uniformly through standard request and metadata structures, regardless of document size
• When a Flow Service forwards EDI payloads without transformation or persistence, no additional large-file logic is required in the Flow Service itself
• Built-in B2B utilities handle streaming internally, shielding the integration logic from file size concerns

It is also important to note that large document support is not enabled by default in all webMethods B2B SaaS tenants. Customers can verify the status of this feature by navigating to Administration → Subscriptions within the webMethods B2B user interface

If the following informational message is displayed: “Info: Large document support is not enabled. To enable this feature, contact IBM support.” then large document handling is currently disabled, and IBM Support must be engaged to enable it.

Note: This step is only required if large document handling capabilities are needed; do not enable it unless you need it.

Enhancements for large-file scenarios

If future requirements include forwarding very large EDI documents or payloads approaching platform limits, the Flow Service may need to be enhanced to ensure efficient processing. Potential considerations include:

• Avoiding unnecessary loading of full payloads into memory
• Ensuring downstream calls operate on binary or streamed data rather than string representations
• Minimizing or disabling verbose payload logging
• Optionally branching logic based on large-document indicators provided in B2B metadata

These enhancements were intentionally omitted from the demo to keep the integration focused on visibility use cases rather than high-volume file transfer optimization.

Syncrofy payload constraints

When forwarding EDI payloads to Syncrofy, several practical constraints should be considered:

• Syncrofy typically prefers one ISA envelope per file, as this simplifies presentation and investigation within the UI
• While ISA envelopes can technically contain multiple GS and ST segments, excessively large envelopes are discouraged
• Syncrofy begins rejecting payloads at approximately 50 MB. Most EDI transactions fall well below this threshold, particularly when envelopes are scoped appropriately

These constraints informed the demo design and should be validated during solution planning for production implementations.

Key takeaways and closing

This article presented a practical integration pattern for extending EDI transaction processing in webMethods B2B (SaaS) with business-facing visibility and analytics in Syncrofy, using webMethods Integration (SaaS) as the orchestration layer.

The pattern is intentionally non-intrusive. webMethods B2B remains the authoritative system of record for EDI processing, partner management, and compliance, while Syncrofy consumes a copy of EDI payloads to provide supply chain teams with actionable insight into orders, shipments, invoices, and related events.

webMethods Integration enables this exchange in a controlled and decoupled manner, preserving architectural flexibility and scalability.

By separating transactional responsibility from visibility and analytics, organizations can:

• Maintain stable and governed EDI operations
• Reduce dependency on IT for routine investigation and reporting
• Enable supply chain support and operations teams to work more proactively
• Extend the value of existing EDI investments without introducing unnecessary complexity
• Define centralized error-handling and alerting patterns early, especially when forwarding EDI payloads to downstream analytics platforms

The demo-based integration flow described in this article illustrates how these platforms can be combined using supported SaaS components within IBM webMethods Hybrid Integration, while remaining adaptable to different document types, partners, and operational requirements.

Next steps

Organizations considering this integration pattern may want to:

• Identify which EDI document types would provide the greatest operational value if surfaced to business users for monitoring and investigation
• Confirm whether webMethods B2B is already serving as the system of record for EDI processing, or whether that role needs to be established
• Evaluate whether HTTPS or SFTP aligns best with existing governance and operational models, based on the architectural distinctions described in this article
• Engage both integration and supply chain teams early to define visibility, alerting, and reporting expectations

References and additional resources

Syncrofy

• One-pager
• eBook
• Video
• Webinar
• Free trial 

IBM webMethods B2B (SaaS)

• Product documentation

IBM webMethods Integration (SaaS)

• Product Documentation

Want to explore what webMethods and Syncrofy can do for your business? Contact us to connect with a CoEnterprise expert and get started today.