Skip to Content
Technical Articles

CDS based data extraction – Part III Miscellaneous

Back to the CDS view extraction..

After the Overview in part I and Delta deep dive in part II, I would like to spend the final blog on some miscellaneous points regarding CDS view based extraction.

 

Hierarchy extraction

The topic of hierarchy extraction deserves a small section, as some things have changed here in contrast to the classical extractors. You will need to make some changes to your hierachy bearing characteristics in order to work with the hierarchy CDS views. This is due to the fact that the node texts are not delivered by the actual hiercharchy CDS view, but a separate one.

We’ll use the Cost Center hierarchy as example. You will need the following three CDS views for getting the complete picture for a cost center hierarchy across:

  • Cost Center Hierarchy Node (I_COSTCENTERHIERARCHYNODE)
  • Cost Center Hierarchy Node Text (I_COSTCENTERHIERARCHYNODET)
  • Cost Center Text (I_COSTCENTERTEXT)

You will need to equip a characteristic Cost Center, ZCOSTCTR in our case, with two additional external characteristics in the hierarchy:

One characteristic for the Cost Center Hierarchy ID (ZCOCTRHID) type CHAR40.

One characteristic for the Cost Center Hierarchy Node Text (ZCOCTRHNT) type CHAR50, compounded to the Cost Center Hierarchy ID

 

The hierarchy transformation between a DataSource based on CDS view Cost Center Hierarchy Node (I_COSTCENTERHIERARCHYNODE) and the cost center characteristic needs to be mapped as follows (Segment 0003):

 

The hierarchy node texts will be delivered via a DataSource based on CDS view Cost Center Hierarchy Node (I_COSTCENTERHIERARCHYNODE) and loaded into the characteristic Cost Center Hierarchy Node Text (ZCOCTRHNT)

The cost center texts will be delivered via a DataSource based on CDS view Cost Center Text (I_COSTCENTERTEXT) directly into the cost center characteristic as usual:

Just for completenes, please note that the two additional characteristics needed as external hierarchy characteristics can have different lengths according to a particular hierarchy characteristic (e.g. GL Accounts, Profit Centers etc.). Please make sure to check them in the respective hierarchy node CDS view first.

 

Testing CDS view extraction

With classic extractors the Extractor Checker S-API (transaction RSA3) is your friend on source system side. No need replicate a DataSource to BW side etc. Bad news, you cannot use RSA3 to test your extraction enabled CDS views.

 

How can you test CDS view extraction? The good news, you can use report RODPS_REPL_TEST.

Before sharing the details, please consider the warning on top (Warning: Not Simulated): Initializing a delta and/or running a delta extraction with the report will trigger a real subscription in the ODQ frame work. This is no dummy run.

When starting the report RODPS_REPL_TEST you will need to fill the fields as shown in the screen shot below.

The ODP Name equals the @AbapCatalog.sqlViewName again and is suffixed by the data category classification in the CDS view:

  • $P for master data attributes
  • $T for texts
  • $H for hierarchies
  • $F for facts/transaction data
  • $E for other/without dataCategory

After you are done with testing please make sure to press Reset Delta so your ODQ subscription can be cleaned.

One speciality for the hierarchy extraction test. For being able to see the extracted hierarchy data you will need to check the hierarchy segement that you would like to see, i.e. use F4 value help for Projections

 

While in RSA3 you can navigate to the different segements via a drop-down

in RODPS_REPL_TEST you can double-click on the figures to jump to these segment entries.

 

Units, Currencies, Fiscal Year Variants via CDS

In SAP BW and SAP BW/4HANA you will most likely also want to work with the units of measurement, currencies, currency conversion rates and fiscal year variants as they are maintained in your SAP S/4HANA system. In the on-premise world, this means a right click on your source system, choosing options

  • Transfer Exchange Rates
  • Transfer Global Settings

This is the same for a SAP S/4HANA Cloud source sytem in the ODP_CDS context:

In case you do not see these menu entries for your SAP S/4HANA Cloud source system, please check SAP note 2792996.

Alternatively after implementing the SAP note you can call up the reports RSIMPCUST (currencies, units of measurement and fiscal year variants) and RSIMPCURR (exchange rates) and trigger the replication manually or scheduled via process chain.

 

BW/4HANA Content based on CDS extraction

As mentioned in the last blog already, SAP has started delivering content based on CDS view extraction.

So far the Sales and Distribution (Sales Documents, Billing Documents, Conditions) and Plant Maintenance areas have been covered. You can find them in the documentation.

For the upcoming areas please check the road map slide in our BW/4HANA Content presentation here.

As usual taking over the content is done via transaction RSORBCT, selecting the data flows or objects that you require. As it sometimes leads to confusion about the content being missing, please make sure to check the steps described in the following SAP note, especially point 4 and 5

2433354 – Missing Business Content DataSources or Transformations when using ODP framework

 

FAQ

