Application Logging in ABAP SDK for Google Cloud
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 “API stubs” 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.
ABAP SDK for Google Cloud building blocks
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.
API-like call based application logging avoids the boilerplate repetitive code
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”.
SAP IMG node to setup Application Logging in 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.”
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.
Default configuration in the Log Configuration Table
Log Object and Log Subobject shipped with the ABAP SDK for Google Cloud
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.
Log configuration table with the shipped “Default” configuration
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.
Application log with default configuration shipped with the SDK
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”.
Developer defined log object and log subobject
- 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”.
Log configuration table with developer defined log objects and set 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.
Application log against developer defined log objects
“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).
Developer defined log objects for a specific business process
- Configure the same in the log configuration table without checking the “IS_DEFAULT” checkbox.
Log configuration table with both “Default” and “Custom” configurations
- 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.
Application log done against the custom overriding log objects passed by the developer during instantiation
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.
Name of the ABAP object logged the SDK along with the error
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”.
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 blog from Former Member 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. Checkout blog from Kriti Sugandha on how to use embedded “Code Wizard” tool 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 –