File Gateway Preliminary Decisions - The Use of Communities

Body

This is the first in a series about things to think about prior to implementing IBM Sterling File Gateway (SFG).

There are some things that, if you do not think about them early in the process of implementing SFG may come back to haunt you because they are difficult and time consuming to change once you go into production. The first subject for consideration is the different possible uses of communities.

Perhaps the most common use of separate communities, and one recommended by IBM Support, is for the separation of partners that are company employees, but do not perform administrative functions in SFG ("internal partners" below), from partners that are not employees of the company ("external partners" below). This can be particularly important in cases where you intend to use the broadcasting function of SFG (i.e. sending the same message to multiple consumers).

There are always going to be files that are fine to send within the company, but which you do not want to send to anyone that is not an employee. It just makes sense to limit the scope for human error in that area by not putting both internal partners and external partners in the same community. It can also make the setting up of adapters easier. For internal partners that are going to be listening consumers (meaning consumers who have files pushed to their server by SFG) , particularly ones inside the same firewalls as SFG, you may want the option of not having to send their files through an external perimeter server. Such setups are easier if you have already separated the partners that can use that option from the ones that cannot into separate communities and so know who they are.

Another common way to separate communities is by the protocols they use. You might choose to have one community limited to partners that are only producers, one for initiating consumers (meaning consumers who go out to their mailbox and pull files from it), one for listening consumers to whom you send files via FTPS, one for listening consumers to whom you send files via SFTP, one for listening consumers to whom you send files via Connect:Direct, etc. One example from a security standpoint that may make the use of such communities worthwhile is that you can create user account groups in SB2BI, put the community members in them, then limit the users who can log in to certain protocol adapters to members of the group that should be using them. Suppose you should happen to have an extended problem with connections that use one protocol at some point in time. If the problem does not affect other protocols, having separated communities of this type helps you quickly identify which partners you need to find workarounds for.

In addition, at the administrative level, if a different person is in charge of each protocol based community, that person is likely to become skilled at the setup more quickly than if they have to learn to set up four or five different protocols. They should also be capable of making better internal documentation on the procedure. Over time, that can help to reduce the amount of time it takes to get a new partner set up.

Similar to the company internal vs. company external distinction, if your SFG is used by multiple divisions of the company and you need to keep files related to different divisions separate, using some communities based on company divisions may assist with that. It will definitely not be the only requirement, though.

Some customers have found it advantageous to separate external partners who are their customers from external partners who are their suppliers by putting them in separate communities.

Some customers have put their key trading partners and/or trading partners for whom the timing and/or order of file routing is critical in a separate community and then assign someone to keep special watch on files from or to partners in that community.  

Many customer have a designated test community used for general planning and testing of new protocols and partners that are not real trading partners. If you have a community named "FOR_TESTING_ONLY", that is a pretty clear sign that there is no need to worry that making a mistake with a partner in that community will affect a real trading partner.

Depending on your business needs, you may want to combine multiple different types of community separation, e.g. have a community that is for external partners that do business with your accounting division, and are listening consumers whom you connect to via the FTPS protocol. That level of granulation is not for everybody, but if you have enough partners on your system, it may be useful.

Another consideration when it comes to creating communities has to do with SFG migration. Even if you are brand new to SFG, it is likely that at some point you will need to migrate to a different server. Migration is done one community at a time. The larger and more diverse a community is, the more scope there is for problems to pop up during the migration process and the greater the number of partners affected may be. If you have say, 20,000 partners, you should not put all of them in a single community even if potential migration issues is the only reason for that. 

There could certainly be considerations as to how to organize your communities other than the few listed here. This is just intended to get you thinking about what the possibilities are. The important thing is to take the time to consider what your business needs are, not only at the moment, but down the road. It makes sense to consider how many SFG partners you plan to eventually have when making decisions about how to organize your communities at the start. That will contribute to setting up your SFG implementation in a way that helps keep things organized and working better as you move forward.