Skip to Content
Technical Articles

FAQ Modeling HANA Calculation Views in Web IDE

This blog is intended to provide answers to frequently asked questions around modeling in Web IDE. For a general overview of the differences between modeling in Web IDE compared to HANA Studio have a look at this blog.

The following topics are covered below:

  • What is a project in Web IDE?
  • How do projects relate to containers?
  • Why do I not see the development objects of other developers in my Web IDE workspace?
  • Why do I not see the catalog objects in a tree structure while developing Calculation Views – as was the case in HANA Studio?
  • How should projects be structured?
  • Can I create my objects everywhere in my project structure?
  • How do I consume objects that are not included in my project?
  • Why do we need to define synonyms and services if we want to refer to objects outside of a project?
  • How can I flexibly point in different systems to different objects (e.g., after transporting), in other words: How can I abstract from the concrete schema / objects in different systems?
  • Is there a way to build a project while ignoring inconsistencies?
  • When I delete a Calculation View file the runtime object is still accessible with SQL. How do I remove also the runtime object?
  • Contrary to the typical development approach of using individual containers per developer, I want to allow different developers to deploy to the same container. How can this be achieved?
  • I have a view A that references another view B. Now I want to change the underlying view B in an incompatible way (e.g. remove a column). When I change the underlying view B and try to build it, the build fails because of the dependent view A. However, I can also not change the dependent view A and build it, because I can only import the active runtime of the underlying view B which is the old version. How do I successfully build these views?
  • In a nutshell: What authorizations do I need to start modelling?
  • The name of the technical and application users are different for different developers because Web IDE adds a counter for each developer (see “How do projects relate to containers?”). How can I assign the relevant privileges?
  • How do I assign analytic privileges to the user that runs a data preview in Web IDE?
  • How can I run a SELECT statement on views that are deployed in the new environment?
  • I would like to trace the execution of a Calculation View query, e.g. by adding “WITH PARAMETERS (‘PLACEHOLDER’ = (‘$$CE_SUPPORT$$’, ”))” to my query but my application user is not authorized. How can I assign these authorizations?
  • How do I manage my different versions of development artifacts?
  • How do I transport emergency fixes from my development system when there are objects contained in my project that are not yet ready to be transported?
    Are there any best practices for security?
  • What is a SPACE?
  • Due to individual security policies Web IDE is not connected to a productive system in your landscape. How can the productive system still be debugged?
  • I would like to assign a role collection, e.g., to allow developing in Web IDE by means of SQL. How can I achieve this?
  • What is needed so that SAP support can investigate an issue?
  • SPACE developers can see credentials used in services like e.g., user provided services in XSA Cockpit. Can I prevent this?
  • Where can I find some more demos illustrating the concepts?

 

What is a project in Web IDE?

From the perspective of a modeling user, a project is a folder structure that starts directly under root “Workspace” in Web IDE. A project typically contains all entities that should be deployed together. An example might be an application with all its views and procedures. Typically, you have one Git repository per project.

 

How do projects relate to containers?

When projects are built in Web IDE an HDI (HANA Deployment Infrastructure) container consisting of several technical schemas and users is created (more information can be found here). By default, your development objects are deployed to a schema that includes your user and project name. You can also use an option to specify the individual schema (details can be found here).

Per default, the schema names have to be unique. Therefore, Web IDE will automatically add a counter to the schema name, like “schemaName_1”.

Technical schemas are for example:

  • <schemaName> which contains your deployed objects
  • <schemaName>#OO of the object owner (comparable to user _SYS_REPO in the deprecated repository)
  • <schemaName>#DI that contains technical procedures for deployment
  • <schemaName><XXX>_RT of runtime users. Runtime users are executing e.g., the statements of a data preview
  • <schemaName><XXX>_DT of design-time admin users. Design-time users are used to perform administrative tasks on an HDI container (they have write and make authorizations on containers and are used during deployment)

 

Why do I not see the development objects of other developers in my Web IDE workspace?

Your user with which you log on to Web IDE is associated with a workspace that is separated from the workspace of other users. Therefore, you only see objects that you have created/imported.

