Dotnet6 project to connect consumers like apps/services hosted on SAP Business Technology Platform via OData with Azure PaaS services through their native SDKs. This repos uses Azure CosmosDB and its NoSQL API SDK as well as provides foundation for Azure Blob Storage.
Apply the app to enable scenarios like below: for scalable global read-access to selected SAP data and SAP Private Link scenarios for SAP Cloud Application Programming Model (CAP).
- Geodes pattern for BTP apps powered by Azure CosmosDB. Learn more about the setup here and checkout the corresponding blog post
- OData proxy pattern with private connectivity for SAP CAP apps powered by Azure CosmosDB (serverless). Find the CAP app repos here.
Note - Learn more about private connectivity for SAP NodeJS apps powered by distributed Azure CosmosDB NoSQL here.
Note - the OData proxy is configured to be compatible with any Azure PaaS services. Foundation for Azure Blob storage is already present.
Our implementation creates a fully functional solution. The approach is standardized, so that all components could be replaced as long as the runtime environment for the application stays .NET 6. To replicate our particular setup you will need:
- Azure account with subscription and rights to deploy Azure CosmosDB and App Service in two regions
- SAP on Azure with private VNet connectivity or routing from private VNet to SAP any-premise
- SAP BTP account with Business Application Studio, Destination configured and Fiori Launchpad service to host an HTML5 app
- (optional) Azure AD authorization to configure app registration and potentially give admin consent initially
- (optional) Access to SE80 on SAP backend to upload Z-Programm for data extraction HTTP Post via ABAP.
Move appsettings.json template to root of GenericODataWebAPI and maintain according to your environment. The 'appsettings.json' is ignored by git, so you can safely maintain your secrets in the file.
cd GenericODataWebAPI
dotnet run- Navigate to https://localhost:52055/health to check if the app is running.
- Use provided queries to test further with VS Code REST Client. Alternatively, find the Postman collection in the Templates folder.
Note - From within GitHub Codespaces, click the URL shown (https://localhost:52055) on the console output to navigate to the exposed domain and port. It will be something like https://.preview.app.github.dev/health
Public interfaces are:
- /health
- /api/geode
- /api/odata/$metadata
Protected interfaces are:
- /api/odata/*
Consider tweaking the OData batch configuration on the Startup.cs depending on your requirements.
Build upon provided queries to test with VS Code REST Client for convenience.
Fill the details you collected from your app registration on AAD on the environment and pay attention to the difference between client_id and scope. They use the same id but have different prefix and suffix. We didn't provide fixed values for the prefix, because they can be altered by you during creation on Azure.
The Tests tab writes the env variable bearerToken, which is used for all calls in the collection, that require authentication.
This repos offers two flavours of deployment guidance supporting the associated blog posts with the goal in mind to reduce time to reproduce. Not every step is template driven yet.
- via template deployment, VS Code extension and some manual steps - more information is available here
- (coming soon) via Azure Developer CLI
You can do a lot more once the app is deployed. Curious? We go you covered with some more information here
Feel free to reach out over GitHub Issues in case of any questions :-) Until then happy integrating and enjoy reading your SAP data globally.