How can I securely connect a web application hosted on e.g. Azure to an S/4HANA on-premise system?

[turkaj]

I have developed a web app using ReactJS that is hosted on Azure and I want to retrieve data from an S/4HANA On-Premise system. I am looking for a secure and reliable way to establish this connection. The data that I want to retrieve includes orders, customer information, and inventory levels ... The data transfer needs to happen in near real-time.

I have identified the following possibilities for establishing this connection:

1. Direct access to the SAP system via OData/SAP Gateway. This would require opening the Gateway web service to the outside, which is very unfavorable for security reasons. The connection would look like this:
   
   S/4HANA <-> Proxy <-> Web App

2. Communication via SAP BTP: This option would involve using the Cloud Connector to connect the S/4HANA system to the SAP BTP, and then accessing the data from the web app via the SAP BTP. The connection would look like this:
   
   S/4HANA -> Cloud Connector -> SAP BTP <- Web App

3. Use of an SAP Business Connector: This option would involve using an SAP Business Connector to connect the S/4HANA system to the web app. The connection would look like this:
   
   S/4HANA -> Business Connector <- Web App

4. Use of SAP PO: This option would involve using SAP Process Orchestration (PO) to connect the S/4HANA system to the web app. The connection would look like this:
   
   S/4HANA -> SAP PI <- Web App

In terms of security requirements, the data transfer needs to be encrypted and authenticated, and only authorized users should be able to access the data. In terms of technical requirements, the solution needs to support JSON data format and RESTful APIs. In terms of operational requirements, the solution needs to provide monitoring, logging, and error handling capabilities.

I am not sure which of these options is the best and most secure for my use case.

Are there any other options that I should consider?

Are there any best practices or recommendations for securely connecting a web app hosted on Azure with an S/4HANA On-Premise system? It doesn't have to be Azure. It can also be another provider.

I would appreciate any help and advice from the community.

[CarlosRoggan]

just a little comment:
I guess you mean SAP Cloud Integration instead of PO, right?
It is powerful and safe and ideal for integrating different worlds.
message payload can be encrypted, HTTP endpoint protected with OAuth, etc

[turkaj]

Hi carlos.roggan,

Thanks for your reply.

In this case I did indeed mean SAP PO/PI. Many companies are still using it. SAP Cloud Integration is the solution of the future. SAP Cloud Integration seems like the best solution. Is there another solution for companies that are behind (and they are not few)?

Thanks

Jim

[Willem_Pardaens]

