Best practice for Z-CDS in SAP customer systems?

[vonglan]

We are just starting to use Core Data Services in our system (were are still on Basis 7.50, the migration project to S/4 has just started).

I am very interested in Best Practices, and I could not find anything regarding this question:

During typical SAP customer Z development activities (not third party or SAP application development, and not Fiori), when should I create a CDS (basic view) for a Z-table? What are the pros and cons?

I can think of the following:

Pro:

• If the Z-Table already exists and has short field names, I can map to longer field names (like SAP does), thus the code can become more readable, and the longer field names are propagated to higher-layer CDS automatically
• I can use associations, which can contribute to readability and performance (associated tables are only read from the DB if they are actually used, as opposed to JOINed tables)

Con:

• Additional effort (not much)
• Additional development objects, which can be seen as redundant

What do you think?

Additional question:

I write a Z-application, that reads open sales and intercompany purchase orders (via a Z CDS), then enriches the data with several ABAP-calculated fields (that are not possible to determine in CDS), and shows it in a SAPGUI ALV (and in a prototype via OData in Fiori).

Should I follow the classical approach and define a DDIC structure for the ALV fields? Then use move-corresponding from the CDS? (The DDIC structure would then have to use the long fieldnames like SALESORGANIZATION instead of the classical brief VKORG.)

Or should I add the to-be-calculated-from-ABAP fields in the CDS, with initial values (just as placeholder)? So the CDS serves first for reading the database fields, and then serves as a kind of DDIC structure.

Updates:

28.09.2021: refined the first "pro" based on Michael Biber's comment

[vonglan]

Only now did the system show me that there was a similar discussion previously here.

Still, I would be happy to have a more detailed discussion of pros and cons here.

[BiberM]

We decided that we want to have the full stack whenever someone creates more complex CDS views. Additionally we want to have the short field names replaced already in the basic interface views. Because if you don't do it right away it will never be done.

Also comparing to ABAP development: You don't write spaghetti code if a piece of code is called only once. It is also best practice to split it into small methods. So why not have reusability in CDS right away?

Also we stick to the SAP recommendations concerning naming and entity types (basic/composite interface views, ...).

[gasparerdelyi]

I agree with Michael on reusability in ABAP CDS right away.

Let me call your attention to the Best Practice Guides:

• https://tinyurl.com/ABAP-CDS-inside-S4HANA
• https://tinyurl.com/ABAP-CDS-inside-BusinessSuite

and especially call your attention that reusability and performance are concurring goals. Especially discipline on calculating on the fly fields as late as possible is important if you process large data volumes: ideally calculate in consumption layer in ABAP CDS, so that calculated fields are not reused within the data model for joins or group by clauses etc.