Q: Is there a Mapping of classic extractors to CDS views?

A: Unfortunately you will not find a mapping between classic extractors and CDS views provided by SAP; mainly due to the fact that data structures in the SAP S/4HANA have and keep changing as well as the extractor logic that can be expressed in a classical ABAP based extractor vs a CDS view.

Q: Where can I find a list of available extraction enabled CDS views delivered by SAP?

A: Please have a look the blog of my colleague Ranjitha Balaraman here

Q: I a missing a certain CDS view for extraction, where can I provide feedback to SAP to request it?

A: Please go to the customer influence site and provide your request here.

Q: What about global field names in CDS views and BW naming?

A: You can find the details on the CDS naming conventions in the SAP help documentation. Due to their descriptive nature, CDS view field names are sometimes quite lengthy clashing with the SAP BW limits, like DataSource Field names, Unit field names in field-based DataStoreObjects (CHAR 25). So please keep your eyes open to not lose the semantics of a field.

Q: Which delta method should I use?

A: hm, it depends. If possible from a CDS point of view (projection or a left_outer_to_one_join) go for the Change Data Capture (CDC), escpecially if you are after deletions as well.

Q: Formerly an application has worked with before- and after-images in the classic extractor. Is this still supported in the CDS view based extraction?

A: CDS view based extraction will only deliver after-images, i.e. the status of the record at the point of time it was added to the ODQ. This results in mode Overwrite (MOV) for key figures on BW side. Hence if you are working with InfoCubes (in SAP BW) or Data Mart DataStore Object (SAP BW/4HANA) you will need a Standard DataStore Object as first target in your data flow before.

Q: Can I switch between full/delta methods?

A: Changing a C1 released CDS view from full data extraction to the CDC delta extraction is considered a compatible change. Hence adding the annotation for CDC delta into an already C1 released full-extraction CDS view is possible.

Changing the delta method from generic to CDC delta is considered an incompatible change as you will be forced to re-initialize your data load. If reloading the data is not an issue for you, you can neglect this point.

Q: How do classic extractors from the Logistic cockpit compare against CDS views?

A: The good news, with CDS view extraction you can skip the whole process of Set-up tables, system lock, but start loading data right away. Also SAP is focusing on delivering the data via  denormalised header-item CDS views, so no more header-item consolidation on BW side.

Q: What about filters on non-key fields using the CDC delta?

A: Please do not use any filters on non-key fields (i.e. as part of the WHERE condition of a joined view). An update on the table level might lead to a change of the cardinality of the join.

Q: Using the CDC delta I receive delta records for records that supposedly do not have changed.

A: Due to the nature of the CDC delta you will always receive a delta record in case some field value has changed in the underlying tables of your CDS view, no matter if this field is exposed as a view element in the CDS view. In case the field in question is not exposed as view element, your delta record will look the same as the one you already have. As the records are all after-images, no harm to your existing data, but good to keep this in mind in case you wonder.

Q: Are there any CDS annotations that do not go well together with extraction annotations?

A: Yes there are, please make sure to avoid the following annotations in a CDS view that you want to use for extraction:

  • @Odata.publish : true
  • @Analytics:dataCategory : AGGREGATIONLEVEL
  • @Analytics.query
  • @ObjectModel.transactionalProcessingEnabled : true
  • @ObjectModel.transactionalProcessingDelegated : true
  • @UI.*

Getting help

Last but not least, if something goes wrong and the above answers do not help you …

Should you experience any issues with CDS extraction to BW please open a ticket on the component Operational Data Provider for ABAP CDS, HANA & BW (BW-WHM-DBA-ODA).

Should you experience any issues with CDS extraction using the Change Data Capture (CDC) delta, please open a ticket on component SAP Data Hub ABAP Integration (EIM-DH-ABA).

 

The End

Well, I guess this is it… for now…, thanks for reading up until here.

Any feedback, questions let me know; happy to answer your questions and to extend the Q&A part.

