From File Transfer Execution to Visibility: Integrating webMethods MFT with Syncrofy File Transfer (FT), Part II

This post is Part II of a two-part series on integrating webMethods Managed File Transfer (MFT) with Syncrofy File Transfer (FT). Part I focused on the business context, target users, and high-level architecture behind the integration, explaining how webMethods MFT and Syncrofy FT work together to provide file-centric operational visibility.

In Part II, we walk through a demo-based implementation of the integration, describing how file transfer events are generated by webMethods MFT Actions, mediated through webMethods Integration Flow Services, and consumed by Syncrofy FT. This part also highlights key design considerations and assumptions based on the reference solution that was built.

Visibility is only valuable if you can turn file transfer activity into actionable operational insight.

Previously, we explored the business rationale, platform roles, and high-level architecture behind integrating IBM webMethods MFT with Syncrofy File Transfer (FT). We examined how organizations can extend secure file transfer execution with event-driven visibility, monitoring, and operational insight while preserving their existing MFT investments. In this installment, we move from concept to implementation and walk through a working demo that shows how file transfer events are generated within webMethods MFT, mediated through webMethods Integration, and surfaced in Syncrofy FT. Along the way, we’ll highlight key design decisions, implementation considerations, and lessons learned that can help guide real-world deployments.

End-to-end integration flow

Let’s explore the end-to-end flow of the demo integration and show how file transfer execution events generated by webMethods Managed File Transfer (MFT) are emitted during action execution, mediated through webMethods Integration, and ultimately consumed by Syncrofy FT for visibility.

As a reminder, here is the high-level architecture diagram that was included in Part I:

The flow described below correspondsbelow corresponds directly to the above and reflects a working demo implementation. While the specific task steps, event types, and Flow Service calls shown are based on the demo, they are intended as a reference pattern that customers can adapt to their own file transfer requirements.

Step 1: File arrives at source endpoint (virtual folder)

The integration begins when a file is uploaded to a source virtual folder managed by webMethods MFT. In the demo, a Post Processing Action named wMMFT_to_SFTV_full_demo_Wayne is configured to execute automatically when a file arrives in the following virtual folder:

/SyncrofyFTVdemo/encrypted/

Once the file arrives, the Action is triggered immediately and begins executing its configured task steps sequentially, from top to bottom. The Action serves as the orchestration mechanism for file processing, delivery, and event emission.

Step 2: Initial event emission and file processing within the MFT Action

As the Action begins execution, an Integration FlowService task step is invoked early in the Action to emit a StartTransfer event. This event establishes the beginning of the file transfer lifecycle in Syncrofy FT. From this point forward, the Action executes a series of file processing task steps. In the demo, the following task types are used:

• Unzip
• Decrypt
• Rename
• Zip
• Encrypt
• Delete
• Move
• Integration FlowService

The incoming encrypted ZIP file is unzipped into a working virtual folder:

/SyncrofyFTVdemo/working/

The extracted file is decrypted, renamed to a normalized .dat extension, and then re-zipped and encrypted prior to delivery. Temporary working files are explicitly removed to ensure that only the final encrypted artifact is delivered. Throughout this process, Integration FlowService task steps are interleaved at key points to emit ProcessDetails events. These events provide visibility into processing progress without altering the execution of the file transfer itself.

Step 3: Delivery Initiation and Delivery-Level Event Correlation

When the Action reaches the delivery phase, a StartedDelivery event is emitted via an Integration FlowService task step. At this point, the file is delivered to the target virtual folder:

/SyncrofyFTVdemo/completefiles/

In the demo, this virtual folder maps to an Amazon S3 bucket, though webMethods MFT supports many endpoint types. Each delivery within an Action is tracked independently. While all events related to a single Action execution share a common ARRIVEDFILE_KEY (sourced from the MFT eventExecutionId), each delivery generates its own unique EVENT_KEY. This delivery-level key is reused for all subsequent events related to that specific delivery, including:

• ProcessDetails events with stage = Delivery
• CompleteDelivery events
• FailedDelivery events (if applicable)

This approach allows Syncrofy FT to correlate multiple deliveries executed within a single Action while preserving a unified view of the overall transfer.

• Emit event for StartedDelivery:

• Deliver the file to the target virtual folder (endpoint):

Step 4: Event mediation via webMethods integration flow services

Each Integration flow service task step within the MFT Action invokes a Flow Service hosted in webMethods Integration. In the demo, all Flow Services reside in the project:

wMMFT_to_SyncrofyFTV

The primary Flow Service, send_MFT_data_to_SyncrofyFTV, receives a superset of runtime metadata from webMethods MFT, including:

