Key Concepts Refresher
Many of the concepts in this chapter will help you deploy the solutions you build into a live environment for end users. As such, you will start working more closely with an SAP HANA system administrator at this point. Typically, export and import duties are performed mostly by the system administrator.
Some other concepts, like refactoring, are used in larger projects to ensure your modeling work stays fresh and useful. The idea is similar to gardening: You need to mow the lawn, pull weeds, and prune the roses to maintain a beautiful garden. This idea of upkeep can be applied to the administration of your data models.
Validating and Activating Information Models
Before end users can use your information models, you need to ensure that they are both valid and available to the users. In SAP HANA, validation rules are used to check for possible errors that may affect the usability of your models. Once you’ve worked out all the kinks, you’ll need to activate the models to make them available.
Validation Rules
SAP HANA has built-in validation rules for the different types of information models and modeling objects. These validation rules check for possible syntax errors and missing properties. When you request a validation run, SAP HANA applies the relevant validation rules to your information model.
Here are some example validation checks:
- That a language column is specified when you use a text join (without a specified language column, the text join will not have a 1:1 cardinality)
- That a dimension view has at least one attribute specified as the key attribute
- If filter values are valid
- That a calculation view does not have any floating (orphan) nodes
- That there there are no unjoined (orphan) tables in a view
- If attributes or measures are defined for large object data types (e.g.,
BLOBorCLOB)
You can access the validation rules (see Figure 11.1) in SAP HANA studio by selecting Preferences from the Window menu. Drill down the tree to SAP HANA · Modeler · Validation Rules.
Figure 11.1 Validation Rules in SAP HANA Studio
When your information model is ready, you can validate it by clicking the Save and Validate button on the toolbar, as shown in Figure 11.2. You can also Save the model and then use the model’s context menu to Validate it.
Figure 11.2 Validating an Information Model
If the system finds an error during validation, you will see a message in the Job Log tab in SAP HANA studio (Figure 11.3). Double-click the error message to open the dialog box shown in Figure 11.4. Read the message carefully to understand why SAP HANA does not accept the model as valid. (In this case, you did not specify one of the attributes as a key attribute. To fix this, you will specify one of your attributes as a key attribute in the semantic layer.)
Figure 11.3 Error Found When Validating an Information Model
Figure 11.4 Validation Error Dialog Box
[+] Tip
With complex data models, the problem often lies in the way you created the joins, so recheck your joins. Often, the easiest way to fix a problem with joins is to delete and recreate the joins.
Activation
The next step to get your information models ready for use is to activate them. When you click the Save and Activate button on the toolbar (Figure 11.5), SAP HANA creates an “active” copy of the information model. This active copy is then used by end users.
Figure 11.5 Activating an Information Model
[+] Tip
We recommend that you get into the habit of using the Save and Activate button. It saves the information model, checks it against the relevant validation rules, and creates an active version. You do not need to perform a Save and Validate action first.
We have seen modelers become confused when using the Activate menu option alone. They try to activate their model and get errors. After solving the errors, they try to activate again, but keep getting the same errors. This is because they forget to click the Save button before activating the model again. Therefore, SAP HANA activated the last saved copy on the server, which still has the same error. Only when they save their changes to the server will SAP HANA activate the latest version that includes the corrections.
By using the Save and Activate button as we recommend, you can avoid this kind of situation.
Let’s dive a little deeper into this activation process.
When you create and validate an information model, it is saved in the Content area of the Systems view. The objects stored here are called repository objects or design-time objects. These objects are merely definitions (metadata) for what SAP HANA should create when running the information models. They are seen as the “inactive” versions, and end users cannot run them.
When you activate an information model, SAP HANA first checks the model against the
validation rules. It then creates an “active copy” of the model in the _SYS_BIC schema. When you activate the calculation view CV_CALCVIEW_DEMO, you will find the “active copy” of that model in the Column Views folder of the _SYS_BIC schema, as shown in Figure 11.6.
This “active copy” is referred to as the runtime version of the object. End users can only run the active versions of objects. All runtime versions are stored in the Catalog area of the Systems view.
Figure 11.6 Active Copy of Information Models in _SYS_BIC Schema
If you edit and save (without activating) this information model, you will have two copies of the object on the server: An active runtime version, which users can still use, and a new inactive design-time version that you are busy modifying.
You can switch between the active and the inactive versions in the SAP HANA modeling tools via the dropdown menu (see Figure 11.7). If your new model won’t activate or contains any sort of similar error, you can compare the two versions to see what was changed and adjust accordingly.
Figure 11.7 Switching between Active and Inactive Information Model Versions
If you do not want to keep changes to the information model, choose the Revert to Active option (see Figure 11.7). SAP HANA then discards your changes and resets the design-time version back to the runtime version. You can only revert to a changed version you saved, but have not yet activated. Once you’ve activated the new version, you cannot revert to a previous version any longer.
If you are happy with your changes, you can activate the new version with the changes made. The existing runtime version is replaced by the newer version of the information model, provided your model passes the validation rules.
SAP HANA uses the _SYS_REPO user to execute activated models. To do this, the _SYS_REPO user must be able to read the tables in your schema. Otherwise, your information views cannot be activated. We discuss how to do this in Chapter 13.
Transporting Information Models
When working with SAP systems, you will have to deal with transports. SAP systems are used by many of the largest corporations in the world and for mission-critical systems. These corporations expect the SAP production (live) systems to be exceptionally stable and robust. If someone frequently makes changes directly to a running production system, the chance of making a mistake becomes quite large. For this reason, SAP established a standard way to deploy SAP systems and update them to increase stability.
In a standard SAP environment, you will find three systems instead of just a single production system, as shown in Figure 11.8:
- Development system
This is where all of your modeling and development work is done. Once the development work is finished, it is copied (“transported”) to the quality assurance system. - Quality assurance system
This is where all testing is done before moving to the production system. The quality assurance system is normally a recent copy of the production system. Any errors created in this system would also create errors in the production system. By catching them here, we can ensure an error-free production environment. When all errors have been fixed, the error-free development and modeling work is finally transported to the production system. This setup is important for ensuring stable business systems. - Production system
This is the area where companies’ business activities occur and where end users perform functions for their daily work.
Figure 11.8 Standard SAP System Landscape
You can copy all your SAP HANA packages, information models, and objects to quality assurance and production systems using transports. You can also use transports to update the sandbox (“playpen”) and training systems.
In SAP HANA, you can combine several packages with all their modeling objects into a single artifact called a delivery unit. A delivery unit therefore consists of one or more packages. Each package in a delivery unit can contain many information models.
[»] Note
You can only transport design-time objects with delivery units (i.e., those contained in the Repository or Content areas). You cannot transport runtime objects (e.g., tables with their content).
In the following subsections, we will discuss the different methods for importing and exporting information models in SAP HANA. We’ll begin with a general discussion on importing and exporting content, before diving into special topics including using the SAP HANA Application Lifecycle Manager, exporting extra data, importing objects via scheme mapping and mass copy, and comparing native vs. imported objects.
Importing and Exporting from the Development System to the Quality
Assurance and Production Systems
The first method that you can use to transport your SAP HANA modeling work is to export it from the development system and then import it into the quality assurance and production systems.
You can access the Import and Export options from either the Quick View menu in the Modeling perspective or from the File · Export and File · Import menu options.
Figure 11.9 shows the Export dialog screen.
Figure 11.9 Importing and Exporting Content from SAP HANA
Here, we opened the SAP HANA Content folder in the dialog box to export SAP HANA content. The following options are found in this folder:
- Change and Transport System (CTS)
This option is used by SAP HANA system administrators in cases in which a company has many other SAP business systems. They will use the Change and Transport System (CTS) of SAP Solution Manager to manage all of the company’s SAP transports. This provides control over large volumes of transports from all SAP development systems to their respective production systems. - Delivery Unit
You can use this option to export and import delivery units. - Developer Mode
You can manually transport a few selected or individual information models from one system to another by exporting them and importing them into the quality assurance or production system. You can also use this to mode make backups of your own information models. - SAP Support Mode
When you encounter problems with your SAP HANA system, you can log an SAP message with SAP Support. Sometimes, SAP Support will ask you to send some of your information models so that it can replicate the problem on its own servers. SAP Support will not use your system to try and solve the problem. You can export the relevant information models to SAP Support via this mode.
Figure 11.10 shows the options for exporting a delivery unit. Select the name of the delivery unit you want to export. You can also choose the time period of the latest changes to objects in the delivery unit. Optionally, you can choose whether the delivery unit should be exported to the server or to your client machine (e.g., your laptop).
Figure 11.10 Exporting a Delivery Unit
[+] Tip
You cannot export and import a package alone. You can transport packages contained in a delivery unit, or you can transport the objects contained inside a package using the developer mode. If you want to transport a single package, the easiest way is to create a new delivery unit containing just that one package.
Using the SAP HANA Application Lifecycle Manager
Another method you can use to transport your SAP HANA modeling work is to use the SAP HANA Application Lifecycle Manager, shown in Figure 11.11.
Figure 11.11 Transporting SAP HANA Objects Using the SAP HANA Application Lifecycle Manager
You can access this built-in transport tool from the context menu of your SAP HANA system. This is especially useful for companies that do not have other SAP systems or SAP Solution Manager to manage their transports. This web-based interface also works well on larger mobile phones and tablets.
Exporting Data (Extra)
There is a special method to export and import tables with their data between systems. This method is not automated like transports, but it can still be quite useful—for example, to build a training system.
Access the same Import and Export menu options as for the transports, but in this case open the SAP HANA folder in the dialog box and select Catalog Objects (see Figure 11.12) to export SAP HANA data tables.
Figure 11.12 Exporting Data Tables
You can export the tables in either CSV or binary format.
Importing Objects with Schema Mapping
Sometimes, you may find that a schema in a development system is named differently
than a similar schema in the production system. If someone named the original schema
SALES_DEV in a development system, such a name makes no sense in the production system. Therefore,
it’s renamed to SALES in the production system. When you create information models in the development system
using the PRODUCTS tables from the SALES_DEV schema, SAP HANA uses the naming convention <schema name>.<table name> (e.g., SALES_DEV.PRODUCTS) for tables used in the models. If you now transport these information models to
the production system, the models expect the PRODUCTS table in the SALES_DEV schema. The table has to exist already in this exact location. If the schema or table
is not found, you will receive an activation error. In this example, the schema is
now simply called SALES, so you will receive an error when transporting the models.
You can work around this problem by using schema mapping. You can create such a schema mapping in the production system, as shown in Figure 11.13. You can find the Schema Mapping functionality in the Quick View menu (see Figure 11.13).
The original schema name in the development system is called the Authoring Schema. The target schema in the production system is called the Physical Schema.
After you set up the schema mapping and import the data models, all references to
the SALES_DEV.PRODUCTS table are automatically changed to refer to the SALES.PRODUCTS table. In this case, you do not receive activation errors because the PRODUCTS table already exists in the SALES schema in your production system.
[+] Hint
Schema mapping is applied on information models as part of the import process.
Maintaining a Default Schema for a Package
We can use schema mapping to map multiple authoring schemas to a single target schema. For example, the BOOK_DEMO and SAP_HANA_DEMO authoring schemas might both map to the physical BOOKS schema in the production schema. If you do this, SAP HANA studio might not be able to determine which authoring schema an information model must reference when doing schema mapping.
You can therefore specify the default schema for models in a package. When you import information models contained in such a package into the target schema, SAP HANA studio knows what the authoring schema is, and can perform the mapping to the physical target schema. This is a new feature in SAP HANA SPS 11.
Figure 11.14 shows that the book package is mapped to the BOOK_DEMO schema as its default schema, and the sap.hana.democontent package is mapped to the SAP_HANA_DEMO schema as its default schema.
You can leave the Package Name field open. In Figure 11.14, we have a blank Package Name field, and a Default Schema named DEFAULT_SCHEMA_FOR_OTHER_PACKAGES. In this case, all other packages in the system that do not have a default schema specified will use this DEFAULT_SCHEMA_FOR_OTHER_PACKAGES schema for their default schema.
Figure 11.14 Maintain Default Schemas for Packages
Importing Objects with Mass Copy
In the Quick View menu (see Figure 11.13), you can find the Mass Copy option. Mass copy allows you to copy many information models at the same time and keep the references between the copied models consistent. All references are updated automatically. For example, you could create a limited SAP HANA sandbox (playpen) environment to quickly test some modeling and reporting functionality.
You could also think of this as a “Mass Import” option. The Mass Copy option can be used to import SAP HANA application content created by SAP or SAP partners into your SAP HANA landscape. This application content can consist of many SAP HANA information models and objects.
Native vs. Imported Objects
To further ensure the stability of production systems, SAP HANA marks all transported objects as imported objects in the production system. In the development system, where they were created, they are marked as native objects. SAP-created objects will be marked as imported objects in all your systems—even in your development system—because you did not create them.
[+] Hint
Imported objects should not be edited. If you want to make changes, you can make a copy of the relevant objects and modify the copy. This ensures that you do not lose all your changes when SAP updates SAP-provided content. When the new version of the SAP content is imported, it will overwrite all the current objects. All your changes would be lost if you modified the imported objects directly.
Core Data Services
SAP takes the concept of design-time versus runtime objects to the next level with Core Data Services (CDS) in SAP HANA (CDS was discussed in Chapter 4). You can think of CDS as a more intelligent activation process that combines with transports to allow activation in other SAP HANA systems as well.
CDS data sources are fully transportable. Previously, you had to ensure that all tables required by your information models were available in the target system before you could import your models, but with CDS data sources, you can now import and activate the data sources together with your information models.
The SHINE demo package is a good example of CDS data sources in action. You do not have to create a schema, tables, or import data into these tables. When SHINE is imported into your SAP HANA system, it automatically creates all that content for you using CDS statements. This means there is no need to do schema mapping in your target system.
Refactoring Information Models
Refactoring is the process of restructuring your information models without changing their external behavior (i.e., their result sets). You do this to improve, simplify, and clarify the design of your models—for example, when you move information models inside the system from one package to another, or when you rename an information model.
You can access the Refactor option from the context menu of an information model, as shown in Figure 11.15.
Figure 11.15 Refactoring Information Models
Renaming or moving an information model is not always a trivial task. If the information model is used in many other models, you will have to update those models as well. You can easily find yourself having to update hundreds of information models when simply trying to rename a single dimension view.
The Refactor option in SAP HANA takes care of this process for you. The only case in which you will still have to manually help with the refactoring process is when the information model is also used in some SQL or SQLScript code, and with updating the security authorization when you move the models to another package.
Refactoring and Restructuring Nodes in a Graphical Calculation View
Figure 11.16 shows the context menu of a node in a graphical calculation view. From this menu, you can rename the node.
Figure 11.16 Restructuring and Refactoring Nodes in Graphical Calculation View
In this case, you can also go further and replace the data sources used in the node, or even replace or delete the entire node. However, such actions are not normally part of refactoring because the result set of the information model will change.
[+] Tip
Replacing the data source in a node is useful when you have to create different information models that are based on similar data tables. You can make a copy of an existing view, and then change the data source to a similar table. SAP HANA will ask you to verify the mapping of the old data source to the new data source. It will then keep as much of the current information intact as possible. This can save you many hours of building similar information models.
Where-Used
In the refactoring process, you may have to figure out where a specific information model is used. Figure 11.17 shows the context menu of an information model. By selecting the Where-Used menu option, SAP HANA finds all the places where that information is used.
The Where-Used functionality was used in older versions of SAP HANA to find out where to rename an information model. This feature shows you a list of models that use your information model. These models will be affected when you rename the information model, and will therefore also need updating. The new Refactor · Rename feature makes this task much easier. It renames the information model and updates all the models where it is used to ensure everything still works post-renaming. This feature became available as of SAP HANA SPS 10.
History
Just below the Where-Used menu option in the context menu of an information model (Figure 11.17), you will see the History menu option. The History feature shows which users updated and activated the current and previous versions of an information model.
Deprecate
Sometimes, you create a new variation of an information model that is better than the older version. However, you cannot simply get rid of the older version; it might be used in many other information models, and you do not have time to make the necessary changes in all those models. In this case, you can go to the properties of your information model and mark the information model as deprecated by selecting the Deprecate checkbox, as shown in Figure 11.18.
Figure 11.18 Deprecating an Information Model
This does not stop the old version of the information model from working. However, it will produce a warning if you or any of your colleagues try to use the old version when creating new models. The Model Is Deprecated message indicates that everyone should use the newer variation of the information model.
Documenting Information Models
As you near the end of a modeling project, documentation becomes important. You need to hand your modeling work over to someone else. There are always good reasons for the many decisions you make, such as why the various nodes of a calculation view are in a specific order. Documentation tools and features in SAP HANA allow you to communicate that information to anyone who may work on your project in the future.
Comments
In SAP HANA, you can document various aspects of information models using comments. Figure 11.19 shows what the comments look like.
Figure 11.19 Documenting a Join Node of a Graphical Calculation View
A yellow comments popup will open when you click on the Sticky Note icon.
Auto Documentation
In the context menu of an information model (see Figure 11.20), you’ll find another useful documentation feature: Auto Documentation.
Figure 11.20 Auto Documentation Option in an Information Model’s Context Menu
The Auto Documentation feature documents graphical information models in SAP HANA. Figure 11.21 shows an example of the output generated.
Figure 11.21 Example Documentation Generated by Auto Documentation
Translating Information Models
SAP HANA also provides functionality to help you prepare your information models for consumption by end users who communicate in other languages. In this section, we will focus on the translation of labels and how to use the Repository Translation Tool (RTT).
Translating Labels
You can open the Multi-Language Support dialog box (see Figure 11.22) by clicking on the World icon (leftmost icon resembling a globe) on the information model toolbar (refer back to Figure 11.5).
Figure 11.22 Translating Information Model Labels
Select the language that you require from the Language dropdown menu, and click the Load Text button. You can then translate all the labels in your information model.
Repository Translation Tool
SAP HANA also provides a command-line tool known as the Repository Translation Tool for exporting, uploading, downloading, and importing language files. These language files contain all the text of repository objects and are in a standard format for customer or partner usage. Because RTT is a command-line tool, you will need to ask your SAP HANA system administrator for access to it.