Working with Modeling Content in a Project

After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Analyze and document calculation views
  • Explain the structure of a project
  • Build modeling content
  • Manage modeling content

Auditing Dependencies Between Calculation Views

Two features are available in the Business Application Studio to analyze modeling content within a project. These are:

  • Data lineage

  • Impact analysis

They work in a symmetrical way. For any calculation view you choose, you can show the dependencies with other modeling content.

To use these features, right-click a calculation view file in the Explorer view and choose Show Data Lineage or Open Impact Analysis.

Data Lineage

Data lineage shows all the calculation views and source tables on which a given calculation view depends.

Impact Analysis

The purpose of impact analysis is to show all the chain of calculation views that depend on a given calculation view.

In the Data Lineage or Impact Analysis view, you can directly open a calculation view from the dependency tree by double-clicking it.

Tracing the Origin of a Column in a Calculation View Scenario

Another powerful auditing feature is available within a calculation view to show the origin of a column.

From the Semantics node, you can choose a column and trace its origin with Column Lineage.

The column lineage shows, within the scenario of the opened calculation view, all the nodes where this column exists. At the bottom of the calculation view scenario, you find the origin of the column. Opening the Mapping tab of this node allows you to identify the source column name in the data source.

In a cube with star join calculation view, the Show Lineage feature only works for private columns, not shared columns from dimension calculation views.

Column Lineage

Column lineage is very useful when columns are renamed within the calculation scenario, or when you want to see quickly where a calculated or restricted column originates from.

It also helps you to avoid mixing up columns with the same name, but not necessarily the same data that are present in several nodes of a calculation view.

For example, the NODE_KEY column in an SAP ERP system is used in many tables to join the master data-defining attributes.

You might want to make sure that the NODE_KEY column in the output of a dimension calculation view originates from the correct table (for example, the table SNWD_BP containing business partners) and not from another table, also used in the calculation view, in which a NODE_KEY column is present but does not identify business partners (for example, the NODE_KEY in the table SNWD_AD containing Contact addresses).

The Show Lineage feature stays active until you exit the Show Column Lineagemode by choosing Exit.

The Outline View

Watch this video to learn about the Outline View.

Make sure you do not mix up the Outline feature of the calculation view editor with the general Outline view of SAP Business Application Studio, which displays structured code into a hierarchy.

Workspace, Projects, and Modules

The workspace in SAP Business Application Studio is file structure where you can work on one or several projects. Each user has their own workspace, and can create additional ones if needed.

The workspace of a user can contain as many projects as needed, but each project must have a different name. Practically, this is done by storing the content of different projects into different root folders. It is possible to open a single project/folder at a time, or to create a multi-root workspace.

When you create a new project, the creation wizard will ask you to choose a project template. SAP Business Application Studio comes with several templates and you choose the one most suitable for the type of application you want to create. Depending on the template you choose, you will be prompted for various settings which are then used to create the very basic project shell.

When creating applications in a Cloud Foundry environment, SAP Business Application Studio relies on a concept called Multi-Target Application (MTA). An MTA is comprised of multiple components (modules) created with different technologies and deployed to different targets, but with a single common lifecycle.

Here we focus exclusively on the HANA Database Module, which is the one that provides the capabilities for SAP HANA persistence, calculation view modeling, and so on. So, among the available project templates, the SAP HANA Database one includes an SAP HANA Database module. It is also possible and very easy to start from a basic MTA and add an SAP HANA DB Module later. Adding a DB module is also what you do when you need more than one in the same project.

Main Types of Modules

The source code for your application is stored inside various modules of your project.

The first step is to create a module of the type you require and then begin developing the source code in that module. You can create as many modules as you need for your project, for example, you may choose to create two database modules: one for tables and one for views, if that helps with better organization of source code. You should provide a helpful name for the module so that it is easy to identify the module type and what it contains. Do not create empty modules that you will not use.

Main Types of Modules

