Authors: amine.mabrouk, mariatrinidad.martinezgea, edward.neveux, kristian.papai, qsmith.
This blog is part of the SA Repair blogs’ series we have published covering a business use case on the topic “Transform Your Business Processes using SAP Signavio and SAP Build”. The first blog SA Repair: Transform Your Business Processes using SAP Signavio and SAP Build introduced the importance of Process Automation; we talked about how to Analyze a process with SAP Signavio in our second blog SA Repair: Analyze and Explore with SAP Signavio and in our third blog SA Repair: Automate with SAP Build Process Automation we focused on how to Automate some of the manual processes. In this blog SA Repair: Trigger with SAP BTP Graph and Build Apps we will focus on the implementation of the application that the users will consume to Trigger the process.
To develop our application, we will use SAP Build Apps. But before exploring SAP Build Apps let me provide some details about SAP BTP Graph Service.
As you have seen on the use case description, we will connect to two different backend systems to retrieve and update the data required by our solution:
As each backend system has its own set of APIs, we could directly connect to each system and consume their APIs from our application. To simplify the usage and the configuration of the different systems’ APIs we will use an SAP BTP Service called Graph.
Graph is an SAP Business Technology Platform (BTP) service offering a unified API for the Intelligent Enterprise and as such providing developers a single connected and unified view of all their business data. Graph consolidates the data models of data sources like SAP S/4HANA, SAP Sales Cloud and SAP SuccessFactors into one, unified and connected, data model, representing all the data in a landscape. Custom oData APIs can also be configured to be accessed via Graph.
You can setup your own Business Data Graph on your subaccount, where identity, trust and connectivity can be established between your own applications, extensions and integrations, and your landscape. An advantage of Graph is that IT Administrators take care of the Business Data Graph as well as the destination’s configuration, while developers just consume the entities via Graph independently of which specific tenants they are working with.
In our use case architecture, SAP Build Apps application consumes both SAP S/4 HANA Cloud and SAP Success Factors entities via Graph. User Identity is propagated from SAP Build Apps to Graph, and Graph will circulate the identity to each specific backend tenant to verify the end user authentication and authorization.
Developers only connect to the Graph destination configured by IT Administrators without having to care about changes on the specific backend servers’ configuration.
As introduced previously, the next figure shows how Graph accesses the configured APIs on the backend systems via the Destination service.
The next picture shows a snippet of our Graph configuration file where the destinations consumed by our Business Data Graph are listed as DataSources:
A set of Location Policies allows the selection of the leading data source on cases where more than one tenant of the same type is exposed by graph either for entire namespaces like for example “sap.graph” or only for specific entities like for example “sap.graph.Product” shown in the following image:
Now that we understand how a Business Data Graph can help us configure the access to our backend systems, let’s see how we can consume Graph from our user interface application built with SAP Build Apps.
To build the end user interface we will use SAP Build Apps.
SAP Build Apps is a professional application development solution providing an intuitive no-code development environment to empower business users and developers to create apps quickly and visually.
SAP Build Apps key capabilities are:
In our use case the SAP Build Apps application is used by employees in two different steps of our flow:
We will start by configuring our application authentication method. As we want our end users to be authenticated by BTP, we will select the BTP Authentication method. With BTP Authentication users can directly consume BTP destinations and services required by our application without requiring an extra authentication.
To access the different tenant’s data SAP Build Apps directly consumes Graph entities by configuring a BTP destination pointing to our Graph instance. In the next image you can see that the “sa_graph” BTP Destination offers access to the Product entity among others. We can then use this entity to access all the required Graph entities that will connect to the specific backend tenant depending on the Graph configuration.
Once the products and employee details are retrieved via Graph the next step is to call SAP Process Automation flows, to do so SAP Build Apps uses SAP BTP Destinations as well. A REST API integration is configured in SAP Build Apps pointing to a BTP destination called “SAPBuildProcessAutomation” in our specific case. The required headers and the request body to be sent to our flow containing all the required details about the employee placing the order as well as the products to be ordered are configured as well in our SAP Build Apps REST API configuration.
Now that the implementation is completed let’s have a look to the demonstration of the final solution implemented by our SA Repair use case:
This blog is part of a series going over the “SA Repair” use case, please review them all to have a clear full picture:
For more details on the different topics covered by this use case as well as full demos and step by step exercises on each feature implemented you can check a set of sessions we delivered as part of our Hands-on bootcamp: Transform Business Processes Using SAP Signavio and SAP Build.
I hope you have enjoyed this blog and the full series, please leave us a comment!
This blog is part of the SA Repair blogs’ series we have published covering a business use case on the topic “Transform Your Business Processes using SAP Signavio and SAP Build”. The first blog SA Repair: Transform Your Business Processes using SAP Signavio and SAP Build introduced the importance of Process Automation; we talked about how to Analyze a process with SAP Signavio in our second blog SA Repair: Analyze and Explore with SAP Signavio and in our third blog SA Repair: Automate with SAP Build Process Automation we focused on how to Automate some of the manual processes. In this blog SA Repair: Trigger with SAP BTP Graph and Build Apps we will focus on the implementation of the application that the users will consume to Trigger the process.
To develop our application, we will use SAP Build Apps. But before exploring SAP Build Apps let me provide some details about SAP BTP Graph Service.
Graph
As you have seen on the use case description, we will connect to two different backend systems to retrieve and update the data required by our solution:
- SAP S/4 HANA Cloud – to get the list of products that can be purchased.
- SAP Success Factors - to get the list of employees and their corresponding role in the company.
As each backend system has its own set of APIs, we could directly connect to each system and consume their APIs from our application. To simplify the usage and the configuration of the different systems’ APIs we will use an SAP BTP Service called Graph.
Graph is an SAP Business Technology Platform (BTP) service offering a unified API for the Intelligent Enterprise and as such providing developers a single connected and unified view of all their business data. Graph consolidates the data models of data sources like SAP S/4HANA, SAP Sales Cloud and SAP SuccessFactors into one, unified and connected, data model, representing all the data in a landscape. Custom oData APIs can also be configured to be accessed via Graph.
You can setup your own Business Data Graph on your subaccount, where identity, trust and connectivity can be established between your own applications, extensions and integrations, and your landscape. An advantage of Graph is that IT Administrators take care of the Business Data Graph as well as the destination’s configuration, while developers just consume the entities via Graph independently of which specific tenants they are working with.
In our use case architecture, SAP Build Apps application consumes both SAP S/4 HANA Cloud and SAP Success Factors entities via Graph. User Identity is propagated from SAP Build Apps to Graph, and Graph will circulate the identity to each specific backend tenant to verify the end user authentication and authorization.
Developers only connect to the Graph destination configured by IT Administrators without having to care about changes on the specific backend servers’ configuration.
As introduced previously, the next figure shows how Graph accesses the configured APIs on the backend systems via the Destination service.
The next picture shows a snippet of our Graph configuration file where the destinations consumed by our Business Data Graph are listed as DataSources:
A set of Location Policies allows the selection of the leading data source on cases where more than one tenant of the same type is exposed by graph either for entire namespaces like for example “sap.graph” or only for specific entities like for example “sap.graph.Product” shown in the following image:
Now that we understand how a Business Data Graph can help us configure the access to our backend systems, let’s see how we can consume Graph from our user interface application built with SAP Build Apps.
SAP Build Apps
To build the end user interface we will use SAP Build Apps.
SAP Build Apps is a professional application development solution providing an intuitive no-code development environment to empower business users and developers to create apps quickly and visually.
SAP Build Apps key capabilities are:
- Build user interfaces easily
Visually compose enterprise-grade custom apps with drag-and-drop ease. - Create data models and business logic visually
Build cloud services without code - Integrate seamlessly
Connect to SAP and non-SAP solutions securely with pre-built components, connectors, and integrations.
In our use case the SAP Build Apps application is used by employees in two different steps of our flow:
- See the list of products available and order them directly via the application:
- The list of products is read from a S/4 HANA Cloud via SAP Graph.
- Details about the user placing the order are read from a Success Factors tenant via SAP Graph.
- Once a product is selected, SAP Build Apps will start an SAP Process Automation flow to get the product ordered and approved in S/4 HANA Cloud, details about the end user placing the order are also transferred to the flow for further checking. - See the list of orders placed by the application and allow the confirmation of the orders upon reception of the goods:
- Once an order is confirmed, SAP Build Apps will execute an SAP Process Automation flow to get the order confirmed in S/4 HANA Cloud.
We will start by configuring our application authentication method. As we want our end users to be authenticated by BTP, we will select the BTP Authentication method. With BTP Authentication users can directly consume BTP destinations and services required by our application without requiring an extra authentication.
To access the different tenant’s data SAP Build Apps directly consumes Graph entities by configuring a BTP destination pointing to our Graph instance. In the next image you can see that the “sa_graph” BTP Destination offers access to the Product entity among others. We can then use this entity to access all the required Graph entities that will connect to the specific backend tenant depending on the Graph configuration.
Once the products and employee details are retrieved via Graph the next step is to call SAP Process Automation flows, to do so SAP Build Apps uses SAP BTP Destinations as well. A REST API integration is configured in SAP Build Apps pointing to a BTP destination called “SAPBuildProcessAutomation” in our specific case. The required headers and the request body to be sent to our flow containing all the required details about the employee placing the order as well as the products to be ordered are configured as well in our SAP Build Apps REST API configuration.
Now that the implementation is completed let’s have a look to the demonstration of the final solution implemented by our SA Repair use case:
This blog is part of a series going over the “SA Repair” use case, please review them all to have a clear full picture:
- SA Repair: Transform Your Business Processes using SAP Signavio and SAP Build
- SA Repair: Analyze and Explore with SAP Signavio
- SA Repair: Automate with SAP Build Process Automation
- SA Repair: Trigger with SAP BTP Graph and Build Apps (this blog)
For more details on the different topics covered by this use case as well as full demos and step by step exercises on each feature implemented you can check a set of sessions we delivered as part of our Hands-on bootcamp: Transform Business Processes Using SAP Signavio and SAP Build.
I hope you have enjoyed this blog and the full series, please leave us a comment!
- SAP Managed Tags:
1 Comment
