Is it time to adjust your SFG partner and SFG administrative account deletion process?

Body

This has come up multiple times in the past month, so I think it is time to address this here. We have a lot of IBM Sterling File Gateway (SFG) customers who are lacking a certain best practice that is related to deleting SFG partners and administrative accounts (meaning the accounts of company internal SFG architects, operators, route provisioners or SFG sys_admins) who have transferred to another job or left the company. I will refer to all the company internal administrative SFG users as "CIUs" in the rest of this blog entry.

The particular thing I want to bring up is the failure to make sure that you delete any subscriptions that such accounts have made to event notifications prior to deleting the account itself. Some people may assume that would already be included in the partner or account deletion routine, but at the current time, it is not.

Why would you bother make sure to delete the subscriptions? The primary reason is to make sure that your filegateway log does not become clogged with errors that result from the failure to do so. Once a partner or CIU account has been deleted without first deleting the event notification subscriptions, multiple lines of errors will be  generated in the filegateway log each time that an event that the deleted user had subscribed to occurs. For any one account, that may not make a big difference, but as you delete more and more partners and CIUs over time, you may end up with literally thousands of lines of errors in the log daily. As anyone who has spent time combing logs for errors knows, it is no fun in the best of circumstances, but having to find the one error you need to find for an issue when there are 2000 errors in the log and the other 1999 are there because of this situation is just painful.   

Other reasons for doing this include avoiding wasting resources/capacity doing unnecessary processing. That includes such things as saving storage space used for unnecessarily large log files, and reducing  the load on the CPU. Also, it is good to avoid leaving orphan records in the database.

This is usually a bigger issue for CIUs than for partners, because CIUs are subscribing to all partners when they subscribe to a certain event, and those routes will not stop happening when the CIU's account is deleted. In contrast, it should usually be the case that if a SFG partner stops doing business with you, they stop attempting to route files. So, for partners, it is less likely that you will see ongoing errors of this type.

Removing event notification subscriptions is fairly easy if the partner or CIU account has not yet been deleted. The steps are as follows:

1. Unless you know the user's password, go into User Accounts in the dashboard and change it. (As necessary, you may need to ask someone with
fg_sysadmin level permissions to do that.)
2. If the type of object to delete is a partner, log into myfilegateway as the partner using their user account and the password. For CIUs, log into filegateway as the CIU.
3. Click Profile in the top menu (white letters in the blue bar). That changes the window content. All of the events that the partner or CIU is subscribed to will appear in the Subscribed Notifications box on the right side of the screen.
4. Highlight the top item in the list.
5. Press and hold the Shift key, then click the bottom item in the list in order to highlight all of the items..
6. Click the Delete button just below the Subscribed Notifications box.
7. When the deletion is finished, use your existing process to delete the partner or CIU.

If you are getting errors generated for an account that has already been deleted, the process is more complicated. You have to recreate the account, then do the above steps, and then delete the account again. For SFG partners, you can change the partner name, but the account name of the new partner needs to be the original account name that appears in the error message in the log.  Also, it  has to use the same authentication type (local or external) as it originally did or you will get an error when trying to create it. I recommend that you just make the new partner, since it is only temporary, an initiating consumer. There is no sense setting the partner up with a listening protocol that requires you to fill in more fields since you will only be using the partner for a few minutes before deleting it.  

It should also be kept in mind that for CIUs and partners, if they are recreated at a time when the volume of files being routed is high, it could potentially trigger a lot of emails being routed. Prior to doing the deletion, you may want to consider asking the administrator of the server that SB2BI uses to send email notifications to give you access to an email address that points to a "dead letter" mailbox for this, so the emails will not go out. If you do that, remember to use the "dead letter" email address rather than the original email address in recreating the CIU account or partner.