In this blog post I want to share some learnings from a customer project where we migrated a productive SAPUI5 application from the SAP Cloud Platform Neo platform to the newer SAP Business Technology Platform Cloud Foundry (SAP BTP CF).
Our learnings will hopefully help others to not step into the same pitfalls as we did :-).
Many thanks as well to
jan.schanzenbaecher who contributed to this blog post.
The undertaking
The goal of our project was to migrate not only data but the full custom-code solution (SAPUI5 applications) from the SAP Cloud Platform Neo running on SAP HANA 1.0 database to SAP BTP Cloud Foundry. The productive solution was already fully functioning for about 3 years and we had to build-up the SAP BTP CF applications next to the running productive version on SAP SCP.
The legacy architecture on SAP SCP Neo
- Backend implementation on the SAP HANA database comprised of the following features
- Odata v2 service
- Automatic role asssignment supported through custom-code in XSJS scripts (using anonymous connections)
- HANA Stored Procedures to support storage of data and enrichment of data coming from the frontend application written as well completely in HANA Stored Procedure Scripts
- HANA Calculation Views with authorization logic through custom tables (joining of information)
- No or only partial design-time components of the database and the roles
- Frontend implementation comprised of
- SAP Fiori Launchpad (former SAP SCP Neo Launchpad Service)
- various SAPUI5 applications including overview list and multiple input forms to deal with the data display and data input for different personas
- SAP SCP functionality contained
- multiple job instances to deal with
- purging of assigned temporary roles
- synchronization of data with the help of a JSON-based REST-service coming from a customer MySQL database, no SAP Cloud Platform Integration (SAP CPI) was used
- sending of Emails based on custom-logic depending on the state transitions of the implemented workflow (no SAP Workflow Service was used)
- Email Server configuration to use send the Emails via the customer SMTP server
- SAML 2.0 configuration for customer-specific IdP integration (identity provisioning)
- Artificial separation of DEV and PROD instance due to the fact that the customer did not have more than one SAP HANA instance
The estimation and its flaws
We wrongly estimated that the endeavor to migrate from SAP Cloud Platform to SAP BTP Cloud Foundry takes us about 15 days of effort due to the fact that (a) no additional features need to be included (no new TO-BE state of the application) and (b) everything is in place and already known (AS-IS state of the application).
This however turned out to be completely off the chart. Until we reached final Go-Live of the application on SAP BTP Cloud Foundry we accrued in total about 35 days of effort instead of the initially estimated 15 days. Thus, in the end we had more than 130% overtime.
We completely underestimated the architectural differences and its impact on the transitioning of the coding between SAP SCP Neo and SAP BTP Cloud Foundry.
The innovative new architecture on SAP BTP CF
The Cloud Foundry architecture that we reached contained in the end the following components:
- Backend implementation is comprised of
- Odata v4 service
- Design-time components for database (CDS script, HDB sequences)
- CDS Views (newest version, including newest approach of authorization) to replace previous HANA Calculation Views
- Instead of HANA Stored Procedures we had to use Node.JS Java Script services and include these via hooks at the beginning of the initial Node.JS script
- Previous jobs had to be integrated inside the Node.js scripts
- The email sending functionality had to be included as direct calls after some redesigned service calls. This was mostly reached by redesigning the functionality from lazy response to direct response.
- Data synchronization via the JSON-based REST-service had to be rewritten as Node.JS coding as well and called inside the included central server.js file as part of the bootstrap execution (using specific timing to mimic the previously scheduled jobs). The solution still synchronizes the data only once per day in the early morning hours.
- Frontend implementation is comprised of
- no SAP Fiori Launchpad anymore
- various applications as overview list and input forms to deal with the data display and data input for different personas – this was the sole part that did not change too much from SAP SCP to SAP BTP CF 😊
- SAP BTP functionality contained
- SAML 2.0 configuration for customer-specific IdP integration (identity provisioning)
- Separate spaces for Dev, Test, Prod to separate development, testing and productive execution of the solution
The learnings
- SAP SCP Neo vs. SAP BTP Cloud Foundry big differences
- One of the big differences is that on SAP BTP you cannot anymore implement coding close to the SAP HANA database, but you have to use design-time objects. This standardizes a lot but makes the transitioning from SAP SCP to SAP BTP to a re-implementation task instead of a mere migration task.
- The authorization concept changes completely from SAP SCP to SAP BTP. Whereas on SAP SCP there were different roles available for frontend and backend (both had separate role concepts that did not overlap and had to be kept in sync via scripts in the backend or coding in the frontend), SAP BTP now supports only one set of roles. On the database layer there is only a “technical” user access and there is no differentiation anymore on the database side. On the frontend side the role-approach was kept in shape and a custom backend service provided details of the business user’s roles.
- Nice and clean separation of system stages through the usage of spaces and SAP HDI containers. With the new concept of SAP HDI on the database, separation of stages can be easily implemented with an identical code line.
- Rewriting XSJS Coding to Node.JS Coding
- Be aware that these are two different worlds and even though Java Script is included in both acronyms it does not mean that you can copy/paste coding directly. Our initial thought was that "XS-JavaScript" and "Node-JavaScript" should be close, but in reality every single line of code had to be checked again and especially database calls had to be completely rewritten (which is mostly the tricky part).
- Using End-Points like Destinations
- The JSON REST-service could be included as destination. However, we did not succeed in setting up the backend Node.JS to work together with the destination. We hope newer versions provide better support for this.
- The SMTP email server configuration should as well be represented as a destination of type “MAIL”, however using the destination inside the backend Node.JS did not work for us and we hence had to deflect to Node.JS only sending. We hope that newer SAP BTP versions provide better documentation and examples for this.
- HANA Stored Procedure
- The HANA stored procedures cannot be reused in SAP BTP Cloud Foundry but they had to be rewritten inside Node.JS services. The trick here is to include this functionality as “service.before” or “service.on” coding inside a SAP BTP CAP service. This mimics the previous behavior of the HANA stored procedure coding before or after committing of data.
- HANA Jobs
- XSJS Jobs of SAP SCP cannot be moved to SAP BTP Cloud Foundry. Hence our approach was to rewrite the job functionality from a periodic execution to a direct execution after the state transition was executed. This was successfully reached by rewriting the XSJS coding to a Node.JS service which is triggered correspondingly by the service that includes the state transition logic. The replacement of the email sending from background job execution to in-time update on process step transition is a cleaner approach compared to the previous approach.
- The integration of email sending via the customer SMTP server turned out to be very difficult as online tutorials and references did not work in our project and we hence had to even include “pure” Node.JS email sending. This solution had to be taken because the SAP BTP destinations (which should work) were for our project not working in the intended way. Let’s hope that this gets easier and can be integrated without much pain in the future in SAP BTP.
- Document Service
- Replacing (former SAP SCP NEO) Document Service with fully working SAPUI5 Upload/Download Functionality and HANA BLOB Data Type.
- BLOB Data store is supported by SAP BTP CAP, integration with SAPUI5 needed some custom development as the standard components (we used the relatively new UploadSet) did not send the data in the expected format.
- Authentication Changes
- Previously, on SAP HANA as a Service, authentication was handled by the database directly. Custom IdPs were configured there, and shadow database users would be created automatically.
- This concept completely changed on SAP BTP. Business users are authenticated on the platform-level and database operations are done through service bindings and technical database users. We had to adapt our entire authentication concept to fit this new structure.
- Anonymous Login
- Functionality required an anonymous login via a one-time token. Previously, this was possible via a separate endpoint without authentication. Database operations were only carried out when a one-time token was present and valid.
- On SAP BTP, it is not easily possible to offer a database connection without authentication. As a workaround, a “dummy” IdP was created, which would, by default, just redirect the user back to the application, authenticating the browser as “anonymous”. A custom authentication handler in Node.JS did the rest by setting sessions accordingly and checking the one-time token for validity against the database.
- That way we achieved a login without credentials, so that both SAP BTP (requiring authentication) and the end user (not requiring authentication) were satisfied.
- Data Migration
- Data migration was done through a third-party tool DBeaver - see here. It offers connectivity to both SAP HANA 1.0 and SAP HANA Cloud and some great migration functions.
- The challenge was getting connected to the SAP HANA as a Service instance as it is not publicly available. For this, we used SAP HANA Studio to establish a connection tunnel via SAP SCP Neo. After establishing the connection in SAP HANA Studio, the database was available be connected in DBeaver via localhost. After getting around this struggle, the database migration went without issues as both source and target structures were identical.
I hope you'll have more success in your estimation and implementation in similar projects than we had. For us it was a very educational project where we touched many corners of the SAP BTP platform and could experience its maturity first-hand.
If you want ask a question about the same topic, please use the following
Q&A tag link. In the case you have other learnings to share let me know and post them in the comments. Thank you.
