Last year, SAP officially launched the 3SL in S/4HANA Cloud, public edition. This three-system setup offers scalability in ABAP development in ADT, allowing developers to create projects on SAP S/4HANA Cloud, and leverage the benefits of custom ABAP code for development extensions. From an analytical perspective, what are the advantages of report development under the three-system Landscape compared to the two-system Landscape only has key user extensibility? What limitations of the two-system embedded analytics can be overcome? This blog post will explore the differences in report development under these two using a customer use case.

Customer Use Case Introduction:

The customer is a high-tech enterprise integrating R&D, manufacturing, and sales. In their daily production process, the business personnel hope to view the inventory time of the production materials within the system, i.e., the “stock age”. Unlike traditional stock age reports, this customer places a greater emphasis on batch management. They need to trace back to the earliest storage time of the batch of materials, without considering transfer between warehouses, to calculate the stock age of the batch.

The client’s requirements are roughly as follows:

2 System Landscape:

The 2SL provides key user extensibility for development. Using scalable applications, key users can create segmented database tables and design queries.

Based on analysis, the data sources needed for the report have been released and can be used for key user extensions: I_MaterialDocumentItem_2 and I_MaterialStock_2. I_MaterialDocumentItem_2 is primarily used to obtain the material storage time, thus calculating the storage age. I_MaterialStock_2 can obtain the material inventory quantity at a specified time. By associating these two data sources, the user’s required report can be obtained, but the following limitations have been found when using key user application development:

• Custom CDS View APP: Date type fields cannot be aggregated.

           In this use case, it is necessary to obtain the earliest storage time of the material, so aggregation (i.e., Min()) must be performed on the date in the material voucher. However, the Date is a Dimension, and APP cannot directly aggregate the fields of the Dimension.

Custom CDS Views

A workaround for reference: create a new calculation (measure), such as calculating the number of days, and aggregate the new calculation.

• Custom CDS View APP: CDS dimensions cannot be adjusted.

           According to the customer’s analysis needs, the customer needs to find the earliest storage time based on the material + batch + warehouse, that is, the transfer of the warehouse location does not affect the calculation of the storage age.

          However, in the APP, the dimensions of the CDS cannot be adjusted, that is, the groupby operation cannot be performed on the warehouse location dimension of the material voucher.

• Manage KPI and Reports APP: A single table does not support the display of measures from two different data sources.

          Measures from different data sources cannot be added to the same table for display.

• Custom CDS View APP: Union operations are not supported.

          Only left joins are supported within the APP.

Due to the above limitations of the key user APP, using CDS I_MaterialDocumentItem_2 and I_MaterialStock_2 cannot perform Group by and join as required, so this customer use case cannot be implemented within the 2SL.

3 System Landscape:

The 3SL offers scalability for development, allowing for report development through code writing.

Given the requirements of this use case, by using group by and aggregation, we can quickly obtain the earliest storage time for materials + batch + warehouse based on CDS I_MaterialDocumentItem_2. This solves the limitation issue within the key user APP.

define view ZXXXXXXX 

  as select from I_MaterialDocumentItem_2 

{ 

  key  Plant, 

  key  Material, 

  key  Batch, 

       min(PostingDate) as EPostigDate 

} 

where 

  ReversedMaterialDocument = '' 

group by 

  Plant, 

  Material, 

  Batch 

The final query is as follows:

Query

Moreover, the three-system architecture can ensure better report quality. In the 2SL, development (or design) and testing are conducted within the same system, which may lead to interference and conflicts during the testing process. However, in the 3SL, the introduction of a testing system can isolate the development and testing environments, ensuring the independence and accuracy of the tests, thereby improving the quality of the reports.

However, there are some limitations within the 3SL, such as:

• The number of CDS views available for development scalability is limited.

           It’s important to note that not all CDS views published in the key user extensibility are equally available in development extensibility. The detailed publication status of CDS views should be determined based on the information in the SAP Help Portal and the application View Browser. Currently, there are more CDS views available for key user extensibility, especially some cube-type CDS views are not available in development extensibility.

• The annotation VDM.VIEWTYPE is not available. (Some other annotations either)

Annotation not released

Comments on the detailed analysis that has been published can be referred to in the link provided.

In summary, the development of extendability in the 3SL offers higher flexibility and supports more functions compared to the 2SL for key users. At the current stage, the development of extendability for key users has the advantage of a relatively larger number of available CDS for analysis and simpler operation. Customers can choose the development method that suits them best from the perspective of report content and development cost.