BTP private linky swear with Azure – business as usual for iFlows with Private Link Service
This post is part 2 of a series sharing service implementation experience and possible applications of BTP Private Link Service on Azure. Find the introduction in part 1 of the series. Part 3 sheds light on the different deplyoment modes given by your SAP architecture. Part 4 focusses on how to debug and test your private-link-enabled app. Part 5 describes SAP Principal Propagation – cf user mapping to SAP backend users. Part 6 describes how to restrict access to your SAP backend endpoints to keep your auditor happy. Part 7 discusses how to setup end-to-end SSL with the new host name feature.
You seem to be one of those brave folks, because you made it to part two of this Private Link Service Beta series. Last time I introduced the new service and shared my views on the implementation. Today we will build on top of that and hook it up with SAP Integration Suite.
Quick intro: Integration Suite gets you everything you need for standard integration with SAPs SaaS portfolio, Connectors, API Management etc. Formerly the SAP Cloud Connector played its role at making private SAP backends available to SAP Business Technology Platform (BTP). Let’s bridge that with the new private link service too.
“Rock on” as they say.
Fig.1 pinkies “swearing” some more
I extended the architecture overview from the first post with the Integration Suite service and potential “callers” of the deployed iFlows. That involves C/4Hana for instance. Basically, every app that can reach your Integration Suite instance – or going forward API Management – will be able to communicate with your SAP backend on Azure through a private connection. Speaking of API Management: Have a look at the post from Niklas Miroll on how to setup Azure AD with S4 including Principal Propagation with BTP API Management for further details on that aspect. We will follow up with Azure API Management soon.
Fig.2 architecture overview
Standard integration pattern stays the same
All developers may continue with the practices and technologies they are used to. Like with the Cloud Connector setup, you would add the URL of your BTP backend app to your iFlow.
During my first post I showcased two implementation variations. One in Java with SAP Cloud SDK and one using CAP. In this example I fed the CAP implementation as target for the OData connector.
Fig.3 iFlow OData connection with BTP Private Link for Azure
The path was derived from the routing config in the CAP application. It masks “sap/opu/odata/sap/epm_ref_apps_prod_man_srv” behind “product”. Depending on your implementation this might look different. If you did everything correctly, the OData EntitySets will show up on the wizard:
Fig.4 OData Entity discovery via private link
Once finished this will create the EDMX file on your iFlow. Next you should verify on the connection tab of the connector that the URL was taken properly from the wizard (see fig.3). Find my iFlow package here.
Great, let’s deploy and test this.
Fig.5 Postman request to iFlow for products on S4 on Azure via private link
Cool, that concludes the initial groundwork to get started with BTP Private Link for Azure and CPI 😊
For the time being of the beta phase we need to integrate with the private link service from iFlows via the “relay” app. Any upvotes to get it done through the connectivity service directly?
Linky swears are not to be taken lightly. I believe SAP is making good use of the Azure portfolio creating another integration scenario that will become popular going forward. Today we saw the setup process for SAP Integration Suite with this new private link service and verified the usual integration development approach can be applied.
In part three of this series, we will look at the deployment styles in more detail. Any other topic you would like to be discussed in that regard? Just reach out via GitHub or on the comments section below.
Find the mentioned Java, CAP projects etc. on my GitHub repos here.
As always feel free to ask lots of follow-up questions.