Skip to Content
Technical Articles

ABAP CDS Views Development Guidelines and Naming Conventions

It always helps to define development guidelines / naming conventions and adhere to them. ABAP  CDS View development is not an exception.

Development guidelines / Naming Conventions are not something set in stone. They need to make sense and meant to help rather than complicate life. So if you have better ideas, please share in comments.

General Considerations:

  • STOB (name after define view) and DDLS (used in CDS wizard creation wizard) MUST be the same. Will save you trouble locating views
  • Dimension and measures names for SAP standard fields should be the same as SAP uses. It is absolute MUST for dimensions to make sure that navigations are working;
  • Associate dimension to dimension fields to take advantage of attributes, hierarchies, texts and values helps
  • Associate ABAP Boolean fields (‘X’ / ‘ ‘) with I_Indicator SAP standard dimension CDS view to provide user friendly texts like Yes / No
  • Associate User ID field with Rv_P_User with SAP standard dimension CDS view to provide user friendly full name instead of user id
  • Format % values accordingly instead just decimal fraction of 1. See my blog for more information
  • Suppress row and/or columns with all zeros using Analytics.settings.zeroValues.handling annotation
  • If needed, cast custom fields to SAP data elements to get the right descriptions and formatting
  • Assign quantity and amount unit of measures to ensure correct aggregation and presentation;
  • If you extend standard CDS view with custom fields then name custom fields starting with Z to avoid future naming collisions with SAP standard fields
  • Use UNION ALL instead of UNION where applicable to improve performance
  • If CDS View has parameters, then provide value help as explained. See Maksim Alyapyshev’s blog for more information.

General Naming Convention:

  • Use CamelCase naming for CDS View fields (not underscores);
  • CDS STOB views name should start with prefix, for example, ZC_ followed by CamelCase name (not underscores). CDS DDLS is capitalized by the system;
  • CDS View parameter names should be prefixed with P_ followed by by CamelCase name (not underscores).
  • Association names should start with _ followed by view without prefix, for example, _Material for I_Material.

View Specific Naming Conventions:

View Type Naming Convention Comments
Dimension ZI_<DimensionName>
Dimension Extension ZX_<DimensionName>
Value Help ZX_<DimensionName>VH
Text ZI_<DimensionName>TEXT
Hierarchy ZI_< DimensionName >HIER Add sequence number at the end if need more than one
Table Function ZI_<CubeName>FUNC Add sequence number at the end if need more than one
Cube ZI_<CubeName>CUBE
Query ZI_<CubeName>QUERY Add sequence number at the end if need more than one
Access Control ZI_<CubeName>CUBE
Transactional ZI_<BusinessObjectName>TP

 

 

11 Comments
You must be Logged on to comment or reply to a post.
  • I always struggle with the need for a naming convention.  If you do a search, you’ll see what CDS objects are available and the type with them.

    You are right a lot of them are just a general type.  Clicking into them might be a pain.   I do see some benefit to using your naming convention at that time..   I don’t know, we used to have naming conventions something like this – ZOTC_.  But we didn’t need that once we really started using packages.

    So perhaps at this point the naming convention is good.  Then later if we find out we don’t use them then get rid of it.  Only time will tell.

  • How about CDS views used in transactional application development. Business Object view and Consumption views? Any naming recommnedation for there?

  • Uladzislau, was that a typo or deliberate? Your clarification will be much appreciated:

    Access Control ZI_<CubeName>CUBE

    Shouldn’t it have a suffix of ACCESS or AUTH? Because Access Control can be applied to different view types, not only CUBEs.

    • Volodymyr, you are right that Access Control apply to different view types. In my case it is a specific scenario. Regarding suffix I do not agree. If you check SAP standard DDLS  their corresponding DCLS have identical names, so it is is better to follow SAP naming convention without any suffixes

  • Hi Uladzislau,

    Is there a technical reason for the following recommendation or is it for aesthetic reasons only?

    • Use CamelCase naming for CDS View fields (not underscores);

    I have looked and cannot find this recommendation in the SAP best practice guide. So I am curious to know if using CamelCase can avoid a particular technical issue?

     

    Thanks