The development concept has fundamentally changed in that the synchronization between different developers is done via Git. This means you make your development objects available to others via Git push and pull mechanisms. This provides you with high flexibility in situations in which different developers work on the same objects.

 

Why do I not see the catalog objects in a tree structure while developing Calculation Views – as was the case in HANA Studio?

The new development concept more clearly distinguishes between design time and runtime artifacts. While design time objects like Calculation Views are developed in Web IDE, runtime objects like tables are accessed in Database Explorer to which a direct link is available from Web IDE.

 

How should projects be structured?

The following provides some rules of thumb and needs adaptation to the specific requirements of your development setup and trade-offs might occur. For example, if no stable interface of an external object can be guaranteed it can be better to increase the scope of the project to include also this object in contrast to the suggestion to keep the project small

– a project should map to a logical unit, e.g., an application

– referenced development objects outside of your project should be stable in their interface (e.g., column names of a external view should not change)

– no cyclic references between projects are allowed. This means if project A references objects from project B, project B must not reference objects from project A.

– keep the project small. Given that building a project is an all or nothing approach in HDI, it is better to keep the projects small enough so that you can always achieve a fully consistent build of your project.

 

Can I create my objects everywhere in my project structure?

Building your objects will only work if they are below your db module. Typically your objects should be placed below folder “src”. There can be a special folder “cfg” below your db module for configuration files like .hdbsynonymconfig. As long as you don’t use schema.configure (see “How can I flexibly point in different systems to different objects …”) you don’t need the folder “cfg” and all your objects can be placed below “src” or in subfolders of “src”.

 

How do I consume objects that are not included in my project?

Given that every developer is typically deploying to an individual container it is important that consumption of other objects does not target these individual containers but a common container. One approach to achieve this is to use a separate Git branch for objects that are ready for consumption and use this Git branch to deploy these objects to a separate “reuse” container, for example, by setting up a CI/CD pipeline for that branch (more information).

The mechanisms by which you access external objects depends on whether the other object resides in a different SPACE (see also question “What is a SPACE”) or not.

 

Access between projects in the same SPACE:

you can either use

user provided services or

the hdi-service of the other container. If you use the hdi-service approach define a logical name for the service so that you preserve the association also after transporting the two projects. More details on service replacement in this context can be found here.

Access between projects in different SPACES:

The hdi-service option is not available but user provided services can be used

Access to objects in non-hdi schemas / remote databases:

user provided services can be used to access objects in non-hdi schemas.

Access to remote sources can be seen like access to non-hdi schemas, so the general steps of remote source access remain valid:

a) define a remote source

b) ensure that the connecting user has the authorizations on the remote source objects (if the remote source object is in a HDI container these authorizations can be assigned by creating and assigning a HDI role, or using the SQL API to grant the privileges to the respective connecting user)

c) ensure that the consuming user (e.g., the #OO user in case of Calculation Views) has the authorization to query the remote source.

With newer versions of Web IDE user provided services and hdi-services can be added using a graphical interface.

 

Why do we need to define synonyms and services if we want to refer to objects outside of a project?

Your projects should be logical units and therefore a kind of stable interface between the units should exist. To this end objects that are not inside your project can only be referenced via synonyms. Because of the use of synonyms, all you need to do if the environment of your project changes (e.g., after transporting to another system), is to ensure that your synonyms are pointing to the right objects. By help of the abstraction of synonyms you don’t have to re-check every used object in every development object individually. Similarly, to make sure that the relevant authorizations are available in your project also in other system contexts, you can make use of services that provide the necessary authorizations. This means you do not rely on the existence of a certain database user that grants the authorizations. Instead you reference a service that provides these granting abilities. Taken together services and synonyms provide your interface to objects that are outside of your container. For details look at e.g., this blog. See also “How do I consume objects that are not included in my project?” above.

 

How can I flexibly point in different systems to different objects (e.g., after transporting), in other words: How can I abstract from the concrete schema / objects in different systems?

Often, you want to point to different schemata after transporting a project to another system. With the new development approach you are very flexible in determining the target of synonyms. The topic is discussed in depth here: In a nutshell, you can define a .hdbsynonymconfig file that overwrites the “template” of the .hdbsynonym files at runtime. By transporting only .hdbsynonym but not .hdbsynonymconfig files and by adapting the .hdbsynonymconfig files in the individual systems, you can let the synonyms point to different targets in different systems. In addition, the target schema can be provided by a service (schema.configure option) instead of being coded in a file. If the target schema should be taken from the service mentioned in schema.configure, the configuration file needs to reside in folder “cfg”. Similar to ABAP, there is also an option to define a logical schema that is used to map in different systems to different schemata.

 

Is there a way to build a project while ignoring inconsistencies?

The new deployment mechanism of HDI does not allow deploying any objects when parts of the deployment fail. This means that HDI treats a build process as all or nothing to ensure overall consistency in the system. Therefore, inconsistent objects must be excluded from the build of a project. You can specify a black list of objects that should be ignored during building via the HDI Deployer’s –exclude-filter parameter. For example, to exclude all Calculation Views from building that are located in any subfolder of src, you would add the following parameter to your package.json file: –exclude-filter src/**/*.hdbcalculationview

The “**” is used when also nested subfolders should be affected

As an example, the package.json file would then look similar to:

{

“name”: “deploy”,

“dependencies”: {

“@sap/hdi-deploy”: “3.10.0”

},

“scripts”: {

“start”: “node node_modules/@sap/hdi-deploy/deploy.js –exclude-filter src/**/*.hdbcalculationview ”

}

}

Another option is to change the ending of an inconsistent file to “.txt”. This will exclude the respective file from the building process.

 

When I delete a Calculation View file the runtime object is still accessible with SQL. How do I remove also the runtime object?

You need to undeploy the respective file. Generally, this requires that either an undeploy whitelist is maintained or the –auto-undeploy parameter is set (see here for details). Web IDE will per default use the –auto-undeploy parameter. Thus, with Web IDE, you only have to successfully build the folder in which the Calculation View has been deleted to also remove the runtime object.

 

Contrary to the typical development approach of using individual containers per developer, I want to allow different developers to deploy to the same container. How can this be achieved?

How different developers can deploy to the same container is described here: Keep in mind that this can introduce difficult to debug deployment sequence effects if different developers deploy to the same container objects that depend on each other. Therefore, this option should rather be avoided.

 

I have a view A that references another view B. Now I want to change the underlying view B in an incompatible way (e.g. remove a column). When I change the underlying view B and try to build it, the build fails because of the dependent view A. However, I can also not change the dependent view A and build it, because I can only import the active runtime of the underlying view B which is the old version. How do I successfully build these views?

Given that only fully consistent builds are possible you need to temporarily exclude the dependent view A from the building process by adding the ending “.txt” to the dependent view A. After successfully building the underlying view B, the dependent view A can be renamed back and the changed runtime version of view B imported.

 

In a nutshell: What authorizations do I need to start modelling?

The object owner of your container needs the SELECT/EXECUTE privilege on the underlying objects  of your Calculation Views and be able to grant these privileges to others. In SQL terms this means the privileges need to be granted using “WITH GRANT OPTION”. This is similar to what user _SYS_REPO needed in the deprecated repository.

The application user needs simply SELECT authorizations on the objects that you would like to browse in dialogs like the data source browser. Also SELECT on the views for data previews is needed. Per default, SELECT on project objects is granted to the application user. See also next question for information how these privileges can be assigned.

 

The name of the technical and application users are different for different developers because Web IDE adds a counter for each developer (see “How do projects relate to containers?”). How can I assign the relevant privileges?

You can use .hdbgrants files for assigning authorizations to the object owner (referred to with the tag “object_owner”) and to the application users (referred to with the tag “application_user”). This way you abstract away the changing names. More details on .hdbgrants can be found, e.g., here and here.

 

How do I assign analytic privileges to the user that runs a data preview in Web IDE?

Similarly to the “default_access_role”, a “development_debug_role” can be used to add additional privileges to the application user. This is only intended for development and debugging, not for productive use!

If a role definition file exists at the path “src/defaults/development_debug_role.hdbrole”, and this file defines a role named “development_debug_role”, and this file is explicitly included in the deployment via the –deploy option, then the HDI Deployer grants the deployed “development_debug_role” role to the service instance’s global “access_role”.

You can add the –deploy option to the package.json file. The file could then look like:

 

{

“name”: “deploy”,

“dependencies”: {

“@sap/hdi-deploy”: “3.10.0”

},

“scripts”: {

“start”: “node node_modules/@sap/hdi-deploy/deploy.js –deploy src/defaults/development_debug_role.hdbrole”

}

}

In order to remove the privileges granted this way, the file has to be undeployed (https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/2.0.04/en-US/9235c9dd8dbf410f915ffe305296a032.html)

 

How can I run a SELECT statement on views that are deployed in the new environment?

With the old repository Calculation Views are built into schema “_SYS_BIC”. With the new Web IDE development environment the runtime objects of the views are residing in the schema that is defined by your “.yaml” file (see “How do projects relate to containers?”). Thus, in your SQL query, you need to replace schema “_SYS_BIC” with the respective schema.

In addition, you need to grant the authorization to SELECT on the Calculation View. To this end you can define in your project a .hdbrole that grants this SELECT privilege. Here is an example role “selectRole” that would provide SELECT on the objects in the container schema

{
“role”: {
“name”: “selectRole”,
“schema_privileges”: [{
“privileges”: [
“SELECT”
]
}]
}
}

(for more details see examples/syntax). Assignment of this role can be done with a user with authorization ROLE ADMIN, for example.

Similarly, you can assign relevant analytic privileges using .hdbroles.

Another way to grant SELECT access to all objects that are defined in your project is to grant the automatically created role with the name <schemaName>::access_role. This role will per default contain SELECT privileges for all objects that are defined in your project.

 

I would like to trace the execution of a Calculation View query, e.g. by adding “WITH PARAMETERS (‘PLACEHOLDER’ = (‘$$CE_SUPPORT$$’, ”))” to my query but my application user is not authorized. How can I assign these authorizations?

Your application user needs the system privilege TRACE ADMIN. You can assign this authorization via a .hdbgrants file (see also question “The name of the technical and application users are different for different developers because Web IDE adds a counter for each developer …”). You could use the following .hdbgrants file to assign the TRACE ADMIN authorization to your application user:

{

“UPS”:{

“object_owner”:{

“object_privileges” : [

]

},

“application_user”:{

“system_privileges” : [

“TRACE ADMIN”

]

}

}

}

 

This .hdbgrants file assumes that

a) a user provided service with name “UPS” exists

