Skip to main content

CDS View Generation (GDD)

Intro​

Creating and utilizing Core Data Services (CDS) Views for generating a customer's data model within the SAP system is crucial for achieving a highly efficient and adaptable landscape. The importance of this process cannot be overstated, as it brings together flexible data modeling through QPPD customizing with the establishment of a robust data model and business layer.

  1. Flexibility in Data Modeling via QPPD Customizing
    QPPD customizing provides a powerful and flexible environment for data modeling. This allows for tailoring data structures to the specific needs of the organization, ensuring that the data model accurately reflects the business requirements. The customizing stays as flexible as it is, without any limitations modelling your objects.
  2. Establishment of a Data Model/Business Layer
    The creation of a comprehensive data model and business layer is the foundation for building a unified and coherent system. This layer acts as the cornerstone for various applications and functionalities within the SAP ecosystem. Let's have a famous example: Just like standard SAP's view I_Product you can establish a view to your newly created object modelled and maintained in QPPD.
  3. Typed APIs
    CDS Views provide the basis for creating Typed APIs, ensuring a standardized and strongly typed interface for communication between different applications and services. This results in enhanced reliability, maintainability, and ease of integration.
  4. Critical for UI5 Apps Development
    CDS Views are essential for developing SAP UI5 applications. It provides a standardized and consistent data structure, enabling seamless integration between the frontend and backend. This ensures a superior user experience and facilitates efficient application development. CDS Views and, more concrete, generated Interface Views for your QPPD objects lays the foundation for an efficient App development.
  5. Data Querying and Analytics
    CDS Views enable efficient and optimized data querying and analysis. Users can extract relevant information easily, build their own Queries and even make use of SAPs standard Data extraction for BI/SAC/... "CDS based data extraction". No more custom code to have your QPPD data in Analytics tools!
  6. State-of-the-Art Integration within SAP
    Leveraging CDS Views aligns with the state-of-the-art practices within SAP. It ensures that the customer's data model in QPPD is in sync with the latest advancements in technology, making it future-proof and compatible with evolving SAP standards.
tip

In conclusion, the generation of CDS Views for building a customer's data model based on QPPD Specifications is not just a best practice; it is a strategic imperative. It empowers organizations to harness the full potential of QPPD by providing a solid foundation for application development, data analysis, and seamless integration. The adaptability and efficiency gained through this approach are essential for staying competitive and agile in today's dynamic business environment.

Technical Overview​

CDS Views for QPPD Specifications gets administrated in our very own Workbench called /MXP/QP_GDD (transaction). As this is an UI5 App you can also start GDD using the following information: Target Mapping GDD The generated CDS Views are expected to be "generated only" and act as the very first foundation layer (Interface View) in your system representing the QPPD object. No extensions are allowed directly. Instead, make use of View extensions to model your custom relations like "Association from your Demand Specification to Sales Order Item". A Root View will be assigned to a Specification Type in QPPD.
You are free to use this first layer in every application you need, the best practice is to just wrap it in more layers dedicated to your use case "consumption layer". Consider reading the following link for an introduction into CDS VDM Layers. The generated views are of category "interface" and therefore should be prefixed with I_.

success

Model once, use it anywhere.

Example use case

Explanation:

  • DemandSpecification is the root CDS View generated for a Specification Type in QPPD, here: DemandSpecification linked to the SAP standard SalesOrderItem
  • In QPPD, for DemandSpecification there are modelled childs Testing and Schedule generated for a DemandSpecification. The generated root view also has associations to the generated views Testing and Schedule which makes it very easy to consume that later.
  • Optionally, you can also add some custom logic/expressions and/or associations to the generated views DemandSpecification, Schedule or Testing through View Extension. Here: adding an extension view for DemandSpecification adding an association to SalesOrderItem. Example Extension
  • You can then consume DemandSpecification in your custom consumption view just reusing the fields and modelled associations having access to all the involved objects.
warning

Never change the generated views manually, as they may be overwritten with a new generation. Always add custom fields/assocations with View Extensions.

One Root CDS View and many subsequent CDS views gets generated for a Specification Type (/SCT/QP_C25). Once generated, the Root CDS View gets linked automatically to the Specification Type via customizing.
Please note, that you cannot see the View linked to a Specification Type directly in /SCT/QP_C25 as the field is an extension (/SCT/QP_TVART-/MXP/DDLNAME):
Specification Extension Customizing with example View

