Embedded Analytics – Extending CDS Views for Consumption

This scenario will extend the following CDS views to include a fiscal view of the Sales Order Creation
Date based on the Fiscal Variant found against the Controlling Area.

The data view of I_SalesDocumentItem shows that the original Fiscal Year and Period are not
populated from table VBKD, so we are going to create an alternative set.

Consumption C_SalesOrderItemQry Extension -

View Fiscal Year / Period

Interface - I_SalesOrderItemCube Extension -

Cube View Fiscal Year / Period

Interface - I_SalesDocumentItemAnalytics Extension –

Composite View Fiscal Variant

Basic View I_SalesDocumentItem

As a training exercise I have copied the views to be extended. In reality at the client site you would
extend the original view.

Original View Original SQL Name Copied View New SQL Name
I_SalesDocumentItemAnalytics ISDSLSDOCITMANTS ZKPJ_I_SalesDocumentItemAnalyt ZKPJISDSLSDOCITM
I_SalesOrderItemCube ISDSALESORDERIC ZKPJ_I_SALESORDERITEMCUBE2 KPJISDSLSORDIC2
C_SalesOrderItemQry CSDSLSORDERITEMQ ZKPJ_C_SALESORDERITEMQRY2 ZKPJCSLSORDITMQ2

In the query view I have also changed the authorisation annotation to not required, to make thing
simpler @AccessControl.authorizationCheck: #NOT_REQUIRED
Add Fiscal Variant to the Interface Composite View
1. As previously mentioned, I have copied the original view by searching for the view, opening
it and then copying from the outline section (bottom right of ABAP perspective in Eclipse).

2. Then create a new data definition in $TMP

3. Name the extension view you are creating. You will need a naming convention to confirm it’s
an extension. I have E after the I (for interface), but in reality, you will probably choose a
convention that adds an _E to the end.
Note: you have 30 characters available for the view name and 16 characters available for
the SQL view name. It’s the SQL view name used when the view is consumed in reporting
tools. After activating for the first time, you won’t be able to change the SQL name.
4. Click NEXT to move to the transport screen. In this case no transport is used, so click NEXT
again to move to the next screen.

5. Choose the Extend View template. Click Finish to move to open the CDS View in the ABAP
editor.

6. First step you will need to add the name of the view to be extended and the SQL view
append name for this extension. Note: the append name needs to be globally unique of up
to 16 characters, so a naming convention is required

7. In this training example I have used basic names

8. For additional fields that could be used in the future, I want to add the view
I_FiscalYearVariant, which I will rename _FiscalYearVariant as an ‘association’ – effectively a
left outer join that won’t be joined until needed.
I will need to supply the key FiscalYearVariant, which I will need to add to the body of the
extension view
9. Fiscal Variant itself is not available in the view I am extending, but Controlling Area is in the
view I_SalesDocument as _SalesDocument and this has been brought through from view
I_SalesDocumentItem into the view we are extending.

10. Controlling Area master, I_ControllingArea, is brought through to I_SalesDocumentItem

from I_SalesDocumentBasic as _ControllingArea

11. To make Fiscal Variant available we need to work backwards –

a. _SalesDocument
b. _ControllingArea
c. FiscalYearVariant
12. In the body of the extend view, type ‘_SalesDocument.’, which will cause a list of options
from to open from I_SalesDocument, from which you can pick the association
‘_ControllingArea’

13. Typing the full stop after _ControllingArea opens a new list from which FiscalYearVariant can
be chosen

14. Complete the statement to rename the extension field as a ‘ZZ’ field. This is import for
extensions to avoid any clashes in naming between the original SAP view and the custom
extension. I have finished with a comma to add another entry.

15. Finally, we want to make the contents of I_FiscalYearVariant available to views that consume
this view, using the renamed version with underscore
16. The final extension looks like -

17. Activate the extension

18. Open the view that has been extended and confirm with the symbol against the view name
that the view has been extended

19. Hit F8 in the original view to see a sample of the data and use the Select Columns button to
focus on our new Fiscal Variant field.
Add Fiscal Year / Period to the Interface Cube View
1. Create an extension to your copied version of I_SalesOrderItemCube. Name it appropriately
for this training example or following naming convention at a client site.
2. Firstly, add an association to the view to pick up I_FiscalCalendarDate, which will link the
FiscalYearVariant passed from the previous view (note: we will need to bring it through in
the body later in this extension) and CreationDate already available in the view we are
extending. View I_FiscalCalendarDate will give us the conversion from calendar date to Fiscal
Period.

3. In the body of the extension bring through the FiscalVariant field, created in the previous
extension.

4. Also take through the association for I_FiscalCalendarDate, so all fields are available for any
view that consumes the view we are extending.

5. I have also chosen to bring through the I_FiscalYearVariant view we associated in the
previous extension

6. In this example I have chosen to take the Fiscal Year and Fiscal Period field through as part of
the view, partly so I could test the association worked. I could have included the fields from
the association in the calling view.

7. Full extension view is

8. Activate and test the view with F8

Add Fiscal Year / Period to the Consumption View
1. In the final extension I just bring through the fields created in the previous cube view. I also
give the new fields a description different from the underlying data type, using the
@EndUserText.label annotation.

2. Activate and test

3. The annotation for @Analytics.query:true will make the consumption view available for AFO
and Design Studio in Fiori, while the annotation @OData.publish:true will make the view
available for other Fiori consumption. However, for both types there is an additional step to
be completed before the view is available.

4. For AFO consumption the view needs to be released as of S/4 1809. In the properties tab
below the view, there should be a tab API State. If this is missing, update the ABAP
perspective in Eclipse. The view can then be ‘released’ for consumption.

5. To activate the OData service there is an old way using transaction /IWFND/MAINT_SERVICE
in the GUI you will find in some blogs. This won’t put the activation in a transport.
To activate, click Add Service -> System Alias = LOCAL and put a partial view name with
wildcard in Technical Service Name -> click ‘Get Services’ -> highlight the view and ‘Add
Service’
6. The alternative to add the activation to a transport and allow mass activation is using
transaction STC01 with task list SAP_GATEWAY_ACTIVATE_ODATA_SERV

7. Four rows will be presented. Check all rows for maintenance

8. Maintain the package and transport details in the first row maintenance dialog. In this case
we are not going to transport.
9. In the second row maintain a list of the consumption views (with suffix _CDS) and OK

10. In the third row mainenance dialog choose Co-deploy only

11. In the fourth row maintenance you should find the queries added to the second

12. Run the task list