File Gateway Preliminary Decisions - Selecting Protocols

Body

This is another in a continuing series about decisions to be made in the planning stages of an IBM Sterling File Gateway (SFG) implementation. It has to do with thinking about protocols. It is intended as a guide to the decision making process.

In the latest versions of SFG, the following protocols are built in to the product: "Mailboxing" (indicated by a check in the box labeled "Partner Initiates Protocol Connection to Mailbox" at the Protocol screen when creating a community), "FTP or FTPS", "Sterling Connect:Direct", "SSH/SFTP", and "WebSphere MQ FTE". It is also possible to create a "custom protocol" in order to use other protocols that IBM Sterling B2B Integrator (SB2BI) is capable of, such as AS2 or HTTP. It is even possible to create a custom protocol using one of the built in protocols. The trick there is to make sure make sure you need one before implementing one.  

The first thing to do is make decisions on what protocols you need to use. Plain FTP might be fine and less complicated for files that stay within the same firewall as SFG, but is certainly not suitable for invoices, purchase orders, etc. sent to or received from a trading partner over the internet. Those need to be sent securely. Do you have any company internal people with whom plain FTP would be appropriate?

As long as Secure Plus is used with Connect:Direct, there is no significant difference from a security perspective between using it or FTPS or SFTP. Due to that, it comes down to more of a question of which protocols you are comfortable with and which protocols your trading partners want to use.

My experience is that more customers use WebSphere MG in IBM Sterling B2B Integrator (SB2BI) than in SFG. I have not had any discussions on that with customers, so I do not know the reason.

That brings us to the subject of custom protocols. Clearly, if you want to use, say, the HTTP protocol within SFG, you are going to have to create a custom protocol in order to do that since no built in HTTP protocol exists in SFG. The bigger question as to custom protocols is should you make a custom protocol to use instead of the built in version of that protocol, e.g. use a custom FTPS protocol instead of the built in "FTP or FTPS" protocol.

What are the advantages to making your own custom protocol?  The first is that you can add whatever parameters you want to the GUI in which you input settings when creating a partner. Along the same lines, you can add whatever you want to the business process (BP) associated with the custom protocol.  You will not have to worry about the possibility of being in an unsupported setup as you might be if you, for example, changed the content of the built in BP named FileGatewayDeliverFTP which is used to route files via FTP or FTPS. As a reference, please note the following at the below link to the SFG documentation: "Do not alter the system business processes."

http://www.ibm.com/support/knowledgecenter/SS4TGX_2.2.0/com.ibm.help.sfg_sys_admin.doc/SFGSystemBusinessProcesses.html

You may find that if you make changes to the built in BP and something stops working, that if you engage Support, you will be instructed to revert to the default version of the BP as an initial step. That would not happen with a custom protocol.

What are the disadvantages of a custom protocol? First and foremost, it takes a lot more time to create and test it than with a built in protocol. Also, it will almost always take SFG Support longer to diagnose and resolve issues with a custom protocol than with the built in protocol due to the lack of familiarity. That is because your custom protocol will be a "one-off" protocol that Support has never seen before, at least in some respects.

Here are some questions worth asking before you decide to make a custom protocol for a protocol that is already built in to the software. Some of the questions are also worth asking if you are just considering whether or not to create, say, an AS2 protocol.

1. Exactly what functions do you feel your business needs that are not in the built in protocol?
2. Would the benefits in terms of time gained from those functions be worth the time and effort that it takes to create and test a custom protocol?
3. Would the benefits in terms of cost gained from those functions be worth the time and effort that it takes to create and test a custom protocol?
3. Do you need the proposed custom protocol for all partners that use that protocol, or could some still use the built in version of that protocol?
5. Will the use of the proposed custom protocol make the onboarding of new SFG partners less difficult and time consuming, more difficult and time consuming, or have no discernible effect on the difficulty and amount of time it takes to onboard new partners?
6. Will the use of the proposed custom protocol require more system resources, fewer system resources, or will there be no difference with regard to system resources as compared to the built in protocol?

It is also worth noting that just because custom protocols exist, that does not mean they have to be enabled in every community.

Whatever your decisions about which protocols to use and about whether or not to create a custom protocol, the important point is to make sure that you are looking at the right facts in order to make that decision.