Project Structure

Within a project there are modules. There are different types of modules. For example, there's a module for Java, a module for HTML, and a module for database objects.

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 even of the same type. Typically, for a database module, you probably only need one. You should provide a meaningful name for the module so that it's easy to identify the module type and what it contains. Don't create empty modules that you won't use.

Within a module, we have folders. Folders are used to subdivide your source files into meaningful groups. For example, you may choose to create two folders: one for tables and one for calculation views.

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's stored in another location, such as a classical database schema. Let’s consider the two following examples to illustrate these approaches:

The object identifiers (including the namespace) are always specified in the design-time objects. That is, the design-time objects must define 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 Business Application Studio 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.

• An 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 folders.

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 namespaces.

Note

It's recommended to make such a change at the beginning of the project to avoid breaking dependencies. Similarly, you must decide early on whether a single namespace should be used for all your modeling artifacts' runtime objects, or if you want to use several ones.

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

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

As a consequence, your runtime modeling objects can be referencing several namespaces. For example, in your HDB module, you could decide the following convention:

• Tables are prefixed with db.data.table, and
• Calculation are be prefixed with db.models.dim and db.models.cube.

Caution

When you modify the specifications of the .hdinamespace file (or create a new .hdinamespace file in a folder), this change has an immediate effect on the identifiers assigned to your design-time objects.

However, when it comes to deploying these objects, the new namespace rules are considered only after the .hdinamespace file has been deployed. Before the deployment of the new .hdinamespace file, deploying these objects, for example, a calculation view with the new namespace specification, will fail because, on the HDI container's side, the former rules are still used to validate the runtime object identifier.

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.

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.

(*) 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.

Note

In this table, we aren't 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.

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.

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