Help us help you.

Body

Every day, we in IBM Support are working with customers to help them solve their problems. There are occasions, however, when the problem is not with our
product, even though the symptoms may make it look that way. I am going to bring up a few examples of issues I have worked on or heard about from colleagues.

I recently was on a call for a routine, known issue. We needed to adjust a setting in a property file for that issue, then stop and restart IBM Sterling B2B Integrator (SB2BI below) in order to make the new setting active. The real problem occurred after we stopped the application, because we could not restart it.

The symptoms did not seem to make sense. The logs indicated that some files necessary to the startup process could not be created, even though the ID the customer was logged in as, and was attempting to do the startup with, was an administrator on the machine.

It turned out that the evening before, some new virus definitions for the anti-virus software had been added, and those blocked certain file naming formats. A couple of our files had names that fit those formats, and were therefore blocked from being created. Once those definitions were "suspended", everything returned to normal, and there was no problem starting SB2BI.

A problem that I have seen a number of times has to do with load balancers. This can be a tricky area, because the support for SB2BI does not include support of load balancers themselves.

It is not unusual for customers to open PMRs with IBM Support saying that they have an issue with their communication sessions where the clients are not reaching their server, or connections are made, but then dropped.  

Once we are made aware that the path that the sessions take goes through a load balancer, we should always ask if the load balancer is configured for
"sticky sessions" (this may alternatively be referred to as "persistence", "server affinity" or "sticky cookies" among other terms). If it is not, we will request that the settings to make it so be changed, and that will often resolve the problem.

Also, whenever possible, we should request that a test be run to go directly to the server rather than through a load balancer. If the same issue shows up when the load balancer has been taken out of the equation, then it is likely an issue with SB2BI, but if the issue disappears, it is likely that there is an issue with the load balancer's configuration.   

Another problem that I recently heard about occurred with a customer that had SB2BI and the database on different machines. Someone at the customer site had
mistakenly changed the permissions on the database machine for the ID that was used to initiate SB2BI's connection to the database. The ID no longer had
write or update  permissions, only read permissions. Needless to say, that caused some problems.

Most issues that at first glance appear to be an SB2BI problem, but turn out not to be, have certain things in common. These things tend to be related to
separation of duties. For example, one of those things is that the person in charge of SB2BI at the customer site, is not the database administrator (DBA),
and there are not processes in place to make sure that the DBA can be engaged quickly when necessary.

In the first issue mentioned above, it was lucky that the person who had done the anti-virus definition updates was also on the customer's Network Support
Team and recognized what was going on.

In the load balancer example above, I have seen few cases where the person in charge of SB2BI is also in charge of the load balancers, but I have seen
several cases where the person in charge of SB2BI did not know who was in charge of the load balancers and had to find out after the problem was
occurring.

If you are in charge of SB2BI at your company, it can help a lot if you know who the person in charge of the following items is, if it is not you, and how
to get hold of that person quickly:

* the system administrator of the server that SB2BI is loaded on
* the DBA
* network settings (network administrator)
* firewall
* anti-virus software
* load balancers
* administrators of machines used as external perimeter servers.

It is also a good idea to know at least one backup person for each of those areas and how to get hold of the backup quickly.

The last point I want to make in this entry can be summed up as "Communication, communication, communication". Are you informed ahead of time
when things like the items in the below list occur?

* operating system updates or an upgrade is applied to the SB2BI machine
* new anti-virus software or urgent virus definition updates are applied
* load balancer configuration changes are made
* firewall settings are changed
* external perimeter server machines are going to be turned off for
maintenance
* network routing to and/or from the SB2BI machine is changed
* the person in charge of the areas mentioned above is about to leave your
company or has just left

The SB2BI Support Team is always here to help if you need us. Please do not hesitate to open a PMR when you see issues with SB2BI. We ask that you keep in
mind that an awareness of the items mentioned above can help us help you.