18 Comments
You must be Logged on to comment or reply to a post.
  • Thank you Simon for the detailed blog posts around CDS views as extractors.

    I am currently trying to build a CDS view with CDC on the table JEST (Statuses).

    The view looks ok, I see the right options while creating the datasource and DTP.

    The initial load has worked. But when it comes to transferring delta, I am not sure what I am missing. I keep getting zero records in delta. Is there a job here which I need to run to make the changed records come through in the trigger tables come through?

     

    Is this related to a table (like JEST)  not being compatible for database triggers?

    • Just an addendum – The case here is CDC – Automatic with no mappings. It is just based on projection selecting OBJNR and STATUS as key fields from JEST along with INACT field,

      Just not sure what I am doing wrong.

       

      /
      • Hi Subramanian,

        from what i see, the view looks good. Could you state your SAP S/4HANA version? CDC delta is available starting from SAP S/4HANA OP FP01…

        best regards,

        Simon

        • Hi Simon,

           

          My client is using 1909 but still am not able to achieve this delta through CDC. but generic delta is working.

          i tried standard enabled  CDC but not working for delta. is it require any additional steps is need to take care.

          Thanks

          Ravilla

        • Thanks Simon,

          Apologies, I missed replying to you (looks like notifications for replies is not working for me).

          The version of S/4HANA is 1909.

          I can see the GL Line Item Raw Data extractor uses the CDC method. But even that is not working.

  • Simon,

    Very well written blog . Thanks for all the hard work in putting together the process in details.

    One question I still have. Though you specified FieldsGlass , Concur and Ariba in your Part-1 I do not see any details on how to extract the data from these sources to BW/4HANA or BW on-premise systems.

    Can you though some light on this aspects too ?

    Thanks

     

  • Hi Simon,

     

    What is the alternative of RSA2 for CDS view based datasources? I understand RODPS_REPL_TEST replaces RSA3. What replaces RSA2 then?

    The reason I ask is that I have such a datasource and can’t find it in RSA2 of my source system.

     

    Regards,

    Sagar

    • Hi Sagar,

      there isn’t really a UI for looking at the properties of it on SAP S/4HANA side, but you can open the respective CDS view in the ABAP Editor in Eclipse.

      best regards,

      Simon

       

  • Hi Simon,

    I learnt a lot reading your three blogs about CDS based data extraction. Thanky you for taking the time to compile this list. It was really helpful.

    One question though. If I am only interested extracting data from C_SALESDOCUMENTITEMDEX for a fixed SALESGROUP (e.g. 001) will the CDC framework then take care that only deltas are tracked for records which have SALESGROUP 001?

    If the data is changed to SALESGROUP 002 will e delete record be written?

    RODPS_REPL_TEST allowes to specify selection criteria. So at least it seems like something like this is possible but if you could provide some details what happens behind the scene on a technical level this would be great.

    Best Regards,

    Dirk

     

    • Hi Dirk,

      if you restrict it for example from BW side via a DTP filter (SalesOrg 0001), you will not get an updated record into your BW later, if the record is changed on source system side with regards to this field. So you will need to be aware which fields you use in your filter, and if they can be changed in the application.

      best regards,

      Simon

      • Hi Simon,

        Thx for the reply. Just to check if I understand this correctly:

        Assumption: I have from BW side via a DTP filter (SalesOrg 0001)

        Now in source system document A with SalesOrg 0001 is created

        => This document will be fetched with next delta and will then be visible in BW

        Now in document A the SalesOrg is changed to e.g. (SalesOrg 0002)

        => This change will not be captured with next delta. So document still is visible in BW with the old state (SalesOrg 0001)

        If this is the case then this means I can/should only define fields as filter criteria that are immutable in the source system (e.g. application guarantees that SalesOrg can no longer be changed once document is created => Then field SalesOrg could be used as a Filter Criteria without risking any data inconsistencies between source and BW system)

        Best Regards,

        Dirk

         

  • Hi Simon,

     

    Reading section “Testing CDS view extraction” shows still a lot of manual steps to test.

    Do you know a way to test the CDS View extraction with automated tests (e.g. ABAP Unit?)

     

    Regards,
    Jonathan

  • Hi Simon,

    Thanks alot for detailed explanation on CDS Extraction.

    I followed as per the blogs and able to replicate the cdsview (C_SALESDOCUMENTITEMDEX) in b4hana system successfully. I see delta process as “Overwrite delta with deletions(delta queue)” for this cdsview in the data source level.

    Now i have created a new custom cdsview using cdc and replicated to B4hana system, but i do not see this option “Overwrite delta with deletions(delta queue)”. Instead i see “Overwrite delta without deletions(BW local)”  or  “No delta,only full”.

    So how to get this option “Overwrite delta with deletions(delta queue)”  for custom cdsview?

    Thanks

    sheshi

     

    • Hi Sheshi,

      hm, hard to judge from your writing, seems CDS view is not being regarded as delta-enabled for some reason. Could you check your view definition, CDC annotation again and/or try with another sample custom view?

      best regards,

      Simon

       

  • Hi Simon. Hope you’re doing fine. I have tried all the steps to create the CDS but I’m having problems at the point of the delta. I run the RODPS_REPL_TEST program and the delta init is created on the ODQ monitor. But once I make changes in the view table and run the program again as delta the suscription is created in the ODQ monitor but it’s empty so no delta is registered. Is it possible that I’m missing something in between? I followed every step in your article but the results are different from the ones expected.

    Thanks in advance!

    • Hi Matias,

      (assuming your system is on the right SP level, i.e. at least 1909 FP01 for S/4HANA on premise and your CDS view definition and annotations are correctly set)

      Having run the delta init with RODPS_REPL_TEST  and then having changed some records in the underlying table you should actually get them with the next run of the RODPS_REPL_TEST program as delta records.

      best regards,

      Simon