Business Configuration in SAP BTP ABAP Environment...

ThomasSchneider · ‎10-01-2021

In my blog post Business Configuration in SAP BTP ABAP Environment (1): Overview and BC Maintenance Apps I provided an overview on how to create business configuration maintenance apps in SAP BTP ABAP Environment.

However, business Configuration content is normally not directly maintained in a production environment, but it is created in a content development environment and transported/deployed to the test and production environment. In this blog post, I want to share some details on BC content transport that is available for SAP BTP ABAP Environment.

Before we discuss solutions, let us have a look at typical system/tenant setups for the SAP BTP ABAP Environment. The following figure shows customer tenant landscape, which consists of 3 instances of the SAP BTP ABAP Environment service serving as development, test, and production instance. For simplicity, we call an instance of the SAP BTP ABAP Environment service an ABAP system, because it behaves very similar as an ABAP system that you may know from the on-premise world. In this landscape, you have a “main line” of one tenant (ABAP client) per system, labeled as “100” in the figure. Software is transported along the main line from dev to test and prod. The process is described e.g. in the following help document:

(For larger development projects, a 3-system landscape may be not sufficient, and systems may be added to have a development and a maintenance code line. A typical setup with 5 systems is described here. The principles that I want to discuss are valid for a 3-system landscape or for a 5-system landscape. To keep this blog post simple, I will refer to a 3-system landscape only.)

Transport technology powered by gCTS is used to transports development object between SAP BTP ABAP Environment instances (aka systems). (I have added some link on gCTS in the SAP BTP ABAP Environment at the end of this blog post.) The same technology is used for transporting business configuration. But there is one important difference between development objects and business configuration:

Development objects are client-independent and they are available in the entire system after import.

Business configuration is client-dependent (same as master or transactional data), and after import, it is only available in the client where the import was executed. This is why in Figure 1, I have depicted a box labeled “100” to show this client behavior. Since some time, ABAP Environment instances can be operated with multiple clients (see Section Business Configuration and Multiple Clients below for details)

Process Overview on Transporting Business Configuration

The process of transporting business configuration covers the following aspects:

If business configuration is relevant for transport, it must be recorded on a transport request. The transport request is either managed (determined, created) automatically when business configuration data it saved, or it is selected explicitly by the configuration expert. When a transport requests is released (in the Fiori UI or in the Eclipse UI), the data a pushed into a Git repository. This means that a Git repository must be available (cloned) in a system before you can create transport requests (Exception: you can create a transport requests of type “local” that cannot be released/exported; these requests can be created without cloning of a Git repository.) After the configuration data are pushed to a repository, they can be pulled into subsequent system (test, production, …).

Transport Patterns

You can use one of the following transport patterns:

1. Isolated tenants – no transports

The tenant is isolated. Business Configuration can be created but is not imported or exported. (Note: All Consumer tenants (>=200) in Steampunk MT systems fall into this category, as Git repos cannot be cloned/pushed/pulled in these clients.)

Procedure:

No SWC/Git repo is cloned in this tenant

In the Export Customizing Transport Fiori app, and create a transport request. (The system creates a local request with category “Default”) [role: BPC_EXPERT]

Configuration is recorded on this request [role: BPC_EXPERT or any other role that has authorization for BC apps]

2. Simple – Transports via SWC of type “Business Configuration” and default transports

Business configuration is transported via a software component of type “Business Configuration”

Procedure:

In the Manage Software Component Fiori app, create a software component of type “Business Configuration”, clone it to the tenant where business configuration is created [role: ADMINISTRATOR]

In the Export Customizing Transport Fiori app, and create a transport request. (The system creates a request with transport target hat relates to the SWC/Repo created in the previous step and with category “Default”) [BPC_EXPERT]

Configuration is recorded on this request [BPC_EXPERT or any other role that has authorization for BC apps]

In the Export Customizing Transport Fiori app, release the request [BPC_EXPERT]

Repeat from 2.

In exceptional cases (e.g. an urgent pre-import that must be done in parallel to the default request), customers can create a 2nd request of category “MANUAL” using ADT (see below for details). Users that work on the exceptional cases can record their changes on the 2nd request (prerequisite is that the maintenance UI supports transport selection, e.g. Spaces&Pages, custom BCOs).

3. Multiple SWCs/Git Repos– transports via SWCs/Repos of type “Development”

Customer runs multiple separated development projects in parallel at separated timeline and in multiple software components/Git Repos. The configuration shall be transported together with the development via respective SWCs/Repos of type “Development”

Procedure:

In Manage Software Component Fiori app, create software components of type “Development”, clone them to the tenant where development and business configuration is created [role: ADMINISTRATOR]

In the Export Customizing Transport Fiori app, and create a transport request for each software component and assign them to the transport layer that refers to the respective software component/Git Repo) [BPC_EXPERT]

Users can record their changes on the request that refers to their (prerequisite is that the maintenance UI supports transport selection, e.g. FLP spaces & pages, custom BCOs*).Users that create Configuration is recorded on this request [BPC_EXPERT or any other role that has authorization for BC apps]

In Export Customizing Transport Fiori app, release the request [BPC_EXPERT]

