Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Improve doHTTPRequest Method (ScriptLibrary)

Improve doHTTPRequest Method (ScriptLibrary)

Related: https://community.softwaregrp.com/t5/SMA-Idea-Exchange/SM-functions-in-JavaScript-need-to-follow-JS-exception-model/idi-p/1661109

Details

Currently the doHTTPRequest method that can be used in ScriptLibraries has several flaws that make it difficult to use with modern web services. The biggest issues are:

  1. doHTTPRequest throws a hard error when returning any non-200 OK response. This error cannot be suppressed in any way. (try, catch, etc. do not work). The default error message on failure cannot be changed. This can result in URL's being passed back to the end-user that we may not want to make easily accessible to general users.
  2. doHTTPRequest does not return a response body when a non-200 OK response is given. This makes it impossible to read useful information that may be returned in soft-fails caused by bad data. Most modern web services today return the data that was bad and info on how to fix the data.
  3. doHTTPRequest seems to ignore the timeout related fields and, still takes RTE / Tomcat timeouts into consideration. Meaning even if you set a timeout to occur after 1 second, the method will continue to wait for an additional 10 seconds (depending on how your tomcat is configured).

 

Scenario

Anytime doHTTPRequest is called and there is a soft-fail such as bad data, which results in various return codes such as 401, 403, etc as well as anytime there is a hard failure (failure to connect, etc.)

 

Workaround

There is no workaround that I'm aware of. We have to display default error messages to end-users with no ability to read into the error or strip REST API URL's. Timeouts are not honored regardless of what integer values we provide.

 

Unacceptable

Modern web services often return a message body containing information relevant to the specific error code (401, 403, etc.) -- it's unacceptable that we cannot consume and utilize this information to provide meaningful non-technical information to our end-users. Without the ability to adjust timeouts or change the default message, when something goes wrong, errors are usually very technical, contain API URL's and, are not displayed timely enough.

 

Required
doHTTPRequest returns a message body if one is provided for non-200 OK responses. Timeout parameters are honored exactly to the integer provided. Default error messages can be overridden so that non-technical and user friendly information can be provided to the end-user on what happened and what can be done to fix the issue.

1 Comment
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
Status changed to: Waiting for Votes
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.