3.5    Case Study

E-Corporation is the world’s largest robotics manufacturer and a large multinational conglomerate. The company has a large SAP ERP implementation and has recently purchased SAP HANA to facilitate a high-performance sales analytics data mart that combines data from multiple core SAP Business Suite systems and data from a few subsidiaries that use non-SAP applications to manage their sales operations.

The new E-Corporation analytics project is still in its early phases. Developers are just starting to analyze and profile data from various source systems. However, the director of analytics for E-Corporation is aware that extremely sensitive data will be hosted in the SAP HANA system. Because the data is sensitive in nature, implementing a sound security model is of the utmost importance. To help the E-Corporation team implement a sound security model, the company has contracted an SAP HANA security expert from a trusted consulting partner.

During initial project meetings, the security consultant recommends that E-Corporation start planning for the security model during the development phase. The security consultant knows that the development team will need to create several catalog tables and a few schemas to house the data from the various sources, and he highly recommends that the company begin the development process by creating two repository-based schemas to host the staging and data mart tables. The consultant also recommends that E-Corporation create repository-based tables to help simplify the development and management of a security model.

Before activating any repository-based objects, the security consultant recommends defining a package hierarchy to store the core repository objects that will be used to define the security model. (Chapter 1 provides the necessary information for creating packages and a package hierarchy.) Knowing that package privileges are critical to the security of the security model itself, the consultant recommends defining a top-level package named Security, followed by a subpackage named Schemas and another named Roles. Figure 3.12 shows the complete package hierarchy as viewed in the SAP HANA Web-Based Development Workbench editor.

E-Corporation’s Initial Package Hierarchy

Figure 3.12    E-Corporation’s Initial Package Hierarchy

E-Corporation decides to create two repository schemas (using the steps outlined in Section 3.3.1). The first schema will be named StagingMart, and the second schema named SalesMart. The repository schemas will be activated within the SAP HANA package named Security.Schemas. The syntax for creating each repository schema is listed in Table 3.1.

Schema Name

Repository Schema Syntax

StagingMart

schema_name = "StagingMart";

SalesMart

schema_name = "SalesMart";

Table 3.1    Repository Schema Names and Syntax

Figure 3.13 shows the items present in the package hierarchy. Under the subpackage Schemas will be two objects, both with the .hdbschema file extension. Each object or file is preceded by the name of the file and then the name of the schema.

Now that the schemas are in place, developers can create tables to store the data. The security consultant recommends that developers use repository-based tables for two reasons: First, developers won’t need the CREATE ANY object privilege for the two schemas, which simplifies the security model. Second, repository tables can be promoted easily with the security model to other SAP HANA environments to support sound lifecycle management.

Development Repository Schema Artifacts and Corresponding Script Syntax

Figure 3.13    Development Repository Schema Artifacts and Corresponding Script Syntax

Because the tables created by the developers must be secured in such a way that developers can frequently make changes, the security consultant recommends that E-Corporation create a new package hierarchy to store development artifacts that the development team can use for the sales analytics project. Setting up a separate package hierarchy in these instances is recommended because this hierarchy can be secured independently from the top-level security package. The consultant thus recommends that a top-level package named e-corp be created and, within it, a subpackage named sales. Within the sales package, he also recommends that a package named tables be created. Figure 3.14 shows how the resulting package hierarchy should appear within the SAP HANA Web-Based Development Workbench editor.

E-Corporation’s Package Hierarchy

Figure 3.14    E-Corporation’s Package Hierarchy

E-Corporation creates the Customers table and the Products table in the StagingMart schema (following the steps in Section 3.3.2). The repository CDS tables are created within the e-corp.sales.tables package. The repository object type will be a CDS document or an .hdbdd file. We’ll use the context stg so that each table is prefixed with “e-corp.sales.tables::stg.” Listing 3.2 shows the syntax of the stg.hdbdd script that will be activated to generate runtime tables in the SAP HANA schema “StagingMart”.

namespace "e-corp".sales.tables;
@Schema: 'StagingMart'
context stg {ENTITY Customers {
    key CustomerID : Integer;
    CustomerName : String(256);
    CustomerAddressLine1 : String(256);
    CustomerCity : String(256);
    CustomerLatt : Decimal(26,6);
    CustomerLong : Decimal(26,6);

    }
ENTITY Products {
    key ProductID : Integer;
    ProductName : String(256);
    ProductDescription : String(256);
    ProductTypeID : Integer;
    ParentProductID : Integer;
    }

}

Listing 3.2    Syntax of the stg.hdbdd Script

Once the CDS document table script is activated, two new tables will be visible within the StagingMart schema. The names of the tables are shown in Figure 3.15, which shows the SAP HANA Web-Based Development Workbench catalog. Notice how the name of the runtime version of each table includes the repository package hierarchy name, two colons, the context name, and finally the table or CDS entity name.

CDS Repository-Based Tables Created in the StagingMart Schema

Figure 3.15    CDS Repository-Based Tables Created in the StagingMart Schema

SAP HANA requires unique object names for all runtime versions of objects created within the repository. To achieve this requirement, the package hierarchy name is automatically included as a prefix for every catalog object created within the CDS document.

E-Corporation now has two design-time schema scripts, one CDS document script resulting in two runtime schemas, and two runtime catalog tables. The foundation for a sound security model has been implemented. Developers that have been granted privileges for these objects can now begin loading data into these SAP HANA tables. Security administrators can relax, knowing that their security model can be transported and backed up.