IBM Sterling Ideas

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Post your ideas

IBM is transforming its request for enhancement (RFE) process. The purpose of the transformation is to provide a more consistent experience for you to submit requests and to enable IBM product owners to respond to your requests more quickly. For more information click here.

Start by posting ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
1. Post an idea
2. Upvote ideas that matter most to you
3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The offering manager team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notifications on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

SFTP Client Adapter “ResponseTimeout” setting does not have the desired effect causing hung BP activity

SFTP Client Adapter “ResponseTimeout” setting does not have the desired effect causing hung BP activity

Documentation Reference Links for B2BI 5.2.x/6.0.3/6.1.0:

https://www.ibm.com/support/knowledgecenter/SS3JSW_5.2.0/com.ibm.help.svcs_adpts_m_z.doc/SFTP_Client_CD_svc.html

https://www.ibm.com/support/knowledgecenter/SS3JSW_6.0.3/integrating/integrating/integrator/SFTP_Client_CD_svc.html

https://www.ibm.com/support/knowledgecenter/SS3JSW_6.1.0/integrating/integrating/integrator/SFTP_Client_CD_svc.html

Based on the published documentation for the SFTP Client construct there is a default ResponseTimeout value defined within the SFTP Begin Session service by which this timeout length can be overridden during certain SFTP operations. In our Technical Support Case TS004564739 we specifically call out the issue around the Change Directory function, though the same "ResponseTimeout" facility is present in SFTP CD/LIST/PUT/GET/DELETE/CHMOD/etc. operations as well and is similarly affected/ignored.

The B2BI documentation states repeatedly, across multiple SFTP operations under the different B2BI versions:

ResponseTimeout The maximum number of seconds it can take for the trading partner system to respond before the session times out and terminates. If a number less than 30 is specified, 30 seconds will be used. Optional. Default is ResponseTimeout specified in SFTP Client Begin Session service.

PROBLEM SUMMARY:

The SFTP Client Adapter “ResponseTimeout” setting does not have the desired effect in most SFTP Client Adapter operations. Arguably this is a bug, however we have been instructed by IBM Support to file this as a Request For Enhancement (RFE) as well. This unexpected and undesirable behavior of mishandling of the ResponseTimeout causes business processes to hang and queue depth to grow for each missed timeout.

BACKGROUND DETAIL:

Based on the above description of "ResponseTimeout" it should be reasonable to deduce and expect that the “response” timeout would be experienced if the remote SFTP server was unable to initiate and/or complete the requested operation. Given an example of a short or quick operation like change directory, chmod, move, etc. one would normally expect a “response” timeout should be reflective of the actual operation completion within a reasonable amount of time. However, that is not the case. What was even more unexpected was that we were told by IBM support that the ResponseTimeout value does not exhibit this expected behavior.

Under certain conditions, network failures, or during other unusual circumstances, operations like change directory could potentially take much longer than the response timeout value, which would be undesirable. In our example documented within the technical support case, due to unexpected back-end network issues on a remote SFTP server, we were experiencing numerous instances of change directory operations that were holding up business processing for multiple hours at a time. We found the SFTP Client Adapter and its CD operation specifically are not honoring the “response timeout” setting. The remote server did not respond with “change directory complete” in a timely fashion, and the business processes became effectively hung at that point in time, and BP Queue Depth increased for every file being sent across the connection to the server with the issue.

One would think it should also be reasonable to assume that while an entire “PUT”, “GET” or “LIST” longer running operation (start to finish) where data/file is actively being transferred, may not complete within the response timeout timeframe but that the session would remain alive and active since regular responses are received as long as data is being transmitted and acknowledged and there should be data consistently being exchanged until the transfer/operation itself completed. The response timeout counter in these cases should be consistently reset while data is still flowing through the connection considering those as active server responses.

The SFTP Client Adapter ResponseTimeout value should be handled more appropriately.

See also: https://watsonsupplychain.ideas.aha.io/ideas/B2BI-I-803

  • Guest
  • Dec 3 2020
  • Is a defect
What is your industry? Insurance
How will this idea be used?

The SFTP Client Adapter "ReponseTimeout" should be honored and executed upon for short operations like Change Directory, Move, Chmod, etc. in such a way that IF the required operation does not complete within the defined ResponseTimeout period, the Business Process should immediately fail and move to execute the appropriate "On Fault" clause upon reaching the operational timeout value where a timely response is not received from the server. This will keep Business Processes from spooling up unnecessarily and will keep BP Queue Depths to reasonable numbers even when a remote server has back-end connectivity issues.

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.