Do you want to know how you can transport key user custom fields from one S/4HANA Public Cloud development system to another system using abapGit?
This is especially interesting for SAP partners who already transport their developer extensibility artifacts (RAP business objects, classes, CDS views,…) to their customers using abapGit but so far could not do that with key user custom fields.
If your answer is yes, then this blog post is just for you.
This blog post covers the following topics:
Experience shows that whenever partners (or IT departments especially in rather large companies) develop additional functionality that extends the S/4HANA standard functionality almost always custom fields are involved to extend respective SAP standard objects. Till date it was possible to export development objects from the partner system into several customer systems using abapGit except for custom fields. The only way to transport key user custom fields from one S/4HANA Public Cloud system to another was to use SAP’s extensibility templates. But using this approach did involve another transport tool which is superfluous if everything else is transported using abapGit.
This changes now with the 2302 release of S/4HANA Public Cloud as with this release SAP also supports the transport of key user custom fields using abapGit.
That means from 2302 on a partner can export a complete partner solution consisting of developer extensibility and key user custom fields from the partner system landscape into customer system landscapes using abapGit.
As there are some specific aspects to be considered which differ from what must be done if only developer extensibility objects are used the complete process based on a demo solution example is explained in this blog.
The following picture illustrates the overall process.
The next four chapters describe what is needed to get the demo solution from the partner system landscape to an external git repository. If you are more interested in installing the demo solution you can skip to ‘Install example solution from git repository’.
The demo solution consists of an SAP ‘Manage Sales Order’ demo application. As an SAP partner I have extended this existing application with two key user custom fields ‘OMG Rating’ and ‘Deal Size’. These two fields and the implementation how to calculate them represent the business value of my partner solution that I offer to my customers.
The two key user custom fields ‘OMG Rating’ and ‘Deal Size’ represent the key user custom field part of the demo solution.
In a simple scenario the business logic to calculate these fields could be implemented completely using key user extensibility and using SAP’s extensibility templates for transport would be the recommended solution.
But this blog concentrates on the complex scenarios of shipping larger pieces of functionality. Functionality where a lot of specific business logic is needed to calculate the key user custom fields and the features of developer extensibility are needed to get the job done as a lot of different developer extensibility artifacts (RAP business objects, classes, CDS views, Database tables, Data elements, ...) would be needed to implement the required functionality. In this case it is highly recommended to store all these objects in one ABAP package or subpackages of this package as abapGit works by linking one ABAP package and its subpackages to exactly one git repository.
However, to keep things simple in this example the ABAP package ‘ZDS_TSHIRT_01’ only contains one ABAP class ‘ZDS_CL_TSHIRT_01’ which calculate and updates the two key user custom fields. But keep in mind, that in a real world example this package would contain a lot of developer extensibility objects.
To avoid naming conflicts key user custom fields created in the default YY1_ namespace cannot be transported to any system outside of their own system landscape.
The app ‘Extensibility Settings’ is also used to assign users to this namespace. If a user, who is assigned to the abapGit namespace, creates key user custom fields, these fields will be created starting with the abapGit namespace (here YYS7947382) instead of YY1_ and thus can be transported using abapGit.
Customer customizing tenants will not allow the installation of key user custom fields from an unknown namespace. Instead, namespaces have to be registered in the customer system as described in chapter ‘Customer Customizing Tenant: Register abapGit namespace’. The registration file needed for this step has to be created in the partner customizing tenant. This is done in the app ‘Extensibility Settings’ using the option ‘Download Installation File’. As the registration file is specific for a customer customizing tenant you have to be careful to enter the correct ‘Consumer Tenant URL’ as shown below:
To work with abapGit the ABAP Development Tools (ADT) and the abapGit plugin is needed. You find installation instructions here.
To export key user custom fields to a git repository this has to be created at the git provider of your choice (e.g. github.com). In this example the repository is called ‘key-user-etj-100'.
The key user custom fields are part of ABAP package TEST_YY1_DEFAULT. This is a fixed package and cannot be changed. This package TEST_YY1_DEFAULT has to be linked to the repository ‘key-user-etj-100’ in ADT view 'abapGit Repositories' as shown here:
Next step is to ‘Stage and Push’ the changes to the git repository. The ADT view ‘abapGit Staging’ will provide a list of all key user custom fields that can be added to the git repository:
Be aware that only key user custom field from abapGit namespace will be shown in this list. In addition, key user custom fields can only be exported to abapGit from the customizing tenant. Make sure you are working in the right tenant.
Once you stage your changes and commit them the key user custom fields will show up in the git repository:
To export developer extensibility content almost the same procedure must be followed. As developer extensibility content belongs to the development tenant these steps have to be executed in the development tenant and a separate git repository is needed. In this example the second repository is called ‘ZDS-TSHIRT-01-ETJ-100’.
The package of the demo solution (‘ZDS_TSHIRT_01’) is linked to the repository ‘ZDS-TSHIRT-01-ETJ-100’ and all content from this package can be pushed to the git repository using ‘Stage and Push’ in ADT:
Based on the work done in ‘Transfer the demo solution to a git repository’ an important milestone was reached: The complete demo solution is stored in two git repositories and ready to be installed in any number of customer system(s). The next three chapters describe the steps how to do this in detail.
As mentioned in ‘Partner Customizing Tenant: abapGit namespace’ the abapGit namespace must be registered in the customer customizing tenant before key user custom fields can be installed from abapGit. This is done in the app ‘Extensibility Settings’ by using the ‘Register’ action and uploading the registration file from the previous chapter:
Once the abapGit namespace is installed the key user custom fields can be installed from the git repository. As in ‘Partner Customizing Tenant: Export Key User Custom Fields to abapGit’ the ABAP package TEST_YY1_DEFAULT has to be linked to the abapGit repository (key-user-etj-100). Once this is done the action ‘Pull…’ allows to install all custom fields from the repository in the system.
The new fields will be visible in the ‘Custom Fields and Logic’ app directly after import:
All content installed from abapGit is installed in an inactive version. For key user custom fields this means the original status will be ‘Not published’ for all imported fields. Thus, the final step to make sure that the fields of the demo solution are usable is to publish them in the ‘Custom Fields and Logic’ app.
In this last step, the developer extensibility artifacts are installed. Thus, an ABAP package has to be created in the customer development tenant and linked to the corresponding git repository (ZDS-TSHIRT-01-ETJ-100). Again, the action ‘Pull…’ from the abapGit plugin is used to fetch all content from the repository. As these are ABAP objects they have to be activated in ADT:
Congratulations! The demo solution is now completely installed in the customer development system. All objects of the demo solution are now successfully installed in the system. The last step is to make sure that the fields are displayed properly and make final customer specific adjustment if needed.
As key user custom fields are automatically added to the corresponding UIs and Services, they are directly available for consumption. Either as additional new columns in tables or as additional fields that can be made visible using ‘Adapt UI’ functionality:
With the new feature of S/4HANA Public Cloud release 2302 it is now possible to transfer a complete partner solution including key user custom fields to a customer systems using abapGit.
But be aware. This is a point to point transfer. Once the content is transferred to the customer system, the lifecycle is completely up to the customer. There is no separation of partner or customer content. The objects behave as if developed in customer system directly. Thus, this approach is best used as a baseline installation for content that is further adopted or adjusted in the customer system landscape based on individual project needs.
Please note that in order to be able to implement and transport your own solution, you need users in the development tenant and in the customizing tenant having at least the following business catalogs (within SAP S/4HANA Cloud):
Partner System Landscape:
Customer System Landscape:
You’re cordially invited to provide them in the comments section below. Also, please follow my profile to get updates when I publish more posts on these topics.
Also feel invited to post and answer general questions concerning
SAP S/4HANA Cloud Extensibility here.
I want to thank georg.wilhelm and Christian Holzer for their extremely helpful contributions.
Software Lifecycle Management for SAP Cloud Platform ABAP Environment
Custom Fields in S/4HANA: Key User versus Developer Extensibility
This is especially interesting for SAP partners who already transport their developer extensibility artifacts (RAP business objects, classes, CDS views,…) to their customers using abapGit but so far could not do that with key user custom fields.
If your answer is yes, then this blog post is just for you.
This blog post covers the following topics:
- How to get a namespace and install it in the respective target system(s)
- How to export the key user custom field into a git repository out of the partner development system
- How to import the key user custom field from this git repository into the customer(s) development system
- How to publish(activate) the custom field in the customer(s) development system
Experience shows that whenever partners (or IT departments especially in rather large companies) develop additional functionality that extends the S/4HANA standard functionality almost always custom fields are involved to extend respective SAP standard objects. Till date it was possible to export development objects from the partner system into several customer systems using abapGit except for custom fields. The only way to transport key user custom fields from one S/4HANA Public Cloud system to another was to use SAP’s extensibility templates. But using this approach did involve another transport tool which is superfluous if everything else is transported using abapGit.
This changes now with the 2302 release of S/4HANA Public Cloud as with this release SAP also supports the transport of key user custom fields using abapGit.
That means from 2302 on a partner can export a complete partner solution consisting of developer extensibility and key user custom fields from the partner system landscape into customer system landscapes using abapGit.
As there are some specific aspects to be considered which differ from what must be done if only developer extensibility objects are used the complete process based on a demo solution example is explained in this blog.
The following picture illustrates the overall process.
Transport from partner development system to customer development system using abapGit
Transfer the Demo Solution to a Git Repository
The next four chapters describe what is needed to get the demo solution from the partner system landscape to an external git repository. If you are more interested in installing the demo solution you can skip to ‘Install example solution from git repository’.
Demo Solution
The demo solution consists of an SAP ‘Manage Sales Order’ demo application. As an SAP partner I have extended this existing application with two key user custom fields ‘OMG Rating’ and ‘Deal Size’. These two fields and the implementation how to calculate them represent the business value of my partner solution that I offer to my customers.
SAP application enhanced by two key user custom fields
The two key user custom fields ‘OMG Rating’ and ‘Deal Size’ represent the key user custom field part of the demo solution.
abapGit transportable Key User Custom Fields as shown in app Custom Fields and Logic
In a simple scenario the business logic to calculate these fields could be implemented completely using key user extensibility and using SAP’s extensibility templates for transport would be the recommended solution.
But this blog concentrates on the complex scenarios of shipping larger pieces of functionality. Functionality where a lot of specific business logic is needed to calculate the key user custom fields and the features of developer extensibility are needed to get the job done as a lot of different developer extensibility artifacts (RAP business objects, classes, CDS views, Database tables, Data elements, ...) would be needed to implement the required functionality. In this case it is highly recommended to store all these objects in one ABAP package or subpackages of this package as abapGit works by linking one ABAP package and its subpackages to exactly one git repository.
However, to keep things simple in this example the ABAP package ‘ZDS_TSHIRT_01’ only contains one ABAP class ‘ZDS_CL_TSHIRT_01’ which calculate and updates the two key user custom fields. But keep in mind, that in a real world example this package would contain a lot of developer extensibility objects.
Partner Customizing Tenant: Setup abapGit Namespace
To avoid naming conflicts key user custom fields created in the default YY1_ namespace cannot be transported to any system outside of their own system landscape.
Extensibility Setting app with abapGit Namespace YYS7947382
The app ‘Extensibility Settings’ is also used to assign users to this namespace. If a user, who is assigned to the abapGit namespace, creates key user custom fields, these fields will be created starting with the abapGit namespace (here YYS7947382) instead of YY1_ and thus can be transported using abapGit.
Customer customizing tenants will not allow the installation of key user custom fields from an unknown namespace. Instead, namespaces have to be registered in the customer system as described in chapter ‘Customer Customizing Tenant: Register abapGit namespace’. The registration file needed for this step has to be created in the partner customizing tenant. This is done in the app ‘Extensibility Settings’ using the option ‘Download Installation File’. As the registration file is specific for a customer customizing tenant you have to be careful to enter the correct ‘Consumer Tenant URL’ as shown below:
Creating a Registration File in the Partner Customizing Tenant
Partner Customizing Tenant: Export Key User Custom Fields to abapGit
To work with abapGit the ABAP Development Tools (ADT) and the abapGit plugin is needed. You find installation instructions here.
To export key user custom fields to a git repository this has to be created at the git provider of your choice (e.g. github.com). In this example the repository is called ‘key-user-etj-100'.
The key user custom fields are part of ABAP package TEST_YY1_DEFAULT. This is a fixed package and cannot be changed. This package TEST_YY1_DEFAULT has to be linked to the repository ‘key-user-etj-100’ in ADT view 'abapGit Repositories' as shown here:
Package TEST_YY1_DEFAULT linked to git repository for key user custom fields
Next step is to ‘Stage and Push’ the changes to the git repository. The ADT view ‘abapGit Staging’ will provide a list of all key user custom fields that can be added to the git repository:
Key user custom fields can be staged and committed to git repository
Be aware that only key user custom field from abapGit namespace will be shown in this list. In addition, key user custom fields can only be exported to abapGit from the customizing tenant. Make sure you are working in the right tenant.
Once you stage your changes and commit them the key user custom fields will show up in the git repository:
Final result: Key user custom field of demo solution are stored in git repository
Partner Development Tenant: Export Developer Extensibility Content to abapGit
To export developer extensibility content almost the same procedure must be followed. As developer extensibility content belongs to the development tenant these steps have to be executed in the development tenant and a separate git repository is needed. In this example the second repository is called ‘ZDS-TSHIRT-01-ETJ-100’.
The package of the demo solution (‘ZDS_TSHIRT_01’) is linked to the repository ‘ZDS-TSHIRT-01-ETJ-100’ and all content from this package can be pushed to the git repository using ‘Stage and Push’ in ADT:
Final result: Second git repository storing all developer extensibility objects of the demo solution
Install Demo Solution from Git Repository
Based on the work done in ‘Transfer the demo solution to a git repository’ an important milestone was reached: The complete demo solution is stored in two git repositories and ready to be installed in any number of customer system(s). The next three chapters describe the steps how to do this in detail.
Customer Customizing Tenant: Register abapGit Namespace
As mentioned in ‘Partner Customizing Tenant: abapGit namespace’ the abapGit namespace must be registered in the customer customizing tenant before key user custom fields can be installed from abapGit. This is done in the app ‘Extensibility Settings’ by using the ‘Register’ action and uploading the registration file from the previous chapter:
Register abapGit Namespace in customer customizing tenant
Customer Customizing Tenant: Import and Activate Key User Custom Fields from abapGit
Once the abapGit namespace is installed the key user custom fields can be installed from the git repository. As in ‘Partner Customizing Tenant: Export Key User Custom Fields to abapGit’ the ABAP package TEST_YY1_DEFAULT has to be linked to the abapGit repository (key-user-etj-100). Once this is done the action ‘Pull…’ allows to install all custom fields from the repository in the system.
The new fields will be visible in the ‘Custom Fields and Logic’ app directly after import:
Key user custom fields of demo solution are imported inactive and must be published
All content installed from abapGit is installed in an inactive version. For key user custom fields this means the original status will be ‘Not published’ for all imported fields. Thus, the final step to make sure that the fields of the demo solution are usable is to publish them in the ‘Custom Fields and Logic’ app.
Customer Development Tenant: Import and Activate Developer Extensibility Content in abapGit
In this last step, the developer extensibility artifacts are installed. Thus, an ABAP package has to be created in the customer development tenant and linked to the corresponding git repository (ZDS-TSHIRT-01-ETJ-100). Again, the action ‘Pull…’ from the abapGit plugin is used to fetch all content from the repository. As these are ABAP objects they have to be activated in ADT:
Demo solution developer extensibility objects have been pulled from git repository
Check the Final Application
Congratulations! The demo solution is now completely installed in the customer development system. All objects of the demo solution are now successfully installed in the system. The last step is to make sure that the fields are displayed properly and make final customer specific adjustment if needed.
As key user custom fields are automatically added to the corresponding UIs and Services, they are directly available for consumption. Either as additional new columns in tables or as additional fields that can be made visible using ‘Adapt UI’ functionality:
SAP demo sales order app enhanced by demo solution
Summary
With the new feature of S/4HANA Public Cloud release 2302 it is now possible to transfer a complete partner solution including key user custom fields to a customer systems using abapGit.
But be aware. This is a point to point transfer. Once the content is transferred to the customer system, the lifecycle is completely up to the customer. There is no separation of partner or customer content. The objects behave as if developed in customer system directly. Thus, this approach is best used as a baseline installation for content that is further adopted or adjusted in the customer system landscape based on individual project needs.
Technical Details
Please note that in order to be able to implement and transport your own solution, you need users in the development tenant and in the customizing tenant having at least the following business catalogs (within SAP S/4HANA Cloud):
Partner System Landscape:
- User in the development tenant - the following business catalogues have to be assigned:
- All business catalogues from Business Role Developer (SAP_BR_DEVELOPER)
- User in the customizing tenant - the following business catalogues have to be assigned:
- All business catalogues from Business Role Extensibility Specialist (SAP_BR_EXTENSIBILITY_SPEC)
- Business catalogue SAP_A4C_BC_DEV_SUP_PC
Customer System Landscape:
- User in the development tenant - the following business roles have to be assigned:
- All business catalogues from Business Role Developer (SAP_BR_DEVELOPER)
- User in the customizing tenant - the following business roles have to be assigned:
- All business catalogues from Business Role Extensibility Specialist (SAP_BR_EXTENSIBILITY_SPEC)
- Business catalogue SAP_A4C_BC_DEV_SUP_PC
Feedback, Comments, or Questions:
You’re cordially invited to provide them in the comments section below. Also, please follow my profile to get updates when I publish more posts on these topics.
Also feel invited to post and answer general questions concerning
SAP S/4HANA Cloud Extensibility here.
I want to thank georg.wilhelm and Christian Holzer for their extremely helpful contributions.
Other related blog posts:
Software Lifecycle Management for SAP Cloud Platform ABAP Environment
Custom Fields in S/4HANA: Key User versus Developer Extensibility
- SAP Managed Tags:
4 Comments