• Constants (Event type, Stage)
• General
• FileReference
• DateTime
• User

These inputs are populated using MFT server variables. While not all customers will require every field, the demo intentionally includes a superset to simplify mapping and future extensibility. Within the flow service, logic evaluates the Event and Stage values, maps the data to the appropriate Syncrofy FT event format, converts the document to JSON, and sends it to Syncrofy FT using an HTTPS POST authenticated via a bearer token.

Event and stage are checked to determine event to map:

Event in JSON format is sent to Syncrofy FT using HTTPS POST:

 

Step 5: Error handling and failed delivery events

Each webMethods MFT Action supports a single error handler task step. In the demo, the error handler is implemented using an Integration FlowService task that invokes errorhandler_MFT_data_to_SyncrofyFTV. This task step is executed only when the Execute error task option is enabled and an error occurs during Action execution. When invoked, the error handler Flow Service evaluates whether a delivery was in progress and, if so, maps the available context to a FailedDelivery event and sends it to Syncrofy FT.

While mappings for a FailTransfer event exist in the Flow Service, this event type is not emitted in the demo. Further analysis is required to determine how delivery-level failures, Action reruns, and MFT rerun behavior should be reflected consistently in Syncrofy FT. Action rerun can only be done on Post-Processing Actions.

 

Step 6: Event processing and visibility in Syncrofy FT

Syncrofy FT receives the JSON event payloads sent from webMethods Integration and processes them to build a correlated view of the file transfer lifecycle. As events arrive, Syncrofy:

• Correlates events using ARRIVEDFILE_KEY and EVENT_KEY
• Persists event data for monitoring and analytics
• Surfaces transfer status, history, and exceptions through its UI

Syncrofy FT does not participate in file execution or delivery. Its role is strictly to provide visibility into file transfers executed by upstream systems such as webMethods MFT.

Syncrofy FT dashboard:

Syncrofy FT summary of transfers:

Syncrofy FT file transfer details:

 

End-to-end recap & design considerations

Together, these steps demonstrate how webMethods MFT Actions can be extended with event-driven integration logic to provide business-facing file transfer visibility without disrupting core execution. The demo implementation serves as a reference pattern. Customers should expect to adapt Action design, flow service logic, and event granularity to match their own operational requirements, followed by appropriate unit and QA testing prior to production deployment.

This section highlights key design considerations observed during the implementation of the webMethods MFT to Syncrofy FT integration. These considerations are based on lessons learned from the demo and are intended to help guide customers as they adapt this reference pattern for their own environments.

Action design and task step placement

In webMethods MFT, Actions act as the execution backbone for file processing and delivery. The placement and sequencing of task steps within an Action directly influence both execution behavior and the visibility signals emitted to downstream systems. In the demo, Integration FlowService task steps are intentionally interleaved throughout the Action to emit lifecycle events at meaningful points, such as transfer start, processing progress, delivery initiation, and completion. This approach provides granular visibility while preserving the native execution semantics of MFT.

When adapting this pattern, you should carefully decide:

• Which processing steps warrant visibility events
• Where FlowService calls should be placed to accurately reflect progress
• Whether all processing steps need visibility, or only key milestones

There is no single correct placement strategy as event granularity should be driven by operational needs rather than technical convenience.

Event granularity and visibility trade-offs

Syncrofy FT supports multiple event types that together form a detailed lifecycle view of a file transfer. While emitting more events can improve observability, it also increases integration complexity. The demo strikes a balance by:

• Emitting StartTransfer and CompleteTransfer events to define the overall lifecycle
• Emitting ProcessDetails events during key processing stages
• Emitting delivery-specific events to track each delivery independently

You should evaluate:

• How much visibility is truly required by operations teams
• Whether processing-level detail adds actionable insight
• The operational cost of managing additional FlowService calls

Starting with a moderate level of granularity and expanding over time is often preferable to over-instrumenting from the outset.

Correlation strategy for transfers and deliveries

A critical aspect of the integration is how events are correlated across the file transfer lifecycle. In the demo:

• The ARRIVEDFILE_KEY is derived from the MFT Action execution identifier and correlates all events related to a single Action execution
• Each delivery within an Action generates a unique EVENT_KEY, allowing multiple deliveries to be tracked independently while still rolling up to the same overall transfer

This approach enables:

• Accurate lifecycle reconstruction in Syncrofy FT
• Clear separation between transfer-level and delivery-level events
• Support for Actions that perform multiple deliveries

When designing production integrations, customers should ensure that correlation keys are:

• Stable across retries and reprocessing
• Unique at the appropriate scope (transfer vs delivery)
• Consistently reused across related events

Error handling boundaries and responsibilities

