Project Structure

Within a project there are modules. There are different types of modules. For example, there is 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 needs one. You should provide a meaningful 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.

Within a module, we have folders. Folders are used to sub-divide 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 is 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 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 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).

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

Caution

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.

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

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 is no specific rule or recommendation for the design-time file name.