b) the database user behind the user provided service has the authorization to grant the system privilege TRACE ADMIN

 

How do I manage my different versions of development artifacts?

With Web IDE we provide a close integration to the very well established version control system Git. This means that you handle all your artifacts using Git. For an introduction to Git have a look here.

 

How do I transport emergency fixes from my development system when there are objects contained in my project that are not yet ready to be transported?

Building with HDI uses an all-or-nothing approach. This means that if you need to build an emergency fix, building of all objects needs to succeed. One option is to create a dedicated branch based on the current production code in Git, apply the fix, and transport the artifacts from this branch into the production system. Because of the HDI Delta Deployment only the modified files will be deployed per default.

 

Are there any best practices for security?

Have a look here .

 

What is a SPACE?

A SPACE is a concept to separate developers with different authorizations. In a nutshell, developers in the same SPACE have access to the same services and therefore have the same authorizations. Different SPACES are required if developers should have different authorizations. You can create a SPACE in your administrative environment, e.g., SAP Cloud Platform Cockpit or using the XSA or Cloud Foundry command line clients.

 

 

Due to individual security policies Web IDE is not connected to a productive system in your landscape. How can the productive system still be debugged?

For debugging purposes, it is possible to query also intermediate nodes of Calculation Views using SQL. Details can be found in SAP Note 2853770.

There are different reasons why Web IDE connections to a productive system are often not allowed. Here is a list of potential risks and which setups help to reduce which risk:

Web IDE users can…

a) modify productive content

b) modifying objects outside of the deployed content

c) run untested queries in a productive system

d) gain access to data that should not be visible

 

Generally speaking it is possible to prevent users from doing modifications to objects in the “productive” SPACE by only allowing them to work in another “non-productive” SPACE in the productive system. Due to the HDI-isolation concept it is possible to deploy the same object multiple times in one system. This gives the users the option to deploy the same content as in the “productive” SPACE to another SPACE and modify/test the content in the productive system using the productive data. However, isolating developers in a “non-productive” SPACE does not automatically exclude the other risks b) to d)

a) per default Web IDE would create a new container per user and thus not touch the HDI container into which the content is deployed. Developers might be able to circumvent this default setting if they are allowed to work in the same SPACE in which the “productive” content is deployed. Assigning developers only to other SPACES as SPACE developer would prevent modification to the content in the “productive” SPACE.

b) Even if the “productive” content is deployed into another SPACE similar authorizations to the authorizations in the “productive” SPACE are necessary so that the content can be used. For example, if a view is accessing an external object, these privileges for the external object also must be made available in the “non-productive” SPACE. Depending on the required privileges (e.g., DELETE on a table) this could allow modifications outside of the deployed content. Modifications to objects outside of the deployed content thus could only be prevented by not granting these modification privileges at all into the “non-productive” SPACE. Depending on the use case this might limit the usefulness of the “non-productive” SPACE.

c) users can build new views and run queries in the “non-productive” SPACE which can lead to untested resource consumption and potential crashes. To a certain extent, albeit not in all cases, this can be mitigated by creating and assigning workload classes. You can find more information about workload classes in SAP Note 2222250. For example, you could define a workload class for your application user that is doing the firefighting to restrict resource consumption of this user. In addition, auditing should be in place for users that have a Web IDE user in a productive system.

d) depending on the authorizations that are assigned to the “non-productive” SPACE data access might be possible outside of the standard authorization process for end users. This can only be prevented by not making the authorizations available in the “non-productive” SPACE which might counteract the purpose of investigating e.g., differences in results.

 

Given this situation the decision to connect a Web IDE to a productive system depends on the individual evaluation of the customer and might be acceptable in special situations like firefighter scenarios with a good governance and auditing in place.

 

 

 

I would like to assign a role collection, e.g., to allow developing in Web IDE by means of SQL. How can I achieve this?

see SAP Note 2859562.

 

 

What is needed so that SAP support can investigate an issue?

This depends on the specific issue and SAP support will guide you on what is needed (see also question “I would like to trace the execution of a Calculation View …”)

If the issue should be investigated in the customer system you will probably be asked to provide a

WTS connection

or a

http Connection

If you go for a http connection the ports of Web IDE and of the authentication service UAA need to be forwarded.
If relevant information should be exported, generally speaking there are two types of objects: design-time (e.g., Calculation View definition that you use in Web IDE) and catalog objects (e.g., table, or runtime view of a Calculation View).
Design-time objects:
– by right-clicking  in WebIDE on the Calculation View, the view can be opened in the code editor. This XML can be send directly.
– by right-clicking at the respective level in the folder structure (e.g., single View / folder) and choosing “Export” the zip-file including the design time information of the selected objects will be exported to the local machine and can subsequently be shared with SAP support.
Catalog objects:
– Navigate to your HDI container in Database Explorer, e.g., by right-clicking at folder “src” and choosing “Open HDI Container”. Search for the to be exported Calculation View  under “Column Views”, choose the one without the technical hierarchies (“/hier”), right-click and choose “Export Catalog Objects”
In the dialog select also the dependent objects. Depending on the sensitivity and size of the data also the data can be included. The export can be stored on the local machine and handed over to support.
– SAP Note 2756364 describes how a complete hdi-container can be exported

 

 

SPACE developers can see credentials used in services like e.g., user provided services in XSA Cockpit. Can I prevent this?

SAP Note 2757226 describes how to restrict individual clients so that this information is not exposed by the client.

 

 

Where can I find some more demos illustrating the concepts?

You can find some more details in this blog

Be the first to leave a comment
You must be Logged on to comment or reply to a post.