Error handling is an area where careful boundary definition is required. webMethods MFT provides built-in error handling and rerun capabilities at the Action level. Syncrofy FT, on the other hand, is responsible for representing failures in a way that is meaningful to operations teams. In the demo:

• A dedicated error-handling Flow Service is invoked from the MFT Action error handler
• FailedDelivery events are emitted when a delivery is determined to have failed
• Logic for FailTransfer events exists but is intentionally not enabled

This reflects an important design reality: the relationship between MFT retries, Action restarts, and visibility events must be thoughtfully designed to avoid conflicting or misleading signals. You should explicitly decide:

• Which failures should be surfaced immediately
• How retries should be represented in visibility views
• Whether certain failures should suppress or replace earlier events

The demo’s error-handling implementation should be treated as a starting point, not a finalized error model.

Retry behavior and visibility implications

webMethods MFT supports reruning Actions and restarting execution under certain failure conditions. How these retries interact with previously emitted visibility events requires additional consideration. The demo does not attempt to fully resolve this interaction. Instead, it highlights the need to consider:

• Whether retries generate new ARRIVEDFILE_KEY values or reuse existing ones
• How partial deliveries should be represented if a rerun occurs
• Whether visibility systems should reflect retries as new attempts or continuations

These decisions are highly dependent on operational expectations and should be validated through testing in a QA environment.

Superset data modeling and mapping flexibility

The flow services in the demo accept a superset of MFT runtime metadata based on documented server variables. This approach simplifies mapping and allows for future expansion without redesigning interfaces. In practice:

• Not all customers will need every available server variable
• Some fields may be redundant or irrelevant for certain transfer scenarios

Starting with a superset and pruning fields over time provides flexibility while minimizing upfront design churn.

Testing and production readiness

Finally, it is important to reiterate that the demo implementation has been unit tested across common scenarios but has not been subjected to exhaustive failure, scale, or performance testing. Before deploying a similar integration to production, you should plan for:

• Action-level unit testing
• Flow Service error and rerun testing
• End-to-end validation of visibility semantics
• QA testing across representative file sizes and volumes

The demo demonstrates feasibility and architectural alignment, but production readiness requires additional validation.

Key takeaways and closing

We presented a practical integration pattern for extending file transfer execution in webMethods Managed File Transfer (MFT) with business-facing visibility in Syncrofy FT, using webMethods Integration as the orchestration and mediation layer.

The pattern is intentionally non-intrusive. webMethods MFT remains the authoritative system of record for file transfer execution, security, protocol handling, and delivery, while Syncrofy FT consumes event data emitted during execution to provide operational visibility into transfer progress, delivery status, and exceptions. At no point does Syncrofy participate in file movement or execution logic.

webMethods Integration enables this exchange in a controlled and decoupled manner, mediating file transfer events between MFT and Syncrofy FT while keeping execution and visibility concerns cleanly separated. This architectural separation is central to the pattern and is illustrated conceptually below. By separating execution responsibility from visibility and monitoring, you can:

• Maintain stable and governed file transfer operations
• Reduce dependency on IT for routine investigation and operational reporting
• Enable operations and support teams to proactively monitor and diagnose file transfer issues
• Extend the value of existing MFT investments without introducing additional transfer engines or complexity

Figure 1. Conceptual separation of responsibilities between file transfer execution, event mediation, and business-facing visibility.

This demo illustrates how webMethods Managed File Transfer, webMethods Integration, and Syncrofy File Transfer can be combined using supported components within IBM webMethods Hybrid Integration. The pattern is intentionally flexible and can be adapted to different file transfer scenarios, endpoint types, processing requirements, and operational expectations.

While it provides a concrete reference implementation, it is not intended to be deployed as-is. You should treat it as a solution pattern and starting point, refining event placement, error handling, and rerun behavior to align with their specific operational and governance requirements.

Next steps

If you and your organization are considering this integration pattern, you may want to:

• Identify which file transfer scenarios would benefit most from enhanced operational visibility and monitoring
• Evaluate how existing webMethods MFT Actions should be instrumented to emit meaningful lifecycle and delivery events
• Assess how error handling and rerun behavior in webMethods MFT should be represented within visibility tooling, especially in the context of partial deliveries or retries
• Engage both integration and operations teams early to define expectations for monitoring, alerting, escalation, and exception handling

---

References and additional resources

Syncrofy File Transfer (FT)

• One-pager
• Video
• Blog

IBM webMethods Managed File Transfer (SaaS)

• Product documentation

IBM webMethods Integration (SaaS)

• Product documentation

---

Want to explore what webMethods MFT and Syncrofy FT can do for your business?

Contact us to connect with a CoEnterprise expert and get started today.