orkungedik/SAP-basis-dataset huggingface dataset:
## 4.2.15.7.3  Security Audit Log
In Security Audit Log (SAL), you can get information about user access to the Customer Data Browser application.
You can check the security audit logs for the Customer Data Browser app using the Display Security Audit Log [page 2882] app. In the Display Security Audit Log app, choose the audit event FU5.
For more information about security audit logs, see: Security Audit Log.
## Related Information
Customer Data Browser [page 1370] Accessing the App [page 1376] Data Visibility Based on Restrictions [page 1373]
## 4.2.15.7.6  Working wtih the App
When you choose the Customer Data Browser tile, you can see a list of Customer Data Browser objects that you are authorized to view.
The list of Customer Data Browser objects includes:
- CDS views, including custom CDS views
- Database tables
## Working with the App
## Navigating to the Data Details Screen
Choose a row to navigate to the Customer Data Browser - Data Details screen where you can view the data relevant to the object. You can sort the data and configure filter criteria to view a subset of data.
## Entering Parameter Values for CDS Views
If you choose a CDS view that requires you to enter parameter values before previewing data,  you can enter the values in the Maintain Parameters dialog box.
## Customer Data Browser - Data Details Screen
You can see the following options on the Customer Data Browser - Data Details screen
- Total Records : Choose to display the total number of records in the selected Customer Data Browser object.
##  Note
If you set filters, the total number of records is calculated based on the filter criteria.
- View Technical Name/View Business Name : Choose this toggle button to display the technical names or the business names of the columns.
- Parameters : Choose this button to change parameter values for CDS views that require parameters.
##  Note
This button is visible if the CDS view requires parameter values before preview.
- Maximum Rows to Be Displayed : Enter the maximum number of rows to be displayed on the screen. By default, this value is set to 100. This means that the first 100 entries that match the filter criteria are displayed on the screen. You can reset this value to display a different maximum number.
- Adapt Filters : Choose this button to select additional filters or deselect existing filters.
- Export : From the Export icon, choose the export option to download data displayed on the screen to your local machine as a spreadsheet.
- Settings : Choose this button to select columns you want to view or deselect columns you no longer want to view.
## Related Information
Customer Data Browser [page 1370] FAQs [page 1380]
## 4.2.15.7.7  FAQs
## Business Users
## 1. Why can't I see any Customer Data Browser objects in the app?
Answer : Y ou do not have the authorization to view the objects. Please contact your administrator and ask them to grant the authorization you need to view the objects. For more information, see Data Visibility Based on Restrictions [page 1373].
## 2: How can I see the complete list of Customer Data Browser objects available with the app?
Answer : Y ou can view the complete list of Customer Data Browser objects if you have admin-level authorization. Contact your administrator to get the complete set of authorizations. Please ask the administrator to select all values in the Object Name restriction field.
## 3. Why can't I find a particular CDS view or table in the list of Customer Data Browser objects?
Answer
: Here are some possible reasons:
- Your administrator has not granted you authorization to access this object, or
- The particular object is not yet enabled for Customer Data Browser
Contact your administrator for the exact reason.
## 4.2.15.8  Application Jobs
You can use this app to schedule and monitor application-related jobs. If you have manual activities that you often need to do at a specific time, the Application Jobs app can reduce your workload by running these tasks smoothly in the background. Planning regular jobs will keep you free to concentrate on other tasks.
The application job framework ideally defines long-running, repeated jobs. It's not recommended to use it to define short-running jobs with a high frequency. See also Technical Limits and Boundary Conditions for ABAP Applications.
## Key Features
You can use this app to:
- Schedule jobs based on a job template: Select a job template, define the description, start date, start time and recurrence of the job, and enter job-specific selection criteria and parameters
- Work with personalized job templates: Create and personalize a job template, save personalized job template for later use, and share personalized template
##  Note
The parameters under Scheduling Information can't be saved as part of a template.
- Schedule jobs with a custom factory calendar: In the Application Jobs app, define the scheduling information, change an existing calendar, create a new one, and define execution days
- Arrange job series that take different time zones into account
- Monitor jobs
- Display logs and results: You can navigate to job logs and job results by selecting the icon in the Log or the Results column
- Copy a job
- Cancel a job
- Restart job chains
- Navigate to the Application Logs reuse library. Y ou can do this by selecting the corresponding icon in the log on the initial screen of the app.
## Supported Device Types
- Desktop
- Tablet
## Component for Customer Incidents
If you need support or experience issues, please report an incident under component BC-SRV-APS-APJ .
## Related Information
Application Logs [page 1417]
Working with Application Job Objects
## 4.2.15.8.1  Creating a Job Catalog Entry and a Job Template
Follow these steps to run your business coding in an application job.
## Procedure
1. Implement the business logic. You need to create a class which implements certain interfaces so that it's usable in an application job. Implement the coding there that should run within the application job. For more information, see Implementing the Business Logic [page 1384].
2. Define the job catalog entry. Using ABAP development tools for Eclipse, you create a job catalog entry which refers to the class of step 1. In the job catalog entry, you can specify how the selection fields are rendered in the job scheduling dialog in the app. In addition, you can configure various settings which are used by the application job. For more information, see Creating the Job Catalog Entry [page 1389].
3. Define the job template. Using ABAP development tools for Eclipse, you create a job template which refers to the job catalog entry of step 2. In the job template, you define the default values of the job parameters which appear on the selection screen. For more information, see Creating the Job Template [page 1390].
For more information on how to create a job catalog entry and a job template in ABAP development tools for Eclipse, see Working with Application Job Objects.
If you want to implement a simple RAP (ABAP RESTful application programming model) business object, see Code Sample: How to Schedule Application Jobs from a RAP-based Business Object . This code sample allows you to schedule a class as an application job that takes the semantic key of the selected entity as a parameter.
## Related Information
Setting up the Authorizations [page 1406]
## 4.2.15.8.1.1  Implementing the Business Logic
Business logic is ABAP coding that you want to be run within an application job.
Usually, business logic also defines the data type and some properties of the selection fields that you get on the selection screen before you schedule an application job. In this context, the business logic is implemented in an ABAP class. The following development steps require a user with the development role.
To implement the business logic, create an ABAP class that implements a certain interface:
- Create an ABAP class with interface IF\_APJ\_RT\_RUN . Here, the selection fields are defined as public attributes of the class. See Creating an ABAP Class with Interface IF\_AP J\_RT\_RUN [page 1384] for more information. It's recommended to use this interface for all new developments.
- You can still create an ABAP class with interfaces IF\_APJ\_DT\_EXEC\_OBJECT and IF\_APJ\_RT\_EXEC\_OBJECT . Here, the selection fields are defined in method GET\_PARAMETERS of the interface IF\_APJ\_DT\_EXEC\_OBJECT . See Creating an ABAP Class with Interfaces IF\_APJ\_DT\_EXEC\_OBJECT and IF\_APJ\_RT\_EXEC\_OBJECT [page 1387] for more information.
##  Note
Note that this is a legacy interface. Don't use it for new developments. If you use this interface, you only have limited options during the editing of the job catalog entry.
The ABAP class mentioned here is considered the main class of each application job. This class needs to be part of a customer-defined software component (not ZLOCAL ) to be able to transport the class into subsequent systems.
## Related Information
Creating the Job Catalog Entry [page 1389] Creating the Job Template [page 1390] Setting up the Authorizations [page 1406] Application Logs [page 1417]
## 4.2.15.8.1.1.1  Creating an ABAP Class with Interface IF\_APJ\_RT\_RUN
Learn how to create an ABAP class that implements the interface IF\_APJ\_RT\_RUN to run the business logic of your application in an application job.
The interface IF\_APJ\_RT\_RUN contains the following method:
- EXECUTE : This method is called by the application job framework when the scheduled application job is run. This means that the ABAP coding that should run within the application job is implemented here.
Before you schedule an application job, you get a selection screen where you can enter values for the application job parameters. These parameters are used to control the processing of the business logic. If
you put the business logic into an ABAP class with interface IF\_APJ\_RT\_RUN , you can use the public attributes of the ABAP class as selection parameters. The parameters should fulfil the requirements described in Defining Class Attributes Used as Selection Parameters [page 1385]. Apart from the job catalog entry, the data type of the class attribute determines how the parameter is displayed and behaves on the selection screen.
Before the EXECUTE method is called by the application job framework during the job run, the class attributes are automatically filled with the values which were entered on the selection screen. The attributes can be used in the class coding without further preparations.
When you create a new application job template based on this class (see Creating the Job Template [page 1390]), its parameter values are prefilled with default values. To determine these default values, the class is instantiated and the values of the class attributes which have the same name as the template parameters are read. You have the following possibilities to set these default values:
- In the definition section of the class as default values of the class attributes
- In the CONSTRUCTOR of the class by setting values to the class attributes
- In addition, you can implement the interface IF\_APJ\_DT\_DEFAULTS in the class and define default values in method FILL\_ATTRIBUTE\_DEFAULTS by setting values to the class attributes
##  Note
If the parameter is a date field, you can use a command like @STARTDAYPLUSDAY@:03 in the value field of the template to define a dynamic date. This command can't be set as default value in method FILL\_ATTRIBUTE\_DEFAULTS , but you can enter it into the template after the template has been created.
## 4.2.15.8.1.1.1.1  Defining Class Attributes Used as Selection Parameters
Find out how to define class attributes that can be used as selection parameters to create your own business logic.
Before you schedule an application job, you get a selection screen where you can enter the values of the selection parameters. These values are transferred to the ABAP class before the EXECUTE method is run by the application job. To use a class attribute as selection parameter of the application job, it should fulfil the following requirements:
- The class attribute must be public
- Constants and read-only attributes can't be used
- The length of the attribute name is limited to 38 characters
##  Note
If the attribute is part of an interface which is implemented in the class, and if the total length of the interface name and attribute name is longer than 38 characters, you may define an alias in the class and use the alias name in the job catalog entry
On the selection screen, fields either allow a single value, or multiple values or a value range to be entered. These fields have the following additional requirements:
- If the selection field allows the input of a single value, the corresponding class attribute must have an elementary data type.
<!-- image -->
- If the selection field allows the input of multiple values or a value range, the class attribute must be defined as ranges table.
##  Note
A ranges table is an internal table with the fields SIGN , OPTION , LOW , and HIGH . These fields fulfil the following conditions:
- SIGN is a character field of length 1
- OPTION is a character field of length 2
- LOW uses an elementary data type
- HIGH uses the same data type as LOW
A ranges table can, for example, be defined via ABAP command TYPE RANGES OF .
The data type of the class attribute determines the data type and behavior of the selection parameter on the selection screen. An example: if the class attribute uses a date type, the selection field allows to enter a date, and it offers a value help for date selection.
The data type of the class attribute determines whether the selection field on the selection screen allows to enter a single value or multiple values or value ranges. If the data type is an elementary type, a single value can be entered. If it's a ranges table, multiple values or value ranges can be used.
When a parameter is added to a job catalog entry, the default value of the parameter title is taken from the description text of the class attribute. In ABAP development tools for Eclipse, the description text of the class attribute can be set using the ABAP Doc comment: "! &lt;p class="shorttext synchronized" lang="en"&gt;…&lt;/p&gt;
It's possible to define class attributes in the ABAP class which don't fulfil the above requirements if you don't want to use them as parameters of a job catalog entry.
## 4.2.15.8.1.1.3  Exception Handling
Learn how to handle the exception CX\_APJ\_RT\_CONTENT of the method EXECUTE .
The method EXECUTE has the exception CX\_APJ\_RT\_CONTENT in its signature. Y ou can raise an exception of this type and specify a message text (see code snippet) . The application job framework handles exceptions of type CX\_APJ\_RT\_CONTENT and creates a separate log for the application job. The log contains the message text, and information about the source position where the exception was raised. The application job gets the status Failed .
```
 Sample Code " the following coding simulates the application logic that causes a system exception " (in this case: division by zero) DATA a TYPE i. DATA b TYPE i. DATA c TYPE i. TRY. a = 1. b = 0. c = a / b. CATCH cx_root INTO DATA(exc). " Precondition for the following statement: " message class Z_APJ must exist, message 001 must exist in this message class with one variable part RAISE EXCEPTION TYPE cx_apj_rt_content MESSAGE ID 'Z_APJ' NUMBER 001 WITH exc->get_text(  ). ENDTRY.
```
The application job framework doesn't handle any other exception apart from CX\_APJ\_RT\_CONTENT . Any other exception which is not handled within the EXECUTE method itself will lead to a runtime error. The log will then contain the name of the runtime error, and further details of the runtime error have to be checked in the ABAP Runtime Errors app.
## 4.2.15.8.1.2  Creating the Job Catalog Entry
An application job catalog entry contains the information that is needed for scheduling and running an application job. The application job catalog entry contains the name of the class that implements the business logic, and the information on how selection fields are rendered in the job scheduling dialog in the app. In addition, the job catalog entry contains some further settings which are used during the scheduling and running of the application job.
To create a job catalog entry, use the ABAP development tools for Eclipse (ADT) editor. For more information, see Working with Application Job Objects. Alternatively, you could still also create job catalog entries and job templates via a released API. For more information, see Creating a Job Catalog Entry and a Job Template via API [page 1404].
Job catalog entries and job templates are created with a package assignment and the objects are assigned to a transport request. You need to make sure that the package and transport request fit together (regarding the transport layer) and that possible naming conventions are obeyed.
## Related Information
Creating the Job Template [page 1390] Setting up the Authorizations [page 1406]
## 4.2.15.8.1.3  Creating the Job Template
An Application Job Template refers to an application job catalog entry and contains values for some or all selection fields. It can be thought of as a variant of an application job catalog. In the simplest case, a job template doesn't contain any values for the selection fields. In this case, the selection fields are prefilled with their initial values (such as 0 if the selection field is of type integer). An application job catalog entry can have more than one application job template. The job template is the entity that can be scheduled in the Application Jobs app. In the scheduling dialog, the selection fields appear and are prefilled with the values defined in the template. They can be overwritten by the user. Scheduling an application job template then results in an application job.
The creation of a job template follows the same technical rules as a Job Catalog Entry as described in Creating the Job Catalog Entry [page 1389]. To create a job template, use the ABAP development tools for Eclipse. For more information, see Creating Application Job Templates. Alternatively, you could still also create application job templates via a released API. For more information, see Creating a Job Catalog Entry and a Job Template via API [page 1404].
## Related Information
Setting up the Authorizations [page 1406]
## 4.2.15.8.1.7  Deleting the Job Catalog Entry and the Job Template
Find out how to delete a job catalog entry and a related job template.
To delete a job catalog entry or a job template, use the ABAP development tools for Eclipse. Right-click on the object in the Project Explorer and select Delete .
Alternatively, you could also still delete job catalog entries and job templates via a released API. For more information, see Creating a Job Catalog Entry and a Job Template via API [page 1404].
Before you can delete a job catalog entry, you must first delete all related job templates: When you create a job catalog entry, an IAM app that is based on the job catalog entry is automatically created in the Cloud. If you have followed the steps in Setting up the Authorizations [page 1406], you should perform additional steps before deleting the job catalog entry, since otherwise, the IAM app can't automatically be deleted together with the job catalog entry:
- Remove the business role from the business user in the Fiori app Maintain Business Users
- Delete the business role in the Fiori app Maintain Business Roles
- Unassign the IAM app from the IAM business catalog in ABAP development tools for Eclipse
- Delete the IAM business catalog in ABAP development tools for Eclipse
Now, you can delete the job catalog entry.
If you only want to replace the job catalog entry (if you want to delete it to recreate it with the same name), it's sufficient to remove the IAM app assignment from the IAM business catalogs. After the creation of the new job catalog entry, assign the new IAM app to the IAM business catalogs.
## 4.2.15.9  Application Logs
You can use the Application Logs to display and check if any errors occurred during runtime.
The Application Logs are a reuse library that is mainly used within the Application Jobs app, but can also be used in other apps. This reuse library gives you a clearly structured overview of all errors that might have occurred during runtime.
## Key Features
You can use this reuse library to:
- view application log details
- filter the logs by severity
- search for message texts
- display the message details
- display archived application logs
## Component for Customer Incidents
```
BC-SRV-APS-APL For more information, see
```
- Design Time API [page 1418]
- Runtime API [page 1422]
- How to Use the Fiori Reuse Library [page 1483]
## Related Information
Working with Application Log Objects
## 4.2.15.9.2  Runtime API
Use a class-based API to create and read application logs.
You can use a class-based API to create and read application logs. The application log is a tool for collecting messages or exceptions which are stored in a log. You can save this log in the database or read and delete it from there.
If an application wants to collect messages and exceptions which occur during runtime of an application program, the following steps are required:
- Create a New Application Log [page 1423]
- Set Header Information [page 1426]
- Add Items [page 1427]
- Writing Application Logs to the Database [page 1433]
If an application wants to read the content of an application log from the database, for example, to display its content, the following steps are required:
- Define a Filter [page 1435]
- Read Application Logs from the Database [page 1437]
- Get Header Information from the Log [page 1439]
- Get Items from the Log [page 1440]
## 4.2.15.9.2.1  Creating an Application Log
If an application wants to collect messages and exceptions which occur during runtime of an application program, the following steps are required:
- Create a New Application Log [page 1423]
- Set Header Information [page 1426]
- Add Items [page 1427]
- Writing Application Logs to the Database [page 1433]
## 4.2.15.9.2.1.2  Set Header Information
An application log contains header information and attributes to identify the log. During log creation, the following header information can be set:
- Log Object (required): Identifies the application to which the log belongs.
- Log Subobject: An application can define subcategories of its log object. These subcategories are called subobjects and must be set if the application defined them. If no subobjects were defined for the log object, the field should remain empty.
- External Identifier: We recommend to enter your preferred identifier containing, for example, the application document number.
- Expiry Date: It defines the date when the log expires and can be deleted from the database. The default value is the creation date of the log + 7 days.
- A flag defining whether it should not be allowed to delete the log before the expiry date by a standard report. The application is still able to delete the log before this date.
- Context: Allows the storage of application-specific data related to the log. See Set a Context [page 1432].
To define the log header, an instance of the IF\_BALI\_HEADER\_SETTER interface is required. To create this instance, you can use method CREATE of class CL\_BALI\_HEADER\_SETTER . It allows to set the object, subobject and the external identifier of the application log.
Interface IF\_BALI\_HEADER\_SETTER contains the following methods to set or change the header attributes:
- SET\_DESCRIPTOR : Changes the object, subobject and external identifier.
- SET\_EXPIRY : Sets the expiry date and the keep until expiry flag.
- SET\_CONTEXT : Sets the context of the log.
##  Note
You have two options to transfer the header to the application log object:
- Using method CREATE\_WITH\_HEADER of class CL\_BALI\_LOG when the log object is created.
- Using method SET\_HEADER of interface IF\_BAL\_LOG .
If the header was already written to the log (for example, using method SET\_HEADER of interface IF\_BAL\_LOG ) and if the header object is changed afterwards (for example, using method SET\_DESCRIPTOR ), you must call method SET\_HEADER to make these changes visible in the log.
```
 Sample Code ... TRY. DATA(l_header) = cl_bali_header_setter=>create( object = 'ZOBJECT' subobject = 'ZSUBOBJECT' external_id = 'External ID' ). l_header->set_expiry( expiry_date = CONV #( cl_abap_context_info=>get_system_date(  ) + 5 ) keep_until_expiry = abap_true ). CATCH cx_bali_runtime INTO DATA(l_runtime_exception). out->write( l_runtime_exception->get_text(  ) ). ENDTRY. ...
```
## 4.2.15.9.2.1.3.1  Create a Message
One item category, which can be written into an application log, is a message. A message is identified by the message ID and the message number.
When an application log message is defined, you can set the following attributes:
- Severity, such as Error , Warning , Information . Possible values of the severity are defined as constants in interface IF\_BALI\_CONSTANTS .
- Message ID
- Message Number
- Variables 1 - 4 of the message
- Detail Level of the item: If the application displays the items of the application log, the detail level can be used to define at which level of detail the item shall be displayed.
- Context: Allows the storage of application-specific data related to the message. See Set a Context [page 1432].
To add a message to an application log, an instance of interface IF\_BALI\_MESSAGE\_SETTER is required. T o create this instance, class CL\_BALI\_MESSAGE\_SETTER provides the following methods:
- CREATE : It allows to set the severity, message ID, message number and the variables of the message.
- CREATE\_FROM\_SY : Y ou can use this method to create an application log message from the system fields in the list below. These system fields are filled, for example, by ABAP command MESSAGE . The following system fields are available:
- SY-MSGTY
- SY-MSGID
- SY-MSGNO
- SY-MSGV1
- SY-MSGV2
- SY-MSGV3
- SY-MSGV4
- CREATE\_FROM\_BAPIRET2 : It allows to set all message parameters via structure BAPIRET2 .
Interface IF\_BALI\_MESSAGE\_SETTER contains the following methods to set or change the attributes of the message:
- SET\_ATTRIBUTES: Changes the severity, message ID, message number and the variables of the message.
- SET\_FROM\_SY: Changes the severity, message ID, message number and the variables of the message to the values of the system fields, such as SY-MSGTY.
- SET\_FROM\_BAPIRET2: Changes the severity, message ID, message number and the variables of the message to the values of structure BAPIRET2.
- SET\_DETAIL\_LEVEL: Sets the detail level.
- SET\_CONTEXT: Sets the context of the message.
##  Sample Code
```
... DATA(l_ref) = cl_bali_message_setter=>create( severity = if_bali_constants=>c_severity_error id = 'BL' number = '315' variable_1 = 'A' variable_2 = 'B' variable_3 = 'C' variable_4 = 'D' ). l_ref->set_detail_level( detail_level = '7' ). ... MESSAGE ID 'ZTEST' TYPE 'I' NUMBER '315' WITH 'E' 'F' 'G' 'H' INTO DATA(l_message). l_ref = cl_bali_message_setter=>create_from_sy( )->set_detail_level( detail_level = '3' ). ... DATA(l_bapiret2) = VALUE bapiret2( id = 'BL' type = 'I' number = '315' message_v1 = 'A' message_v2 = 'B' message_v3 = 'C' message_v4 = 'D' ). l_ref = cl_bali_message_setter=>create_from_bapiret2( message_data = l_bapiret2 ). ...
```
## 4.2.15.9.2.1.3.2  Create a Free Text
One item category, which can be written into an application log, is Free Text . It is any text with up to 200 characters.
The following attributes can be set when an application log free text is defined:
- Severity, such as Error , Warning , Information . Possible values of the severity are defined as constants in interface IF\_BALI\_CONSTANTS .
- Text content
- Detail level of the item: If the application displays the items of the application log, the detail level can be used to define at which level of detail the item should be visible.
- Context: Allows the storage of application-specific data related to the free text. See Set a Context [page 1432].
To add a free text to an application log, an instance of interface IF\_BALI\_FREE\_TEXT\_SETTER is required. T o create this instance, you can use method CREATE of class CL\_BALI\_FREE\_TEXT\_SETTER . It allows to set the severity and the text content.
To set or change the attributes of the free text, interface IF\_BALI\_FREE\_TEXT\_SETTER contains the following methods:
- SET\_TEXT: Changes the text content and severity.
- SET\_DETAIL\_LEVEL: Sets the detail level.
- SET\_CONTEXT: Sets the context of the free text.
```
 Sample Code ... DATA(l_ref) = cl_bali_free_text_setter=>create( severity = if_bali_constants=>c_severity_error text = 'Some Error Text' ). l_ref->set_detail_level( detail_level = '4' ). ... l_ref = cl_bali_free_text_setter=>create( text = 'Some Other Text' )->set_detail_level( detail_level = '1' ). ...
```
## 4.2.15.9.2.1.3.3  Create an Exception
One item category, which can be written into an application log, is an Exception . An exception is raised by the application using ABAP command RAISE EXCEPTION and can be caught by ABAP command CATCH .
To define an application log exception, you can set the following attributes:
- Severity, such as Error , Warning , Information . Possible values of the severity are defined as constants in interface IF\_BALI\_CONSTANTS .
- Reference to the exception object
- Detail Level of the item: If the application displays the items of the application log, the detail level can be used to define at which level of detail the item should be displayed.
- Context: Allows the storage of application-specific data related to the exception. See Set a Context [page 1432].
To add an exception to an application log, an instance of interface IF\_BALI\_EXCEPTION\_SETTER is required. To create this instance, method CREATE of class CL\_BALI\_EXCEPTION\_SETTER can be used. It allows to set the severity and the reference to the exception object.
If you want to set or change the attributes of the exception, you can use interface IF\_BALI\_EXCEPTION\_SETTER . It contains the following methods:
- SET\_EXCEPTION: Changes the reference to the exception object and the severity.
- SET\_DETAIL\_LEVEL: Sets the detail level.
- SET\_CONTEXT: Sets the context of the exception.
```
 Sample Code ... DATA: i TYPE i. TRY. i = 1 / 0. CATCH cx_sy_zerodivide INTO DATA(l_exception_ref). ENDTRY. DATA(l_ref) = cl_bali_exception_setter=>create( severity = if_bali_constants=>c_severity_error exception = l_exception_ref ). l_ref->set_detail_level( detail_level = '2' ). ...
```
## 4.2.15.9.2.1.3.4  Define a Filter for the Log Items
If items are put into an application log, there may be the requirement to use an item filter in order to, for example, keep the log small. For example, a report calls an encapsulated application class which writes different types of items into the application log. If the report doesn't need all items, but, for example, only the errors, it may define an item filter which only lets the errors pass.
To create a filter, an instance of interface IF\_BALI\_ITEM\_FILTER is required. T o create this instance, the method CREATE of class CL\_BALI\_ITEM\_FILTER can be used. It creates an empty filter. The interface IF\_BALI\_ITEM\_FILTER contains the following method to set the filter parameters:
- SET\_SEVERITY : Set a filter for the severity (error, warning,…) of the item. The severity values which pass the filter are set via an internal table.
```
 Sample Code Example: Set a filter which lets all items pass that have the severity Error or Warning : ... TRY. DATA(l_filter) = cl_bali_item_filter=>create( ). l_filter->set_severity( severity_table = value #( ( 'E' ) ( 'W' ) ) ). CATCH cx_bali_runtime INTO DATA(l_exception). out->write( l_exception->get_text(  ) ). ENDTRY. ...
```
## 4.2.15.9.2.1.3.5  Set a Context
There may be the requirement to store application-specific data in the log. For example, a message may only be meaningful if you have information about the context in which a message was generated. An example of the context is the number of the order which was processed when the message was written into the log.
You can set a context for the complete log in the log header, and for each individual item of the log. To do this, the following steps are necessary:
- You need a structure which can store the context data. It must meet the following requirements:
- The structure must either use a database table type, or a structure type which is defined in the data dictionary.
- The structure type must be flat (which means that no internal tables or nested structures are allowed).
- The structure type must be character-like (which means that no integer fields are allowed).
- The total length of the complete structure must not be larger than 256 characters.
- Now, you can fill the structure fields with the application data which you want to store as context in the log or item.
- To transfer the structure with the context data to the log, you can use the method SET\_CONTEXT of the header or item object.
## 
```
Sample Code ... DATA: l_context TYPE ADDRESS_1. " it can be any application structure that fulfils the requirements l_context = VALUE #( name1 = 'Test' name2 = 'Data' ). " fill the structure with the context data TRY. DATA(l_header) = cl_bali_header_setter=>create( object = 'ZOBJECT' subobject = 'ZSUBOBJECT' ). l_header->set_context( l_context ). CATCH cx_bali_runtime INTO DATA(l_runtime_exception). out->write( l_runtime_exception->get_text(  ) ). ENDTRY. ...
```
## 4.2.15.9.2.2  Reading an Application Log
If an application wants to read the content of an application log from the database, for example, to display its content, the following steps are required:
- Define a Filter [page 1435]
- Read Application Logs from the Database [page 1437]
- Get Header Information from the Log [page 1439]
- Get Items from the Log [page 1440]
## 4.2.15.9.2.2.1  Define a Filter
If one or more application logs shall be read from the database and if the log handles are not known, you can identify the logs by defining a filter.
To create a filter, an instance of interface IF\_BALI\_LOG\_FILTER is required. T o create this instance, you can use method CREATE of class CL\_BALI\_LOG\_FILTER . It creates an empty filter.
##  Note
Due to performance reasons, we recommend to set at least the object and subobject in the filter.
Interface IF\_BALI\_LOG\_FILTER contains the following methods to set the filter parameters:
- SET\_DESCRIPTOR: Set a filter for the log object, subobject and external identifier. It offers the following parameters:
- Select a single object
- Select a single subobject (wildcards allowed)
- Select a table of subobjects (wildcards allowed)
- Select a single external identifier (wildcards allowed)
- Select a table of external identifiers (wildcards allowed)
- SET\_CREATE\_INFO: Set a filter for the attribute which identifies the creator of the log. It offers the following parameters:
- Select a single user (wildcards allowed)
- Select a table of users (wildcards allowed)
- SET\_TIME\_INTERVAL: Set a time interval for the creation date and time of the log. The start and end time of the interval are set using UTC time stamps.
- SET\_MAXIMUM\_LOG\_NUMBER: Set the maximum number of logs which shall be read from the database. If the parameter is not set, all logs are read (which fulfill the other filter criteria).
<!-- image -->
## 4.2.15.9.2.2.3  Get Header Information from the Log
An application log contains header information and several attributes which identify the log. To read the header from a log, method GET\_HEADER of interface IF\_BALI\_LOG can be used. It returns an object which uses interface IF\_BALI\_HEADER\_GETTER .
Interface IF\_BALI\_HEADER\_GETTER contains the following attributes:
- OBJECT: Log object which identifies the application to which the log belongs.
- SUBOBJECT: Log subobject which is the subcategory of an application log object.
- EXTERNAL\_ID: A free text which is usually used by the application to identify the log. It contains, for example, the application document number.
- LOG\_TIMESTAMP: UTC time stamp of the log (usually the creation time).
- LOG\_USER: Log user (usually the user who created the log).
- EXPIRY\_DATE: It defines the date when the log expires and can be deleted from the database.
- KEEP\_UNTIL\_EXPIRY: A flag which defines whether or not it is allowed to delete the log before the expiry date. If the flag is set, the standard reports which delete application logs do not delete the log before the expiry date. The application is still able to delete the log before this date.
- CONTEXT\_STRUCTURE\_NAME: The name of the dictionary structure which was used to set the context. See Get the Context [page 1444].
- NUMBER\_ALL\_ITEMS: Total number of items which are stored in the log.
- NUMBER\_ABORT\_ITEMS: Number of abort items which are stored in the log.
- NUMBER\_ERROR\_ITEMS: Number of error items which are stored in the log.
- NUMBER\_WARNING\_ITEMS: Number of warning items which are stored in the log.
- NUMBER\_INFORMATION\_ITEMS: Number of information items which are stored in the log.
- NUMBER\_STATUS\_ITEMS: Number of status items which are stored in the log.
Interface IF\_BALI\_HEADER\_GETTER contains the following methods:
- GET\_OBJECT\_DESCRIPTION: Returns the description text of the log object in the logon language.
- GET\_SUBOBJECT\_DESCRIPTION: Returns the description text of the log subobject in the logon language.
- GET\_CONTEXT: Get the context of the log. See Get the Context [page 1444].
##  Note
The header object contains the header attributes that were valid when the method GET\_HEADER was called. If the log is changed after this call (for example, when new items are added to the log), these changes are not automatically visible in the header object. To refresh the header object it's necessary to call the method GET\_HEADER again.
##  Example
Load a single log from the database which uses log handle l\_handle, and output some fields of the log header:
```
 Sample Code ... DATA l_handle TYPE if_bali_log=>ty_handle. ... TRY. DATA(l_log) = cl_bali_log_db=>get_instance( )->load_log( handle = l_handle ). DATA(l_header) = l_log->get_header( ). out->write( |{ l_header->object } { l_header->get_object_description( ) } { l_header->subobject } { l_header->external_id } { l_header->log_user }| ). CATCH cx_bali_runtime INTO DATA(l_exception). out->write( l_exception->get_text(  ) ). ENDTRY. ...
```
## 4.2.15.9.2.2.4.1  Get a Free Text
Similar to all other items, a free text can be read from the application log using methods GET\_ITEM and GET\_ALL\_ITEMS of interface IF\_BALI\_LOG . The free text object, which is returned by these methods, uses interface IF\_BALI\_FREE\_TEXT\_GETTER .
The interface supports all attributes and methods of interface IF\_BALI\_ITEM\_GETTER .
Interface IF\_BALI\_FREE\_TEXT\_GETTER contains no additional attributes.
##  Example Load a single log from the database which uses log handle l\_handle and output the text of the first item:  Sample Code
```
... DATA l_handle TYPE if_bali_log=>ty_handle. ... TRY. DATA(l_log) = cl_bali_log_db=>get_instance( )->load_log( handle = l_handle ). DATA(l_item) = l_log->get_item( log_item_number = '1' ). out->write( |{ l_item->get_message_text( ) }| ). CATCH cx_bali_runtime INTO DATA(l_exception). out->write( l_exception->get_text(  ) ). ENDTRY. ...
```
## 4.2.15.9.2.2.4.2  Get a Message
Similar to all other items, a message can be read from the application log using methods GET\_ITEM and GET\_ALL\_ITEMS of interface IF\_BALI\_LOG . The message object, which is returned by these methods, uses interface IF\_BALI\_MESSAGE\_GETTER .
The interface supports all attributes and methods of interface IF\_BALI\_ITEM\_GETTER .
Interface IF\_BALI\_MESSAGE\_GETTER contains the following additional attributes:
- ID: Message ID
- NUMBER: Message Number
- VARIABLE\_1: Variable 1 of the message
- VARIABLE\_2: Variable 2 of the message
- VARIABLE\_3: Variable 3 of the message
- VARIABLE\_4: Variable 4 of the message
- COUNT: The count of the message. It is increased, if method CUMULATE\_ITEM of interface IF\_BALI\_LOG is used to add a message to the log and if the log already contains a message with the same message attributes (severity, message ID, message number and variables).
##  Example
Load a single log from the database which uses log handle l\_handle and output some attributes of the first item, if it is a message:
##  Sample Code
```
... DATA l_handle TYPE if_bali_log=>ty_handle. ... TRY. DATA(l_log) = cl_bali_log_db=>get_instance( )->load_log( handle = l_handle ). DATA(l_item) = l_log->get_item( log_item_number = '1' ). IF l_item->category = if_bali_constants=>c_category_message. DATA(l_message_ref) = CAST if_bali_message_getter( l_item ). out->write( |{ l_message_ref->id } { l_message_ref->number }| ). ENDIF. CATCH cx_bali_runtime INTO DATA(l_exception). out->write( l_exception->get_text(  ) ). ENDTRY. ...
```
## 4.2.15.9.2.2.4.3  Get an Exception
Similar to all other items, an exception can be read from the application log using methods GET\_ITEM and GET\_ALL\_ITEMS of interface IF\_BALI\_LOG . The exception object, which is returned by these methods, uses interface IF\_BALI\_EXCEPTION\_GETTER .
The interface supports all attributes and methods of interface IF\_BALI\_ITEM\_GETTER .
Interface IF\_BALI\_EXCEPTION\_GETTER contains the following additional attributes:
- EXCEPTION\_CLASS: The name of the exception class.
- EXCEPTION\_ID\_NAME: Name of the text ID of the ABAP exception.
##  Example
Load a single log from the database which uses log handle l\_handle and output some attributes of the first item, if it is an exception:
##  Sample Code
```
... DATA l_handle TYPE if_bali_log=>ty_handle. TRY. DATA(l_log) = cl_bali_log_db=>get_instance( )->load_log( handle = l_handle ). DATA(l_item) = l_log->get_item( log_item_number = '1' ). IF l_item->category = if_bali_constants=>c_category_exception. DATA(l_exception_ref) = CAST if_bali_exception_getter( l_item ). out->write( |{ l_exception_ref->exception_class } { l_exception_ref->exception_id_name }| ). ENDIF. CATCH cx_bali_runtime INTO DATA(l_exception). out->write( l_exception->get_text(  ) ). ENDTRY. ...
```
## 4.2.15.9.2.2.4.4  Get the Context
To read the context data from the log header or from the log item, the following steps are necessary:
- You must define a structure which can be used to store the context data. It's recommended that you use the same structure type that was used when the context was set.
- To get the data dictionary name of the structure type that was used to set the context, you can use the attribute CONTEXT\_STRUCTURE\_NAME of the header or item object.
- After this, you can use the method GET\_CONTEXT of the header or item object to fill this context structure.
- If you use a different structure type for getting the context than the one used for setting, only the identically named components are copied to each other.
```
 Sample Code ... DATA: l_handle TYPE if_bali_log=>ty_handle. DATA: l_context TYPE ADDRESS_1. " the structure type which was used to set the context ... TRY. DATA(l_log) = cl_bali_log_db=>get_instance( )->load_log( handle = l_handle ). DATA(l_header) = l_log->get_header( ). l_header->get_context( IMPORTING context = l_context ). out->write( |{ l_context-name1 } { l_context-name2 }| ). CATCH cx_bali_runtime INTO DATA(l_exception).
```
```
out->write( l_exception->get_text(  ) ). ENDTRY.
```
...
## 4.2.15.9.2.3.8  CL\_BALI\_ITEM\_FILTER (Interface IF\_BALI\_ITEM\_FILTER)
The class CL\_BALI\_ITEM\_FILTER allows you to define an item filter. Y ou can use it if it's necessary to restrict which items are added to an application log. The public interface of the instance methods is IF\_BALI\_ITEM\_FILTER .
## Public Methods
Create an instance of the filter class:
CREATE (static)
## Name
## Description
| Returning parameter   |                                                |
|-----------------------|------------------------------------------------|
| FILTER                | Reference to the interface IF_BALI_ITEM_FILTER |
Set a table of all severity values that pass the filter. It overwrites all previous filter settings related to the severity:
SET\_SEVERITY
## Name
| Importing parameter   |                                                        |
|-----------------------|--------------------------------------------------------|
| SEVERITY_TABLE        | Table with severity values (such as Error or Warning ) |
| Returning parameter   |                                                        |
| NEW_FILTER            | Reference to the current filter object                 |
##  Note
- Valid values of the severity can be found in the interface IF\_BALI\_CONSTANTS
- If the parameter SEVERITY\_TABLE doesn't contain an entry, all severity values pass the filter
- If the parameter SEVERITY\_TABLE only contains invalid entries, no severity passes the filter
Apply the filter to a set of log item attributes and check whether it passes the filter:
APPLY\_FILTER
Name
## Description
| Importing parameter   |                                                      |
|-----------------------|------------------------------------------------------|
| SEVERITY              | Severity of the log item that is checked             |
| Returning parameter   |                                                      |
| FILTER_PASSED         | If set, the set of attributes passes the item filter |
## 4.2.15.9.2.3.10  IF\_BALI\_EXCEPTION\_GETTER
If an exception is read from an application log, an object instance of interface IF\_BALI\_EXCEPTION\_GETTER is returned. It contains the interface IF\_BALI\_ITEM\_GETTER .
## Public Attributes
| Name                                                | Description                                                                          |
|-----------------------------------------------------|--------------------------------------------------------------------------------------|
| CATEGORY (from IF_BALI_ITEM_GETTER)                 | Category of the item Contains fixed value: IF_BALI_CONSTANTS=>C_CATE- GORY_EXCEPTION |
| LOG_ITEM_NUMBER (from IF_BALI_ITEM_GETTER)          | Serial number which is the position of the exception in the log                      |
| SEVERITY (from IF_BALI_ITEM_GETTER)                 | Severity of the exception ('Error', 'Warning', etc)                                  |
| DETAIL_LEVEL (from IF_BALI_ITEM_GETTER)             | Detail level of the exception (number between '1' and '9' or ' ')                    |
| TIMESTAMP (from IF_BALI_ITEM_GETTER)                | UTC time stamp of the exception creation                                             |
| CONTEXT_STRUCTURE_NAME (from IF_BALI_ITEM_GET- TER) | Data dictionary name of the context structure                                        |
| EXCEPTION_CLASS                                     | Nameof the ABAP exception class                                                      |
| EXCEPTION_ID_NAME                                   | Nameof the Text ID of the ABAP exception                                             |
## Public Methods
Get the message short text of the exception (the output of method GET\_TEXT of the ABAP exception object):
GET\_MESSAGE\_TEXT (from interface IF\_BALI\_ITEM\_GETTER)
| Name                | Description   |
|---------------------|---------------|
| Returning parameter |               |
| Name                                                 | Description                                               |
|------------------------------------------------------|-----------------------------------------------------------|
| MESSAGE_TEXT                                         | Message short text of the exception in the logon language |
| Get the context data of the exception:               |                                                           |
| GET_CONTEXT (from the interface IF_BALI_ITEM_GETTER) |                                                           |
| Name                                                 | Description                                               |
| Exporting parameter                                  |                                                           |
| CONTEXT                                              | Structure that is filled with context data                |