Inbound web service troubleshooting
This article describes web service issues and possible solutions.
- Web services are not working
- No response when invoking web service request
- Time out on web service request
- Empty response when making web service request
- Enable debugging properties and verify logs to see if the instance received the request. This also provides some information if the request cannot be parsed.
SOAP debug property : glide.processor.debug.SOAPProcessor
REST debug property : glide.rest.debug
As of the Fuji release, there is no debugging property for JSONv2.
Check various logs provided on the instance, such as Transaction logs, All logs (under System Log), or localhost log files using log file browser, to see if the instance received the request.
- Status codes from web services response.
Response might have a status code other than 200 success. This could provide some information about what happened to the request.
Typical Error codes
400 : Bad request, unparseable, non existing end point, invalid headers
401: UnAuthenticated (Request does not provide proper credentials.)
403: Forbidden (Caller is not authorized to perform the operation.)
500: Internal server error (An error on the server. Check logs to see if you can find more information or exception stack trace.)
- ACLs failures
If you observe something working when using admin credentials, but not with aspecific user, the problem is often with ACLs. There are different ACLs defined to secure the information.
- Processor level ACLs: These are ACLs that are enforced at the processor level - only certain users can access certain processors.
- SOAP Webservice Endpoints: Requires at least one SOAP role (soap, soap_query, soap_create, etc.)
- REST endpoints: Requires rest_service role
- Table and Record level ACLs: There are provisions to define ACLs on table and records. This is something admins usually create to restrict the visibility of data to certain users. Web services honor those ACLs. If you don not receive a response or receive an empty response, it might be that you have access to the endpoint, but not to the particular data you are trying to access.
If you turn on debugging and do not see any requests being logged, it indicates the following:
- The request is not making it out of your network
- Verify the proxy firewall settings of your network. Work with your network team to see if the request is making out of your network. Check the IP information of your instance.
- The connection is failing with handshake failure. This indicates that you need a certificate from ServiceNow instance to be installed on your client side.
- Request reached the instance and is blocked by semaphores lock.
- Look at <instance>/stats.do page to see the semaphores available. If you see there are no semaphores available and every request is failing with timeout, you may have a large set of requests lined up because of some integration to particular web service using all available semaphores. Try to stop the integration and see if semaphores become available. Work with your integration team to send short bursts of requests instead.