Deleting "unneeded" SFG objects? Are you sure they aren't needed?

Body

I have seen a number of customers do one or more of the following things in their SFG setup in an attempt to "simplify" or "clean up" things.

* delete the user accounts for partners that are listening consumers

* delete some user accounts' virtual roots

* change the name of the user account that is associated with an SFG partner

* delete some partners' default mailboxes

At the time, all of these things seemed like a good idea to the person that did them, but they also come with hidden costs.

All of the SFG objects that are created by default are created for a reason, even if the reason is not clear in everyday usage of the partner. Therefore, in determining which partners are "inconsistent", meaning not properly formed, and which ones are "consistent", meaning well formed, certain standards are in place. Those standards include that partners will have virtual roots,  user accounts, certain mailboxes, and that the user accounts will be the original user accounts. Doing the above listed things to a partner will make it inconsistent.

Depending on what exactly is done, for each of the things listed above, the partner may continue to function in relation to file routing on a daily basis, so it may not seem like anything that will harm the partner has been done.

The hidden costs come into play in the future, when it is time to migrate communities to a different instance on a different machine. There is a tool for SB2BI named "sfgdbcheck". In all but versions of SFG that are now very old, a file named sfgdbcheck.sh will exist in the bin directory at installation on instances using a Linux operating system and a file named sfgdbcheck.cmd will exist in the bin directory at installation on instances using a Windows operating system. It is the tool used to identify which partners are inconsistent.

On newer versions of SFG, there is a property named "allowInconsistentPartnerExport" in the filegateway.properties file, which is located in the /<install>/properties directory, and its default setting is "false". That means that when you go to export a SFG community for migration, any partners that are inconsistent will NOT  be exported. That default was put in place to prevent the migration of inconsistent partners from old instances to new ones.

Now, suppose that a high percentage of your SFG partners are listening consumers, and you have deleted all of their user accounts from the dashboard. That will mean a whole lot of work to fix them when you want to migrate the communities that they are members of. Alternatively, you have to change the property's setting to "true" and stop and restart SB2BI, but doing that will leave you open to the possibility of importing inconsistent partners that you are not aware of to your new instance.

In the long run, it just is not worth it to try to "simplify" or "clean up" your SFG partners by changing things that were not designed to be changed. As a rule of thumb, anything that you cannot change from the SFG administrative menu is something that you probably should not change unless you are doing so under the supervision of IBM Support.