Principal Propogation, Event Mesh setup and User Context in CAP Nodejs application

[nileshpuranik]

Dear all,

We have a landscape with SAP S4 on premise system  -> Connected to a Event Mesh service on BTP -> and a CAP NodeJS based application which is the consumer of the event received from S4 .

There is a principal propagation in place between BTP and S4.

When an event is raised from S4 , it reaches to the Message client in Event Mesh service on BTP. The CAP Nodejs based application is subscribed to the queue/topic of the same. It immediately receives the event and starts handling it in an event handler.

Now, during the processing within CAPM, it makes oData calls to the backend S4 via Principle Propagation and fetch some more data.

When running locally ( BAS ), this works fine because we have a user context available and that helps in making the connection with S4 via Principle Propagation.

However, If the app is deployed on the space, then even though the event is received successfully, the application cannot make calls to the backend because there is no user context available.

How can we make this work? We can pass the User Id via the event payload but how can we create/get a context out of a simple user id and pass it in the header while making oData calls ?

Please advice.

Br

Nilesh

[Ivan-Mirisola · Accepted solution]

Hi @nileshpuranik,

When you run an application on BTP that has no UI front-end, there is no way to figure out which user your CAPM is supposed to propagate to your backend. 

Therefore, you will need to rely on a technical user from the backend to perform authentication via a destination that contains this technical user. An On-Prem SAP system will probably accept Basic Authentication, X.509 certificate, SAML 2.0 or OAuth2 Flow.

https://help.sap.com/docs/ABAP_PLATFORM_NEW/e815bb97839a4d83be6c4fca48ee5777/8dd7981f2fdf43049fde35b...

Keep in mind that while creating certain document types in any SAP system from any external application that isn't an SAP SaaS solution or a BOT running on SAP Build PA, you may incur in Digital Access. DA will happen only when creating documents on SAP. Therefore, when your CAPM application calls this destination with a technical user, it should do it just as means to read data from SAP or create data that isn't considered as DA.

Pleas read more here:

https://news.sap.com/wp-content/blogs.dir/1/files/Pricing_for_Digital_Age_Overview-3.pdf

Best regards,
Ivan

[nileshpuranik · Accepted solution]

Hello @Ivan-Mirisola 

Many thanks for your explanation. That makes me clear about when to use Principle Propogation and when not.

I was however triggered by this section in the CAP documentation, where we create an instance of a user

https://cap.cloud.sap/docs/node.js/authentication

const cds = require('@sap/cds')
// with user ID as string
const user = new cds.User('userId')
// a user instance
const anotherUser = new cds.User(user)
// a user instance like object
const yetAnotherUser = new cds.User({id: user.id, roles: user.roles, attr: user.attr})

Is there still a way if we can create such an instance of the user ?

Regards,

Nilesh

[Ivan-Mirisola]

Hi @nileshpuranik,

That topic on authentication is not related to your ERP backend authentication. It is rather the authentication that would happen when you call your service implemented with CAPM. 

Therefore, it will not make any difference whether you create a new instance of that object of not. It will simply not be used when you call your ERP end-point.

Best regards,
Ivan