File Gateway Preliminary Decisions - Naming Routing Channel Templates

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 the naming of routing channel templates (RCTs), and is intended as a guide to the planning your naming rules. 

When you click Routes > Templates in the SFG menu, the screen defaults to the Type tab of the new RCT. At that top of the screen, there is a field titled "Template Name". When you begin to type, you will see a message that reads "Template name. Name for the new routing channel template. Must not begin with AFT, FG, or File Gateway. The only valid characters are alphanumeric, underscore, and space." Here are some things to think about with regard to naming SFG RCTs.

The majority of SFG setups I have seen have at least 10-15 RCTs created, and many have dozens. The use of naming rules for RCTs may not be all that important in cases where you can see all of your RCT names on a single screen. However, once you get to multiple screens, having naming conventions can really help.

Imagine you have 50 RCTs in use already and you are onboarding a new partner. If you have no naming rules for the RCTs, how much time would it take to go through the list to decide whether you can use an existing RCT for the new partner or if you need to create a new one? Depending on the frequency with which you have to create new partners, having a naming system in place for your RCTs can save a lot of time spent searching down the road. A good RCT name should give a searcher a good idea of what it is used for. That may include some of the following characteristics. The name might indicate:

* whether it is a static or dynamic RCT.
* if dynamic, how the consumer is identified (e.g. "BP_IDs_Cons" or "FN_IDs_Cons" which could be short for "a business process identifies the consumer" and "the file name content identifies the consumer", respectively)
* indicate whether it is for use in testing or production (This may be unnecessary if testing and production are always done on different instances of SFG.)
* indicate the types of file layers it uses. (e.g. includes something like "UNKtoZIP" to indicate that the producer will send a file of type "unknown" while the consumer will receive a zip file.)
* indicate if it uses a custom file layer, and if so, name it
* give the producer's name or code if only one producer will use it
* give the consumer's name or code if only one consumer will use it
* indicate if it is used for a broadcast message
* indicate, when applicable, whether it is for only company internal consumers or only company external consumers
* indicate that only certain partner groups' members can it

The above is not an exhaustive list. Your company may need to make distinctions that are not listed here.

Suppose you want to create an RTC that has the following characteristics:
It is static.
It is for production files
It is used to decrypt PGP files to the "unknown" type
It is only used for the producer with partner code ABC123.
It only goes to company internal consumers.

You might choose a name like the following for the RCT:

STAT_PROD_ABC123producer_PGPtoUNK_InternalConsumers

As long as the rules are clear to the SFG administrative users, the abbreviations used can be even shorter than in this example. Also, it is not necessary to use the order of the elements that this example uses. If the most important thing to your company is the producer's name, then that should probably be the first element in the names of RCTs. On the other hand, if the most important thing is whether the RCT is for company internal or external use, then that should be first.  

You certainly do not need to use every one of the characteristics listed above. Pick and choose what your company needs to use in order to make searching for routing channel templates a less time consuming task.