Repeat from 2)

* In custom BCOs, customers can autofill the transport request based on the software component of the customizing table.

Exceptional cases (e.g. a preimport): same as under 2.

Process Details

Software component (Git repository): When a transport request is released (in the Fiori UI or in the Eclipse UI), the data a pushed into a Git repository. The Git repository is 1-to-1-related to a software component, and is managed (created, deleted, cloned, pulled, …) in the Fiori app Manage Software Collection. Therefore, you must create and clone a Git repository in a system before you can create transport requests, see the links on gCTS at the end for details). The Manage Software Collection app support two types of software components: type Development and type Business Configuration. You must decide which type you want to use for transporting business configuration:

You can create a software component of type Business Configuration and transport all your configuration via this software component. This is a very simple way and has advantages that we will reveal when we discuss the transport request handling. Note that there can be only one software component of type Business Configuration in a tenant.

You can transport the configuration using the software components that you also use for your development objects (typically the same software component for table and table content). This is advisable if you run multiple projects on the same landscape that are well separated and have decoupled time schedules.

Transport requests: If business configuration is relevant for transport, it must be recorded on a transport request. Development objects are recorded on transport requests of type “Workbench”, business configuration is recorded on requests of type “Customizing”. Requests for development objects are created and managed (e.g. released) in the Eclipse-based ABAP development tools (ADT, documentation, ), requests for business configuration are created and managed in the BC maintenance Fiori apps and in the Fiori app “Export Customizing Transports” (documentation).

Note that customizing requests can be also managed using ADT (Transport Organizer). For some expert tasks the ADT tool is the more powerful one.

Figure: Export Customizing Transport Fiori App

Transport request selection: During development, developers are used to create or select a transport request when creating or changing an object. Customers have the following option:

Explicit selection of the transport request. Option 1 and 2 hide the transport request handling from the business user. If complex business configuration is required, working with multiple parallel transport requests, and thus, a manual selection of the transport request is required. Alternatively, customers can decide that users should explicitly select transport requests using a value selection.

The tutorial provides the implementation guidance for this process.

Business Configuration and Multiple Clients

For application and configuration tables, SAP recommends including the ABAP client in the table structure. This means this table are client-dependent. For client-dependent tables, the content is separated in the different clients. For details, refer to the guideline Development Guideline to Enable Multitenancy of Products Built on the ABAP Environment. If you want to transport table content to all clients of a system, you can use tables without ABAP client of delivery type “S”.

Customers and partners can use multiple clients in the same system. However, business configuration transport into clients <> 100 (“main line”) are not supported yet. This is a limitation SAP is currently working on. For the time being, the options in a system with multiple clients are:

Use the generic BC file download/upload functionality as introduced in the previous blog post here

Provide “template content” using client-independent tables (without ABAP client, of delivery type “S”).

Links

The transport technology of the SAP BTP ABAP Environment (Git based gCTS) is described in the following documents:

Blog post Software Lifecycle Management for SAP Cloud Platform ABAP Environment

Tutorial Transport a Software Component Between Two ABAP Systems

Documentation on transport management: https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/5c7b17d68bb7427d93ff2086f01...

Steven_UM · ‎10-27-2022

Hi Thomas,

Great insights ... thanks for these blog series.

I got a remark and a question.

Regarding point 3.2 - I believe there is a typo in your text "MANAUAL_CUST". Furthermore it took me a while to grasp that your provided the attribute value but not the actual attribute name. So after some tryouts I came to the following attributes that need to be added before the custom created customizing transport request shows up in the 'Export TR Requests' Fiori App:

SAP_ATO_TRANSPORT_TYPE =  BC

SAP_CUS_TRANSPORT_CATEGORY = MANUAL_CUST

And then my question.

So the described activities are all for customizing data that we want to transport. But what about customizing data that needs to be maintained directly in a system ( so each system needs to be setup directly - cfr SM30 with 'no transport' ). Is it simply a matter then of generating the same business configuration objects but disable transport somewhere ?

Thanks,

Steven

ThomasSchneider · ‎10-31-2022

Thanks for the comment. I added the attributes to the blog text. In future, it will be possible to select the transport target (= Git repo) directly in the Fiori UI. This means tool break into ADT will be obsolete!

Your question: Yes, you proposal would be my recommendation also. Just generate the business configuration app as described in the tutorial https://developers.sap.com/group.abap-env-factory.html and then just remove the parts for transport in the app. In the future, the generator may also provide more options to generate different variants.

Best regards, Thomas

Steven_UM · ‎09-05-2023

Hi Thomas,

It has been almost a year since I asked my previous question on how to handle business configuration and disabling transport requests. In the meanwhile we have developed over 20 BC configuration apps and had plenty of experience with the whole approach.

We are almost ready to actually start moving our (huge) developments for the first time into a next environment and thus I came to revisit your blog(s). Having done so I came up with some new 'findings' and hence some new 'questions'.