Usage​

  1. Open transaction /MXP/QP_GDD or the App directly from the Fiori Launchpad Selection Screen On the first screen you will find an overview of all Specification types and can see to which one already a View is linked. You can also see information about last generation, if any.

  2. Go to the details of one Specification Type
    Details Specification Type before Generation
    You will find information about:

    • The assigned CDS View, if yet one
    • Regeneration needed -> anything changed in the Specification Customizing which results in different Views? (e.g., Element added)
    • Admin Data for the View Generation
    • View Hierarchy for this Specification Type including information about where changes will be required

  3. Start the Generation with „Edit“ -> a new "Draft" will be opened. You will work on this Draft, complete it, and once you Save it the (Re) Generation will be done. Generation Input As we will generate Artifacts and link to Customizing Tables, you are forced to specify Information in section Configuration like:

    1. View Section
      • Prefix
        All your Views gets prefixed with this sequence. Every View Name is just a suggestion which needs to resolved in the workbench later on and can be adapted by you. This is necessary, as the Suggestions can be quite long and you need to chose logical abbreviations due to SAPs limitation of max. 30 characters.
      • Package Every generated CDS View needs to be assigned to a Development Package in the system. Normally starting with Z or Y.
    2. Elements Section As every field in a CDS View needs a concrete type and we want to have semantically rich data models, there needs to be a Data Element for every used Element in your Specification type. You can choose to either use the standalonde tool Data Element Generation (GDE) or just use the integration here to only generate used Elements. We recommend to use the integrated solution here.
      • Prefix Same as in Data Element Generation (GDE). Every Data Element gets prefixed, the following pattern applies <<ddic_prefix>>_<<element_name>>
      • Package Every generated Data Element needs to be assigned to a Development Package in the system. Normally starting with Z or Y.
    3. Transports Section
      • Workbench Request As we generate Artifacts which needs to be transported, this is simply for specifying a Transport Request the changes will be recorded.
      • Customizing Request
        to save the link between QPPD Specification type and Root CDS View.
    tip

    We recommend starting with the section Configuration, as changes for Prefix requires re-calculation of views and its errors in the section below. Changes might get lost.

  4. In the Section Views you can see all involved Views which will be generated and Information like:

  • a Regeneration will be done on Save or not

  • If there are any "Errors" An Error itself identifies that something needs to be done with a View before a Generation can take place. Possible Errors are:

    • Entity name suggested => the suggestion needs to be actively approved
    • Names too long => Association/Element names needs to be adapted to meet CDS limitations
    • Missing Data Elements for QPPD Elements needs to be generated

    Error Resolution

    info

    The overall goal is to resolve all Errors before Save. Having any Error left prevents from saving/(re) generating.

  1. Once all errors were resolved, clicking on "Save" (re)generates all Views where a change was detected. The Draft will be completed automatically and you will be in display mode again. Activation messages will be shown in a Popup.
    Finished Draft
    The link to your newly generated Root CDS View gets persisted in QPPD customizing table for Specification Type /SCT/QP_C25.
tip

For troubleshooting purposes you will find a Button "Unlink", which essentially unlinks the Root View from the Specification Type in Customizing /SCT/QP_C25. Please make sure the Views are not used in any other Objects, as the Deletion cannot succeed then. Unlink Root View

Limitations​

Almost all functionalities of QPPD obect model are supported, even the very complex ones like "multi grid". Unfortunately there are very rare technical limitations which are mentioned below.

  • as the view fields will be typed, Data Elements needs to be generated. The same as for the Data Element Generation (GDE) applies

  • Due to limited CAST functionality in ABAP CDS Views, you need to tick the checkbox "save NUM table" while assigning an Object type to a Specification (/SCT/QP_C25 or /SCT/QP_C30) if you have any numeric Element assigned and need to have that Element in your View. If "save NUM table" is active, every numeric Element (more precise: Elements with conversion type FLTP or PMK elements) gets persisted technically not even in /SCT/QP_VAL//SCT/QP_PMK but also in /SCT/QP_NUM. For the View Generator is is the possible to cast based on the numeric value and to generate also the fields for numeric Elements. save NUM table

    info

    If "save NUM table" is not ticked, the numeric elements of an object type are skipped and not added to the generated views.

  • As references are basically supported and completely transparent for the users, there is an exception:
    "Referencing on field level" is not supported, due to technical limitations in ABAP CDS Views. Object type Reference type

    info

    The Object type is skipped for adding to the generated views, if the Reference type is "Referencing on field level" AND the Object type can have references as modelled in /SCT/QP_C25 hierarchy.

    warning

    Please keep in mind, that leaving the field empty means the default for the technical type is used:

    • Default for TME is "Referencing on line level"
    • Default for PMK is "Referencing on field level"

Integrations​

This section will grow with best practices and examples in the future. You are free to use the CDS Views just as any other View in your application logic for querying data and for typed access to an object. In the following we show various standard integration capabilities and an outlook:

CDS based Data Extraction​

Basically the generated views can just be used in a Consumption View, just add the relevant annotations mentioned here.

success

With configuring the Operational Data Provisioning (ODP) you can just use QPPD data in your BW/4HANA system without any additional effors in like developing custom connectors.

OData Exposure​

Use your fresh generated views for QPPD objects for querying capabilities to QPPD in OData Services, previously generated CDS views can just be listed in the service definition and thus are exposed via OData. It's as simple as that, you only have to focus on your object model! The APIs are readonly if no behaviour is specified. (for CRUD, adding business logic see section RAP).

Querying for a "Product Specification" or any other object is then as simple as that, following the OData conventions for filtering/sorting/...: https://<<sap_endpoint>>/sap/opu/odata/sap/ZQPPD_API_DEMO_R_O2/ProdSpec?$top=10&$filter=ProductForm eq 'COIL'.

RAP Generation​

As the generated views are completely RAP compatible you can just use the generated views as a basis "interface" layer below the RAP layers to add behavior. There is more to come, in the future we will provide RAP/Behavior Generators. It is also planned to provide UI5 generators on top of that.