Manage modeling content

Objective

After completing this lesson, you will be able to manage modeling content.

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're 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 File→Download 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 File→Download.
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 (from the Welcome page) or Import Project(from the File menu). .zip and .tar archives will be extracted.
Caution
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 multiroot 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 doesn't 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>) can't 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's 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've selected for the deploy operation.
During a deploy operation, the checks apply to all the runtime objects that are already built, and also all of the objects included in the deploy scope (that is, in case of a partial deploy, the design-time files you've selected).
A design-time file that has never been built and isn't 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 isn't the case if you copy/paste a file to a different folder where there isn't a file with the same name.

However, in any case, the content of the design-time file isn't 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.

Note

If you copy a design-time file that was already opened in a code or graphical editor, keep in mind that copy/pasting doesn't 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 File→Auto Save feature isn't 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're 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's recommended to also change its ID in the code by opening the ID of the runtime object.
This isn't 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's 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 subfolders that contains the renamed file.

Caution

If you rename a source file but choose not to rename the runtime view (which is bad practice), when you build this individual source file you'll have a build error. This is because the builder considers the renamed source file as a new design item and so doesn't delete the original runtime. This means that the new source file tries to deploy a runtime view using an already used name, and this is the error (deployment can't create a duplicate runtime object name). To overcome this issue, you must build at the folder level so that the original runtime view is first deleted and then a new runtime 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 deleted by the HDI deployer when you deploy the entire HDB module, or any of the subfolders 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's 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 that this parent folder issrc folder and it contains one (or several) models that you know can't 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.

Caution

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 Edit→Find (Ctrl+F) or Edit→Replace (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 SAP Business Application Studio it's possible to rename one or several columns of a Calculation View from the Semantics node.

Renaming a Column in an Intermediate Node

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

Note

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, and not the source columns. Before you can do this, a column must first exist in the output in the Mapping tab. 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 wasn't 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, and so on, 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 Name and Label. You can also use the Rename and Adjust References tool in the Columns tab of the Semantics.

For a Calculation Views that is consumed by another Calculation View, a change in column name could 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.

From SAP HANA Cloud QRC 3/2023 onwards, it is possible to use the option Propagate Recursively in Consuming Views of the Rename and Adjust References tool, for a single column at a time. This column name is then renamed recursively, up to the last calculation view of any calculation view stack.

Caution

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_DESCRIPTION table.

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

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

Deprecate Calculation Views

You can deprecate a calculation view when it should not be used any longer. This is done in the Semantics, in the View Properties→General tab.

Two different settings are available, depending on whether you want to keep the deprecated calculation view available for queries or not:

Deprecated and Queries Permitted
The view is deprecated but queries can still be executed on the view. In the calculation view editor, a warning icon and a tooltip informs the user if a calculation view node references deprecated calculation views.
Deprecated and Queries Blocked (new in SAP HANA Cloud QRC 1/2024)
In addition to the information provided in the calculation view editor, queries on the view are also blocked and a customizable message can be defined to notify the end users, together with the default error Instantiation of calculation model failed;Model '<calculation_view_name>'.

To mark a calculation view as deprecated:

Open the calculation view in the graphical view editor
In the Semantics, choose View Properties→General.
In the Deprecation Option dropdown list, select one of the possible options.
(Optional) If you chose the Deprecated and Queries Blocked option, define a customized message in the Deprecation Note field. For example: Use Calculation View <new_calculation_view_name> instead.

Continue to quiz