Creating SAP S/4HANA Embedded Analytics in Public Cloud with Developer Extensibility

So first of all, what is “developer extensibility”? When mother duck SAP conceived various versions of her new ERP system S/4HANA, she immediately became very protective of her ducklings, especially of the in her view prettiest one: public cloud. Noone was allowed to touch this duckling. Access to the database-side was – and still is – out of the question. Custom-specific modifications via the application-side were limited to two ways: “key user extensibility” or “in-app extensibility” and “side-by-side extensibility”. Key user extensibility is the use of certain key user tools like “Custom Fields and Logic”, “Custom CDS Views” and “Custom Analytical Queries”. Side-by-side extensibility is exporting data via an API to another system, usually the SAP Business Technology Platform, doing something with this data in this system, and then bringing the result back to S/4 also via an API.

With the on-prem/ private cloud duckling, mother SAP is less protective. Developers are allowed to connect to the applications-side with Eclipse and create objects in the development client. For analytics, the most useful objects are CDS-views: basic views, data-integration views, cube-views, query-views. For details, read my book [https://link.springer.com/book/10.1007/978-1-4842-7017-2]. To assess the developments options for a certain type of extensibility I apply two criteria: (1) which objects can be used as “starting points” for developments, and (2) which “operations” are possible? For starting points, one can think of SAP standard CDS-views, either released or not released, tables and database views. A full set of operations consists of left outer join on demand (ASSOCIATION), normal left outer join (LEFT OUTER JOIN), inner join (INNER JOIN), aggregation (GROUP BY), filtering in query (@Consumption.filter), intermediate filtering (WHERE) and union (UNION ALL). And the good news is: all starting points and the complete toolbox of operations are available for on-prem/ private cloud development in Eclipse. This led me to conclude that all transformation ‘tricks’ I managed to master in SAP BW over time can also be developed as “virtual data flows” in CDS-view stacks resulting in embedded analytics.

This is far from true for the key users extensibility apps “Custom CDS Views” and “Custom Analytical Queries”. Only starting point is standard CDS-views released for key user apps, and the only operations allowed are ASSOCIATIONs to connect master data to one set of transaction data in “Custom CDS Views” and analytics annotations, e.g. for filtering, in “Custom Analytical Queries”. That’s it. Who stole my toolbox? The union-operator is especially dearly missed, as this is the only way tot properly integrate two differently structured sets of transaction data.

And now the real-life business requirement. Customer recently went from SAP ECC to Public Cloud S/4 and is seeking an alternative for an ABAP program in ECC that did exactly this: integrating two differently structured sets of transaction data, i.e. financial documents and billing documents. Applying the key user apps starting from CDS-views released for key user apps I came a long way by displaying the required information in two separate queries, but without union-operator it is not possible to properly display Amount from financial documents together with Net Value from billing documents in the same query. We need to try something different.

Back to the original question: what is “developer extensibility” in public cloud context? I believe it is the result of pressure by the SAP developer community to allow more flexibility in the public cloud offering (otherwise no one is buying it). This first resulted in a shady project named “SteamPunk”, evoking an atmosphere of drug abuse in a squat, and later on the option to connect Eclipse to “client 80” of a public cloud S/4 system to carry out “cloud development” on objects “released for cloud development”. Cool! However, the word was that development options were quite limited compared with “non-cloud development”. But let’s find out for ourselves by trying to solve the remaining embedded analytics challenge.

How does “developer extensibility” work technically? Public Cloud S/4 has a system landscape as shown below (picture by courtesy of myBrand).

First you need to find out the url of client 80 of the Dev-system and request a user with proper authorizations. The Dev-system will have two clients: client 100 (Dev-Cust) and client 80 (Dev-Dev). The client is shown in the top bar in the browser.

For key user extensibility you need to work in client 100 via Fiori, for developer extensibility in client 80 via Eclipse. Eclipse can be connected to both clients, but only the connection to client 80 can be used to develop objects. In Eclipse, instead of “File” > “New” > “ABAP Project” you now need to go “File” > “New” > “ABAP Cloud Project” and enter the system-part of the url.

Logon via SSO in browser:

Now you have two Eclipse projects to work in: client 80 for development and client 100 for data preview and unit testing. As CDS-views are cross-client objects, all views created in one client are immediately available in the other client after refresh.

And how was my first experience with public cloud developer extensibility? As a notoriously grumpy old man, I am not easily made enthusiastic about something, but for this I would like to make an exception. Just look at the last column in the table below. I found my toolbox back!

What I ended up doing is create a union-view and a cube-view with developer extensibility in client 80 via Eclipse, and configure a query-view on top with key user app “Custom Analytical Queries” in client 100 via Fiori. I used the same methods as in on-prem development, and found almost no limitations. Below, ABAP CDS-code of the union-view is shown, which is a pretty neat piece of work, if you don’t mind me saying.

To name one limitation: casting to a data element has the advantage that not only the field-format is inherited, but also metadata like description. This, however, led to an error message only for public cloud.

Workaround is to cast to a field format like this in the union-view …

… and provide a label using an analytics annotation in the cube-view:

The real limitation of public cloud developer extensibility compared with on-prem development is not in the toolbox, but in the starting points. I was lucky that required CDS-views were released for cloud development, but this is not always the case. In fact, even less CDS-views are released for cloud development than for key user apps.

Good to mention: releasing CDS-views after development is also something you need to do as a developer. You need to release for cloud development if the next step is also in Eclipse and for key user apps if the next step is in Fiori. Below is shown how the cube-view is released for key user apps to configure a query-view on top (left) and the union-view is released for cloud development as well in order to build a cube-view on top (right).

To conclude: this is good stuff! Oh, and let me proudly show Amount from finance and Net Value from billing in the same query. I know, it doesn’t look that spectacular. But it is pretty smart.

Target audience of this blog: people like me. Caucasian, male, arrogant … just kidding. I mean of course experienced in data modeling (with SAP BW, for instance), experienced in creating embedded analytics in on-prem/ private cloud S/4HANA, but relatively new to Public Cloud S/4 (yes, I know, the full name is “SAP S/4HANA Cloud Public Edition”; geez, get a life!). Let’s face it, we all are relatively new to Public Cloud S/4. And the topic of this blog is creating SAP S/4HANA embedded analytics in public cloud with developer extensibility.So first of all, what is “developer extensibility”? When mother duck SAP conceived various versions of her new ERP system S/4HANA, she immediately became very protective of her ducklings, especially of the in her view prettiest one: public cloud. Noone was allowed to touch this duckling. Access to the database-side was – and still is – out of the question. Custom-specific modifications via the application-side were limited to two ways: “key user extensibility” or “in-app extensibility” and “side-by-side extensibility”. Key user extensibility is the use of certain key user tools like “Custom Fields and Logic”, “Custom CDS Views” and “Custom Analytical Queries”. Side-by-side extensibility is exporting data via an API to another system, usually the SAP Business Technology Platform, doing something with this data in this system, and then bringing the result back to S/4 also via an API.With the on-prem/ private cloud duckling, mother SAP is less protective. Developers are allowed to connect to the applications-side with Eclipse and create objects in the development client. For analytics, the most useful objects are CDS-views: basic views, data-integration views, cube-views, query-views. For details, read my book [https://link.springer.com/book/10.1007/978-1-4842-7017-2]. To assess the developments options for a certain type of extensibility I apply two criteria: (1) which objects can be used as “starting points” for developments, and (2) which “operations” are possible? For starting points, one can think of SAP standard CDS-views, either released or not released, tables and database views. A full set of operations consists of left outer join on demand (ASSOCIATION), normal left outer join (LEFT OUTER JOIN), inner join (INNER JOIN), aggregation (GROUP BY), filtering in query (@Consumption.filter), intermediate filtering (WHERE) and union (UNION ALL). And the good news is: all starting points and the complete toolbox of operations are available for on-prem/ private cloud development in Eclipse. This led me to conclude that all transformation ‘tricks’ I managed to master in SAP BW over time can also be developed as “virtual data flows” in CDS-view stacks resulting in embedded analytics.This is far from true for the key users extensibility apps “Custom CDS Views” and “Custom Analytical Queries”. Only starting point is standard CDS-views released for key user apps, and the only operations allowed are ASSOCIATIONs to connect master data to one set of transaction data in “Custom CDS Views” and analytics annotations, e.g. for filtering, in “Custom Analytical Queries”. That’s it. Who stole my toolbox? The union-operator is especially dearly missed, as this is the only way tot properly integrate two differently structured sets of transaction data.And now the real-life business requirement. Customer recently went from SAP ECC to Public Cloud S/4 and is seeking an alternative for an ABAP program in ECC that did exactly this: integrating two differently structured sets of transaction data, i.e. financial documents and billing documents. Applying the key user apps starting from CDS-views released for key user apps I came a long way by displaying the required information in two separate queries, but without union-operator it is not possible to properly display Amount from financial documents together with Net Value from billing documents in the same query. We need to try something different.Back to the original question: what is “developer extensibility” in public cloud context? I believe it is the result of pressure by the SAP developer community to allow more flexibility in the public cloud offering (otherwise no one is buying it). This first resulted in a shady project named “SteamPunk”, evoking an atmosphere of drug abuse in a squat, and later on the option to connect Eclipse to “client 80” of a public cloud S/4 system to carry out “cloud development” on objects “released for cloud development”. Cool! However, the word was that development options were quite limited compared with “non-cloud development”. But let’s find out for ourselves by trying to solve the remaining embedded analytics challenge.How does “developer extensibility” work technically? Public Cloud S/4 has a system landscape as shown below (picture by courtesy of myBrand). First you need to find out the url of client 80 of the Dev-system and request a user with proper authorizations. The Dev-system will have two clients: client 100 (Dev-Cust) and client 80 (Dev-Dev). The client is shown in the top bar in the browser.For key user extensibility you need to work in client 100 via Fiori, for developer extensibility in client 80 via Eclipse. Eclipse can be connected to both clients, but only the connection to client 80 can be used to develop objects. In Eclipse, instead of “File” > “New” > “ABAP Project” you now need to go “File” > “New” > “ABAP Cloud Project” and enter the system-part of the url.Logon via SSO in browser:Now you have two Eclipse projects to work in: client 80 for development and client 100 for data preview and unit testing. As CDS-views are cross-client objects, all views created in one client are immediately available in the other client after refresh.And how was my first experience with public cloud developer extensibility? As a notoriously grumpy old man, I am not easily made enthusiastic about something, but for this I would like to make an exception. Just look at the last column in the table below. I found my toolbox back!What I ended up doing is create a union-view and a cube-view with developer extensibility in client 80 via Eclipse, and configure a query-view on top with key user app “Custom Analytical Queries” in client 100 via Fiori. I used the same methods as in on-prem development, and found almost no limitations. Below, ABAP CDS-code of the union-view is shown, which is a pretty neat piece of work, if you don’t mind me saying.To name one limitation: casting to a data element has the advantage that not only the field-format is inherited, but also metadata like description. This, however, led to an error message only for public cloud.Workaround is to cast to a field format like this in the union-view …… and provide a label using an analytics annotation in the cube-view:The real limitation of public cloud developer extensibility compared with on-prem development is not in the toolbox, but in the starting points. I was lucky that required CDS-views were released for cloud development, but this is not always the case. In fact, even less CDS-views are released for cloud development than for key user apps.Good to mention: releasing CDS-views after development is also something you need to do as a developer. You need to release for cloud development if the next step is also in Eclipse and for key user apps if the next step is in Fiori. Below is shown how the cube-view is released for key user apps to configure a query-view on top (left) and the union-view is released for cloud development as well in order to build a cube-view on top (right). To conclude: this is good stuff! Oh, and let me proudly show Amount from finance and Net Value from billing in the same query. I know, it doesn’t look that spectacular. But it is pretty smart. Read More Technology Blog Posts by Members articles

#SAP

#SAPTechnologyblog