BTP - Custom Data Browser
What alternatives to SE16 do you have in the ABAP environment to give your department easy access to data? In this article, we'll go into the details.
Table of contents
In this article we look at the Custom Data Browser, how you can easily configure it and how you can best use it.
Introduction
In the classic ABAP world there is SE16, SE16N or SE16H to generically evaluate tables in the system. In the Fiori world there is no longer any access to the SAP GUI and the generic representation of data is seen as more critical. So what options do we have to give our department access to the data without them having to install the ABAP Development Tools? That's what the Custom Data Browser application is for.
Preparation
In the first step, we need some objects to be able to look at the topic of Custom Data Browser. In this chapter, you will get all the objects at your fingertips.
Table
To do this, we will create a team database. We need information about different teams, their roles in the team, their skills and some personal data. The table could look like this.
@EndUserText.label : 'Team Setup'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zbs_dmo_team {
key client : abap.clnt not null;
key user_id : abap.char(7) not null;
player_name : abap.char(120);
player_email : abap.string(0);
player_position : abap.char(35);
score : abap.dec(10,2);
team : abap.char(60);
team_leader : abap.char(7);
}
Data
So that we have some data, we create an executable class and create data records there. Then execute the class so that the data is created in the table. We use the DELETE to clean up the table again and again when there are major changes to our data structure.
CLASS zcl_bs_demo_rap_fill_team DEFINITION
PUBLIC FINAL
CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_oo_adt_classrun.
ENDCLASS.
CLASS zcl_bs_demo_rap_fill_team IMPLEMENTATION.
METHOD if_oo_adt_classrun~main.
DATA team_members TYPE STANDARD TABLE OF zbs_dmo_team WITH EMPTY KEY.
team_members = VALUE #( ( user_id = 'P0020'
player_name = 'Lester P. Riley'
player_email = 'LesterPRiley@einrot.com'
player_position = 'Manager'
score = '0.00'
team = 'Proud SNC'
team_leader = '' )
( user_id = 'P0021'
player_name = 'Brayden Zichy-Woinarski'
player_email = 'BraydenZichy-Woinarski@einrot.com'
player_position = 'Coach'
score = '1465'
team = 'Proud SNC'
team_leader = 'P0020' )
( user_id = 'P0022'
player_name = 'Yong Wang'
player_email = 'YongWang@cuvox.de'
player_position = 'Mid-Lane'
score = '2100'
team = 'Proud SNC'
team_leader = 'P0020' )
( user_id = 'P0023'
player_name = 'Garland Robert'
player_email = 'GarlandRobert@cuvox.de'
player_position = 'Bot-Lane'
score = '2200'
team = 'Proud SNC'
team_leader = 'P0020' )
( user_id = 'P0024'
player_name = 'Søren C. Nilsson'
player_email = 'SorenCNilsson@einrot.com'
player_position = 'Jungle'
score = '1925'
team = 'Proud SNC'
team_leader = 'P0020' )
( user_id = 'P0025'
player_name = 'Emily Correia Oliveira'
player_email = 'EmilyCorreiaOliveira@cuvox.de'
player_position = 'Manager'
score = '0.00'
team = 'Wasteland'
team_leader = '' )
( user_id = 'P0026'
player_name = 'Erin Chandler'
player_email = 'ErinChandler@einrot.com'
player_position = 'Coach'
score = '2000'
team = 'Wasteland'
team_leader = 'P0025' )
( user_id = 'P0027'
player_name = 'Panu Sibelius'
player_email = 'PanuSibelius@cuvox.de'
player_position = 'Jungle'
score = '2122'
team = 'Wasteland'
team_leader = 'P0025' )
( user_id = 'P0028'
player_name = 'Katharina Fuerst'
player_email = 'KatharinaFuerst@einrot.com'
player_position = 'Bot-Lane'
score = '1980'
team = 'Wasteland'
team_leader = 'P0025' ) ).
DELETE FROM zbs_dmo_team.
INSERT zbs_dmo_team FROM TABLE @team_members.
COMMIT WORK.
ENDMETHOD.
ENDCLASS.
Core Data Service
Finally, we create a Core Data Service to create a reusable layer on top of the table, normalizing the field names to have a more readable data model later.
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Team View'
define view entity ZBS_B_DMOTeamView
as select from zbs_dmo_team
{
key user_id as UserIdentification,
player_name as PlayerFullName,
player_email as EMailAddress,
player_position as PlayerPosition,
score as ELOScore,
team as TeamName,
team_leader as TeamLeader
}
Preview
Now that we have created the objects, we can look at the data preview of the Core Data Service. To do this, start the preview within the object with F8 or via the context menu. All data was imported cleanly.
Custom Data Browser Object
We now need a configuration for the Custom Data Browser so that we can access the contents of the Core Data Service. Via the context menu; of the object we are already suggested the correct object.
Now we can fill in the information about the object and create it. However, certain information is set: The name of the object must be the same as the object (table, Core Data Service) and the CDB object must be in the same package.
In principle, such objects are possible for tables and Core Data Services. Once generation is complete, we receive our object and the option to make further settings.
Basically, we can now configure the information in the fields. The following settings are available to us:
- General Information - General information that is always displayed. These fields do not contain any critical information and can be used for searching/displaying.
- Sensitive Personal Information - Sensitive information that is not intended for evaluation is stored in this field. These can be shown or hidden later using authorizations.
- Non Business Information - This information is not relevant for the evaluation and is always hidden.
Finally, we set up our data as follows; the email and personal score are sensitive data and we do not want the team leader in the evaluation.
Custom Data Browser
You can find the "Custom Data Browser" app (F5746) in the ABAP Environment in the "Data Analysis - Preview" business catalog (SAP_CORE_BC_CDB_PC). This should help you find the app in the system.
On the entry page we can choose between the tables and Core Data Services, and then we can find our Core Data Service using the search function. The description is taken from the CDB object if you want to change it later. Basically, you only see objects here for which you are authorized. More on the subject of permissions in the chapter below.
If we run our CDS view, we get the list with the information visible to us, filters to limit the data, an Excel export and other settings.
Hint: It was previously not possible to get the headings clean using UI annotations and labels. However, when real data elements are used, the descriptions are adopted.
Permissions
In the example above, we can also access the sensitive information; this is the case because we have a corresponding role to be able to see everything. In order to restrict the data and the selection of objects, we must create our own role. To do this, we go to the "Maintain Business Roles" app (F1492) and create a new role using the "Create" button. We then assign the Business Catalog to the role.
In the "General Role Details" tab you should then set "Read, Value Help" to Restricted. This makes it possible to limit the authorizations with the stored objects.
Use the "Maintain Restrictions" button in the upper area, we come to maintaining the authorizations and can set the demarcation more precisely.
- Object Name - demarcation of the table or the Core Data Service
- Object Fields - demarcation of the general and sensitive data
For "Object Fields" it is possible to delimit the visible data by making restrictions in the object. This means that the additional field settings of the CDB object take effect.
Conclusion
The Custom Data Browser provides SE16 functions to the user, but also adds the option of standard authorization checks in the CDS. Additionally, sensitive data and content can be protected.
Source:
SAP Help - Custom Data Browser
