An introduction to the scenarios used in this book

The scenarios in this book illustrate how to design file transfer solutions that address a variety of situations. Each scenario uses technology to suit specific needs and, in certain cases, variations of the scenario are shown. You can use these solution designs as they are, or you can use them as the basis to design your own solution.

This section provides a basic overview of the scenarios that we use in this book.

3.1.1 Interal use of Sterling Connect:Direct and WebSphere MQ File Transfer

Edition

This scenario illustrates how to use only Sterling Connect:Direct and how to integrate Sterling Connect:Direct with WebSphere MQ File Transfer Edition for internal managed file transfer. The Connect:Direct nodes and WebSphere MQ File Transfer Edition agents reside in the protected network. This scenario uses features in both products to integrate the two proprietary protocols.

The scenario addresses the flow of files from the following perspectives:

򐂰 Pushing a file from a Sterling Connect:Direct PNODE to a Sterling Connect:Direct SNODE 򐂰 Sterling Connect:Direct PNODE pulling a file from a Sterling Connect:Direct SNODE 򐂰 Pushing a file from Sterling Connect:Direct to WebSphere MQ File Transfer Edition 򐂰 Sterling Connect:Direct pulling a file from WebSphere MQ File Transfer Edition 򐂰 WebSphere MQ File Transfer Edition pushing a file to Sterling Connect:Direct 򐂰 WebSphere MQ File Transfer Edition pulling a file from Sterling Connect:Direct

3.1.2 Using Sterling Connect:Direct for multi-enterprise transfers

This scenario illustrates how to use Sterling Connect:Direct for multi-enterprise file transfers. The scenario features Connect:Direct nodes internal and external to the enterprise. Any external Sterling Connect:Direct transmission should use encryption of the payload. This scenario uses the following topologies:

򐂰 In the first topology, Sterling Secure Proxy sits in the DMZ. Sterling Connect:Direct moves files into and out of the protected network through Sterling Secure Proxy. Sterling Secure Proxy is used as the mediation server that resides in the DMZ for this particular scenario, because it is the only product that is available at the time of publication that supports the use of the proprietary Sterling Connect:Direct protocol.

򐂰 In the second topology, files are transferred between the external Connect:Direct node and the protected network using Sterling File Gateway. Sterling Secure Proxy resides in the DMZ to allow for a secure external transmission. The addition of Sterling File Gateway to a Sterling Connect:Direct multi-enterprise file transfer scenario allows the external partner to have the ability to view transfers through a partner management interface and the ability to convert to other protocols if necessary.

The topologies address the flow of files from the following perspectives: 򐂰 Using Sterling Connect:Direct and Sterling Secure Proxy

Pushing a file from an external Sterling Connect:Direct PNODE through Sterling Secure Proxy to an internal Sterling Connect:Direct SNODE.

򐂰 Using Sterling Connect:Direct and Sterling File Gateway

– Pushing a file from an external Connect:Direct node through Sterling Secure Proxy to Sterling File Gateway in the protected network, using a Sterling Connect:Direct adapter to receive the file and to send to another internal Connect:Direct node.

– Pushing a file from an internal Sterling Connect:Direct to Sterling File Gateway, using a Sterling Connect:Direct adapter, which routes it to an external Connect:Direct node through Sterling Secure Proxy.

3.1.3 Multi-Enterprise file transfer using Sterling Connect:Direct, Sterling File

Gateway, and WebSphere MQ File Transfer Edition

This scenario illustrates how files can be exchanged between enterprises using Sterling Connect:Direct and WebSphere MQ File Transfer Edition using Sterling File Gateway. Sterling Connect:Direct is used externally to send files through a mediation server in the DMZ. Any external Sterling Connect:Direct transmission should use encryption of the payload.

Sterling File Gateway takes advantage of Sterling B2B Integrator’s ability to handle both the Sterling Connect:Direct and WebSphere MQ protocols. Through mailboxes and routing channels defined in Sterling File Gateway, Sterling File Gateway uses trading partner definitions in Sterling B2B Integrator to switch between protocols. Sterling B2B Integrator uses a WebSphere MQ adapter to place a message on a queue for an agent to initiate a transfer. The WebSphere MQ FTE backbone inside the protected network is used to move files securely between back-end systems.

This scenario addresses both inbound and outbound file transfers.

3.1.4 Integrating multi-enterprise transfers with an enterprise service bus

This scenario illustrates how to transfer files with external partners using application layer protocols with Sterling File Gateway, while at the same time taking advantage of the business-to-business partner profile capabilities in Sterling File Gateway. In addition, it illustrates how you can use an enterprise service bus (ESB) in the protected network to affect the file transfer. WebSphere Message Broker provides the ESB capabilities, allowing you to route data to the appropriate back-end application, to transform the transfer request to the protocol required for the target application, or to perform more advanced mediation using the wide range of capabilities of WebSphere Message Broker.