Module TypeKey Role in Application
SAP HANA Database (HDB) moduleDefinition of database objects that provide persistence layer, virtual data model, data access, data processing (functions, procedures)
Java moduleBusiness logic
Node.js moduleBusiness logic
Basic HTML5User interface (UI)
SAPUI5 moduleUI based on the SAPUI5 standard
SAP Fiori launchpad site moduleUI: SAP Fiori launchpad site with entry point (host) and site’s content and configuration
SAP Fiori master-detail moduleUI: Typical split-screen layout (one of SAP Fiori design patterns)

For graphical modeling, the focus is exclusively on the HDB module.

The other types of modules are introduced in another course, HC450 – Application Development for SAP HANA Cloud.

HANA Database Modules

A HANA Database module (HDB module) contains all the design-time files that define the database objects that must be deployed together with the application.

Main Database Artifacts Defined in a HDB Module

  • Tables

  • Table data

  • Calculation views

  • Table functions

  • Procedures

  • Analytic privileges

  • Synonyms

A project can contain several HDB modules.

Persistence Layer: Inside the HDB Module or Outside?

Depending on the type of application, the main data managed by the application can be stored in different places.

A major design option for an application is to decide whether this data is stored in a persistence layer defined by the application itself, or if it is stored in another location, such as a classical database schema. Let’s consider the two following examples to illustrate these approaches:

Internal or External Persistence Layer

Objects Identifier and Namespace

In the SAP HANA database, each runtime object has an object identifier, which is used to reference this object within the container/schema. To provide a simple example, if the calculation view CV1 references the calculation view CV2, the execution of CV1 will trigger a "call" to view CV2 by using its object identifier.

A typical structure of a runtime object identifier is as follows:

Code snippet
<Namespace>::<Runtime Object Name>
Copy code
  • The Runtime Object Name is mandatory.

  • The Namespace is an optional part of the object identifier, and is mainly used to organize logically the runtime objects within the container.

When you work with objects in an HDB module, the naming of runtime objects is distinct from the way design-time files are organized. The main advantage of this approach is that you can more easily relocate design-time objects from one folder to another without impacting the corresponding runtime object name.

In this course, the namespace option we have chosen for the main application is to have a namespace prefix HC, applied uniformly to all objects, regardless of the folder location of design-time objects. In other words, the namespace is the same for all the runtime objects defined in our HDB module. So, these objects all have the identifier pattern HC::<Runtime Object Name>.

Runtime Objects Identifiers

The object identifiers (including the namespace) are always specified in the design-time objects. That is, the design-time objects must define without ambiguity how the runtime objects will be identified.

Let’s take an example of a modeling object, a calculation view CVC_SalesOrders, with its design-time version in the SAP Web IDE workspace, and its runtime version (created during deployment) in the container schema.

The figure, runtime Objects Identifiers, explains how folders are used to organize the design-time files in the HDB module of your application, and shows what the runtime object identifier could be. In this scenario, the calculation view identifier has a namespace. Let’s now discuss the main rules and possible options to define the namespace.


The following rules apply to the namespace:

  • The namespace is optional. Some objects can be defined with a namespace in their identifier, and others without.

  • A HDB module can have no namespace defined at all, or can specify any number of different namespaces.

  • The namespace is always identical for all the design-time objects stored in the same folder.

  • The namespace must always be explicitly mentioned inside the design-time files, and must correspond to the namespace defined explicitly in the containing folder, or implicitly cascaded from the parent folder(s).

The .hdinamespace File

The definition of a namespace is possible in the src folder of an HDB module, and also in any of its subfolders. This is done with a file called .hdinamespace.

When you create an HDB module, a .hdinamespace file is created automatically in the folder <hdbmodulename>src and contains a default value "<application_name>.<HDB_module_name>". You can modify this file to apply different rules than the default to your project’s namespace(s).

Elements of .hdinamespace File

The content of any .hdinamespace file is always comprised of two elements, name and subfolder.

ElementPossible valuesDefault Value
  • "<Any syntactically correct namespace of your choice>"

  • "" [no namespace specified]

  • "append"

  • "ignore"

  • "append"

To structure your runtime modeling content in a way that suits your needs, you can add a .hdinamespace file to any sub-folder of the src folder. The "subfolder" setting determines whether the sub-folder names should be added "implicitly" to the namespace for objects located in sub-folders (append) or not (ignore).


