Unlocking Progress Webservices: 1
We often need to use Webservices to integrate with the other application. In this blog, I am going to discuss the business problem we faced while integrating with other system using Webservices and the type of solutions we found. Some of the problems were quite weird and their solution were interesting to know.
Requirement was to determine the tax amount on an order. We were facing the following problems:
- Webservice was taking too much time. This was the major problem as we have an incoming order every second and because of the time-consuming Webservice, the unprocessed order backlog was growing. The business was not ready to accept it.
- There were lot of connection time out errors. We asked our network team to look but they said everything was okay. We asked the end point networking team to look at their side and they also said that everything was okay. Business was pressurizing us to find the solution.
- Unexpected session terminate/hang. User session started getting terminated often but not always. The issue was not reproducible in test environment.
We tried various solutions and finally following solutions were most effective:
- Time consuming WebService solution -> Use local schema
A typical web service call looks like the following:
shWebService:CONNECT("-WSDL ":U + + " -nohostverify -clientConnectTimeout 6000":U) NO-ERROR.
We found that every time we were establishing a connection with the service provider, the above way of connecting the WebService was downloading the full schema and hence taking additional time.
Instead, we started using the following URL and the WebService connection became very quick.
shWebService:CONNECT("-WSDL ":U + '/home/wsdl/taxcalcualte.xml -SOAPEndpoint ':U + + " -nohostverify -clientConnectTimeout 6000 ":U) NO-ERROR.
Please note that in modified syntax, we have introduced the -SOAPEndpoint parameter. Using –SOAPEndpoint parameter we start using the pre-downloaded schema at /home/wsdl/taxcalcualte.xml instead of downloading it every time which was totally unnecessary in our business requirement.
I understand that in some of the cases where schema change is frequent, this solution might not be feasible but for our case where schema change is rare, I suggest using this way of calling the WebService.
- Connection timeout error solution -> Add Pause and Retry
Adding a “Pause” and then retry was the option used here. We planned for 3 tries with at least one second pause. It worked for us!!
- Unexpected session terminate/hang solution -> Check memory leakage
Management of memory allocation was the key issue here. If you are facing an issue where the system getting hanged and/or unexpected termination of the session, then it is worth checking the code for undeleted memory allocation. This kind of issue normally goes unnoticed as we often see less load in the test environment. But in production, where the load is many times higher, this undeleted memory accumulates to a sizeable number which causes this kind of issue.
Every solution has its pros and cons. The above solution may or may not be suitable for every related business problem but in case your business requirement allows you the flexibility of implementing the above solution, then I hope this will resolve some of the issues mentioned above.
Stay tuned for the next update in this series!!