- SAP Managed Tags:
The need for custom data is nothing new. But these days we want to do it while keeping our core clean and thus we want to look at Key User and on-stack Developer Extensibility, which give a lot of options. Below I attempt to showcase each option relating to having your own "custom data" in S/4HANA, with some pros and cons and when to use which option. To illustrate the options, I'll be doing a bookshop scenario; my company is a bookshop, I have an S/4HANA system and now I need to extend it.
Custom transactional or master data
If you have a need for custom transactional or master data, I would recommend to first look at Custom Business Objects (App on SAP Fiori Apps Reference Library) or Custom Business Configuration (App ). Meaning, if in the old ways you would have created z-table(s) and then generated SAP GUI sm30 maintenance dialog (or even your own ABAP report for maintenance), then you want to use this.
What's the difference? Custom Business Configuration are meant for customizing tables, rather than actual "objects". Simpler data that often has more simple maintenance. Custom Business Objects are meant to represent an actual object that does not yet exist in the system. In the end, both apps do something similar: generate a BO with CDS views and OData service.
Custom Business Configuration objects have the "advantage" that they don't need their own separate Fiori app (as I explain below) but the data maintenance happens in the Custom Business Configuration app, with a nice and simple Fiori UI, all generated for you. Here is a tutorial which explains such an example step-by-step, so I won't go further into it (the tutorial is for ABAP Environment on BTP but works as well on-stack in your S/4HANA ABAP environment).
Custom Business Objects, as said, lets us create our own "object": meaning data that has more than just 1 field. In the example of the bookshop, authors of books could be such a custom object. Custom Business Objects even lets us create hierarchical objects; say for example we even would like to be able to enter one or more family member of that author, we would not want to do it on the same "level" as the author, but we would have author and then 0 or more family members linked to that author. This is done very easily in Custom Business Objects, as all you need to do is add an extra "Node":
And under "Fields" we enter the needed fields for both nodes:
Important before we publish this, if this is data that needs a "maintenance dialog" or a Fiori app which allows us to create, update, and delete entries for this data, then you want to check under Features "User Interface" if you are on S/4HANA Public Cloud. If not, this option will not be available, and you instead manually check "Back End Service" (which is checked automatically after selecting User Interface for Public Cloud).
As seen above, if we need to add some logic before we want to save data (on update and before save), we can also check "Determination and Validation" (only if we need that).
After publishing, we can write the needed logic (if any at all), we can look at our generated Fiori app, and we can create a tile for it, so we can add it to the Fiori Launchpad of the users needing this app. On Private Cloud or On Premise we have a few extra steps to take; using the generated OData service (its name is listed underneath "Back End Service"), we can generate our own Fiori Elements Application on SAP BTP with Business Application Studio. The con here is of course that we need to do this as an extra step. The pro is that we can fully decide how the UI should look like. Once we are done with the UI, we can deploy the app to our system, generate tile and target mapping for it and assign to users, as per usual practice.
Hopefully you can see here that we get a lot of functionality "out of the box" while using Custom Business Object's simple user interface. We define our fields, have the possibility for hierarchical data and for public cloud we can even generate a whole Fiori app. This option should therefore be considered first, before you go and create your custom z-table(s) in the dictionary. If you do it that way, you are many steps away from a Fiori App and an old-school SM30 maintenance dialog is not clean core.
Here a screenshot of the final app, which I generated via BAS on SAP BTP without needing to change anything on the UI (all done via Fiori Tools wizard):
What if the data needs NO maintenance app?
As I mentioned, Custom Business Object is perfect when we want to replace old z-tables with sm30. But what if we had z-tables that were filled differently? Maybe from an integration or through a BAdI? Well, the answer is "it depends" 😉. When we talk about integration, we can use the generated CDS to create a REST API service that could be used by the integration. If we create z-table(s), we have to do the CDS part manually. If a REST API won't do the trick, consider how you update the data? In the ABAP Cloud programming model, we don't want to MODIFY/UPDATE/INSERT directly into the database, not even z-tables. Instead we use EML or Entity Manipulation Language, for example:
DATA update_tab TYPE TABLE FOR UPDATE /DMO/R_AgencyTP.
update_tab = VALUE #( ( agencyID = '070001' Name = 'MODIFIED Agency' ) ).
MODIFY ENTITIES OF /DMO/R_AgencyTP " name of behavior definition
ENTITY /DMO/Agency " name of entity to read
UPDATE FIELDS ( name )
WITH update_tab.
COMMIT ENTITIES.
So once again, having a CDS generated can actually save time here. But there are cases where we want to be in full control of the CDS RAP object, then we could start from z-tables and work our way all the way to CDS and behavior definitions and create everything manually; takes time but it's powerful and flexible.
Custom "Name-Value" data
If you need a simple field where you have a couple of static values (which don't change often and don't need any maintenance app) with a descriptive text, then in the old days we would create a domain. Today we can still do it with a domain, or we can use "Code Lists" as they are called in the Key User apps. Code Lists are explained in the next chapter and can be created as "reusable", meaning those code lists are used on custom business object, or directly when adding a custom field to a business context. To showcase the example, I created a domain for the bookshop:
Further below I add a custom field "Book Genre" into Product General Data and book genre uses this domain. So, if the domain has no direct end user exposure, it is very fast and easy to keep using. However, if I would have added the field directly onto Product General Data, then a Code List would have been preferable, because the input will be managed with drop-down that can be typed in, rather than having to open a pop-up for search-help and finding the domain values.
Extend Standard Data with Custom Data
Often just creating our custom data is not enough; we want to somehow combine it with SAP Standard. Here we have several options:
Case 1: Single Fields to be saved on same level as standard
If you have single, non-connected fields to add to a SAP Standard object, we want to use Custom Fields (App on SAP Fiori Apps Reference Library) app and just add field-by-field. Coming back to the bookshop example and the author; we would not want to create field "Author First Name", and another field, "Author Last Name" and then add both to the Product Master Data, for example. But, we could add a field called "Number of Pages of Book", numeric, to the product master data:
Case 2: Single Field where only certain values (from a drop-down) should be selected
When we have a field where we want to restrict what the user enters, we can again use Custom Fields app, and choose as field type "Code List". This lets us then maintain the possible values for users to enter directly in the Custom Fields app. In our example it could be the format of the book:
These values can of course be translated.
The 2nd option is to create a z-Domain/z-table with values in the dictionary, then create a CDS view as value help for those values, and then use that CDS view in Custom Fields, when selecting "Code List based on CDS View". I did this example for Book Genres:
This is in fact great as a "not so good" example. So we have a z-table but we won't create a maintenance dialog for sm30, because it is not clean core. Above I've set "@AbapCatalog.dataMaintenance" as #ALLOWED, meaning we can simply maintain the data in se16n, but also meaning we have no automatic transport of data and so on, and no regular user can do it, nor is it easy to control authorization for users who should be able to maintain this. So the book genre would have been better solved as Custom Business Object, but I wanted to show different options and also to highlight why a z-table maybe isn't the best solution. Next, I have to create CDS views that I can then use in Custom Fields and I need to 2, in order to follow the ABAP Cloud programming model:
- Basic interface view for reading form the database table
- Value help view using the basic interface view
Only now can I got to Custom Fields and add the Book Genre to Product master data:
Wait: what about Custom Reusable Elements - Code List?
If you are familiar with the key user apps you may know of Custom Reusable Elements (App on SAP Fiori Apps Reference Library). We know this app has custom libraries, meaning ABAP code, but also Code Lists. Having talked about using Code Lists in custom fields, when would be use this one then? This is simply put for Custom Business Objects. If your custom business object has a field where you want the restricted values functionality, you would first create it in this app. For example we could have a "popularity" field on the Author custom business object and we would want only few possible values:
When we add a field now in our custom business object (any custom business object), we select as type "Code List" and then pick one.
Case 3: Link Custom Object with Standard
If we have more than just single, disconnected fields, but instead we want to link a Standard object to our own data that has it's own table or even hierarchical tables (as in our author example), then we still use Custom Fields app. In Custom Fields as we add a new field, we can choose "Association to Business Object". If we do, we need to select the business object in the drop down, which includes all our Custom Business Object. For example:
Case 4: Combining data for reports
If our case is not to save master or transactional data, but instead use some custom data for reports, we have several options.
- Use Custom CDS Views (Version 2) (App on SAP Fiori Apps Reference Library) to combine existing CDS views together for reporting (if your custom data has no CDS view yet, which it will have if you used Custom Business Object, you can get a developer to create one for you, option 3)
- Use Custom Analytical Queries (App on SAP Fiori Apps Reference Library) if you need analytical capabilities with measures, dimensions, calculations, and so on. This app needs an analytical cube or query CDS, which a developer can create for you if not yet existing - option 3
- Use on-stack development to create your own custom CDS views (analytical or transactional) and create any report and combination of standard and custom CDS views. This option can be used together with the first 2 above, or can even be used to create a custom reporting Fiori app with BAS on SAP BTP. This is the most powerful of all the options and allows for a lot freedom on creating exactly what you need. This can also be used if the data needs to be exposed as API to integrations or other purposes
Summary
I'm sure there are lots more cases for custom data and I doubt I can list them all. But the above show cases how to do it with key user apps and how they can help to do it faster, simpler, and have a nice user interface for the end user with input help. If you have a specific case you wonder about, just drop a comment and ask 😊 Hope this was helpful!
16 Comments