When you modify the specifications of the .hdinamespace file (or create a new .hdinamespace file in a folder), the new namespace rules are taken into consideration only after the .hdinamespace file has been deployed.

As a general recommendation, the namespace rules should be defined before you create modeling content. Indeed, if you modify these rules after creating modeling content, you have to adjust the object identifiers (which includes the namespace) before you can deploy your models. And this is even more complicated if dependencies exist between models.

Object Name

The way to define a runtime object name in design-time files is governed by one of the two following rules, depending on the object type.

Defining the runtime object names

Type of modeling objectNumber of objects per design-time filesNaming rule
Calculation views, table functions, procedures, analytic privilegesEach design-time file defines only one runtime object (*)The runtime object name is defined inside the object content and should match the design-time file name (without file extension).
Synonyms, table data import definition, rolesEach design-time file can define one or several runtime object(s)The runtime object name is defined only in the object content and is not linked to the design-time file name.

(*) Here, we mean, only one "core" runtime object. As you might have observed, even a simple calculation view generates a core column view, plus other "child" column views for the attributes, hierarchies, and so on.

In this table, we are not covering the entire typology of models, but only the main ones that are discussed in this course.

Let’s take two examples, one for each of the two approaches.

Object Name Example: Calculation View

Technically, the design-time file name for a calculation view can be different from the runtime object name.

However, we recommend that you always keep these names in sync to make it easier to find a design-time object based on the runtime object name.

Object Name Example: Synonyms

This second configuration example shows that a design-time file for synonyms can define several synonyms. In that case, there is no specific rule or recommendation for the design-time file name.

The SAP HANA Deployment Infrastructure

The SAP HANA Deployment Infrastructure (HDI) is a set of services that allows the independent deployment of database objects. It relies on HDI containers.

HDI containers are like a database schema but they come together with a dedicated owner and metadata to manage their contained database objects.

These objects are described in the HDB modules of multi-target applications, in design-time artifacts that are deployed by the HDI Deployer application; this Node.js application is materialized in the <project>/db/node_modules/@sap/hdi-deploy folder, among other Node.js dependencies.

HDI takes care of dependency management and determines the order of activation; it also provides support for upgrading existing runtime artifacts when their corresponding design-time artifacts are modified.

One key concept of HDI containers is the fact that the entire lifecycle (creation, modification, and deletion) of database objects is performed exclusively by the HDI. Therefore, you cannot create database artifacts, such as tables or views, with Data Definition Language (DDL) statements in SQL.

Indeed, if you create a table in a container schema with a plain SQL statement, this means there is no design-time object for this table. So, upon deployment of the container, this table will not be recreated. Similarly, deleting a database object from your container with SQL will not remove its design-time counterpart, so the object will be recreated upon build and/or deployment.

Data Sources for Calculation Views

When you design calculation views, the data sources must exist as design-time files in the container of your HDB module. So they must be of one of the following types:

  • "Real" database objects (table, view, table function, virtual tables, and so on) existing inside the container and having a corresponding design-time file in the HDB module
  • Synonyms referencing database objects located in any other schema than the container itself. You will learn about synonyms later on.
A Calculation View using as a data source a table that was created by plain SQL in your container (so, without a design-time file) cannot be built. The build fails and issues an error message, such as:
Code snippet
The file requires "db://HA300::TABLE_SQL" which is not provided by any file
Copy code

Key Properties of HDI Containers

  • A container generates a database schema.

  • Database objects are deployed into the schema.

  • Source file definitions must be written in a schema-free way.

  • Direct references to external schema objects are not allowed.

HDI Container Configuration File

Within each HDB module of a project you will find a very important and mandatory file that exists under the src folder with the suffix: .hdiconfig. This is the HDI container configuration file that is used to bind the design-time files of your project to the corresponding installed build plug-in.

Without the build plug-in it is not possible to build the run-time objects from the design-time files. This configuration file directs each source file in your project to the correct build plug-in.

Usually there is only one .hdiconfig file in a HDB module, and this must be located in the src folder of the HDB module. This file contains a list of all bindings for all source file types.

