[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Monitoring for errors when providing web services


Please ask about web services on a web list like WEB400 or a general list like at http://forums.iprodeveloper.com/

But to try to be helpful...
You didn't say how you are providing the web service, but in general TCP ensures the communication occurs via acknowledgements. It does not ensure successful receiving by the other party (IE that they did something with the data - only that the data was sent). In the case of timeout or other error, an error should be signaled back to the web services code. In the web services code, there should be try/catch (monitor/on-error) code around all significant attempts and most likely there is logging. So, you should be able to check the logs for dropped connections and unsuccessful parsing/etc.

In the broader scheme...if this is important service, you should setup a service on the outside that will thoroughly test your service and make sure the appropriate response is received. This starts with simple things like being able to resolve the address, pinging the service (if turned on), and finally sending and receiving the "test data" and checking if the correct response is returned. By running this on a schedule and ad-hoc, you can tell if your service is working.

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Kevin Zarboni
Sent: Thursday, September 19, 2013 7:16 AM
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: Monitoring for errors when providing web services

Good morning all,

We have stood up several Web Service Providers on the i5 quite successfully, however from time to time we need to prove that communications errors are not coming from the i5 service.

For example, we get a request, process it and send back a response. How would we determine if the response was not successfully transmitted/received?


Kevin J. Zarboni
Genuine Parts Co
APG IS Development

This is the FTPAPI mailing list.  To unsubscribe, please go to: