Application Logging in ABAP SDK for Google Cloud

devesh-sapcloud · ‎10-31-2023

ABAP SDK for Google Cloud, is a Google Cloud product that enables native bi-directional and real-time integration between SAP Applications and Google’s services. The SDK abstracts the complexities of integration with Google’s services through ABAP class based “𝐀𝐏𝐈 𝐬𝐭𝐮𝐛𝐬” and provides a “Single window of interaction” for SAP developers. With the ABAP SDK, customers can accelerate their digital transformation and achieve business goals faster.

ABAP SDK for Google Cloud has a robust “Application Logging” module built in as a core foundation component to handle any errors/exceptions that can occur while calling the API stubs.

This blog post elaborates on how “Application Logging” is enabled in ABAP SDK for Google Cloud and the opportunities that SAP developers have to adjust and utilise it as per their use case demands. Application logging in the SDK is based on SAP standard artifacts which is a familiar paradigm for SAP developers and in line with the concept of “subconscious programming” of hiding the complex underlying features related to application logging in SAP.

Application Logging in ABAP SDK for Google Cloud

Generally application logging in SAP is achieved through “SAP Business Application Logging” (BAL), which technically is a boilerplate logic of calling a set of standard BAL function modules one by one in a sequence. This boilerplate logic is repetitive if logging is to be achieved at more than one place.

Application logging in ABAP SDK for Google Cloud is enabled in a way to avoid the boilerplate logic and log errors/exceptions through “API-like” calls. Class “/GOOG/CL_LOGGER” enables this api call based “Logging Framework” and is embedded as a foundation component within the SDK.

The logs capture the points of errors and failure during the execution of the foundation components and enable troubleshooting of the errors and exceptions occurring during the execution.

Application logging in SDK is designed to log below types of messages.

Error messages for local validation errors in the SDK foundation components — denoted by error code “461”.
Error messages for error responses while making the API call — denoted by the standard HTTP Status Codes.
API stub name in which the error occurred to have visibility on point of error during troubleshooting.

Log Configuration Table

Application logging in ABAP SDK for Google Cloud is driven by a log configuration table “/GOOG/LOG_CONFIG”, that can be leveraged to,

Have a “Default” or business process specific logging configurations.
Defining level of logging for a configuration.
Setting the number of days the logs should be retained for a configuration.
Setting validity of a configuration through an “End Date”.
Enable or disable an application logging configuration.

SPRO node for log configuration

ABAP SDK for Google Cloud provides a set of tools and utilities under “SAP Reference IMG” as a SPRO node. This has options ranging from basic “Client Key” setup to tools like “Code Wizard” and demo programs.

Log configuration table can be configured through this SPRO node by executing “Configure Logging Framework” under “Basic Settings” of the node “ABAP SDK for Google Cloud”.

“The SDK is shipped with a default configuration for application logging and also gives opportunities for SAP developers to setup their own business scenario specific logging configuration, below sections elaborate the default and custom setup opportunities.”

Default configuration

A default configuration is shipped with the SDK with the field “IS_DEFAULT” set, along with a default log object and log sub object. All the application logs are logged against the default log object and log sub object in the shipped configuration unless adjusted by the customer.

Set a custom configuration as “Default”

Customers can define their own log object and log sub object and set it as “default” by updating the same in the table with the field “IS_DEFAULT” set and unsetting the flag for the shipped configuration. Once done, the SDK would start taking into account the customer defined “Default” configuration instead of the shipped one. With the validations built in the SDK, at a time only one log configuration can be set as “Default”.

Define level of logging

Logging in ABAP SDK can be configured to log at log levels “Information”, “Warning” and “Error”. The field “MIN_LOGLEVEL” in the log configuration table has the dropdown option to choose the log level for a configuration.

If the log level is chosen as “Information”, SDK would log all the “Information”, “Warning” and “Error” messages raised.
If the log level is chosen as “Warning”, SDK would skip “Information” messages, and would only log all the “Warning” and “Error” messages raised.
If the log level is chosen as “Error”, SDK would skip “Information” and “Warning” messages and only log all the “Error” messages raised.

Setting the number of days for which the logs should be retained

For each configuration, the field “RETENTION_DAYS” in the configuration table can be set to denote the number of days for which the logs should be retained. The default setup is set to retain the logs for 10 days, but can be adjusted by the customer based on their business requirements.

Setting validity of a log configuration

For each configuration, the field “END_AT” in the configuration table can be set to denote the date till which the configuration is valid. No application logs are captured beyond the end date of the configuration. The default setup is set to be valid till “31.12.9999”, but can be adjusted by the customer based on their business requirements.

Enable or disable application logging

Customers can adjust the “END_AT” field for a configuration to activate/enable or deactivate/disable a log configuration based on their business requirement. For example, if the customer wants to disable application logging, they can set the “END_AT” date to a previous date and application logging would be disabled for that configuration.

Opportunities for SAP developers to utilise SDK’s logging framework

Use the default configuration shipped with the SDK

By default, the “Default” configuration shipped with the SDK would take effect and the logs would be captured under log object “ZGOOG” and log sub object “ZABAP_SDK” in BAL.

