In this blog post I would like to tell you about our way to the SAP Cloud Platform (SCP). By “our” I mean the Otto Group and its subsidiaries. You’ll learn something about our architecture and system design.
About Otto Group IT
The Otto Group IT is the IT service provider of the Otto Group. The Otto Group is a globally active group of retailers and retail-related service providers with around 52,560 employees. Through 30 major company groups it has a presence in more than 30 countries in Europe, North and South America, and Asia. The Otto Group is one of the world’s largest online retailers.
We operate several large SAP ERP and BW systems for the different business functions. Until the transition to the SAP Cloud Platform, the access of the users was mainly done with the SAP GUI and an SAP NetWeaver Portal. The SAP NetWeaver Portal was mainly used for Employee Self-Services (ESS) and Manager Self-Services (MSS). We had large load peaks at the end of the month when all users wanted to see their payroll. Access was only possible from the corporate network or with a VPN connection.
It wasn’t up to date anymore and we wanted to modernize it. We decided on using the SAP Cloud Platform because all requirements could be fulfilled with it. In particular:
- Dynamic scalability of resources
- Outsourced hardware and software maintenance
- VPN-less access
- Great integration with our other SAP products in our hybrid system landscape
The big picture
The end user has access to a Fiori Launchpad. We have set up our own domain and SSL host on the SCP Load Balancer. The user authenticates himself with his familiar Microsoft Office 365 login credentials and a second factor. Technically, we created a SAML trust between our Microsoft ADFS Identity Provider and the SAP Cloud Platform.
The Fiori Lauchpad gives the user access to various HTML5 applications. We offer some SAP standard applications and a lot of self-developed applications. With SAP Cloud Platform Identity Provisioning (IPS), we manage which app the user can see. For this purpose, we synchronize the e-mail addresses from SAP ERP user rolls to SCP authorization management groups.
The apps access the data via the SAP Cloud Platform OData Provisioning (GWaaS) service. The GWaaS establishes the connection via the SAP Cloud Connector to our on-premise SAP and non-SAP systems. Authentication against the SAP system is done with X.509 certificates respectively Principal Propagation.
We also use SAP Cloud Platform Integration (CPI), but that would go beyond the scope of this article.
From a developer’s Point of View
Everything is versioned with
git and stored in our GitLab account. As soon as a new version has been pushed, the Continuous Integration (CI) process starts. The new app is built and tested by a GitLab Runner. If everything is OK, the Continuous Delivery (CD) is triggered. The built app is then published to the SAP Cloud Platform as HTML5 app. We have a total of three SCP subaccounts for our 3-tier landscape. Similar to our SAP system landscape, one for development, one for quality assurance and one for production. Like the SAP Cloud Connector, the GitLab Runner is running inside our company network and has access to our SAP systems. The GitLab Runner can therefore also be used to deploy ABAPs to our SAP systems.
If you want to do it the same way, you can find our Docker Image here: https://github.com/Cyclenerd/scp-tools-gitlab
We use the different SAP Cloud Platform Services to provide a modern front-end to our users. The users are very satisfied. Especially the mobile access is very well accepted by the employees. The developers are also happy. They can use a modern toolset.
In the near future we want to launch SAP Analytics Cloud and integrate it into our Fiori Launchpad. We are currently also exploring ABAP on SAP Cloud Platform.