This blog post is part of a series of technical enablements on SAP BTP for Industries.
Check the full calendar here to watch the recordings of past sessions and register for the upcoming ones!
Authors: mariatrinidad.martinezgea, mostafa.sharaf and myself
This blog aims to explain in detail a real-life use case analysis and implementation for the Transportation Industry covering the Fleet Driver Tracking area. We covered this use case in a live session that you can review here as part of a series of use cases our SAP Business Technology Platform team has built to showcase how to design and implement applications on top of the SAP Business Technology Platform.
We’ll start with an introduction to the Transportation Industry, will discuss its challenges and pain points. We will also discuss the impact of bad drivers’ behavior on the industry and its businesses and the solutions that we can offer to tackle them. After that, we will transition to a proposed Solution Architecture, where we will see how to design a cloud solution that might address some of the challenges discussed before.
Once the architecture is presented, we will look at an end-to-end demo of the prototype and move from theory & design to practice & runtime, so that we can show you how each of the components are implemented.
We hope to get you inspired!
The transportation industry refers to the sector involved in moving people and goods from one location to another. In terms of people transportation, it includes various modes such as buses, trains, subways, taxis, ride-sharing services, airplanes, and many others. In terms of goods transportation, efficient transportation systems contribute to businesses fulfilling purchase orders in a timely fashion.
The industry's primary goal is to provide safe, efficient, and reliable transportation services.
This industry plays a crucial role in facilitating economic growth, connecting communities, and improving people's quality of life by providing access to education, employment, healthcare, and leisure activities.
Several of the current challenges on the transportation industry are related to the drivers’ skills, we will present some of them in this blog post.
The top five pain points concerning driver behavior we want to highlight are:
Safety Concerns: Driver behavior such as speeding, reckless driving, and distracted driving can lead to accidents and endanger passengers and other road users.
According to the Insurance Institute for Highway Safety, the improvement on vehicle safety technologies such airbags, ABS, stability control and others have considerably decreased the number of deaths in motor vehicle crashes along the last decades. But that has not been enough to keep such statistics steady due to increasing poor driver behavior in the last two years.
Compliance with Regulations: Drivers must adhere to regulations such as hours of service, vehicle maintenance, and licensing requirements. Failure to comply with these regulations can result in fines, penalties, and legal action.
Cost Management: Managing costs such as fuel consumption, vehicle maintenance, and insurance premiums is critical to the profitability of transportation companies. Driver behavior can have a significant impact on these costs, such as excessive idling, hard braking, and accelerating.
According to the US Department of Transportation, the average cost of maintaining and operating an automobile has steadily increased through the past two decades, with a significant cost in 2022 stemming from a spike in variable cost, most of which caused by poor driver’s behavior.
Customer Satisfaction: Drivers are often the face of the transportation company, and their behavior can affect the customer's overall experience. Professionalism, punctuality, and helpfulness are essential for customer satisfaction.
Employee Retention: The transportation industry often struggles with high turnover rates. Addressing driver behavior pain points can improve job satisfaction, reduce turnover, and increase retention rates.
The next figure shows that in 2022 the driver turnover at private fleets jumped to nearly 23%, a record spike, thus creating the problem space targeted by this use case which is: increase in open positions versus skilled workforce shortage.
In our use case we will focus on the top three pain points: Safety concerns, Cost Management and Employee Retention.
The goal is to build a fleet driver tracking solution for transportation companies, to monitor drivers’ behavior, propose recommendations and take actions to improve it whenever it’s necessary.
Three personas are involved in the scenario:
Whenever John is driving, the sensor devices in the corresponding vehicle capture information such as speed and RPM variation, fuel consumption, braking and steering timing, etc. which is, then, sent to a database handled by a Fleet Driver Tracking App.
Mary will monitor the information proposed by the “Fleet Driver Tracking App” and submit improvement actions and behavior score cards to the drivers’ managers for approval.
The application gets the telemetry data from vehicles and compiles it into a series of KPIs monitored by Mary. It also relies on some custom machine learning models to propose some recommended actions to improve drivers’ behavior and generate individual score cards for performance assessments.
Jane is responsible for approving the recommendations and score cards sent by Mary.
The individual score cards are automatically registered in the company’s HCM system, and the approved recommendations are sent back to John via any usual corporate communication channel such as, for example, e-mail.
Now, let’s see how we can design a solution architecture foundation to cover this business scenario.
On one end we have the public cloud, and on the other, we have SAP Business Technology Platform (namely SAP BTP) which will allow us to extend the backend systems keeping their core clean.
The public cloud hosts the backend systems: SAP S;4HANA Cloud and SAP SuccessFactors, where we have the employees’ data.
In SAP S/4HANA Cloud we have SAP Digital Vehicle Hub, which is built on top of Enterprise Assets Management. Then, we have our first persona: the driver who drives the company’s vehicles from which telemetry data is collected and stored into SAP Digital Vehicle Hub.
Using Integration Suite as a middleware, we retrieve such data doing the appropriate transformations and summarizations and store the outcomes into a driving history database in SAP HANA Cloud.
On SAP BTP we deploy our Fleet Driver Tracking Application whose entry point will be provided by a NodeJS Cloud Application Programming Model (in short CAP) backend service with a Fiori UI accessing data stored in the HANA Cloud database which also feeds a set of KPIs dashboards powered by an SAP Analytics Cloud (in short SAC) tenant.
The same driving history database is used to train custom machine learning models deployed on SAP AI Core which provides recommended actions and score cards to the application.
The application uses SAP Graph to interact with the backend systems.
The SAC dashboard will be embedded into an iframe of the Fleet Drive Tracking application UI. As you may already know, SAC and BTP have their own authentication and authorization features, relying on some Identity Provider to authenticate users. So, the business users of the Fleet Driver Tracking application come from SAP BTP and those users should authenticate to SAC without a “second login” (which we technically call Single Sign-On, in short SSO). This mechanism will be implemented leveraging BTP’s Cloud Identity Services, more specifically the Identity Authentication Service (in short IAS).
The Fleet Manager is the business user who’s going to interact with the Fleet Driver Tracking application when that user selects appropriate recommendations and score cards from the application and submits them for approval a workflow is triggered by SAP Build Process Automation that reaches the Driver Manager’s inbox from where it gets approved or rejected. Approved recommendations are sent back to the driver, for example, via e-mail.
Please, note that this specific blog will focus exclusively on the highlighted components.
Let’s now explore some other ways we could have thought to build this architecture and the rationale behind the decision to choose the selected components and technologies.
Option 1 – without SAP Graph: without SAP Graph our application will require the connection to each one of the solutions it is integrated to, like S/4 HANA Cloud and SuccessFactors. On deployment, our application will need to be configured with the corresponding specific destinations.
By using SAP Graph, the configuration of the environment is done in Graph and the deployed application only needs to get access to the Graph destination for all the required APIs to be consumed.
Option 2 – without IAS: without IAS we would have to manage the users of our application and match their authentication and authorization access to SAC users using its user management APIs. Also, our application would need to take care of the authentication flow in SAC using OAuth 2.0.
Option 3 – without SAC: we could directly develop our own dashboards on our application using, for example, the Analytical Page Fiori template. But, every time a change is required in the dashboards, a developer needs to be engaged to provide such modifications. In this case, IAS would act just as custom IdP to be used by the CAP application. This would be necessary only if the company wants to authenticate using some user store other than the default SAP ID service.
The decision to use SAC in the architecture is because it allows consultants and/or business analysts to adapt the required analytics without having to rely on a developer to modify, test, recompile and redeploy the application.
Option 4 – with RAP: the app could have been built using ABAP Cloud which comprises the RESTful Application Programming Model (in short RAP). Well, decision here is mostly based on the level of expertise of each team in a certain technology, but primarily on the most cost-effective option. In this case, if we opted to go with ABAP, we would need an additional ABAP environment stack that includes a HANA database instance among other pieces of infrastructure. This Is not required, as we are building a side-by-side extension and not in-app development and would lead to unnecessary additional costs while CAP runs on out-of-the-box runtimes available on Cloud Foundry.
Option 5 – with a third-party framework: another option, would be to leverage any other framework or language to build such app. But in that case, if, for any reason, the app had to be extended to incorporate additional functionality, developers would possibly be concerned with technical details that are relieved by the CAP framework. So, that’s the main reason for choosing CAP.
To summarize, the big takeaway here is: “keep it as simple, easy to maintain and cost effective as possible!”
And now, let’s watch a demo video of the complete solution and, then, start right away, to get deeper into the prototyped components: SAP Graph, the setup between SAC and IAS for SSO and the CAP application.
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.
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 Business Data Graph can connect to several systems of the same type, for example more than one S4 backend. In those cases, priorities need to be defined regarding which system is the leading system.
In our case we specify that the BusinessUser entity will be read from the “sap.graph” namespace with SuccessFactors as leading system and the Vehicles will be read from our “s4.vehicles” custom data source.
Now we understand how a Business Data Graph can help us configure the access to our backend systems, let’s continue having a look now to the other components that will be part of our application.
Business success demands strategic, operational, and tactical decision-making. But first, users must access analytics completed with business intelligence, prediction, and planning to act confidently in the moment.
With the SAP Analytics Cloud solution, every user tasked with making intelligent decisions can easily visualize the real-time, contextual insight necessary to boost outcomes.
The goal is to be able to take decisions without Doubt! Thanks to SAP Analytics Cloud you can become a 21st-century intelligent enterprise
SAP Analytics Cloud supports you on the full Insight to Action process:
SAC Modeler uses multi-dimensional modelling approach like cubes in data warehousing. In SAC, a model is a representation of large amounts of business data from source systems. It defines measures & dimensions that are used to build visualizations, filters, and calculations in stories. In SAC, dimensions & measures are data objects that represent categorical, transactional, and numerical data in a model; For example, Products, Sales, or Revenue…etc.
Here is the proposed data model we built specifically for the fleet driving tracking scenario.
Just a clarification regarding Data Integration options before we jump into the demo. With SAC, you can either connect to a live data source OR work with data already imported
With Live Data Connectivity
When using Imported Data Connectivity
Data is refreshed on demand or via schedule.
In our use case we create a live data connectivity to SAP HANA to retrieve the data already imported by our Drivers’ Tracking app that we will analyze in a demo video later on.
SAP Analytics Cloud, Embedded vs Enterprise edition
With SAP Analytics Cloud, embedded edition, you can build and embed reports, dashboards, and visuals into your business application to make confident decisions.
You can explore your business data via live connection between your SAP Analytics Cloud tenant and the remote SAP HANA database on SAP BTP.
It is available as a service on top of BTP under CPEA. This variant is meant for the application developers who would embed SAC and makes the analytics available for the end users within the context of the business application’s UI.
From features point of view, it only offers the BI capabilities (no planning, predictive and analytics designer capabilities available with this variant).
While on the other side, SAC Enterprise Edition is the complete license of analytics that supports the 360-degree analytics with full capabilities like BI, planning, predictive and Analytics designer with both live and import data connection.
Ok, now let’s look at how we did that:
Identity Authentication is part of SAP Cloud Identity Services and represents a strategic central point for authentication for any SAP cloud application with the possibility of being integrated to other third-party cloud applications as well, whereas Identity Provisioning provides a comprehensive, low cost approach to implement identity lifecycle management in the cloud.
This scenario focuses exclusively on Identity Authentication.
The Identity Authentication Service (in short IAS) provides two basic ways for authenticating the users to the different cloud applications for which a trust relationship with it has been previously established:
The first and foremost is pure authentication, where it serves as the main identity provider (in short IdP) meaning that all users are stored and managed by IAS itself.
The second commonly used approach is called identity federation, where IAS simply acts as a proxy IdP and users are not managed by it, hence the actual authentication is delegated to another corporate IdP. In such case, three different scenarios could be implemented:
So, IAS regenerates the SAML assertion in scenarios 2 or 3, but not in scenario 1, and it’s allowed to create users if they don’t exist only in scenario 2 and not 3. Therefore, scenarios 2 and 3 are partially federated.
Depending on several factors (like group membership, IP address range, e-mail domain, user type, etc.), different types of users can be re-routed to different IdPs for authentication (e.g. users with e-mail domain sap.com are routed to the corporate IdP SAP ID Service whereas other users authenticate via IAS itself). That’s exactly the kind of setup we will implement in this use case.
Here’s how authentication of a business user with subsequent system-to-system communication happens on BTP:
Let us understand that picture. You are a developer deploying an application on SAP BTP, so:
Some remarks might be useful in this context:
To get deeper into this topic, please visit: https://blogs.sap.com/2020/02/19/the-cloud-enterprise-security-suite-secure-development-services/.
In this use case, SSO between SAP BTP and SAC has been configured to use the same IdP for authenticating users to both: cloud applications deployed on BTP and SAC.
A particularity of this setup is that it is done using conditional authentication as we have previously seen. As most users from SAP ID Service have the e-mail domain sap.com only those users are authenticated via SAP ID Service. All other users are authenticated via IAS itself, hence they must be registered there and for them a login page will be displayed.
These are the steps to setup SSO in SAC using IAS in this scenario:
1. Establish Trust between SAC and IAS
2. Configure Conditional Authentication in IAS
3. Configure Trusted Origins in SAC
And this completes the SSO setup between SAC and IAS.
The SAP Cloud Application Programming model (in short CAP) is a framework that relieves developers from the burden of concerning with technical details instead of concentrating on what really matters: the business logic to solve real-life business problems.
It provides a “golden path” for agile development of true cloud native applications, fully based on business domain models, relying on proven best practices for cost effective software development and business value achievement.
The framework is available for NodeJS and Java languages, natively serving Fiori UIs through semantic annotations – other UI frameworks supporting generic annotations can be used as well.
It is database agnostic, with native support to SAP HANA and SQLite, serving HTTP requests out-of-the-box based on the OData v4 protocol by combining SAP and open-source technologies.
The backbone of CAP is the so-called “Core Data Services” (in short CDS). So, leveraging the “code first” approach, you start by defining your domain model, which is then reflected in a database. Then, on top of it you create service definitions and add business logic as service handlers, which are easily interpreted by the CAP runtime. You can also add UI annotations to your service entities to be interpreted by some UI framework such as Fiori Elements.
And that’s the main reason why we have chosen CAP to build the app: because the domain model can be easily extended to accommodate new functionality without any concerns with technical details.
To get deeper into the SAP Cloud Application Programming Model, please visit: https://cap.cloud.sap/docs/
Now, let’s move on to the details of the Fleet Driver Tracking application. Please, keep in mind that we will focus exclusively on the key points regarding the elements highlighted in the solution architecture. We won’t be neither showing nor discussing peripheral details such as destination and XSUAA services creation and binding, Fiori App configuration, application deployment, etc. You should take care of such details on your own.
1. Destination to the SAP Graph service
You might recall that an SAP Graph service instance has been previously created to configure the Business Data Model, right? So, view the instance service key using cf service-key (or in BTP cockpit) and in the BTP cockpit create the destination of authentication type “OAuth2ClientCredentials”, using its information.
The uri goes into the URL field, appending the “/v1” endpoint to it, client ID and client secret into their respective fields, and the URL into the Token Service URL field, appending the “/oauth/token” endpoint to it.
2. Import Services Metadata to the CAP Project
3. Destination reference in the CAP Project
Then, two external service definitions are added to the cds.requires section of package.json. The first one is for the HCM model and the second is for the S4 model as previously configured in SAP Graph Business Data Model. This is done when the services metadata are imported to the CAP project, and you just need to add the credentials to point to the SAP Graph destination with the corresponding endpoint for each service: /sap.hcm for the HCM model and /s4.eam for the S4 model.
4. Handle External Services with Low-Code Tools
To avoid writing code to create custom handlers for the external services, we can leverage the low-code external service handler node package (@sap/low-code-event-handler). As it creates HTTP requests to perform service calls it’s also required to install the @Sap-cloud-sdk/http-client node package. After doing so, you also need to reference the low code event handler package in the app-service.impl definition within the cds.requires section.
5. Service Data Model
Next, we define the service data model. From the HCM and S4 external data models, we pick the required entities and their respective most relevant attributes (note that they will be always read-only). Then we define the Drive History entity to store the data collected from SAP Digital Vehicle Hub by the Integration Suite. That’s the only table which will be deployed to the HANA Cloud database. All the rest is coming from the external services.
6. Service Definition
And then, using the data model we expose its entities through a service endpoint secured by user authentication. We also add the UI annotations for each entity in the service definition to be used later by the Fiori Elements templates.
7. Filter Employees
Finally, we write some code in the “before read” event handler of the Employee entity, to force the filtering of employees who belong to the drivers’ department as we want to manage only drivers in the application.
8. Home Page replacement in the Fiori App
Last but not least, after the Fiori App has been created using the usual generator, we rename its original index.html home page to, for example, index_fiori.html and create a new index.html containing two flexible iframes arranged vertically one above the other: in top iframe we load the original Fiori home page and in the bottom an specific SAC story in embed mode with the page bar disabled to get an effect as it was really part of the whole application.
Here are some links to additional resources that can get you up to speed in the presented components and technologies.
And that’s it for this industry use case! This is just the second session of a series; we hope you have enjoyed the reading.
Check the full calendar, register to the upcoming sessions and review the already recorded sessions here!
Check the full calendar here to watch the recordings of past sessions and register for the upcoming ones!
Authors: mariatrinidad.martinezgea, mostafa.sharaf and myself
Introduction
This blog aims to explain in detail a real-life use case analysis and implementation for the Transportation Industry covering the Fleet Driver Tracking area. We covered this use case in a live session that you can review here as part of a series of use cases our SAP Business Technology Platform team has built to showcase how to design and implement applications on top of the SAP Business Technology Platform.
We’ll start with an introduction to the Transportation Industry, will discuss its challenges and pain points. We will also discuss the impact of bad drivers’ behavior on the industry and its businesses and the solutions that we can offer to tackle them. After that, we will transition to a proposed Solution Architecture, where we will see how to design a cloud solution that might address some of the challenges discussed before.
Once the architecture is presented, we will look at an end-to-end demo of the prototype and move from theory & design to practice & runtime, so that we can show you how each of the components are implemented.
We hope to get you inspired!
What is the Transportation Industry?
The transportation industry refers to the sector involved in moving people and goods from one location to another. In terms of people transportation, it includes various modes such as buses, trains, subways, taxis, ride-sharing services, airplanes, and many others. In terms of goods transportation, efficient transportation systems contribute to businesses fulfilling purchase orders in a timely fashion.
The industry's primary goal is to provide safe, efficient, and reliable transportation services.
This industry plays a crucial role in facilitating economic growth, connecting communities, and improving people's quality of life by providing access to education, employment, healthcare, and leisure activities.
The Challenge
Several of the current challenges on the transportation industry are related to the drivers’ skills, we will present some of them in this blog post.
The top five pain points concerning driver behavior we want to highlight are:
Safety Concerns: Driver behavior such as speeding, reckless driving, and distracted driving can lead to accidents and endanger passengers and other road users.
According to the Insurance Institute for Highway Safety, the improvement on vehicle safety technologies such airbags, ABS, stability control and others have considerably decreased the number of deaths in motor vehicle crashes along the last decades. But that has not been enough to keep such statistics steady due to increasing poor driver behavior in the last two years.
Source: IIHS-HLDI - https://www.iihs.org/topics/fatality-statistics/detail/yearly-snapshot
Compliance with Regulations: Drivers must adhere to regulations such as hours of service, vehicle maintenance, and licensing requirements. Failure to comply with these regulations can result in fines, penalties, and legal action.
Cost Management: Managing costs such as fuel consumption, vehicle maintenance, and insurance premiums is critical to the profitability of transportation companies. Driver behavior can have a significant impact on these costs, such as excessive idling, hard braking, and accelerating.
According to the US Department of Transportation, the average cost of maintaining and operating an automobile has steadily increased through the past two decades, with a significant cost in 2022 stemming from a spike in variable cost, most of which caused by poor driver’s behavior.
Source: US Department of Transportation - https://www.bts.gov/content/average-cost-owning-and-operating-automobilea-assuming-15000-vehicle-mil...
Customer Satisfaction: Drivers are often the face of the transportation company, and their behavior can affect the customer's overall experience. Professionalism, punctuality, and helpfulness are essential for customer satisfaction.
Employee Retention: The transportation industry often struggles with high turnover rates. Addressing driver behavior pain points can improve job satisfaction, reduce turnover, and increase retention rates.
The next figure shows that in 2022 the driver turnover at private fleets jumped to nearly 23%, a record spike, thus creating the problem space targeted by this use case which is: increase in open positions versus skilled workforce shortage.
Source: NPTC Report - https://www.truckinginfo.com/10183906/nptc-report-driver-turnover-spikes-at-private-fleets
In our use case we will focus on the top three pain points: Safety concerns, Cost Management and Employee Retention.
How Can You Help, as an SAP Partner? The Proposed Solution
The goal is to build a fleet driver tracking solution for transportation companies, to monitor drivers’ behavior, propose recommendations and take actions to improve it whenever it’s necessary.
Three personas are involved in the scenario:
- The first persona is John, a professional driver who drives the company’s vehicles.
Whenever John is driving, the sensor devices in the corresponding vehicle capture information such as speed and RPM variation, fuel consumption, braking and steering timing, etc. which is, then, sent to a database handled by a Fleet Driver Tracking App.
- The second persona is Mary, a fleet manager responsible for monitoring driver behavior.
Mary will monitor the information proposed by the “Fleet Driver Tracking App” and submit improvement actions and behavior score cards to the drivers’ managers for approval.
The application gets the telemetry data from vehicles and compiles it into a series of KPIs monitored by Mary. It also relies on some custom machine learning models to propose some recommended actions to improve drivers’ behavior and generate individual score cards for performance assessments.
- The third persona is Jane, who’s John’s manager.
Jane is responsible for approving the recommendations and score cards sent by Mary.
The individual score cards are automatically registered in the company’s HCM system, and the approved recommendations are sent back to John via any usual corporate communication channel such as, for example, e-mail.
The Proposed Solution Architecture
Now, let’s see how we can design a solution architecture foundation to cover this business scenario.
On one end we have the public cloud, and on the other, we have SAP Business Technology Platform (namely SAP BTP) which will allow us to extend the backend systems keeping their core clean.
The public cloud hosts the backend systems: SAP S;4HANA Cloud and SAP SuccessFactors, where we have the employees’ data.
In SAP S/4HANA Cloud we have SAP Digital Vehicle Hub, which is built on top of Enterprise Assets Management. Then, we have our first persona: the driver who drives the company’s vehicles from which telemetry data is collected and stored into SAP Digital Vehicle Hub.
Using Integration Suite as a middleware, we retrieve such data doing the appropriate transformations and summarizations and store the outcomes into a driving history database in SAP HANA Cloud.
On SAP BTP we deploy our Fleet Driver Tracking Application whose entry point will be provided by a NodeJS Cloud Application Programming Model (in short CAP) backend service with a Fiori UI accessing data stored in the HANA Cloud database which also feeds a set of KPIs dashboards powered by an SAP Analytics Cloud (in short SAC) tenant.
The same driving history database is used to train custom machine learning models deployed on SAP AI Core which provides recommended actions and score cards to the application.
The application uses SAP Graph to interact with the backend systems.
The SAC dashboard will be embedded into an iframe of the Fleet Drive Tracking application UI. As you may already know, SAC and BTP have their own authentication and authorization features, relying on some Identity Provider to authenticate users. So, the business users of the Fleet Driver Tracking application come from SAP BTP and those users should authenticate to SAC without a “second login” (which we technically call Single Sign-On, in short SSO). This mechanism will be implemented leveraging BTP’s Cloud Identity Services, more specifically the Identity Authentication Service (in short IAS).
The Fleet Manager is the business user who’s going to interact with the Fleet Driver Tracking application when that user selects appropriate recommendations and score cards from the application and submits them for approval a workflow is triggered by SAP Build Process Automation that reaches the Driver Manager’s inbox from where it gets approved or rejected. Approved recommendations are sent back to the driver, for example, via e-mail.
Please, note that this specific blog will focus exclusively on the highlighted components.
Exploring the Possibilities
Let’s now explore some other ways we could have thought to build this architecture and the rationale behind the decision to choose the selected components and technologies.
Option 1 – without SAP Graph: without SAP Graph our application will require the connection to each one of the solutions it is integrated to, like S/4 HANA Cloud and SuccessFactors. On deployment, our application will need to be configured with the corresponding specific destinations.
By using SAP Graph, the configuration of the environment is done in Graph and the deployed application only needs to get access to the Graph destination for all the required APIs to be consumed.
Option 2 – without IAS: without IAS we would have to manage the users of our application and match their authentication and authorization access to SAC users using its user management APIs. Also, our application would need to take care of the authentication flow in SAC using OAuth 2.0.
Option 3 – without SAC: we could directly develop our own dashboards on our application using, for example, the Analytical Page Fiori template. But, every time a change is required in the dashboards, a developer needs to be engaged to provide such modifications. In this case, IAS would act just as custom IdP to be used by the CAP application. This would be necessary only if the company wants to authenticate using some user store other than the default SAP ID service.
The decision to use SAC in the architecture is because it allows consultants and/or business analysts to adapt the required analytics without having to rely on a developer to modify, test, recompile and redeploy the application.
Option 4 – with RAP: the app could have been built using ABAP Cloud which comprises the RESTful Application Programming Model (in short RAP). Well, decision here is mostly based on the level of expertise of each team in a certain technology, but primarily on the most cost-effective option. In this case, if we opted to go with ABAP, we would need an additional ABAP environment stack that includes a HANA database instance among other pieces of infrastructure. This Is not required, as we are building a side-by-side extension and not in-app development and would lead to unnecessary additional costs while CAP runs on out-of-the-box runtimes available on Cloud Foundry.
Option 5 – with a third-party framework: another option, would be to leverage any other framework or language to build such app. But in that case, if, for any reason, the app had to be extended to incorporate additional functionality, developers would possibly be concerned with technical details that are relieved by the CAP framework. So, that’s the main reason for choosing CAP.
To summarize, the big takeaway here is: “keep it as simple, easy to maintain and cost effective as possible!”
Solution Demo
And now, let’s watch a demo video of the complete solution and, then, start right away, to get deeper into the prototyped components: SAP Graph, the setup between SAC and IAS for SSO and the CAP application.
Implementation
SAP 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:
- Custom CDS View on SAP S/4 HANA Cloud – to get the list of the Vehicles and their details.
- SAP Success Factors – to get the list of drivers and their details.
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.
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 Business Data Graph can connect to several systems of the same type, for example more than one S4 backend. In those cases, priorities need to be defined regarding which system is the leading system.
In our case we specify that the BusinessUser entity will be read from the “sap.graph” namespace with SuccessFactors as leading system and the Vehicles will be read from our “s4.vehicles” custom data source.
Now we understand how a Business Data Graph can help us configure the access to our backend systems, let’s continue having a look now to the other components that will be part of our application.
Dashboards in SAP Analytics Cloud
Business success demands strategic, operational, and tactical decision-making. But first, users must access analytics completed with business intelligence, prediction, and planning to act confidently in the moment.
With the SAP Analytics Cloud solution, every user tasked with making intelligent decisions can easily visualize the real-time, contextual insight necessary to boost outcomes.
The goal is to be able to take decisions without Doubt! Thanks to SAP Analytics Cloud you can become a 21st-century intelligent enterprise
SAP Analytics Cloud supports you on the full Insight to Action process:
- You can analyze your data through visualizations and get smart insights
- You can collaborate with other SAC users or teams by adding comments on any visualization or specific data, having discussions, and sharing private or public stories
- With automated, AI-guided analytics; predict potential outcomes and forecasts based on the historical data
- Embed your analytic dashboards on your applications
- Schedule stories and analytic applications for SAC users or teams and even non-SAC recipients, on-demand or on a recurring schedule
- Ask questions in a conversational way – and get instant answers, data visualizations, and explanations – with natural language processing and generation.
SAC Modeler uses multi-dimensional modelling approach like cubes in data warehousing. In SAC, a model is a representation of large amounts of business data from source systems. It defines measures & dimensions that are used to build visualizations, filters, and calculations in stories. In SAC, dimensions & measures are data objects that represent categorical, transactional, and numerical data in a model; For example, Products, Sales, or Revenue…etc.
Here is the proposed data model we built specifically for the fleet driving tracking scenario.
Just a clarification regarding Data Integration options before we jump into the demo. With SAC, you can either connect to a live data source OR work with data already imported
With Live Data Connectivity
- Data is never replicated to cloud – real-time data is streamed directly to client machine
- This connectivity leverages source system's existing business metadata and data authorizations
When using Imported Data Connectivity
- Data is imported/copied into SAP Analytics Cloud
- Users can prepare, wrangle and model the data
Data is refreshed on demand or via schedule.
In our use case we create a live data connectivity to SAP HANA to retrieve the data already imported by our Drivers’ Tracking app that we will analyze in a demo video later on.
SAP Analytics Cloud, Embedded vs Enterprise edition
With SAP Analytics Cloud, embedded edition, you can build and embed reports, dashboards, and visuals into your business application to make confident decisions.
You can explore your business data via live connection between your SAP Analytics Cloud tenant and the remote SAP HANA database on SAP BTP.
It is available as a service on top of BTP under CPEA. This variant is meant for the application developers who would embed SAC and makes the analytics available for the end users within the context of the business application’s UI.
From features point of view, it only offers the BI capabilities (no planning, predictive and analytics designer capabilities available with this variant).
While on the other side, SAC Enterprise Edition is the complete license of analytics that supports the 360-degree analytics with full capabilities like BI, planning, predictive and Analytics designer with both live and import data connection.
Ok, now let’s look at how we did that:
Identity Authentication Services (IAS)
Identity Authentication is part of SAP Cloud Identity Services and represents a strategic central point for authentication for any SAP cloud application with the possibility of being integrated to other third-party cloud applications as well, whereas Identity Provisioning provides a comprehensive, low cost approach to implement identity lifecycle management in the cloud.
This scenario focuses exclusively on Identity Authentication.
The Identity Authentication Service (in short IAS) provides two basic ways for authenticating the users to the different cloud applications for which a trust relationship with it has been previously established:
The first and foremost is pure authentication, where it serves as the main identity provider (in short IdP) meaning that all users are stored and managed by IAS itself.
The second commonly used approach is called identity federation, where IAS simply acts as a proxy IdP and users are not managed by it, hence the actual authentication is delegated to another corporate IdP. In such case, three different scenarios could be implemented:
- The user doesn’t exist in IAS at all: the corporate IdP generates the SAML assertion and IAS just forwards it to the application (called full delegation).
- The user is replicated from the corporate IdP: when IAS receives the SAML assertion from the corporate IdP it creates the user in IAS (if not existing yet) based on the SAML attributes. Afterwards, IAS enriches the SAML assertion and forwards it to the application.
- The user exists in both, corporate IdP and IAS: the SAML assertion is enriched based on the attributes in IAS and forwarded to the application.
So, IAS regenerates the SAML assertion in scenarios 2 or 3, but not in scenario 1, and it’s allowed to create users if they don’t exist only in scenario 2 and not 3. Therefore, scenarios 2 and 3 are partially federated.
Depending on several factors (like group membership, IP address range, e-mail domain, user type, etc.), different types of users can be re-routed to different IdPs for authentication (e.g. users with e-mail domain sap.com are routed to the corporate IdP SAP ID Service whereas other users authenticate via IAS itself). That’s exactly the kind of setup we will implement in this use case.
Here’s how authentication of a business user with subsequent system-to-system communication happens on BTP:
Let us understand that picture. You are a developer deploying an application on SAP BTP, so:
- A business user wants to access your application
- The application router is always the single point of entry to any SAP BTP application. The app router is an SAP-specific component which orchestrates the app authentication and manages OAuth tokens.
- The application router forwards the request to the Authorization Service (XSUAA)
- Authorization Service forwards the request to SAP Cloud Identity Services, to enforce the business user to authenticate. The SAP XSUAA service is instantiated via the subaccount and can reuse an already connected external IdP.
- If the authentication was successful, the user (actually, the web browser of the user) gets a SAML token. This SAML token is used to authenticate against Authorization Service. Why this step? Because a business user can use this SAML token to access all configured applications – users often work on processes which require to access many systems.
- The Authorization Service then generates an OAuth Token which is technically a Jason Web Token (in short JWT). This JWT token will be used by the application router for your application. It cannot be reused by other applications and is only valid for a very short timeframe.
Some remarks might be useful in this context:
- The Authorization Service (XSUAA) is an OAuth server. OAuth is a framework, and it does not specify a concrete security token implementation. Authorization Service is an OAuth Server using JWT tokens.
- OAuth is not designed to authenticate business users – it is primary used for system-to-system authentication/authorization but with a user context
- SAML (standing for Security Assertion Markup Language) is used for the authentication via a web browser (by SAP Cloud Identity Services). It is an established standard in enterprises and allows a wide range of integration scenarios
- You could replace in this scenario also SAP Cloud Identity Services with an 3rd party SAML Identity Provider. But it makes only sense in a standalone scenario since SAP Cloud Identity Services is the default authentication authority for SAP Cloud applications (SaaS). There is also the option to run SAP Cloud Identity Services in a proxy mode.
To get deeper into this topic, please visit: https://blogs.sap.com/2020/02/19/the-cloud-enterprise-security-suite-secure-development-services/.
In this use case, SSO between SAP BTP and SAC has been configured to use the same IdP for authenticating users to both: cloud applications deployed on BTP and SAC.
- The business users authenticate to the cloud application
- User credentials are checked against the SAP ID Service
- The IdP sends the generated SAML assertion back to SAP BTP which will leverage the Authentication Service (XSUAA) to generate the JWT for further propagation as seen in the previous image
- Having the user properly authenticated, the application loads an embedded SAC dashboard
- At this point, SAC requires user authentication, as principal propagation (meaning propagate the same user to SAC) is not available in this scenario. So, SAC requests IAS to authenticate the user as a trust relationship has been established between them.
- IAS delegates authentication to SAP ID Service. In this case, a login page is not displayed, because corporate users from SAP ID Service use an X.509 client certificate for authentication.
- SAP ID Service generates the SAML assertion and sends it back to IAS
- IAS immediately forwards the SAML assertion (with no enrichments) to SAC, thus completing the authentication flow
- SAC responds with the requested dashboard
A particularity of this setup is that it is done using conditional authentication as we have previously seen. As most users from SAP ID Service have the e-mail domain sap.com only those users are authenticated via SAP ID Service. All other users are authenticated via IAS itself, hence they must be registered there and for them a login page will be displayed.
These are the steps to setup SSO in SAC using IAS in this scenario:
1. Establish Trust between SAC and IAS
2. Configure Conditional Authentication in IAS
3. Configure Trusted Origins in SAC
And this completes the SSO setup between SAC and IAS.
Fleet Driver Tracking App built with CAP
The SAP Cloud Application Programming model (in short CAP) is a framework that relieves developers from the burden of concerning with technical details instead of concentrating on what really matters: the business logic to solve real-life business problems.
It provides a “golden path” for agile development of true cloud native applications, fully based on business domain models, relying on proven best practices for cost effective software development and business value achievement.
The framework is available for NodeJS and Java languages, natively serving Fiori UIs through semantic annotations – other UI frameworks supporting generic annotations can be used as well.
It is database agnostic, with native support to SAP HANA and SQLite, serving HTTP requests out-of-the-box based on the OData v4 protocol by combining SAP and open-source technologies.
The backbone of CAP is the so-called “Core Data Services” (in short CDS). So, leveraging the “code first” approach, you start by defining your domain model, which is then reflected in a database. Then, on top of it you create service definitions and add business logic as service handlers, which are easily interpreted by the CAP runtime. You can also add UI annotations to your service entities to be interpreted by some UI framework such as Fiori Elements.
And that’s the main reason why we have chosen CAP to build the app: because the domain model can be easily extended to accommodate new functionality without any concerns with technical details.
To get deeper into the SAP Cloud Application Programming Model, please visit: https://cap.cloud.sap/docs/
Now, let’s move on to the details of the Fleet Driver Tracking application. Please, keep in mind that we will focus exclusively on the key points regarding the elements highlighted in the solution architecture. We won’t be neither showing nor discussing peripheral details such as destination and XSUAA services creation and binding, Fiori App configuration, application deployment, etc. You should take care of such details on your own.
1. Destination to the SAP Graph service
You might recall that an SAP Graph service instance has been previously created to configure the Business Data Model, right? So, view the instance service key using cf service-key (or in BTP cockpit) and in the BTP cockpit create the destination of authentication type “OAuth2ClientCredentials”, using its information.
The uri goes into the URL field, appending the “/v1” endpoint to it, client ID and client secret into their respective fields, and the URL into the Token Service URL field, appending the “/oauth/token” endpoint to it.
2. Import Services Metadata to the CAP Project
3. Destination reference in the CAP Project
Then, two external service definitions are added to the cds.requires section of package.json. The first one is for the HCM model and the second is for the S4 model as previously configured in SAP Graph Business Data Model. This is done when the services metadata are imported to the CAP project, and you just need to add the credentials to point to the SAP Graph destination with the corresponding endpoint for each service: /sap.hcm for the HCM model and /s4.eam for the S4 model.
4. Handle External Services with Low-Code Tools
To avoid writing code to create custom handlers for the external services, we can leverage the low-code external service handler node package (@sap/low-code-event-handler). As it creates HTTP requests to perform service calls it’s also required to install the @Sap-cloud-sdk/http-client node package. After doing so, you also need to reference the low code event handler package in the app-service.impl definition within the cds.requires section.
5. Service Data Model
Next, we define the service data model. From the HCM and S4 external data models, we pick the required entities and their respective most relevant attributes (note that they will be always read-only). Then we define the Drive History entity to store the data collected from SAP Digital Vehicle Hub by the Integration Suite. That’s the only table which will be deployed to the HANA Cloud database. All the rest is coming from the external services.
6. Service Definition
And then, using the data model we expose its entities through a service endpoint secured by user authentication. We also add the UI annotations for each entity in the service definition to be used later by the Fiori Elements templates.
7. Filter Employees
Finally, we write some code in the “before read” event handler of the Employee entity, to force the filtering of employees who belong to the drivers’ department as we want to manage only drivers in the application.
8. Home Page replacement in the Fiori App
Last but not least, after the Fiori App has been created using the usual generator, we rename its original index.html home page to, for example, index_fiori.html and create a new index.html containing two flexible iframes arranged vertically one above the other: in top iframe we load the original Fiori home page and in the bottom an specific SAC story in embed mode with the page bar disabled to get an effect as it was really part of the whole application.
Useful References
Here are some links to additional resources that can get you up to speed in the presented components and technologies.
- SAP Community - Graph
- SAP Community - Identity Services
- SAP BTP Security Recommendations | SAP Help Portal
- SAP Community – SAP Analytics Cloud
- SAP Community – SAP Cloud Application Programing Model
Wrap-up
And that’s it for this industry use case! This is just the second session of a series; we hope you have enjoyed the reading.
Check the full calendar, register to the upcoming sessions and review the already recorded sessions here!
- SAP Managed Tags:
