This blog post is part of a series of technical enablement sessions on SAP BTP for Industries.
Check the full calendar here to watch the recordings of past sessions and register for the upcoming ones!
Authors: Alessandro Biagi, Trinidad Martinez.
Introduction
In this third session of the series we present a simple but powerful approach addressing some of the Real Estate Industry issues on top of the SAP Business Technology Platform.
We start with an introduction to the Real Estate Industry, discuss its challenges and pain points, focusing on the workplace management, and the solutions that we can offer to tackle them.
In a second section, we will propose an architecture taking advantage of several SAP Business Technology Platform services and we will argument our choice. We will share as well an end-to-end demo of the prototype.
We will then move from theory & design to practice & runtime, so that we can show you how each of the components are implemented.
This blog will give you a hands-on experience of the drafted prototype. You will learn not only how to design but also how to bring a solution into a proof-of-concept and how it can help improving businesses in the workplace management.
This doesn’t aim to be a Master Class on all the pieces and parts of a solution, but rather a highlighting on how to go from the analysis of challenges for a specific industry to the implementation of a solution, through the design of a good cloud native architecture.
We hope that by the end of this blog, you will have a better understanding of the Real Estate Industry, mostly with regards to the workplace management, its challenges, and solutions, and how to craft solutions on top of the SAP Business Technology Platform to help customer in their industry out there.
We hope to get you inspired!
Let’s get started!
What is the Real Estate Industry?
So, what is the Real Estate industry? We want to briefly touch on it and its relevance in the context of the workplace management.
The real estate industry is comprised by a broad range of activities, including the buying, selling, and renting of properties such as homes, commercial buildings, and land.
It is a crucial sector of the economy that has a significant impact on individuals, businesses, and communities.
Now, in the context of workplace management, real estate plays a vital role in ensuring the smooth operation of businesses. Effective workplace management requires that companies have adequate physical space and facilities that meet their operational needs.
The workplace industry can be broadly divided into several sectors and here we see a few we selected:
- Facilities management: This sector is concerned with the physical infrastructure of the workplace, including maintenance, repairs, and security.
- Human resources: HR is responsible for managing the people who work in the workplace and how it operates in the context of recruitment, training, and performance management.
- Employees: their engagement and diversity has increased in the last decade due to the many benefits it provides for both employees and organizations. This sector is focused on fostering a positive workplace culture and promoting employee satisfaction and well-being.
- Workplace design: this is concerned with creating functional, comfortable, and aesthetically pleasing work environments that support productivity and collaboration.
- Technology: here we are talking about the digital tools and systems that enable businesses to operate, including software, hardware, and communication networks.
As mentioned before, all these factors are interconnected and often work together to create a cohesive and effective workplace environment.
The Challenge
Managing the workspace can be challenging to the facilities teams to offer solutions to evolving teams and employee needs while also controlling expenses. Attaining a balance on those two factors leads to productive and collaborative spaces that stimulates innovation and cost-effective management.
To succeed in that challenge, we need to address the main pain points that impact a lot on the workplace management. These issues include space utilization, employee productivity, change management, technology integration, and cost control.
Of course, we do not aim to attack all those pain points at once here in this session, not even to cover one of them entirely. The idea here is to focus on couple of them, those you see here, and show you how you can assist your customers with a good solution architecture and implementation.
But, before coming to the solution architecture, I brought here to you interesting data from recent studies on that area.
A study by JLL found that, on average, offices are only 60% utilized during normal working hours, highlighting the issue of underutilization of space. The same study found that organizations could save up to 30% on real estate costs by optimizing space utilization.
Source: https://stage-uk.jll.com/content/dam/jll-com/documents/pdf/personalized-benchmarking/jll-global-2020...
Another study by Steelcase found that employees who have control over their work environment are 88% more productive than those who do not, clearly showing a key factor on what is needed to have highly engaged employees.
Source: https://info.steelcase.com/global-employee-engagement-workplace-comparison#key-finding-2
Finally, the change management. This study found that effective change management practices led to a higher net promoter score, increased job satisfaction, and employee productivity, showing how important it is to offer the right space for different needs, even sometimes for the same team of employees.
Source: https://www.gensler.com/uploads/document/816/file/Gensler_US_Workplace_Survey_2019.pdf
Now, the question is, what would be a great solution architecture to support great space utilization, that would improve Employee Productivity and enable effective change management?
How Can You Help, as an SAP Partner? The Proposed Solution.
You can call it Workplace Management Solution, although this is not a product, it’s just a demonstration on how to go from challenges into architecture and then landing into a proof of concept.
We are going to design an extension to existing Real Estate management solutions. The goal is to automate and streamline the process of managing team workspace requests. With some advanced features, it provides an efficient and effective way of working both remotely, on-site or at the co-working of employees and team’s choice.
The core solution of our extension is an existing industry cloud solution: the SAP Intelligent Real Estate. This solution combines the power of S/4HANA contract management and SAP Cloud for Real Estate; and is built and runs on SAP BTP. Our extension pulls master data from the workplaces that have been set up by the company's facilities teams.
Let’s now talk about the use case itself and the proposed solution.
The scenario involves 3 personas:
The first one is Mary, a facilities manager of a company that configures the workplaces available to employees on a given office. She configures it based on master data and information available on a core SAP solution, for multiple workspaces.
The second is John, an employee who works for that same company and eventually needs to book a seat at the place of his choice.
Finally, the third person is Jane, John’s manager who approves his requests and she can also book a seat for herself.
As this is a multitenant SaaS solution, it will scale to several customers within the same context and needs.
Ok now, how can we build a great architecture to support this use case, ensuring security on data isolation and right authorization to the several personas and companies represented here?
This is exactly what we will explore below.
The Proposed Solution Architecture
Let’s see how design a solution architecture foundation to cover this business scenario.
On one side we have the SAP Cloud Solutions, containing for each customer the workplaces managed by SAP Cloud for Real Estate with the possibility to streamline the end-to-end real estate business processes through native integration with SAP S/4HANA and other connected applications. We also have external coworking workspaces proposing extra workplaces outside the company buildings. And we have the SAP Business Technology Platform which allow us to extend the backend systems keeping their core clean.
Our application is a Multi-tenant Software as a Service application, running in a Provider Subaccount. The application is implemented as a NodeJS backend service that leverages the Cloud Application Programming Model (in short CAP) with a Fiori UI accessing the data stored in the SAP HANA Cloud database.
For each customer the provider creates a BTP Subaccount (part of the same Provider Global Account) from within a subscription to the Workplace Management application is done. The different customers will access the same application by the means of a Subscription. In each Consumer Subaccount we configure the Destinations each customer requires to access his specific backend systems like for example the SAP Cloud for Real State backend.
The facilities manager of each customer will configure the Workplace Management App to define which workplaces can be booked by the customer employees. The workspaces made available can be from the SAP Cloud for Real State tenant attached to his company but also external coworking workspaces can be configured. The data from the external coworking workspaces could be imported into our application from the different coworking workspaces APIs via the Integration Suite acting as a middleware. Please note this component is not part of the prototyped solution but it is only a possible option for improving the solution.
Once the Facilities Manager has finished the configuration. Employees or Team’s Managers can access the Workplace Management App to book the required workplaces depending on the Facilities Manager configuration; an approval procedure might be required for the booking to be confirmed.
If an approval is required a workflow could be triggered on SAP Build Process Automation that for example reaches the Employee Manager’s inbox from where it could get approved or rejected. Approved bookings could then be stored and if required confirmed back to the provider for billing. Please note this component is not part of the prototyped solution but it is only a possible option for improving the solution.
We have proposed here a full architecture consuming several services. Please note, that in this blog will exclusively focus on how to implement the highlighted components.
But before moving to the implementation, let’s explore some other architecture options and the motivation behind our decision to choose the selected components and technologies.
Exploring other 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 multi-tenancy: In a single tenant architecture, 1. each customer will have to deploy the application in their own subaccount and 2. each one of the required service instances will need to be created for each customer, which implies of course fully paying for them.
We decided to implement a multi-tenant Software as a Service application to take advantage of the ready to use multitenant capabilities proposed by BTP, we will see more details later in this blog.
Option 2 – without Integration Suite: Without the Integration Suite middleware, an option could be to develop specific connectors for each coworking workspace solution API. This option implies the implementation, test and deployment of a new version of our application every time a customer wants to consume workplaces from a new coworking facility having a different API.
Redesigning an integration flow option via the Integration Suite requires less effort.
Option 3 – without SAP Build Process Automation: We could directly develop our own approval flow on our application without SAP Build Process Automation. But in this case, every time a change is required in the approval flow, a developer needs to be engaged to provide such modifications as the flow is part of the application code.
The decision to use SAP Build Process Automation in the architecture allows consultants, citizen developers or technical users to adapt the required flows without having to rely on a developer to modify, test, recompile and redeploy the application.
Option 4 – with Third-Party Framework: Another possible option would be instead of using CAP, to leverage any other framework or language to build the application. 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 facilitated by the CAP framework. Multi-tenancy features are also part of the Cloud application Programming model, and we will see that they will facilitate the implementation of the multi-tenancy features of our application.
Option 5 – with RAP: Instead of CAP, the application could also have been built using ABAP Cloud which includes the RESTfull Application Programming Model (in short RAP). Here the decision could be based on the level of expertise of the team in a certain technology or the features offered by each one of the programming languages.
In our case we opted for a NodeJS implementation offered by the CAP.
To summarize, the big takeaway here is: “keep it as simple, easy to maintain and cost effective as possible!”
Solution Demo
Before going deep into the implementation, let’s watch a demo video of the complete solution:
Implementation
Now that we’ve got a clear understanding of the architecture and components that compose our solution and we saw how the prototyped application looks like it is time to deep dive on each of the prototyped components to learn how we did configure, implement and deploy them in the SAP Business Technology platform.
Multi-tenancy
Developing a multi-tenant application implies several benefits, here we have listed the main ones:
Let’s have a look now to the multi-tenancy Software as a Service architecture:
In a multitenant architecture, the provider (typically the partner) develops a SaaS application that he deploys in his own provider subaccount. The provider develops and operates SaaS applications and pays for the platform resources consumed by the application.
Then, for each consumer/customer that wants to consume the application, a consumer subaccount is created and a Subscription to the SaaS application done. Each subscribed consumer has a specific URL based on his subaccount subdomain. But all of them access to the same the SaaS Multitenant application running on the Provider Subaccount.
The customer pays for the subscription to consume the SaaS application that is running in the provider subaccount and shared by all customers. The customer doesn’t pay for the BTP services and resources required by the SaaS application shared with other customers.
We have seen that each consumer creates a subscription to the SaaS Multitenant application on BTP. But how is the Subscription process implemented by our application?
Saas Provisioning Service
BTP has a service called “SaaS Provisioning Service” and our application will register to that service to get listed as a SaaS application. To support SaaS Multitenancy, the application needs to implement the onboarding and offboarding callbacks that are called every time a subscription and un-subscription process are started by a specific consumer/tenant.
To support multitenancy, you need to implement:
- onboarding/offboarding callbacks – called on each customer subscription/unsubscription:
- PUT - called when a subscription is created
- DELETE – called when a subscription is removed.
- getDependencies callback(optional) – If your application is XSUAA-based and has dependencies.
Multi-tenancy with CAP
To facilitate the implementation of your multi-tenant applications we use CAP. CAP has a built-in support for multitenancy with the @sap/cds-mtxs package and guarantees, that each request is served in isolation, which means all work on separate app data, both in service layers as well as in databases.
To make a SaaS application available for subscription to SaaS consumer tenants, the application provider must register the application in the SAP BTP Cloud Foundry environment through the SaaS Provisioning Service by setting the cds requires multitenancy property to true:
Then in the applications mta.yaml we configure the Saas-registry service:
CAP implements some default actions for the saas-registry callbacks. You can still add some extra actions like for example in our case:
- create the specific route for each tenant on Subscription on provisioning.on(UPDATE).
- delete the route on Unsubscription on provisioning.on(DELETE).
- return the multi-tenant services the application consumes as dependencies on provisioning.on(dependencies).
Subscription Management Dashboard
Administrators can access the “Subscription Management Dashboard” to check the list of existing subscriptions for each specific SaaS application deployed, from the SaaS Provisioning Service instance created automatically during the deployment of the SaaS application.
In our case we can see for example that we have 2 subscriptions from wpm-cons2 and wpm-cons1 subaccounts. And if we select one of the subscriptions, we can see all the details, including the application dependencies:
Persistence
If we look at the different services that our multi-tenant application will consume an important point to consider is the data separation between the different consumers. Although the tenants share resources, the data must be stored separately from each other, and one tenant should never be able to access the data of another tenant.
There are multiple options to separate the data ranging from discriminator column to distinct database instances offering different levels of separation and costs:
With the tenant discriminator column option all the data is stored in a shared schema on the same database and the tenant information is provided in a discriminator column. This is the most cost-efficient option but provides a very weak data separation. With this option tenant-specific extensions must implement the discriminator filtering in all features. Additionally, backup and restore is only possible for all tenants at once.
The middle option is Schema Separation where every tenant gets its own schema in a shared database. This is the best compromise, offering a good level of data separation as well as cost efficiency. Tenant-specific backups and restore can be possible depending on the database chosen.
With the Database Instances separation option every tenant gets its very own database instance. This option guarantees highest data separation but also results in highest costs, e.g. for operating all of these instances. Backup and restore are possible for each tenant separately. For customers with a lot of data, this could be a suitable choice.
Considering the given criteria, schema separation is a good match for a lot of projects. This is the default option implemented by Cloud Application Programming model on top of SAP HANA Cloud and the option implemented in our prototype.
We will then have a single SAP HANA Cloud instance shared among the different consumers/tenants and a specific HDI Container for each consumer/tenant. To manage the different HDI containers in SAP HANA Cloud we will take advantage of CAP model, automatically managing the creation and access to the different containers required for multi-tenancy via the BTP service called Service Manager:
Destinations
For accessing the backend applications BTP multitenant applications are based on the Destination service. Each specific consumer tenant configures its own backend application as a Destination and the multi-tenant application will connect to the corresponding SAP Cloud for Real State tenant. If no specific configuration is available in a consumer subaccount, the provider subaccount destinations configuration is considered, it can be useful for systems shared by all tenants.
In our application, we consume a C4RE destination. If the consumer sub-account doesn’t define the C4RE destination, the one defined in the provider subaccount will be used while if we do define a specific C4RE destination in the consumer subaccount, the specific destination is used.
The package.json defines C4RE as a required destination. Then in the handler initialization we connect to the C4RE destination that will depend on each specific tenant destination configuration. Every time we need to access the C4RE APIs for retrieving the list of spaces or workplaces, we use the stablished C4RE destination connectivity.
We have seen our application is consuming C4RE oData APIs for getting the available spaces and workplaces. You can get more details about the available APIs and their properties in the API Business Accelerator Hub by selecting SAP Cloud for Real State product.
Portal Service
As our solution is composed of 2 applications: one for the facilities manager and a second one for the employee, we have created a portal that will present a tile for each one of the roles that will access the solution. The portal address is having cf.portal as the main path with the specific consumer subdomain in the main URL, and each one of the tiles will be a different group pointing to a different visualization ide that for the Bookings correspond to “workplace-display”:
To implement our portal:
- We have configured the SAP Cloud Portal Service multi-tenant service. The welcome file of our AppRouter will define the main path as cf.portal.
- Our portal microservice will define the 2 tiles as groups pointing to different appIds like for example “wpmadm” and “wpmapp” that we will find in the corresponding manifest.json of the app.
- Then for each group the visualization Ids (“workspace-display” and “workplace-display”) will link to the corresponding webapp Semantic Object and action defined in the corresponding app manifest.json file.
We could have manually created a Fiori Launpad sandbox inside our application and implement the tiles inside that launchpad but using the Portal Service Facilitates the implementation.
SAP Build WorkZone is also a good option as enables you to easily build business sites that provide centralized access to business application information on any device. You can then create the required access directly in the customer tenant.
Security
We saw previously that each consumer accesses the SaaS application through a specific URL. The application router, part of our deployed SaaS application, handles the requests of all consumers to the application and determines the tenant-specific subdomain out of the URL taking advantage of the multi-tenant xsuaa service (SAP Authorization and Trust Management Service). The xsuaa service gets the consumer-specific identity provider (IdP) based on the tenant-specific subdomain, delegates the authentication to the configured IdP, and creates a JSON Web Token (JWT) that contains the tenant, the current user, and the authorization scopes of the user. The JWT is then sent back to the application router, and from there to the application that can then proceed with the provided authentication/authorization JWT token.
In our prototype we have used the SAP ID Service to authenticate the users of our application, therefore the user’s creation and roles administration shown in the following screens will show BTP cockpit screens. We could have configured as well a Corporate Identity Provider the SAP Cloud Identity Services Identity Authentication and manage the users and roles assignment from IAS.
After each a consumer subscribes to our application, the Administrator assigns the required roles to the different users of the application. In the next figure, we can see for example that the user “maria.trinidad...@sap.com” for example has the Employee role collection for our WorkplaceManagement App, and only have access to the Booking application. While another user, like Alessandro, might have the Facilities Manager role collection and have access to the Facilities Management App. Any other user without any of the Workplace Management role collection, will not have authorization to open any of the Workplace Management apps.
If we have a look to the implementation:
- The set of role collections is defined in our application xs-security.json file. We can see for example that the Facilities Manager role collection englobes the Employee and FacilitiesManager role templates:
- Each role template is linked to its corresponding scope-reference.
- The scope-references being defined as well in the xs-security.json.
- The scopes are associated to each one of the routes configured approuter xs-app.json.
We have implemented as well in our application a “Data Access Level security”. You can see in the screen capture that I can change the From and To dates for my booking ”maria.trinidad…@sap.com” and even Delete it, but I cannot change it for bookings of another user:
As we see in the code sniped shared in the next figure, we only allow updates if the current user is the same one than the user that did the previous CRUD operation:
Useful References
Here are some links to additional resources that can get you up to speed in the presented components and technologies:
SaaS – Multi-tenancy
Cloud Portal Service
Security
Wrap up
And that’s it for this industry use case, we hope you have enjoyed the reading.
This is the third session of a series.
Check the full calendar, register to the upcoming sessions and review the already recorded sessions here!
- SAP Managed Tags:
4 Comments