The minimum_feature_version entry of this file is there to prevent building your HDB module objects with a version of HANA Cloud that is lower than what is specified and/or what your code requires. For example, if you have designed and tested your HDB module with version 1004 of the build plug-ins, this will not deploy on an SAP HANA Cloud instance where version 1002 is in place.

Inside the container configuration file you will find, for each source file type, two entries:

  • suffix name, for example, "hdbcalculationview"

  • plug-in name, for example, ""

It’s very important to remember that when you import a project into your landscape, it brings with it its own .hdiconfig file that refers to the feature version that was used when it was first developed. If you then plan to update the source file using newer features of SAP HANA (for example, you want to add a new feature to a calculation view that just became available with the newer version of SAP HANA) you will not see the new feature in the source editor if the .hdiconfig file has not been adjusted to use the later feature version.

The HDI container configuration file is an unnamed file and must only consist of the suffix .hdiconfig. If you try to add a name, the build of the .hdiconfig file will fail. Leave it as it is.


In SAP Business Application Studio, when a project includes an SAP HANA DB module, a dedicated view SAP HANA PROJECTS in available (alongside the Explorer view.

The SAP HANA Projects view/panel is the materialization of the HDB module(s) defined in your projects. The upper part represents the folder structure of the HDB module. The root element corresponds to the path to the HDB module in the project. To create the runtime objects inside the connected HDI container schema, you can execute a deployment. This deployment can be triggered at different levels: a single file, a folder, or the entire HDB module.

You cannot manipulate (move, copy, delete, etc) your design-time files from the SAP HANA PROJECTS view, but you can open them in their respective editor.

In the file structure, the mention Pending Deployment identifies where a deployment is required for new or modified files. For deleted design-time files, you need to "activate" the deletion by deploying the folder that contained them.

The lower part represents the Database Connections between the HDB module and the HDI containers or services providing access to external resources.

A project with an SAP HANA Database module needs at least a corresponding HDI Container to deploy its runtime objects. This is what is shown in the image, The SAP HANA PROJECTS View.

In the connection part, you can bind an existing HDB module to a new or existing HDI container. You can also add new connections (for example to another container), and

The Database Explorer

From SAP Business Application Studio, you can launch the Database Explorer application to view the database artifacts (tables, views, procedures, column views) of one or several containers.

When you do this, even if you are logged on to the SAP Web IDE with your usual SAP Web IDE user, access to the container is done by a technical SBSS (Service Broker Security Support) user that is created transparently when you add the container to the Database Explorer. This technical user interacts with the database objects on your behalf, for example, to view the content of a table or preview the data of a calculation view.

If your container consumes data from an external schema, the technical user must also be granted authorizations to the external schema objects, for example, to view the data of an external table referenced by a synonym. You will learn more about this in the unit, Security in SAP HANA Modeling.


The Database Explorer also allows you to connect to classic database schemas, not managed by the HANA Deployment Infrastructure, to show the database objects and the content of tables, execute queries in a SQL console, and so on.

Deploying Modeling Objects

During development, you need to create or update the runtime objects from the design-time objects inside the container schema. For that, you use the Deploy function available in the SAP HANA PROJECTS view.

Deploying relies on the HDI container service (a Cloud Foundry service) which manages the interaction between SAP Business Application Studio, the HANA Deployment Infrastructure, and in turn the SAP HANA database.

The first time you deploy an HDB module (or part of it, for example design-time tables defining the persistence), the HDI service also creates the corresponding container schema.

Structure of Building Modeling Content

A deploy operation can be executed at the following levels of a project structure:

  • An entire HDB module

  • A sub-folder of the HDB module

  • One or several individual objects


The deploy operation describe above should not be confused with what is also called Deployin Cloud Foundry. In Cloud Foundry, the deploy command (cf deploy) applies to an entire application (for example an entire MTA, including potentially more than just the HDB module). It is used mainly when you want to transport and deploy/activate your project to another environment. For example from the DEV to the QA or PROD environment.

Regardless of what you deploy (HDB module, sub-folder, or single object), there is always an end-to-end dependency check applied to each object that is part of the build scope. So, even if you build a single object, there will be a recursive check of all the objects it references to make sure these objects already exist as runtime objects or are defined in a design-time object and built at the same time.

Deploy Errors

When you deploy models defined in a HDB module, you might come across different issues which are described in the log that you can consult in the console. Some are related to the dependency checks we have just discussed, others have to do with the consistency of design-time objects (for example, the namespace settings of design-time folders). Another classical build error is when two different design-time files provide a definition for the same runtime object.

Here is a list of frequent root causes for deploy errors.

Most Common Errors during Build Operations

  • The definition of an object on which another object depends is not provided, or it is provided but this object has not been deployed yet.

  • The definition of a runtime object is provided by several design-time files.

  • There is a namespace inconsistency between the content of a design-time file and the namespace property of the folder in which it is located.

  • The service to access external schemas is not defined or not available in the target space.

  • The synonyms for external schema access are not deployed yet.

  • There is an object-specific design error.

    For example, no measure is defined in a Cube calculation view.

  • There is an inconsistency between the object you build and a referenced object.

    For example, there is a mismatch in a column name between two objects with a dependency.

Putting a Design File Aside to Workaround Build Issues

When a Calculation View cannot be built for whatever reason, it generally prevents the build of its containing folder and any upper folder. There are several approaches you can use to solve this issue temporarily and go on working on the rest of your models, without losing completely the existing design-time file.

  • Export the Calculation View to a safe place, and then delete the Calculation View from your workspace.

    When executing the build, the removed Calculation View won't cause any issue. When you want to resume working on this view, you just need to import it back to its original location.

  • Add .txt to the design-time file. For example, SALES.hdbcalculationview will become SALES.hdbcalculationview.txt

    In this scenario, you do not remove the file from the workspace, but modify its extension so that it is (temporarily) not considered as a Calculation View design-time file but a plain text file. No specific check is performed on a .txt file upon build, so it will have the same effect as removing the file, but it is then much easier to undo: you just need to remove the additional .txt extension.

Import and Export of Modeling Content

SAP Business Application Studio offers import and export features within the development space

These features can be used to keep several versions of your modeling content, and re-import all or part of this content if needed. They are also useful for quick sandboxing, moving content from one development space to another.

Additionally, import/export can be used to share in a simple way your modeling content with another developer. For example, when a series of synonyms to external database objects have been defined in your project, you can easily share the synonyms definitions with another developer by sending the relevant design-time files for synonyms.

Correspondingly, you can import an individual file or an archive

Exporting Modeling Content

An export of modeling content can be executed at different levels of a project structure, and applied to either a single file or a folder. After selecting a file or folder, you use the FileDownload feature. You can also right-click the file or folder and choose Download in the context menu.

  • A single design-time file is exported/downloaded as is, with the source file name and extension.

  • A folder within the project structure (up to the project folder itself) is exported/downloaded as a .tar archive.

    To export an entire project opened as a workspace, you can right-click the blank area below the file structure and choose Download. You can also choose all the files and folders under the root of the project and choose FileDownload.

  • Several files and/or folders can be selected and exported/downloaded as a single .tar archive

Importing Modeling Content

Corresponding to the export, you can either import an individual file or a .zip or .tar archive. Three features are available for that:

  • Drag and drop from your file system into the Explorer view. Archives such as .zip and .tar files are not extracted. This can be done in command line in a Terminal window.
  • Upload Files (from the File menu) and Explorer view context menu. Archives are not extracted.
  • Import files (from the Welcome page). Archives will be extracted.
    If the content you import is an entire project, for example a proj1.tar archive, you need to open the projects folder first, so that the imported project becomes a child of that folder: projects/proj1

After importing a project, you need to open its root folder as a workspace, or to add to a multi-root workspace. Please refer to the lesson, Creating a Project in SAP Business Application Studio.

Copy, Rename, Move, and Delete Modeling Content

The structure of a project in SAP Business Application Studio looks like a classical file structure, but the changes you make to this structure by copying, renaming, moving, or deleting files (or folders) can have strong impact on the consistency of your project. This impact does not necessarily show up immediately during the file structure modification. It generally appears when you deploy the modeling content.

Whenever you copy, rename, move, or delete modeling content, you must keep in mind the key rules that govern the deployment of database artifacts:

Main Rules for a Consistent Management of Modeling Content Files

  • In an entire HDB module, the definition of a given runtime object (<namespace>::<object_name>) cannot be provided more than once.

  • The namespace defined in the design-time file of a database object must correspond to the namespace setting applied to the folder in which it is located

  • A deploy operation always checks the end-to-end dependency between modeling content across all the HDB module, but only deploys the design-time files you have selected for the deploy operation.

  • During a deploy operation, the checks apply to all the runtime objects that are already built, and also all the objects included in the deploy scope (that is, in case of a partial deploy, the design-time files you have selected).

    A design-time file that has never been built and is not part of the deploy operation is ignored.

Copying Modeling Content

When you copy/paste a design-time file within the same folder, you must provide a different name for the copy. This is not the case if you copy/paste a file to a different folder where there is not a file with the same name.

However, in any case, the content of the design-time file is not modified at all. Which means you have in your HDB module two design-time files with identical content.

At least, you must ensure that you rename all the runtime objects defined in the design-time file to make these objects unique in the whole HDB module. And, if needed, you must also change the namespace according to the target folder namespace settings.

If you copy a design-time file that was already opened in a code or graphical editor, keep in mind that copy/pasting does not open the new file (the copy). The file visible in the editor is still the original one, when - in many circumstances - you might want to actually modify the copy. This especially true if the FileAuto Save feature is not active.

Moving Modeling Content

When moving modeling content, one key rule that you must think about is the namespace setting of the target folder.

  • If the namespace settings for source and target folder are the same, moving the file has no particular impact on objects that reference the moved object.

    However, a deployment of the moved object can be successful only if the deploy scope includes the source folder, in order to execute/acknowledge the "deletion" of the moved file in its source folder. If not, the deployment will fail.

  • If the namespace settings for source and target folder are different, you must at least adapt the namespace. In this case, you must first perform an impact analysis to check whether some existing objects reference the one you are about to move.

Renaming Modeling Content

For the HDI deployer, renaming a design-time file is like deleting a design-time file and creating a new one with the same content. You must be aware of the following rules and recommendations:

  • A design-time file that creates only one "core" runtime object (for example, a calculation view or a table function) should always have the same name as the runtime object it defines. For example, after renaming the design-time of a calculation view, it is recommended to also change its ID in the code by opening the ID of the runtime object.

    This is not a technical requirement, but rather a best practice to keep your design-time content readable.

  • You must check if database objects reference the object you plan to rename. Generally speaking, renaming objects that have dependencies requires modification to the references to this object in other objects. Ideally, you should do this only on exception, because it is error-prone, or limit this practice to test objects, typically when you copy —and rename— an existing object in order to test changes you make to this object while keeping the source object.

  • You must be particularly careful with partial deployments. If you rename an object that was already built and had dependencies, the renamed file is seen by the HDI deployer as a new design-time. The original design-time file will be seen as deleted by the HDI deployer only when you deploy either the entire HDB module, or any of it sub-folders that contains the renamed file.

If you rename a source file but choose not to rename the run-time view (which is bad practice), when you build this individual source file you will have a build error. This is because the builder considers the renamed source file as a new design item and so does not delete the original run-time. This means the new source file tries to deploy a run-time view using an already used name, and this is the error. To overcome this issue, you must build at the folder level so that the original run-time view is first deleted and then a new run-time view (with the same name) can be deployed.

Deleting Modeling Content

Deleting modeling content can have surprising effects, especially in case of partial deployments. Indeed, the deleted design-time file is only seen as actually deleted by the HDI deployer when you deploy the entire HDB module, or any of the sub-folders that contained the deleted file.

In other words, the smallest deploy scope you can think of, in order to validate the deletion of a design-time file, is the folder in which the deleted file was located. So, even if it is empty, this folder is extremely precious.

Indeed, if you delete this folder as well, you can only validate the deletion of the design-time files it contained by deploying a parent folder. Suppose this parent folder is the src folder and it contains one (or several) models that you know cannot be built at the moment (for whatever reason).

Therefore, when deleting modeling content, you should apply the following best practices:

  • Before deleting a design-time file, always perform an impact analysis.

  • Before deleting a folder, always perform a partial deployment at this folder level. If the deployment is successful, it means that all the runtime objects that were defined in design-time files from this folder have actually been (successfully) deleted.

As already mentioned, you should NEVER delete a database object located in an HDI container with a plain SQL statement.

Using the Search/Replace Feature

SAP Business Application Studio offers several find/search and replace features that are useful to manage the renaming of objects and the code adjustments that must be performed manually.

  • Within the Code Editor, you can use EditFind (Ctrl+F) or EditReplace (Ctrl+H) to locate easily (and replace if needed) the ID of an object.

  • You can also use the Search view to look for a particular text string within the content of the design-time files. You can directly open a design-time time from the search results (not from the file name, but from one of the search hits within the file content).

    The Toggle search details button () allows you to define file/folder patterns to include and/or exclude.

  • From the Explorer view, you can also right-click a folder and choose Find in folder. This will invoke the same Search view, but this time the folder you choose is defined as the "root" for the search.
  • Another useful search feature is available for the file names inside the Explorer view. Just select an element (folder, file) in the workspace, or the blank area below, and start typing a string to search. A fuzzy search tool shows up, allowing you to highlight or filter matching file names.

Rename Columns

In the Business Application Studio it is possible to rename one or several columns of a Calculation View from the Semantics node.

Renaming a Column in an Intermediate Node

It is possible to rename a column in any node of the calculation scenario.


The case of the top node is specific and is discussed later on.

Inside a calculation view node, you can rename the output columns only, not the source columns. Before you can do this a column must first exist in the output in the Mapping tab before you can rename it. Then you have two main options to rename the column:

  • From the Mappings tab

    Select the column in the Output Columns area. Then, in the PROPERTIES area, modify the Name field.

  • From the Columns tab

    The Name column allows you to change the name of several columns at once.

Note that the impact of renaming a column on the upper nodes of the calculation view depends on the upper mapping status.

  • If the column was not yet mapped in upper nodes, the new column name will be used when adding it to the output of upper nodes, up to the top node.
  • If the column was already mapped in upper nodes, renaming the column applies only locally: at the next level, the column is mapped "back" to a column with the original name.

Renaming a Column at the Top Node Level

This case is different from the one above, because the column names in the output of the top node (similar to the ones shown in the Semantics) are used to consume the calculation view by front-end tool, SQL queries... but also by other calculation views.

Technically, columns of the top node can be renamed in the same way as discussed before: from the Mapping or Columns tabs. In addition, the Semantics allow you to maintain a number of column properties, including the Nameand Label.

However, for a Calculation Views that is consumed by another Calculation View, a change in column name is likely to prevent the build of the consuming calculation views. So the consuming views must first be modified so that they reference the actual column name of their data source.


Calculation Views exposed externally must be handled with special care in order to guarantee they can be used without disruption. This includes, among others, column names.

Generate Properties File for Calculation Views

For a calculation view, you can generate a properties file that contains the name and description of all calculation views objects such as columns, input parameters and variables.

You first generating the properties file for the calculation view and then you must build the SAP HANA Database Module that contains this generated file so that the names and description values are then stored in the BIMC_DESCRIPTION table

One of the key reason for doing this is to enable translation of the name and description values to multiple languages by updating the BIMC _DESRIPTION table.

Client tools can read the BIMC_DESCRIPTION table and displays values in the reporting tools respectively.

To generate the properties file, select a calculation view and choose the menu option ModelingGenerate Properties File.

Deprecate Calculation Views

You can deprecate calculation views to indicate that they should not be used in other calculation views.

This helps other data modelers using this calculation view know that the view is deprecated, or not recommended for use.

The effect of marking a calculation view as deprecated is that a warning is displayed in the menu bar of the graphical view editor for those calculation views that are either deprecated or those that consume deprecated calculation views.

To mark a calculation view as deprecated:

  1. Open the calculation view in the graphical view editor
  2. Select semantics node
  3. Choose View Properties tab
  4. Choose General
  5. Select Deprecate checkbox

Save progress to your learning plan by logging in or creating an account