Why does Support need that when -- analyzing problems sending SFTP and FTP

Body

With my last blog entry I wrote about the reasons why an IBM support analyst would request particular data for an issue when sending HTTP or AS2 data.

Today I'd like to go on with an outline of why we request particular data when we're investigating an outbound SFTP issue, where you are trying to send data to someone using the FTP or SFTP protocol.

I understand how frustrating it is to be asked to send the amount of data I request. It's a lot of data and it takes time and effort to get it all. However, I don't ask for anything but what I will actually use. I will read all of it, and it will usually help me a lot to understand what's happening and how to help you to fix it.

When someone tells me they cannot send data using FTP or SFTP I ask for a set of details, as follows:

Note: I used SFTP for my examples. Though FTP is a completely different protocol, the logging and BPs are very similar.

I ask for general information to outline the problem. Is it a new configuration, or one that worked but then stopped? If it used to work, then it has to have stopped because something changed. The focus will be to find out what that is, and to do what's needed to correct it.

I ask if it affects all partners, because that defines the scope of the problem. It can also pinpoint the source. If a problem occurs for one partner, it might be an error on the partner's system. If it's more than one, it's pretty sure to be an issue within Sterling b2B Integrator.

I ask if it happens every time or if it is intermittent. If it is intermittent, there's a difference between the occurrences that work and those that do not. In order to establish a pattern to help determine what those differences are, I will want to know how often the problem occurs. I will want to know what times, and whether it always occurs on one node. I'll want to ask whether other events were happening such as heavy traffic from partners or system activity such as backups. I'll ask anything I can think of that distinguishes the errors from events that work correctly.

I also ask for some data that's specifically for FTP or SFTP issues.

1) Output from dump_info.sh or dump_info.cmd: My colleague Dana explained why we ask for this. I have nothing to add to her explanation, which is here:

https://www-304.ibm.com/connections/blogs/SterlingB2B/entry/why_does_ibm_ask_for_your_dump_info?lang=en_us

2) Screen prints showing all of the steps of an example of the workflow that failed. I ask for the header information as well, such as this:

The header information is the "Business Process Detail" part at the top. It has the name of the process, SFTP_List_With_Loop, the instance ID, status, and state.

I then ask further for the text of the status report and instance data from the first line that fails. Those are contained in the 1^st and 3^rd "info" buttons on step 1.

Here's the status report:

SFTPClientBeginSession failed.

Error Message = [Unknown host: oxcart: oxcart]

SFTPClientAdapter=[SFTPClientAdapter]

ServiceStartTime =[2016-03-24 12:58:50.644]

ServiceEndTime = [2016-03-24 12:58:50.745]

Time taken to complete the Service is 0.101 Seconds

SessionToken=[SFTPClientAdapter_SFTPClientAdapter_node1_14588387306441005:259]

It shows the EXACT time when the error occurred, and also gives more information about the error. It confirms the Instance ID. It also shows the SessionToken. The instance ID and SessionToken are included in the log files, so this information helps to determine what entries we should focus on in the logs.

3) The full log files from your SI/install/logs directory from the node where the error occurred, as follows:

sftpclient.log

Perimeter.log

If you look for those files in the SI/install/log directory, just from the names you can see a lot of information:

-rw-r--r-- 1 jperry users 1014 Mar 24 13:17 sftpclient.log.D20160324.T004707

-rw-r--r-- 1 jperry users 2540348 Mar 24 13:25 Perimeter.log.D20160324.T000519

The date and time are when the files were last updated.

The names of the files include the date and time when the file was created:

Httpclient.log was created on Date 20160324(which is March 24, 2016)

And at Time 004707, or 00:47:07 in 24 hour time. That's 12:47 AM.

Sometimes people will download these files, then copy the contents into a graphics-oriented word processor like Microsoft Word, and change the names. Then we lose all of the information that was present in the original file names. That's why I always ask for the files with their original names.

3b) If possible, we ask for a new test with the log in full debug mode. To get that information you would first go to Operations > System > Logs, and locate the log, then click on the icon to the left of the log.

Scroll down until you see the log that is being discussed:

Then click on the icon to the far left, and select Logging Level of "On":

For the Perimeter.log, the Logging Level can be set to Error (it's lowest setting), or Info, Communicatiuon Trace, or All. An analyst wants all of the data they can get so will almost always request the Logging Level to be set to "All".

The Logging Level refers to the debug setting for log information. A log with a Logging Level of "All" or "On" will generate a LOT more information.

You are welcome to review the logging information yourself, and to ask questions when you discuss your issue with an analyst. We probably cannot explain everything there is to know about your logs! We can try to help you to see what details we find useful.

4) For all SFTP client issues: The business process itself.

Your business processes will be custom creations. We aren't familiar with them. It's possible the process itself is causing a mistake. If so, we can analyze it and try to make suggestions. We can also install your process on a test server, modify it to work, and run tests using it.

5) The SSH Remote Profile (for SFTP)

You may have used a profile for your client information. If so, the BP may not have all of the details for your client configuration. If you go to Trading Partner > SSH > Remote Profile, and do a search, you will see your SSH profiles that are used for SFTP client connections. Click on the underlined name of the one you are using, and send a screen print showing all of the information that it contains.

For FTP Client Profile (for FTP):

If you used a profile for FTP, it is found under Trading Partner > Setup > Advanced > Profiles. Please search your protocols, click on the underlined name, and send a screen print showing all of the information it contains.

All of this information is part of the problem description. There may very well be more items that I (or another analyst) will ask you to provide. Our goal is only to understand what is happening and why, so we can help you to come to a successful resolution.

If you have any questions about this information, please add comments. I am happy to have suggestions too!