SAP developers need not do any additional setup and can leverage logging through just instantiating and invoking the ABAP class for the required API. Below is a code snippet with Google’s Cloud Pub/Sub API as an example.

TRY.
* Open HTTP Connection
     DATA(lo_pubsub_client) = NEW /goog/cl_pubsub_v1( iv_key_name = 'client_key' ).
* Call API method
     CALL METHOD lo_pubsub_client->publish_topics
       EXPORTING
         iv_p_projects_id = 'Project ID'
         iv_p_topics_id   = 'Topic ID'
         is_input         = ls_input
       IMPORTING
         es_output        = DATA(ls_output)
         ev_ret_code      = DATA(lv_ret_code)
         ev_err_text      = DATA(lv_err_text)
         es_err_resp      = DATA(ls_err_resp).
* Close HTTP Connection
     lo_pubsub_client->close( ).
   CATCH /goog/cx_sdk INTO DATA(lo_exception).
* Handle exceptions
ENDTRY.

An example log against the default setup shipped with the SDK for an invalid client key.

Setup and use own custom configuration

SDK also gives an option to customers to setup their own self defined “Default” configuration by,

Defining your own Log Object and Log Subobject (TCode — SLG0), for example create log object “ZLOG_OBJECT” and log sub object “ZLOG_SUB_OBJECT”.

Uncheck the “IS_DEFAULT” field for the shipped default configuration.
Configure the defined own log object and log sub object in the Log Configuration table and set it as “Default”.

SAP developers can continue to leverage the same single window of interaction pattern of instantiating and calling the API specific SDK class method. An example log against the developer defined default setup for HTTP destination not maintained in Service Map table.

"If you would like to have a specific configuration other than the default configuration for specific business processes, the SDK also gives an option to override the default configuration in the log configuration table (either shipped with the SDK or user defined), to log against specific log object and log sub object. For example, the requirement can be to use the log objects other than the default ones for a “Sales Order” specific business process."

SAP developers can also,

Define the business process specific Log Object and Log Subobject (using TCode — SLG0).

Configure the same in the log configuration table without checking the “IS_DEFAULT” checkbox.

Pass the Log Object and Log Sub Object while instantiating the API stub.

TRY.
* Open HTTP Connection
     DATA(lo_pubsub_client) = NEW /goog/cl_pubsub_v1( iv_key_name   = 'client_key'
                                              iv_log_obj    = 'ZSD'      ”Overriding
                                              iv_log_subobj = 'ZSD_SALES_ORDERS' ). ”Overriding
* Call API method
     CALL METHOD lo_pubsub_client->publish_topics
       EXPORTING
         iv_p_projects_id = 'Project ID'
         iv_p_topics_id   = 'Topic ID'
         is_input         = ls_input
       IMPORTING
         es_output        = DATA(ls_output)
         ev_ret_code      = DATA(lv_ret_code)
         ev_err_text      = DATA(lv_err_text)
         es_err_resp      = DATA(ls_err_resp).
* Close HTTP Connection
     lo_pubsub_client->close( ).
   CATCH /goog/cx_sdk INTO DATA(lo_exception).
* Handle exceptions
ENDTRY.

Passing the log object and log sub object while instantiation of the API stub overwrites the “Default” configuration and logging is done against the passed log object and log sub object.

An example log against the developer defined overriding setup for HTTP destination not maintained in Service Map table.

Adding Contextual Information to logs

Logging framework in the SDK also adds contextual information to the logs denoting in which stub/module of the SDK the error/exception occurred. This gives additional visibility to SAP developers during troubleshooting to know the place where the actual error/exception was encountered.

Summary

ABAP SDK for Google Cloud has a robust “API like” application logging framework embedded as a core component. It is based on SAP Business Application Logging and captures the points of errors and failure during the execution of the SDK’s foundation components and enables troubleshooting of the errors and exceptions. It is configurable and provides SAP developers with the opportunities to either use the default setup shipped with the SDK, or define their own default setup or override the default setup with a specific setup for a specific business process. It also adds contextual information of the placeholder where the error has actually occurred.

Want to hear more “Engineering Excellence” stories by the Google team implementing the SDK, take a look at the blog “ABAP SDK for Google Cloud — Insider story of Engineering Excellence”.

Next steps

I hope this blog has given you insights on the opportunities that SAP developers have to utilize logging framework when building SAP applications using ABAP SDK for Google Cloud.

If you are an ABAP developer and you want to try it out, you can follow the installation and configuration guide available in the public documentation of the SDK. The SDK is offered free of charge, but you will be charged for Google API usage. If you do not have a SAP system available, you can always follow this article to quickly set up the SAP NetWeaver AS ABAP Developer Edition 7.52 (Trial) on Google Cloud Platform and use this system to install the ABAP SDK for Google Cloud. Use embedded tools and utilities like “Code Wizard” to quick start your development.

Below are some more blogs to fuel your innovation quotient where you will get a glimpse of how to develop enterprise-grade applications using the ABAP SDK to solve business problems -