Getting Started with a Development Project

The workspace in the SAP Web IDE is where you can work on one or several projects. Each user of the SAP Web IDE for SAP HANA has their own workspace. The workspace of a user can contain as many projects as needed, but each project must have a different name.

A project contain one or more modules. The source code for your application is created in a module. There are different types of module, each handles a types of development artifact or language, such as SQL or Java.

To organize the source files in each module, we can optionally create folders. So you might create a folder called 'Tables' and another folder called 'Views'.

When you create a new project, the creation wizard will ask you to choose a project template. The Web IDE for SAP HANA 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 with default settings.

The first step is to create a module of the type you require and then perhaps some folders to organize the source files. You can create as many modules as you need for your project, but you usually only need to create one module for each type of development language. You should provide a helpful name for the module so that it is easy to identify the module type and what it contains. For example, you might name your database module that contains the SQL code as 'database', the module for Java code might be called 'application' and the module for the HTML and CSS files might be called 'front-end'.

In this course, we focus only on the database (HDB) module type. This is because in a custom data warehouse development, the database module is typically the only type of module you would need. This type module provides us with everything we need to build a custom SQL data warehouse including tables, procedure, functions, synonyms and all other database-related artifacts. The only reason to use other module types might be to develop tools such as schedulers and monitors using languages such as JavaScript and front ends using languages such as HTML and SAPUI5.

Hint

All types of modules are represented using the same folder icon in your project structure. This means it is not easy to spot the different module types at-a-glance. Every project contains a mta.yaml file at the root, and you can open this file to list all modules in your project. Each module will be identified with its name and module type. When you add or remove a new module to your project, the mta.yaml file is automatically adjusted.

Within the module you can create folders to organize the source files. A typical use of folders is to separate the type of files. For example, tables, functions, and procedures. you could also use folders to identify the role of the objects in the data warehouse layers. For example raw storage, cleansing stage, and data mart layers. That what we will do in this course.

In XS Advanced, each runtime object has an object identifier, which is used to reference this object within the container/schema.

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

<Namespace>::<Runtime Object Name>

• The Runtime Object Name is mandatory.

• The Namespace is an optional part of the object identifier, and is mainly used to organize the runtime objects within the container. Think of this as a tag that can help give meaning to the object.

When you work with XS Advanced projects, 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.

The object identifiers (including the namespace) are always specified in the design-time objects.

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 build) in the container schema.

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 using a namespace file in the containing folder, or implicitly cascaded from a namespace file from parent folder if no namespace file exists in the local folder.

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.

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

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 build your models. And this is even more complicated if dependencies exist between models.

As a developer, you may want to join an existing data warehouse development project. In this case you need to bring the entire project or a sub-section of the project into the workspace of your Web IDE so that you can begin working on it. You can do this either by cloning the project from a Git repository. Git is fully integrated into Web IDE with all the commands such as push, pull, create branch, commit. If you don't use Git then you can simply import the project from a local file server using the import feature of Web IDE.

SAP recommends using Git especially when working on collaborative projects to ensure each developer works with the latest versions of artifacts and to implement full version control including roll-back if needed. The basic import feature is still useful for simpler project with only one developer, where setting up a Git repository is not needed.

Once you have imported or cloned the project into your Web IDE workspace, you need to assign a space to the project. A space is created by the system administrator to provide dedicated run-time environments that have been allocated memory and other essential resources. You should ask your administrator which space to assign your project to. If you do not assign a space to your project you will not be able to generate the run-time objects from the source files - this is called a build.

If you are starting a new data warehouse development project then you will create a new project.

The first thing you will do is to choose a template for your project. A template speeds up the creation of a project by providing a basic project structure and many of the mandatory project files including the very important mta.yaml project descriptor file. The provided files also include many default values which can be changed later, for example the namespace file.

The next step is to create the folders and sub-folders to organize your objects.

Although not technically needed, it is good practice to build the empty project to generate the run-time container. This ensure that there are no problems found with the basic structure before you begin filling the project with database artifacts.

The next steps are to create the basic services that your database module requires, including defining access to external database schemas and synonyms, if you need to reach external database objects.

Hint

Get in the habit of building the run-time objects as-you-go, so it is easier to identify issues as they appear, instead of having to work through a list of issues. Often, fixing one issue will automatically resolve others. The build log will describe what is wrong, so you can fix issues before continuing.