Note: This blog post is the fifth part of a tutorial series. If you arrived here without reading the first, second, third and fourth part, please do so before you continue, and then come back here again. Part I starts with principal propagation from Microsoft Azure by calling a simple Web Service deployed on SAP Business Technology Platform (BTP). Part II of this blog series extends the scenario by propagating the Azure-authenticated user via BTP and SAP Cloud Connector to an SAP Gateway system. Part III adds a business application to the scenario by implementing a chatbot in Microsoft Teams with the Microsoft Bot Framework V4 SDK, SAP BTP Integration Suite, and Core Data Services in the SAP Gateway system. A live demo of this scenario is available on episode #31 of the great SAP on Azure Video podcast series (starting at min 23:30) from hobruche , goran-condric, and roboban. Part IV uses a “low-code” approach for implementing the chatbot of part III with Microsoft Power Platform, demonstrated in episode #40 of the SAP on Azure Video Podcast series. Part V (this blog post) looks at different aspects for production readiness, such as API management, monitoring and alerting. Part VI turns the scenario into the opposite direction by propagating the SAP-authenticated user of a BTP business application to call the Microsoft Graph API and retrieve the user’s Outlook events. Finally, part VII looks at principal propagation from Microsoft Power Platform to SAP in the context of making Remote Function Calls (RFCs) and using Business Application Programming Interfaces (BAPIs) with the Kerberos protocol. See episode 142 of the SAP on Azure video podcast series for a live demo of this scenario. Together with my colleague Will we've recorded another live demo for this part V of the scenario that is available on #episode 83 in the SAP on Azure video podcast series. |
az version
.Parameter | old value | new value |
SID | NPL | A4H |
SAP IP address | 192.168.99.10 (Hyper-V VM) | 172.17.0.x (Docker Container) |
Hostname | vhcalnplci | vhcala4hci |
Default HTTPS Port | 44300 | 50001 |
docker network inspect bridge
. In the output, look for the element Containers
to find your SAP system's IP address (here 172.17.0.2😞...
# APIM Self-Hosted Gateway
127.0.0.1 sapshgw.bestrun.corp
# SAP backend (running on Docker)
172.17.0.2 vhcala4hci.bestrun.corp
...
Step | Description | Screenshot |
01 | Open a terminal and execute the command kubectl config use-context docker-desktop to have the kubeconfig file and context pointing to your Docker Desktop cluster. | |
02 | Login to your Azure subscription with the Azure CLI command az login .A browser window opens to process the login. | |
03 | Register the required providers for Azure Arc-enabled Kubernetes with az provider register --namespace Microsoft.Kubernetes Wait for the providers to complete the registration in your subscription. You can monitor the process with the commands az provider show -n Microsoft.Kubernetes -o table The RegistrationState must be Registered as shown in the screenshot. This may take a few minutes to complete. | |
04 | Run the command az connectedk8s connect --name DockerDesktopK8S --resource-group ProductSearchBotRG to connect your on-premise cluster to Azure Arc. Wait for the operation to complete. | |
05 | Verify the successful connection to Azure Arc by logging into the Azure Portal. Open the resource group ProductSearchBotRG. You should find a new resource of type Kubernetes - AzureArc and name DockerDesktopK8S. | |
06 | Also verify the successful provisioning of the Azure Arc agents in your local Kubernetes cluster with the command kubectl get pods --all-namespaces .You will see the pods deployed by the previous command in the newly created Kubernetes namespace azure-arc. | |
07 | Optionally install (or update) the Azure CLI extension for cluster extensions with the command az extension add --name k8s-extension (or az extension update --name k8s-extension )The k8s-extension provides a platform for different extensions to be installed and managed on an Azure Kubernetes Cluster (AKS) and Azure Arc-managed cluster. This is needed in if you want to deploy the SHGW with the Azure CLI. We'll use the Azure Portal in the next step. |
Step | Description | Screenshot |
08 | Go to Azure Portal, select the ProductSearchBotRG resource group and click Create. | |
09 | Enter "Log Analytics Workspace" into the search bar and click Create. Provide a name for the new workspace (e.g. saplaws). Click Review + Create and after successful validation on Create. | |
10 | Go back to the ProductSearchBotRG resource group and open the DockerDesktopK8S Kubernetes cluster resource. Select Extensions from the left-side navigation menu and click on Add. | |
11 | Select API Management Extension (preview) from the list of available extensions. Click on Create. Select your Azure API Management instance from the list. The following steps use an instance with the name SAPAPIMGMT. Click on Create new to provide the Gateway name of the new self-hosted gateway with your APIM instance. The following steps assume an instance with the name sapshgw. Enter the value 'default' for the (Kubernetes) Namespace the self-hosted gateway will be deployed to. Keep the default selection for Service Type (Load Balancer) and HTTP/HTTPS port numbers. Click on Next: Monitoring > | |
12 | Activate the Enable monitoring checkbox and select the previously created Log Analytics workspace from the list. Click Review + create. | |
13 | Review the settings and click Create. | |
14 | Wait for the deployment to complete. Then click Manage gateway. | |
15 | On the overview page for the newly provisioned APIM self-hosted gateway take a note of the upper right corner of the dashboard. It should report a heartbeat status sent to Azure by the new SHGW in your on-premise cluster. | |
16 | Verify the status of the SHGW deployment in your Kubernetes by running the command kubectl get deployments It lists the new deployment for the SHGW instance in the default namespace. Make sure that it reports 1 AVAILABLE instance. Take a note of the NAME listed in the output. Use this name in the command of the next step. | |
17 | Verify the deployment status of the SHGW service which exposes the HTTPS port of the gateway instance on the localhost. Run the command kubectl get services --selector=app.kubernetes.io/instance=<NAME from the previous command, e.g. apim-gateway-sapapimgmt-sapshgw-default> If there is NO service in the command output that exposes PORTS 80(HTTP) and 443(HTTPS) go the next step. Otherwise continue with step 19. | |
18 | Note: Only execute this step if there is NO service exposing PORTS 80 and 443. In this case, run the following command from the Git repositories subfolder /Kubernetes: kubectl apply -f .\sapshgw-service.yaml Note: If you chose a different deployment name you have to modify the selector's instance name in line 16 of this file accordingly. Verify that that the ports 80 and 443 are now mapped to the SHGW instances by running the command kubectl get services again. It should now list the PORTS in the command output. |
Step | Description | Screenshot |
19 | Navigate back to your SAPAPIMGMT APIM instance, select APIs -> APIs from the left-hand navigation menu. Click Add API and click the HTTP tile. | |
20 | Switch from Basic to Full and enter the following values:
Click Create. | |
21 | Select the newly created API from the list. Click Add operation. | |
22 | The first operation exposes the SAP Gateway's OAuth server token endpoint. Enter the following values:
Click Save. | |
23 | Repeat the previous step and add second operation for the OData service to access the product catalogue:
Click Save. | |
24 | Configure the backend in APIM representing the SAP system in the scenario. Select APIs -> Backends from the left-hand navigation menu. Click Add. | |
25 | Enter the following values:
Note: For security reasons activate both checkboxes for the certificate validation. Validation requires a trusted and valid certificate presented by the SAP backend to the SHGW which will be configured in the next steps. Click Create. | |
26 | Select APIs -> APIs from the left-hand navigation. Click SAP A4H (or another name chosen in step 20) from the list of APIs, select All operations and click the </> symbol to open the Policy code editor. | |
27 | Add the following line to the <inbound> policy after the <base /> element:
Click Save. |
docker network inspect bridge
as explained above, or docker inspect <container id or name of your SAP system>
. In the output, look for the value of the field IPAddress
or IPv4Address
.Step | Description | Screenshot |
28 | Login with SAP GUI to the backend system and start transaction STRUST. Switch to the change mode (Ctrl+F1) and double-click on the SSL server Standard node. Right-click and select Replacement Wizard from the context menu. | |
29 | Click Start. Enter the distinguished name (DN) of the new SSL certificate with the full-qualified domain name (FQDN) of your SAP system: OU=<Org Unit>, O=<Organization>, C=US, CN=<FQDN> For the chosen FQDN using the ABAP developer trial Docker image CN should be set to “vhcala4hci.bestrun.corp“, which results in the following DN as shown in the screenshot: DNS=vhcalnplci.bestrun.corp, OU=SAP Team, O=BestRun, C=US, CN=vhcala4hci.bestrun.corp In the second entry field, enter the Subject Alternative Names (SANs). SHGW expects the IP address of the SAP backend, which must be added to the FQDN by using a colon (":") as a separator as follows: "vhcala4hci.bestrun.corp:<Docker-internal IP address of the SAP system>" Click Choose Distinguished Name. | |
30 | Keep the proposed algorithm and key length and click on Select Algorithm. | |
31 | Click Create Key Pair. | |
32 | Click Save as local file and save the new Certificate Signing Request (CSR) as a new file, e.g. vhcala4hci.csr, to your OpenSSL (see part II) installation’s subdirectory trustedca/csr. Click Next. | |
33 | Open a command line and change to the subdirectory trustedca of the OpenSSL installation. Run the command openssl ca -config trustedca.cnf -out .\certs\vhcala4hci.pem -infiles .\csr\vhcala4hci.csr to sign the CSR. | |
34 | Go back to the replacement wizard. Click Load local file and select the signed certificate response file .\certs\vhcala4hci.pem created in the previous step to load its content into the text field. | |
35 | Open your OpenSSL Trusted CA’s signing certificate (trustedca/trustedca.crt) in a text editor. Copy the content into the clipboard and paste it at the end of imported certificate response file content (after the -----END CERTIFICATE----- tag) in the text field.Click Import Certificate Response. | |
36 | Click Activate New Key Pair and Certificate. | |
37 | Click Back (F3). The updated SSL server Standard PSE now has a certificate with a SAN containing the FQDN and IP Address, signed by the common Root CA for the scenario. | |
38 | The backend in APIM has been registered with all certificate validation options, including the certificate chain. This means SHGW also needs to trust the corporate CA's root certificate that was used in step 33 to sign the SAP systems certificate. Run the following command openssl pkcs12 -export -nokeys -in trustedca.cer -out trustedca.pfx from the trustedca root directory to create a PKCS12 (.PFX) file of the Root CA certificate. | |
39 | To establish trust in SHGW to the corporate root CA, go to Azure Portal and select the APIM instance from the ProductSearchBotRG resource group. Go to Security -> Certificates from the left-hand navigation menu. Click Add. Note: Adding a trusted CA by uploading it to API Management service via the CA certificates tab is not supported. To establish trust you have to configure a specific client certificate so that it's trusted by the gateway as a custom certificate authority. | |
40 | Enter an Id (e.g. "TrustedCA") for the new certificate. Select Custom and upload the previously generated trustedca.pfx file. Provide the password that you entered in the previous step. Click Add. | |
41 | Use the APIM Gateway Certificate Authority REST APIs to create and manage a (custom) CA for the SHGW. This requires a service principal in Azure AD with sufficient permissions. In Azure Portal, go to Azure Active Directory, and select App registrations from the left-hand navigation menu. Click New registration. | |
42 | Enter the name of the new application (e.g. "APIManagementRESTClient"). Click Register. From the Overview page of the new application, copy the Application (client) ID to a notepad. | |
43 | Select Certificates & secrets from the navigation menu of the new application. Switch to the tab Client secrets. Click New client secret. Enter a description (e.g. "RESTAPISecret") and click Add. | |
44 | Copy the value of the new secret to the notepad as well. | |
45 | Managing certificates for a SHGW requires permission for the actionMicrosoft.ApiManagement/service/gateways/ certificateAuthorities/write To assign this permission to the application, select the APIM instance (e.g. SAPAPIMGMT) from the ProductSearchBotRG resource group. Select Access control (IAM) from the left-hand navigation menu, switch to the Role assignement tab, and click Add. Choose Add role assignment from the drop-down menu. | |
46 | From the Role list, select the API Management Service Contributor role. Then switch to the Members tab. | |
47 | Click Select members. Search for the name of the new application (e.g. APIManagementRESTClient). Click Select. Then click Review + assign twice. | |
48 | After successful completion of the role assignment, open a REST client of your choice (e.g. Postman). If you are using Postman, you can download and import the Postman collection for this part of the blog series from here. From the collection's menu ("..."), select Edit. Switch to the Variables tab and maintain the following values in the current value row:
Click Save (or press Ctrl+S). | |
49 | Select the first request from the collection ("Request Access Token for REST API Call") and click Send. The response includes the Access Token returned from Azure AD for the service principal representing the API Management REST Client. A script in Postman sets the response in a collection variable to make the token available for the request in the next step. | |
50 | Select the second request from the collection ("Assign CA cert to SHGW") which sends a request according to the APIM Gateway CA management REST API documentation to configure the CA certificate for the SHGW. A script takes the token from the previous step and adds it to the Authorization header of this request. Click Send. The response should return code 201 with a JSON-formatted output. |
Step | Description | Screenshot |
51 | Change to your corporate root CAs subdirectory (e.g. /trustedca) that you created in step 1 of part II. Generate a new TLS certificate for the SHGW with the OpenSSL command openssl req -newkey rsa:2048 -out sapshgw.csr -keyout sapshgw.key -addext "subjectAltName = DNS:sapshgw.bestrun.corp" Below are suggested values for the new certificate’s Distinguished Name (DN), Make sure to set the Common Name (CN) attribute to you SHGW FQDN (e.g. sapshgw.bestrun.corp):
| |
52 | Sign the certificate signing request with the following command: openssl ca -batch -config .\trustedca.cnf -notext -in .\csr\sapshgw.csr -out .\certs\sapshgw.crt | |
53 | Create a PKCS12 file from the private key and certificate of the new SHGW key pair with the command openssl pkcs12 -export -in .\certs\sapshgw.crt -inkey .\private\sapshgw.key -out .\certs\sapshgw.pfx | |
54 | Select the APIM instance in Azure Portal, go to Security -> Certificates, and select the tab Certificates. Click Add. | |
55 | Enter an Id for the new certificate (e.g. SHGW), switch to Custom, and upload the PFX file created in the /certs subfolder in step 53. | |
56 | Go to Deployment + infrastructure -> Gateways from the left-hand navigation and select your SHGW from the list. | |
57 | Select Hostnames from the left-hand navigation menu. Click Add. | |
58 | Enter the following values:
Click Add. |
Step | Description | Screenshot |
59 | Sign in to Power Apps. Select Solutions from the menu. Click Import. | |
60 | Click Browse and open the file Product_Search_Bot_Solution.zip from the ProductSearchBot subfolder of the Git repository's part5 branch. Click Next. | |
61 | Click Import. | |
62 | Wait until the updated solution has been imported successfully. Then select the Product Search Bot from the list. | |
63 | Select Environment Variables from the left-hand navigation menu. Select BotAppClientID from the list and overwrite the Default Value with the client ID from step 65 of part IV. Click Save. | |
64 | Repeat the previous step for the following remaining environment variables:
| |
65 | Select Cloud Flows from the left-side navigation menu. Select the Exchange Token flow from the list. | |
66 | Click Edit. | |
67 | Select the 4th step ("Connection") from the flow. | |
68 | Select Token Endpoint Connection from the list of existing connections. | |
69 | Click Save, and then go back to the previous page by clicking the back arrow. | |
70 | Select the Call SAP OData Service flow from the list. | |
71 | Select the 2nd step ("Connection") from the flow. | |
72 | Select OData Service Connection from the list of existing connections. | |
73 | Click Save, and then go back to the previous page by clicking the back arrow. | |
74 | Select the action menu (...) of both flows in the list and select Turn on. | |
75 | Select Chatbots from the left-hand navigation menu and click the Product Search Bot from the list. | |
76 | Select Publish from the left-side navigation. Click Publish. |
Step | Description | Screenshot |
77 | Logon to your SAP system with SAP GUI and start transaction PFCG (Role Maintenance). Enter PRODUCT_SEARCH for the role name and click the Pencil symbol. | |
78 | Click the Pencil symbol next to Change Authorization Data. | |
79 | Browse to the PDCATEGORY Authorization Field and click the Pencil symbol. | |
80 | Select a product category of your choice (e.g. Desk Lamps) and click Save. | |
81 | Click Save and then Generate to update the role profiles. | |
82 | Go back to the browser and select Manage -> Channels from the left-side navigation. Click the Microsoft Teams tile. | |
83 | Click Availability options. | |
84 | Click Copy link. | |
85 | Paste the link into a new browser session or incognito session. Use the Teams web application for testing. | |
86 | Log on to Teams with the user who is mapped via the email address to a user in the SAP system. | |
87 | To see the API requests from Power Platform to SAP for the access token and catalog data processed by APIM, execute the following commands to follow the logs in SHGW: kubectl get pods This returns the name of the Kubernetes pod running SHGW. The pods runs two containers: One for the APIM gateway itself, and another one for the monitoring agent. To see the log output of the APIM gateway container, run the command kubectl logs --follow <NAME of the pod from the previous command> azure-api-management-gateway | |
88 | Add the Product Search Bot app to Teams. | |
89 | Start the conversation with the bot by entering one of the trigger phrases, e.g. "Purchase new office equipment". You are single-signed-on to the PVA chatbot. Enter the search term of products you are looking for. If you chose "Desk Lamps" in step 80 as a product category the user is allowed to search for, enter the search term "OF-DL" and hit Enter. The bot will return with a list of products from the catalogue and show some details (price etc.). Take a note of the additional output with the SAP access token and copy the value to the clipboard. You will need it in the next section to do a final load test with APIM protecting the backend from an overload situation. | |
90 | Check the command line window with the log output from the SHGW. You will see both requests to the backend for the token and the product data logged by SHGW. |
Step | Description | Screenshot |
91 | In Azure Portal, select the APIM instance SAPAPIMGMT. Select APIs from the left-hand navigation. Select the SAP A4H API from the list and click All Operations. Click + Add policy on the Inbound processing tile. | |
92 | Click the Limit call rate policy tile. | |
93 | Configure the new policy as follows:
Click Save. By defining the new policy for all operations, every call to the token and OData endpoint counts. To define different rate limits per operation, the policy can be defined on an operation level as well. Because all requests to SHGW are sent by On-Premises Data Gateway in this scenario, setting the Counter key to IP address makes most sense. However, if other internal systems with different IP addresses call the API, another counter key must be found. Note: The rate limit defined here is shared across all the replicas in the self-hosted gateway Kubernetes deployment. By default there are 2 replicas, so the number of calls is set to 20 to actually enforce half of the permitted calls (10) per minute. | |
94 | From the Home screen in Azure Portal select Monitor from the main menu. | |
95 | In Azure Monitor, select Metrics from the left-hand navigation menu. Select SAPAPIMGMT for the resource to define the scope. Click Apply. | |
96 | Configure the following settings:
Click on Finish editing metric | |
97 | Click Save to dashboard and select Pin to dashboard from the drop-down menu. | |
98 | Switch to the Create new tab, choose Private and provide a name for the new dashboard (e.g. SAP APIM). Click Create and pin. | |
99 | Click New alert rule. | |
100 | Click the auto-generated condition name's link. | |
101 | Scroll down to the Alert logic section and configure is as follows:
Click Done. | |
102 | Switch to the Details tab and enter the following:
| |
103 | Switch to the Actions tab. Click Create action group. | |
104 | Enter a Name (e.g. SAP APIM Alerts) and Display Name (e.g. SAP APIM). Click Next: Notifications. | |
105 | Select the Notification type Email/SMS message/Push/Voice. Active the checkbox Email and enter a valid email address of an inbox you have access to. Click Ok. | |
106 | Enter a name for the new Notification (e.g. Admin Email alert). Click Review + create. | |
107 | Back to the Alert rule, click Review + create. Review the settings and click Create. | |
108 | Launch JMeter from the bin subfolder of your local installation directory. Select File -> Open from the menu and open the file SAP API Test Plan.jmx from the Git repository's subfolder JMeter. | |
109 | Select the HTTP Header Manager from the test plan. | |
110 | Click the Value of the Authorization header row. Replace the placeholder <SAP Access Token> with the value of the SAP access token copied from the Teams chatbot conversation in step 89. | |
111 | Click Start to run the load test. | |
112 | Select View Results Tree from the test plan. You can see that the first 10 requests were executed successfully. The last 10 returned with an error message "Rate limit is exceeded. Try again in 59 seconds." and status code 429. | |
113 | In Azure Portal, check the Alerts page in Azure Monitor to see that the condition was met to fire the alert. | |
114 | Check the inbox of the email address provided in step 105. Azure Monitor sent an email according to the notification settings of the alert rule. |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
5 | |
4 | |
4 | |
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 |