Salesforce B2C Commerce 24.7 > Developing Your Site > Web Services

Web Service Logging and Troubleshooting

You can view generated logs by navigating in Business Manager to Administration > Site Development and clicking the link for Log files.

The log file name for a web service always starts with "service" then the log prefix set in the web service profile, and then internal information. For example: service-logprefix-blade2-4-appserver-20150206.log.

Salesforce B2C Commerce logs messages to a custom log category with the following format:

service.serviceName.type

Type is one of the following:

head: After every service call, logs a message indicating success or failure.
comm: After every service call, logs data passed to the underlying transport and the response received from it. Communication logs are disabled by default and log at the INFO level when enabled. This means in order to see communication logs, a service must have its Communication Log Enabled box checked and its log level must be info or debug.

The comm logging is filtered to prevent sensitive data from being accidentally logged on a Production instance. The logging of filtered data is possible, but only by enabling communication logging for the service and also applying the filterLogMessage function or applying both the getRequestLogMessage and getResponseLogMessage functions in the service initialization. Importing a service definition with communication logging enabled on a Production system doesn't enable this logging and throws a warning message in the import log indicating that communication logging is disabled. This is a fail-safe to prevent accidentally enabling communication logging that could contain sensitive data. You can force non-production instances to behave like production instances by checking the Force PRD behavior in non-PRD environments box.
log: Logs miscellaneous messages, such as service initialization and error traces

For example, given three services: mycartridge.http.payment.list, mycartridge.http.payment.get, and mycartridge.ftp.getPriceList; this creates the following logging structure:

service
  .mycartridge
    .ftp
      .getPriceList
          .comm
          .head
          .log
   .http
      .payment
          .get
             .comm
             .head
             .log
          .list
             .comm
             .head
             .log

Note: Although they are created and managed in the same place, unlike custom logs, these logs don't count toward the quota.

Setting Log Levels

Log levels are adjusted in Administration > Operations > Custom Log Settings.

Note: If a logging category doesn't have a log level specified, it inherits its parent log levels. This allows groups of services to have their logging enabled/disabled at the same time.

For example: for the services described above, you might create the following log categories.

Warn

Enable	Log Category
	services
✔	mycartridge.service.ftp

Info

Enable	Log Category
	mycartridge.service.http.payment
✔	mycartridge.service.http.payment.list

Debug

Enable	Log Category
✔	mycartridge.service.http.payment.get
✔	mycartridge.service.http.payment.list.log

In this example, everything in the services.ftp category is set to the warning log level, so comm logs are not generated for the mycartridge.ftp.getPriceList service. The mycartridge.http.payment.get category generates head, comm, and log logs with debug level logging. The mycartridge.http.payment.list category generates head and comm logs with info level logging and a log log with debug level logging.

Filtering Logs

You might need to filter sensitive or private data, such as credit card numbers, so that it's not logged. You can do this in two ways:

Example 1: Filter a System-Provided Log Message

This example shows how to add a filterLogMessage callback to the service definition to filter log messages.

ServiceRegistry.configure("my.service", {
    createRequest: ...,
    parseResponse: ...,
    filterLogMessage: function(msg:String): {
        return msg.replace(/CreditCardNo\: \".*?\"/, "CreditCardNo:********");
    }
});

Example 2: let the ServiceCallback provide the log message

This example shows how to capture log messages using getRequestLogMessage, convert them to log messages and filter or edit them.

ServiceRegistry.configure("my.service", {
    createRequest: ...,
    parseResponse: ...,
    getRequestLogMessage: function(reqObj:Object): {
        // Convert to a String here, doing any filtering...
        return msg;
    },
    getResponseLogMessage: function(respObj:Object): {
        // Convert to a String here, doing any filtering...
        return msg;
    }
});

Web service response Examples

This section shows typical responses from a simple web service.

Using HTTPResult as an example (all other result objects for other service types follow the same schema):

for a Simple HTTP GET Request That Was Successful, You Get Back:

[ error=0, errorMessage=null, mockResult=false, msg=OK, object=<html>…</html>, ok=true, status=OK ]

for a Simple HTTP GET Request That Failed, You Get Back:

[ error=500, errorMessage=null, mockResult=false, msg=INTERNAL SERVER ERROR, object=null, ok=false, status=ERROR ]

for a Simple HTTP GET Request That Failed Due to 404, You Get Back:

[ error=404, errorMessage=null, mockResult=false, msg=NOT FOUND, object=null, ok=false, status=ERROR ]

When You Hit the Rate Limit, You Get Back:

[ error=0, errorMessage=Rate Limit Exceeded, mockResult=false, msg=null, object=null, ok=false, status=SERVICE_UNAVAILABLE ]

When You Hit the Circuit Breaker, You Get Back:

[ error=0, errorMessage=Failure Count Exceeded, mockResult=false, msg=null, object=null, ok=false, status=SERVICE_UNAVAILABLE ]

When You Hit the Timeout, You Get Back:

[ error=0, errorMessage=SocketTimeoutException:Read timed out, mockResult=false, msg=Read timed out, object=null, ok=false, status=SERVICE_UNAVAILABLE ]

Troubleshooting Web Services

In Business Manager:

make sure the cartridge containing your script is in the cartridge path.
make sure that the web service is enabled.
make sure that the web service is set to Live and not Mocked.

In UX Studio:

make sure that you point to your initialization script in your package.json.
make sure that your initialization script has a service definition for your web service.
make sure that your service definition includes callback objects that handle the web service response.
make sure that you have written a script that calls your web service
Make sure that your web service is available.