CAP SaaS external S/4HANA service version differences

[Attila]

Dear Community,

I am trying to find the best way to approach the following problem.

The CAP SaaS application consumes external S/4HANA services (public APIs) of the subscribers. However the subscribers can have different version of S/4HANA systems => so different metadata, like new fields added in latest releases etc.

How could be the different versions handled properly ?

The CAP service projects and defines service entities like this:

using ZAPI_EXTERNAL from './external/ZAPI_EXTERNAL.cds';

service ZAPI_EXTERNALSampleService {

@readonly

entity EntityA        as projection on ZAPI_EXTERNAL.EntityA {
  key ID,
  InternalID,
  Text,
...

And forwards requests to an external service like this:

const cds = require('@sap/cds');

module.exports = async (srv) => 
{        
// Using CDS API      
  const ZAPI_EXTERNAL = await cds.connect.to("ZAPI_EXTERNAL");
  srv.on('READ', 'EntityA', req => ZAPI_EXTERNAL.run(req.query)); 
...

In the above sample the ZAPI_EXTERNAL service metadata was imported into the CAP project and relates to a dedicated version of S/4HANA.

What could be the possible/known approaches to handle multiple metadata versions ?

a.) have a running version for each version of S/4HANA onPremise and one for latest S/4HANA Cloud of the application (FYI the public APIs has the name prefix OP_ for onPremise systems)
=> okay, but what if customer upgrades, tenant data has to be moved to other application.

b.) have one version imported into CAP project for onPremise and Cloud, then simply point the BTP Destination to a backend system which might have different metadata.
Will it cause a runtime error in CAP in case we use only entity properties which are the same and exists in all service versions ?

c.) Import all version like ZAPI_EXTERNAL 1909FPS1, ZAPI_EXTERNAL 2020FPS1 ... and put a switch/case statement in the service handler to route/send the request to the corresponding service / version like above.

ZAPI_EXTERNAL<version>.run(req.query)); 

okay, but how-to handle the data defintion / projection ?

d.) pull in SAP Graph into the picture for entity definitions/projection and implement request handling manually to forward the queries ?

Graph support only read access covering the backend system. Does it handle version differences as well ?
Restriction it is still pilot and EU Frankfurt region only.

e.) any other option ?

Any support and opinion is welcome Ladies & Gentlemen ! I would highly appreciate it!

🙂

Thank You

[MustafaBensan · Accepted solution]

Hi Attila,

I am familiar with how the CAP multitenant SaaS architecture works. What I was asking for was a description of the business functionality or business processes that your application covers.

Here are two other options you could consider:

1) Have you looked into the Extending SaaS Applications capability of CAP? Instead of using it to allow the subscriber(customer) to extend their own tenant, you could possibly pre-build extension projects for each S/4HANA version and then automate the deployment of the relevant extension project based on the subscriber's selected version.

2) If the API changes for incremental S/4HANA versions are additive to the data model, then you could potentially just keep the app aligned with the latest version of S/4HANA and only populate/display the fields that are relevant for the version that the subscriber has selected.

Regarding your comment:

"Let's say we have all the metadata version in the project, and provide an admin UI to select version. Since CAP to my knowledge provides no option to dynamically hook in/provide metadata and build up the model, we need to do all dynamic coding and request handling by ourself to have a safe and stable solution without error. I am not sure this at the end can bring ROI to us unfortunately. So we need a magic trick 🙂 !"
Yes, that is correct and I'm not sure if there would be a "magic trick" to solve the issue out-of-the-box.

Regards,

Mustafa.

[Attila · Accepted solution]

Thank You Mustafa,

What You suggest seems me feasible and the best choice, actually not having a magic trick this is the only option. I was searching the capire documentation meanwhile and ended up on this, but was unsure how this could be applied in our case, but as You explain now it is clear :)!

Thank You very much for Your support !

Best regards!

Attila

[MustafaBensan]

Hi Attila,

I have faced this dilemma before. The approaches I considered rather than "hardcoding" the API structures were as follows:

1) Create an admin UI in the SaaS application that allows an administrator to configure connections to backend S/4HANA services dynamically using the OData metadata URL, and/or

2) Create a "Content Library" feature in the SaaS application that includes each version of S/4HANA and allows the administrator to select the version to generate the connections for.

With either approach, there could also be the possibility of implementing a dynamic checking mechanism for structure changes in order to gracefully inform the end user of the SaaS application rather than letting them experience a runtime error.

Before diving deeper though, it would be helpful if you could provide some more context about what the SaaS application does from a functionality perspective and its features. This will help in making more specific suggestions. I also have the following questions related to your SaaS app:

i. Can a single subscriber connect to multiple S/4HANA systems, or must a separate subscription be created for each S/4HANA system?

ii. With your comment: "okay, but what if customer upgrades, tenant data has to be moved to other application", what do you mean by "tenant data has to be moved to other application"?

Regards,

Mustafa

[Attila]

Hi Mustafa,

thank you for Your answer. I really appreciate it!

i. a single subscriber cannot connect to multiple S/4HANA systems

ii. SaaS applications have a single application running in service provider subaccount. The resources of the provider subaccount are shared across all the subscribers. Upon subscription from a separate consumer(subscriber) subaccount, the service broker creates an isolated HDI container for the subscriber data in the provider account managed by the SaaS application.

So we have by default a single CAP application which connects through the destination configured in the subscriber subaccount to the subscribers S/4HANA system.

This is also done automatically for multi-tenant applications, the SaaS application select destination from consumer subaccount not from provider.

  {"cds":{"requires":{
    "S4": {
      "destinationOptions": {
        "selectionStrategy": "subscriberFirst",
        ...
      }
    }
  }}}

We can import as many S/4HANA version of the metadata into the single multi-tenant app with CDS import as You describe having a "Content library", but we can base our data model on only one of them (ZAPI_EXTERNAL):

entity EntityA        as projection on ZAPI_EXTERNAL.EntityA {

This means if we want to handle multiple versions of metadata in CAP, we need multiple multi-tenant(SaaS) applications running in provider account. Each corresponds to one S/4HANA metadata version, like 2021FPS1 etc.

In case the customer upgrades to a new S/4HANA version => we need to move the isolated tenant HDI container to one service broker to another.
image.png

I am not sure this is possible at all. If Yes, then it adds a complexity in DevOps, and results in a very strange codebase and branching, because we cannot deploy the same application two times with the same name into the same BTP region as SaaS application. And it has many negative impacts from maintenance perspective. This is what I meant with moving tenant database,and this is the setup behind it.

In case we provide a customizing or possibility to select S/4HANA version, so that we know in CAP application with which version of S/4HANA we are dealing with is a good option. Unfortunately as I see it will not help to overcome the above issue to define entities in the service, because CAP is requiring to tell him exactly one external service metadata, from the many versions we imported before.

The other option to import metadata into CAP from an Admin UI is not possible into the CAP app itself. cds import can be done during development only (or we store in a tenant db table)

Let's say we have all the metadata version in the project, and provide an admin UI to select version. Since CAP to my knowledge provides no option to dynamically hook in/provide metadata and build up the model, we need to do all dynamic coding and request handling by ourself to have a safe and stable solution without error. I am not sure this at the end can bring ROI to us unfortunately. So we need a magic trick 🙂 !

Thanks & regards
Attila