Take deep dive to learn how our act.in | migrate solutions can accelerate this journey
Migrating to a new database system can be overwhelming, especially when considering that there are many components to update and execute. If you are looking to make the move from SAP HANA to another technology or to simply extend your analytic components outside the SAP HANA Views area, then chances are you will need some help with the tables, graphical views and content.
Moving complex logic between databases often requires more time than desired, but what if you could have an automated solution? As part of our act.in | migrate solutions we have can provide the needed help! Our solution is designed to significantly reduce migration time by rapidly converting tables, as well as existing graphical views into standard SQL format, allowing them to work seamlessly on any compatible database system, along with associated content. Our step-by-step approach ensures a smooth transition while retaining all the complexity of your existing codebase. Below, we will focus on a major component of the solution – the SAP HANA Graphical Views convertor.
As SAP HANA calculation views have a graph structure, the main idea is to convert each individual node to SQL, standalone, and then put the results together.
We have identified multiple node types, each with a specific structure, and we managed to translate them to standard SQL.
We have identified the below main node types:
Projection
Join
Union
Aggregation
Rank
Expression conversion
Filters
Calculated columns
Restricted columns
Schemas
Input parameters
Semantics
For each type of node there are three steps:
Identify the node's internal representation in the XML, with all its elements
Store the entire information of the node in a custom data structure that allows processing
Generate SQL output based on the node's information
Example - Projection node
In order to better showcase the steps, let's consider the case of a Projection node.
1. XML parsing
The goal for this step is to determine all the elements of the node and their XML representation.
Some of the elements which form this node are:
The source of the projection (which can be a table, a view or another node)
The columns that are selected, along with their new aliases (if applicable)
New calculated columns
A projection node is identified in XML as:
A column of the projection is identified in XML as:
Similarly, all the elements are identified.
2. Store the node information
The goal for this step is to have the data in memory in a usable format. Since the calculation view is based on a graph structure, the custom format is also based on a graph structure.
In the case of a projection node, the following information is stored:
The identifier of the node (the technical name)
The input node (source of the projection)
The list of columns that is used, with their new names
The list of calculated columns, with their names
3. Convert the node to SQL
The goal for this step is to create a valid SQL syntax for this particular node only, with the assumption that the source is well defined. This assumption works because the source is also a node, so it should have itself a valid conversion. The only downside is the fact that the query is not fully optimized, but it will still save tremendous amount of work.
A projection corresponds to a SELECT statement, so an example of output would be the following:
Showcase
Consider the following calculation view:
INPUT:
OUTPUT:
Conclusión:
Although it is not possible to fully migrate all objects, great news is that automation has come to the rescue. With an impressive automation percentage, the duration of the overall process can be reduced by up to 70-80%. As a business or a technical professional, this incredible level of automation means fewer headaches, less downtime, and more efficiency.
Given our expertise in SAP HANA, which spans over a decade, we are delighted to offer assistance through our act.in | migrate solutions whether you are planning to move to Snowflake, Azure, or other solutions.