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