Having to manually select a transport request each time a change is done, was one of my frustrations, especially because there exists only 1 (dev compononent ) related. I just found your blog section on 'Automatic selection of a transport request' and you refer to a tutorial where that would be explained. I looked at all the (sub)tutorials but cannot find any information on that subject.
We have 'disabled' the recording of some of the configuration changes as per my above question/suggestion. Now reading the transport blogs I noticed that one has to define a 'test'/'prod' system as 'non-development' in order to 'disallow changes'. I was wondering how this setting then impacts the editing of business configuration ? Will we still be able to maintain BC data for those tables that we deem to be 'non-transportable' and thus should be 'maintained' within a test or production system directly.

Thanks,

Steven

ThomasSchneider · ‎09-07-2023

Hi Steven,

thank you for sharing your experience.

1. On "Having to manually select a transport request each time a change is done".

Unfortunately my blog got outdated with regards to the section 'Automatic selection of a transport request' so I have to remove it.

But there is light at the end of the tunnel. RAP will provide an "default values function" so that we can set a default transport request when the "transport" button is clicked.

2. The system setting as 'non-development' does not have any impact on the editing of business configuration.

If you want to make a business configuration app read-only, you would have to provide a business role which is read-only. See the documentation for Authorization Control for details: https://help.sap.com/docs/sap-btp-abap-environment/abap-environment/authorization-control -> "Whether or not the user has write or read authorization is finally defined in the General Role Details section of the Business Role the Business Catalog with this IAM app is assigned to."

Steven_UM · ‎09-07-2023

Hi Thomas,

Thanks for your fast reply.

Good to know this is being looked at. I have implemented my own 'logic' that basically defaults the transport request if only one customizing is found.

2. Ah interesting. So if I understand this correctly then we will actually have to provide 2 'business catalogs' - one for the apps that support transport and should thus not be editable in PRD and one for the apps that do not support transport and should be editable. As such we can craft a business role in PRD that would then disable edit for 1 catalog while keeping it for the other.

Thanks,

Steven

ThomasSchneider · ‎09-07-2023

Hi Steven,

on 1) thank you for sharing this. This is of course a valid solution. However we got the feedback from customers that they want to show the transport before a user hits save. This is why we will go for a defaulting before the save once the aforementioned RAP event is available.

on 2) Yes exactly.

Best regards,

Thomas

.

Steven_UM · ‎10-09-2023

Hi Thomas,

Regarding point (2) and putting business configuration in 'read-only' modus. I am afraid the expected behaviour is not working 'as expected'.

So what did I do ?

(a) I separated my apps into different business catalogs based upon the need for having them 'read-only' or not in production.

(b) I created separate business roles in PRD. The business role which has the catalog for 'read only' has a general 'write' attribute put to 'no access'.

So what are my observations:

(1) If I assign both roles to my user then I am getting 'edit' access to ALL BC ( so even for the tables from the 'read only' business role business catalog ).

(2) If I remove the business role which has 'edit' access then it works and the read only table entries cannot be edited.

So it seems that once you add a 'write' access role for any BC table then it activates 'edit' for all of them. Am I doing something wrong conceptually or is this a 'feature bug' ?

Kr,

Steven

ThomasSchneider · ‎10-10-2023

Hi Steven,

this is exactly the expected behavior. Authorizations are always additive. So if you want to have an app read-only, you should assign only the role which has the property 'write' = 'no access'.

If you only want to edit in the dev system, then do not transport the role with 'write' = 'unrestricted' to production.

Best regards,

Thomas

.

Steven_UM · ‎10-10-2023

Hi Thomas,

Thanks for your quick feedback.

I understand the additive behavior. That's only logical. My case however was that the 2 business roles contained different tables. So once the 2nd role was added with WRITE access to DIFFERENT tables then ALL tables received write access.

Now I started ofc with one very old business role - which I then edited by removing IAM apps and moved those to a new role. I have the suspicion however that - although the entries are removed, activated and published - that somehow this 'old' version still impacts the check. There is really no other logical way to explain the behavior.

I am gonna restart over and delete the old role and create a new one.

In addition I am also witnessing strange behaviors on DEV as well. Again it has something to do with publish issues I think. I have IAM apps that have status 'unpublished'. I replubish and all goes fine - no issues - but still the status remains 'unpublished'.

Would an unpublished IAM app have an impact on the authorisation check ? What I am witnessing is very very bizar. I have only a display role assigned - write 'no access' - and still the authorization check on activity '02' passes fine. On some other object with the same role it does not pass and thus correctly disables edit. The only difference I found is this 'publish' status of the iam apps.

Auth check is fine while role has no write

This is starting to drive me a bit mad 😛

Steven_UM · ‎10-10-2023

Hi Thomas,

I can unfortunately confirm that the same behavior happens in our brand new PRD instance with a brand new user.

Observations:

(1) Assign the read-only role to the new user

(2) BC app displays all custom objects with edit button disabled

huray !

(3) Assign another custom role to the same user. The role has nothing to do with business custom configuration or apps.

(4) Reopen BC app. Some objects have the edit button enabled.

cry !

Why .. no clue.

I am going to raise a SAP support ticket as I can't find any reasonable logic why this is happening.

Steven

ThomasSchneider · ‎10-12-2023

This sounds weird. I think an incident is the right approach.