Option 2 is the most-used approach and offers all the features you mentioned. Have a look at the CAP framework that would use this approach (https://cap.cloud.sap/docs/get-started/).

[turkaj]

Hello carlos.roggan & willem.pardaens,

you are both right. It is best to invest your energy in SAP Cloud Integration and SAP BTP. The second option is definitely the better choice.

Thank you very much Jim

[CarlosRoggan]

Hi Jim,
I just wanted to point out that new development on the classic PI might not make much sense, as SAP will phase out that classic product, although you're right, there are many customers and it will take long.
Buy a license for Cloud Integration if you only want to build one straight-forward scenario also doesn't make much sense, overengineered .
Also have to say that a cloud connector instance would be required anyways, when using cloud integration.
On the other side, if you create an app on BTP which is only a proxy, then CAP sounds overengineered as well, as cap is used for business applications, and a simple lightweight node app would be sufficient
Cheers
Carlos

[turkaj]

Hi Carlos,

in this particular case. What do you suggest? I agree with you. I think it is a bit over-engineered to use the BTP just as middleware. In my opinion that is not what it was designed for. In this case, it is to securely read data from the on-premises SAP system. So there is a call to an Gateway service and the data is returned. If you expose that endpoint from the on-premises system to the outside, we have a security risk. That's why the idea is to use SAP BTP. But BTP offers a variety of services. Which one is the right one? And is this the right approach?

Thanks
Jim

[Ryan-Crosby]

Hi Shkelqim,

If you are looking for near real-time, then it may be worth considering the use of the event mesh to push data of interest based on events instead of needing to constantly poll for the data.

Regards,

Ryan Crosby

[turkaj]

Hi Ryan,

Yes, I was thinking of using an ABAP push channel. This will allow me to push the changes in real time. The remaining challenge is how to get the data securely from the on-premises SAP system to the web application?

willem.pardaens suggested the SAP CAP (Cloud Application Programming Model). This is a good way to develop web applications based on NodeJS, for example. In this case there is already a web application and I don't know if I can build a kind of middleware with CAP, i.e. the communication between the web application and the on-premises system is redirected via SAP BTP. However, as carlos.roggan has written, it might be a bit over-engineered to begin with.

The question remains:

• What is the way SAP suggests?
• How can I transfer the data securely and with as little effort as possible (on-premises system --> web application)?

Regards
Jim

[Ulrich_Schmidt · Accepted solution]

A lot of useful ideas have already been mentioned in the comments, but no one has ventured an "answer" yet, so I'll go first... 🙂

Option 1 is ruled out, if you don't want to open your firewall for outside access.

Option 2 is in my opinion "shooting sparrows with cannons" (hope this idiom translates into English... 🙂 ) The task at hand is clearly a job for a middleware, while BTP is a full-blown application platform.

So the best solution would indeed be to use a middleware, which leaves options 3 and 4. Both, SAP PI/PO and SAP Business Connector would probably be well-suited for this task. Both provide the required capabilities in terms of real-time communication, encryption, user management & authorization, monitoring, logging, and error handling. I'm not an expert for PI/PO, but I can provide a few pros & cons for SAP BC:

• SAP BC is a very lightweight but nevertheless powerful work-horse. (Much less hardware requirements than a PI/PO system.) Also SAP BC is included in any SAP standard license, while PI/PO requires an additional license.
• PI/PO is going out-of-maintenance within the next few years, but I expect that SAP BC will stay with us for another decade or two... (Latest release has just been published by SAP in 2021.)
• The following SAP BC feature could be perfectly suited for your current requirements: "Reverse Invoke". It allows outside applications to access the SAP BC by HTTP without having to open your firewall for outside access! (It is basically the same mechanism that the Cloud Connector uses for allowing SAP BTP applications to access customer's on-premises systems without having to open the firewall. SAP copied the idea of "Reverse Invoke" from the SAP BC to the Cloud Connector.)
  For details see the chapter "Protecting Your Internal SAP BC Server with Reverse Invoke" in the SAP BC Administration Guide available at https://support.sap.com/en/product/connectors/bc/details.html?anchorId=section_295234589
  (I'm not aware that PI/PO provides a similar feature.)
• In addition to "Basic Authentication", SAP BC also supports X.509 certificate based logon. So you could import an X.509 certificate (private & public key) into the Azure app, and then import the public key into SAP BC and map it to a dedicated user that just has the permission to execute those "Flows" that pull the data from the S/4 backend.

So much about "pros". There is one "con" that comes to my mind: SAP BC does not have a built-in JSON parser, while PI/PO probably has. However, there are many good open-source JSON parsers, and it is very easy to plug in any third-party/open-source jar archive into your Business Connector and use it in your "Flows". In fact, just a few weeks ago, I wrote a blog on how one can do exactly that: in my example I'm using an Apache open-source library, which creates files in Microsoft Excel format, from a SAP BC RFC Flow to convert an ABAB internal table to an Excel file: Using Java Functionality from your ABAP Programs

Downloading a JSON parser and using it in the Flows that receive the HTTP/REST calls from your Azure application, would work just the same.

An interesting question to consider further is how exactly the S/4 system exposes the data you are interested in. You say "The data that I want to retrieve includes orders, customer information, and inventory levels", but it doesn't say much about the interfaces available for this. If (most of) this data is exposed via BAPIs or remote-enabled function modules, it is very easy to retrieve from the SAP BC: making an RFC call just takes a few mouse clicks and no coding. For SOAP/OData/WebService calls you can use the BC's built-in HTTP client, but you will probably have to write a bit of code to create the correct request body from the JSON data you receive from Azure.

[turkaj · Accepted solution]

Hi Ulrich,

Thank you for your response. It is very helpful and rounds off the discussion nicely. From your response and the previous answers, I draw the following conclusions:

1. A lean, effective and sustainable solution is SAP BC, provided that the customer does not have SAP BTP and a Cloud Connector in use, as it would probably be more sensible to use the Cloud Connector in that case. It also meets my exact requirements. I need to take a closer look at the JSON format. I will try this option.
   
2. If a Cloud Connector is in use, then I can use it for read access (as you say, it is the same principle as with the Business Connector). However, if I also need write access to the SAP on-premise system, I must use an SAP Cloud Integration in this constellation.

I thank you and all others for the different perspectives and answers to this question.

Regards
Jim

[Ulrich_Schmidt · Accepted solution]

Hi Jim,

to clarify this:

> However, if I also need write access to the SAP on-premise system, I must use an SAP Cloud Integration in this constellation.

SAP BC also supports both read/write access.

And yes, you are right: if one or the other component is already used for other tasks in the customer's landscape, then it makes sense to "re-use" the existing components as much as possible instead of adding further components to the system landscape (which increases complexity).

[turkaj · Accepted solution]

Thank you very much for your help

[Ulrich_Schmidt]

Another thought on the question "should the Azure app pull the data from S/4, or should S/4 push it to Azure". The answer to this question depends on several factors:

• The push approach has one major drawback: you need to keep two copies of the data. If it's a big amount of data, that could be expensive (requires an additional potentially big database in the Azure landscape), and there is always the risk, that the "two sources of truth" get out of sync.
• So if the entire data source is big, but the Azure app will always need only small parts of it, or if it is essential that the Azure app always works on the latest up-to-date data, then "pull" is definitely better.
• However, if the "response time" as seen by the end-user is most important, "push" could be better, as the Azure app will be faster, if it can immediately access a local copy of the data, than if it has to make a REST call via Internet and SAP BC to the on-premises S/4 system.
• Another question is about security. You seem to be worried about improper access to sensitive data. Is it safe to store big amounts of that sensitive data in the Azure application?

[turkaj]

In my case, I don't want to store data twice. The data comes from the SAP system and is only displayed to the user when needed. This means that the data is not additionally stored or kept on a non-SAP database. As you write, I do not want to store the data twice for security reasons.

It may be that the data is stored temporarily as a draft for the user. But this is only temporary. For this reason, I will have to look more closely at whether I need a push mechanism at all.