As highlighted in What’s New for Developers in Istanbul - Integrations, APIs, Authentication, the Istanbul release introduced Outbound Web Services Logging. This feature is a major quality-of-life enhancement for anyone working with integrations, and some potential benefits include:
- Write fewer gs.debug/log/info/etc. statements in your code and simplify the debugging process
- Quickly pinpoint the source of an outbound HTTP request
- Look at the history of requests made by a particular integration
- Analyze the volume of requests made by a particular integration
What gets logged?
Outbound SOAP and REST requests are logged, as well as requests made using the GlideHTTPRequest and GlideHTTPClient APIs.
Viewing the Request Log
The quickest way to get started is to go view some logs. There is a new module under System Logs named Outbound HTTP Requests. Clicking this module will open the list of recent Outbound HTTP Logs.
Each log entry indicates when the request was sent, the HTTP Method and URL, Response status and time, and a series of Form Sections / Tabs with additional detail that may be populated depending on the Log Level (more on this in a minute).
The Source section will attempt to show where the request originated. For example, if the request was initiated by a UI Action, the Source table will be populated with UI Action [sys_ui_action] and the Source record ID will contain the actual UI Action that triggered the request. This is extremely helpful if you’re trying to figure out what is triggering an outbound call. There are additional fields to help track down the source of a request such as the Application scope, Transaction name, the User that initiated the transaction and others.
The Request section includes details about the outbound request depending on log level. In this example, the request headers and truncated JSON request body are shown.
The Response section includes details about the response, again depending on the configured log level.
I’ve mentioned Log Levels a few times, so let’s take a look at how you can use them. Log Levels control the level of detail included in each log entry. By default, a basic level of detail will be logged. For a full list of logged attributes, see this page on the documentation site. You also have the option to set elevated and all log levels.
Elevated includes everything logged by basic plus:
- Request headers
- Request query
- Response headers
All includes everything logged by basic and elevated plus:
- Request body
- Response body
Setting Log Levels
There are several ways to set log levels.
From a REST Method form
REST HTTP Method and SOAP Message forms now include a Set HTTP Log Level Related Link. Clicking this opens a dialog that allows you to select the desired log level for that Method or Message.
Directly in code
The RESTMessageV2 and SOAPMessageV2 APIs now provide a setLogLevel(level) method that accepts one of three values: basic, elevated, or all. This can be used when constructing an HTTP call from either API, and here’s a quick example of what this might look like for a RESTMessageV2 call.
var rm = new sn_ws.RESTMessageV2(); // Set the log level rm.setLogLevel(‘all’); // The rest is up to you…
By setting a system property
If you’d like to set http log levels system-wide, you can do so by setting the following properties:
- glide.outbound_http_log.override: set to true
- glide.outbound_http_log.override.level: set to basic, elevated, or all
Use these properties with care, and use request/method-level options for setting log levels when possible.
Viewing a list of log levels configured for HTTP messages
You can view a list of configured log levels by navigating to System Web Services > Outbound > HTTP Log Levels. This will take you to a list of log level settings associated with specific HTTP messages (SOAP or REST).
If desired, you can restrict outbound logging to basic-level logging for specific domains. This is achieved by creating an Outbound HTTP Log Domain Blacklist record. This may be useful if sensitive data will be passed to an external API and you want to prevent that data from showing up in log entries. See Docs: Outbound request logging blacklist for more information.