Intelligent Processes are Integrated Processes
If you are already building advanced workflows in SAP Build Process Automation you are probably familiar with SAP Business Technology Platform and its comprehensive integration services. Those components a key for our Low-Code/No-Code portfolio to deliver truly integrated processes and automate in a more secure and standardized fashion. It can also be used as a complimentary tool next to SAP Build to re-use prebuilt integration content, establish central API Governance and to utilize more advanced technologies such as eventing or iPaaS solutions in the cloud.
In today’s blog I want to highlight why you should consider the API Business Hub and how this component can help you during process development.
More and more companies rely on modern interfaces, especially REST APIs, in order to build integrations or applications. The proliferation of REST APIs makes the documentation and testing of APIs absolutely necessary. This is where the API Business Hub comes into play as a central catalog of SAP and selected partner
APIs for application developers to search, discover, test and consume these APIs to build extensions or integrations using SAP Business Technology Platform. The API Business Hub also comes with a sandbox environment where you can test and review listed APIs. Logged-in users can experience this API without having an account or license for a specific API.
Here are some advantages of using the sandbox environment:
- Homogeneous API Sandbox approach for the consumer
- One API Key per user to test and experience the APIs in SAP API Business Hub
- SAP community user can test and experience APIs without an account/subscription.
- When user test an API with Sandbox, implicitly user’s API key is passed to authenticate/authorize user for API call.
Note: In API Business Hub, all sandbox APIs are protected by API Key which is generated per user.
This blog-post is ideal for process-developers that want to get a simplified backend-access which ought to be used for Proof-of-Concepts, Hackathons or testing purposes.
How to use the API Business Hub for integrated processes
APIs across SAP solutions are heterogenous in terms of protocols, documentation and access mechanisms. Application and Integration Developers on SAP Build do not easily know the available APIs in various SAP systems (on-premise/cloud). This increases the total cost of Low-Code/No-Code development. Additionally, it is hard to easily test APIs and build quick prototypes as developers may spend quite some time to get access to systems/tenants.
Based on a use-case for purchase order management I want to show you how to leverage the API Business Hub inside SAP Build Process Automation. The goal of this scenario is to generate a purchase order approval workflow to change the purchasing organization of a purchase order that is documented inside SAP S/4 HANA. It is very critical to retrieve PO-related information directly from S/4 HANA and therefore we will utilize BTP Destinations and
Actions-Projects in SAP Build Process Automation. Please keep in mind that it is a very simplified scenario to keep it as generic as possible. The same procedure can also be used for other backend systems as well.
First you need to login to the
API Business Hub. If you don’t already have a user you need to create one to access the sandbox environment and to retrieve the API key which is protecting the connection in a very simplified way. Inside the API Business Hub you can basically select any Rest-API that would be relevant for your scenario, but you need to make sure that the API also comes with a sandbox. I recommend using APIs from S/4 HANA Cloud because they are very well documented and have a sandbox system attached to it. In my example I went for the purchase order API to retrieve PO-related data based on the given purchase order ID. By clicking on the
Try Out button you are automatically being forwarded to the sandbox environment where you can start testing your calls:
The Hub also gives me the necessary JSON-Data for both input and output and publishes the URL to perform the API-call. As you can see in the screenshot, there are very diverse call mechanisms for various use-cases and you can pick and choose the one that suits best to you:
After selecting the right API-call you need to copy the URL. Make sure that you use the base-URL and not the path extension. If you add the path extension inside the destination you will run into errors later in the project. You can now use the URL to generate a
Destination in your Business Technology Platform Subaccount. In this case you need to select HTTP, paste in the URL, remove the Authentication and add the property ,,sap.processautomation.enabled=true” to make it available inside SAP Build Process Automation. Keep in mind that we are not using a authentication mechanism because we only want to test APIs. In a productive scenario you can add additional authentication mechanisms, that are applicable for your backend-system – but for now this is not necessary.
After adding the BTP-Destination you need to go back to the API Business Hub to download the API Specification, which needs to be retrieved as a JSON-File. This API Specification will be used later when we want to generate the Actions-Project inside of SAP Build Process Automation. Just go back to the Hub, click on the
Overview of you API and download the specification under the tab
API Resources.
Generate the Actions-Project in SAP Build Process Automation
Now we can go to SAP Build Process Automation to actually establish a connectivity between the sandbox environment and our projects for process automation and workflow orchestration. The first thing you need to do is to navigate to your SAP Build Lobby. Click on the
Create button and select
Build an Automated Process. After this you need to select the option the create an
Action as you can see in the screenshot. After that you need to give your Actions-Project a name and upload the API Specification which you downloaded from the API Business Hub.
Once you click on
Create you will be automatically be directed to the Actions-Designer where you can configure your connectivity. As you can see all the APIs calls from the documentation are now available inside of your Actions project where you directly start working on them. First you need to select all the relevant API-calls. In my case I only need the GET Purchase Order Data based on the Purchase Order ID:
In the tab for Input you can select the mandatory payload data for triggering the GET-call. In my case I have also added the input field for APIKey because the sanbox environment requires a key. I have selected it as a header-field which is mandatory. You also need to do that if you want to call the sandbox system.
In the tab for
Output you can re-define the output JSON-file that comes back from the sandbox system. Here it really depends on what type of information is relevant for your own process logic. Please keep in mind that if you want to use one of those values inside your process logic, you need to label them as mandatory. Otherwise you can not select them in the process designer.
In the tab for
Test you can enter some dummy data to see the output from the sandbox system. It can happen that your BTP-Destination would not appear automatically, so I recommend entering the URL manually. Enter a value for a purchase order and click on
Test.
You will also get the output shown directly inside the Actions-Designer. If you are satisfied with your result you need to release your project and publish it into your library. Otherwise it can not be used in the workflow designer.
Using Actions inside the Process Designer
Now you can use this API-Call inside your workflows of SAP Build Process Automation. I hope you have already generated a workflow project which can be used for our scenario. The first thing that you need to do is to add your BTP-Destination as a variable of your SBPA project. Click on the settings of your project and navigate to the tab
Environment Variables. As a identifier you need to select the exact same name of your BTP-Destination, otherwise the mapping would not work. You also need to select
Destination as your type and you can Save your variable.
In my scenario I have already created a little Trigger-Form to initiate the workflow instance by a business user. The user can use the workflow in order to change the purchasing organisation of a purchase order. Once the user enters the purchase order ID and the new company code an Action should be triggered automatically to get additional PO information based on the purchase order ID. You can now add an Actions-Project inside your workflow-logic by clicking on the + button and navigate to the Actions library as you can see in the screenshot:
Select the project that you have created previously:
In the Action itself you have to define the correct Destination variable:
And select the input information that is coming from your process logic:
In my case I want that the PO-related data from the API appears inside an approval formular. Therefore I have added a second form with all the UI-Elements where I can make the PO appear. An approver can review the data and approve the PO:
Now I need to map the API data with my new generated approval form. Here I can select all the values that I have identified as mandatory and re-use them anytime throughout my workflow logic:
As the final step I need to publish and release my workflow project. Once I have done that, I can start testing it. Here you can see a screenshot of the Request Purchase Order Change trigger-formular:
Please keep in mind that the users has to enter the APIKey since this is required for the Sandbox environment. In a productive scenario you would configure the authentication mechanisms inside the BTP-Destination or you could also maintain variables like an API Key as a static variable.
In the following screenshot you can see how the approval form would appear inside the inbox of a business user:
As I mentioned already this is a very basic example how both worlds of process automation and integration can be combined. You can create much more extensive and complex scenarios with both tools from our platform.