High-Level Analysis of the transaction (Debugging)

In addition to using the Activity-Log policy for debugging purposes, a more indepth look into the transaction may be conducted on the syslogs and probe on the DataPower Gateway. You will not have access to the DataPower Gateway on Bluemix, therefore this section only applies to the on-prem environment.

The syslog and probe for the API calls will be found in the APIC generated domain on DataPower.

If you have multiple DataPower domains on a system, you may find the APIC generated ID from the CMC Services, listed in the DataPower Service section under DataPower Domain:

Debug Logs (syslogs)

WARNING

• The syslog level is defaulted to warning level for APIC generated domains. 
• The syslog file itself is titled default-log, and the name of rotated files are as follows: default-log.1, default-log.2, and default-log.3 (log rolls every 500KBs).
• The syslog is written to the logtemp directory of the File Management, therefore you may view the raw logs from the logtemp, or through a visual friendly parsed System Logs section of the DataPower WebUI:

• Setting the log level is in the Troubleshooting section of the webui. You will want to set this to Debug log level when debugging.

Most error transactions will not include the transaction ID, therefore, to narrow down the error, you must cross-reference the URI of the call, the time of when the error took place, and any other key indicators from the API.

The start of the transaction will acknowledge that DataPower recieved the transaction.

The syslog includes the datetime, the event ID, the service object type, the log level, protocol, transaction ID, client IP, and log message, as shown below. The example below is the last transaction from API created in this tutorial.

20170531T024253.740Z [0x80e0013a][mpgw][info] source-https(webapi-https): tid(36981154)[192.168.88.1]: Received HTTP/1.1 GET for /demo/sb/myloopbackapi from 192.168.88.1

Once the desired log details are found, the transaction ID may be cross-referenced for all the logs that belong to the particular transaction which you are debugging.

At debug level, the syslogs contain over 300 lines of debug details, therefore we wil not be looking at the full logs, although, to note that each log detail walks through each processing step throughout the APIC framework on the gateway, therefore, when an error is thrown, it is a good indicator of where to debug.

The Probe

WARNING: Probes may impact performance, therefore, it should be avoided in production.

• The Probe can be enabled in each gateway object, but the Troubleshooting section contains consolidated Probes you can enable/disable under the Debug Probe tab.

The probes will be rarely used for APIC work, unless there are deeper DataPower development work done such as building User-Defined Policies or Extensions.

The probe would be used mostly when APIC developers would like to leverage DataPower variables which may not be exposed for APIC, to verify that the context variables are being set properly, verify headers, troubleshoot DataPower extension variables, and/or etc.

By expanding the one transaction line item in the probe shown in the figure above, you will see that there are several calls made to process the request and response. The developer can see each step of the call, action to action.

The figure in this section shows a sample of analyzing the request transaction in one spot of DataPower as it traverses through the gateway:
1. Expansion of the transaction to see all the processing rules
2. Selection of the rule right before the response
3. Selection of the final action taken of this particular rule
4. and view of DataPower context variables used and/or can be used in this request alone.

From the same screen as shown in the figure above, the APIC developer will be able to scroll down to find the “var://context/_apimgmt/readContext” variable to see what APIC context variables are being set  (after clicking show node to open the page). All these variables are listed in the API Connect context variable knowledge center page.

The APIC developer may also see the headers and response body of the transaction.

The take-away from this section is, the APIC developer can set and get variables from the system memory and leverage them for custom code, view headers for the transaction, the body of the message, and/or analyze the request for any additional errors which the error logs may not output.

Most of the time, leveraging the syslogs are enough for debugging.