Outlining the Technical Architecture of Intelligent Content

SAP provides the business user with ready-to-use analytics that include data-rich dashboards and data models. This is called intelligent content. Intelligent content is powered by SAP BDC data products that provide the real-time data from SAP applications.

Intelligent content is developed and managed by SAP and is shipped in a delivery container called an Intelligent Package that groups the related intelligent content. Customers subscribe to Intelligent Packages so that they can install the intelligent content they contain.

Let's learn about the basic architecture of intelligent content.

There are four SAP BDC software components required to support intelligent content:

• SAP Analytics Cloud - provides the story that includes visualization elements such as tables and charts, and navigation features such as filter selectors and drill-down buttons.
• SAP Datasphere - provides the analytic models that provide the modeled data to the stories.
• SAP Business Data Cloud Foundation Services - provides the data products that are consumed by the analytic models.
• An SAP source application - provides the source data required by the data products. The source application must be included in the SAP BDC formation where the intelligent content is installed.

Let's look at an example of the structure of intelligent content from the Intelligent Package People Intelligence.

The layers within intelligent content are:

• Story - in the diagram we see two SAP Analytics Cloud stories that present the data to the business user. These stories consume the analytic models of Datasphere.
• Analytic Models - the analytic models of Datasphere combine and enrich the required data products by adding semantics to form ready-to-consume analytical data shapes, such as dimensional models and hierarchies, to support drill-down and data exploration.

The layers that support the intelligent content are:

• Data Products - data from the source application tables is replicated to the data products. A data product can combine one or more tables from the source application.
• Source tables - source tables are provided by the SAP SuccessFactors application.

Let's look at the relationship cardinalities within the layers:

• An analytic model consumes multiple data products. A single data product can be re-used by multiple analytic models.

• An analytic model can be consumed by only one story. A story can consume multiple analytic models.

• A data product delivers data from at least one, but usually multiple tables from the source system.

Intelligent content implements an SAP-managed live data connection that links SAP Datasphere to SAP Analytics Cloud. A live data connection means that the data consumed by the story is not stored inside SAP Analytics Cloud but is read live from SAP Datasphere.

When intelligent content is installed, several SAP-managed spaces are automatically created in SAP Datasphere. These spaces store the Datasphere modeling artifacts that are also generated during the installation.

The SAP-managed spaces are read-only and cannot be edited. Users who are members of the relevant spaces can explore these objects in read mode using the standard SAP Datasphere tools, but they cannot modify them.

The Datasphere spaces that are generated during the installation of intelligent content are:

• Ingestion Space - contains the local tables that store the data loaded from data products, and the replication flows that load data to the local tables. This space has the name of the source system. Think of this space as managing the raw unprepared data that is ready to be used in data modeling.
• Preparation Space - contains views built on top of the local tables that prepare the data for consumption. This space also contains the data access controls that provide user permissions to the data. This space has the name of the source system.
• Application Space – contains analytic models built on top of the views to add semantics so that the data is ready for consumption by stories in SAP Analytics Cloud. This space has the name of the intelligent content.

When you install intelligent content from multiple Intelligent Packages that connect to the same source system, the intelligent content shares the same ingestion space and preparation space. When uninstalling intelligent content, the shared spaces are retained until the final intelligent content that requires the space, is removed.

In the example above, we have two stories installed that are connected to the same source system. This results in the reuse of the ingestion and preparation spaces and in the creation of a separate application space for each story.

You can install the same intelligent content multiple times for different source systems.

For example, your organization operates multiple SAP S/4HANA instances across different countries and you require separate analytics using the same intelligent content. In this case, three separate spaces are created in SAP Datasphere for each instance of the intelligent content, distinguishable by an alias that was assigned to the spaces during installation. When uninstalling intelligent content, the appropriate spaces are removed.

In the example above, the intelligent content provides one story that connects to our two source systems. This results in separate spaces, where each space identifies the source system providing the data.

The most important security elements are:

• Users

  It is often necessary to specify different security policies for different types of users. In the context of SAP BDC, we encourage identity providers to allow SAP Analytics Cloud users to also operate in SAP Datasphere.

• Spaces

  It is necessary to separate objects for different topics or user groups. In SAP Datasphere, object-related authorization is managed via the space concept. A space is a separate development area that enables access to certain resources, and specific users can access a space. All objects are defined in one space. This combined nature of data residence and data responsibility needs to be taken into account when creating an authorization concept.

• Roles

  Roles are a set of allowed activities for certain object types.

• Data Access Controls

  Data Access Controls (DAC) are the Datasphere objects that you define to grant row-level authorizations. The DAC acts as a user-specific filter based on a combination of values of the fields on which the data access control is defined.

Artifacts such as tables, views or stories as well as data reside in a particular space and are only visible for users assigned to that space. On the other side, users assigned to a particular space have access to all artifacts and data of that space. Spaces partition data into areas of responsibility and authority.

By default, some spaces are only accessible by technical users, others. like the automatically established preparation spaces or consumption spaces can be read but its objects cannot be changed. You can create your own additional spaces.

Cross-space sharing allows you to make objects of a particular space available for consumption for other teams. You start in the data builder of the source space or in the repository explorer, then select one or multiple objects, define one or several target spaces and choose share to expose these objects to the target spaces. Target spaces must be in the in the same SAP Datasphere tenant.

SAP provides standard roles, such as DW Viewer (for consumption of SAP Datasphere data) or DW Administrator. The most of them are not directly usable. Instaed, a scoped role must be defined based on a template. A scoped role is a role that enables activities only for one or multiple specified spaces - a scope.

Scoped roles provide a more flexible and granular authorization concept. Users can have different roles in different spaces. Allocation of users and roles and spaces is possible via SAPM (security assertion markup language) which enables referencing the users from SAP Analytics Cloud in SAP Datasphere.

For a scoped role, there is exactly one reference role. The same reference role can be used for any number of scoped roles. A scoped role is designed for any number or spaces. A space can be part of any number of scoped roles. Any number of scoped roles can be assigned to a user. The same scoped role can be assigned to any number of users.

User, role and authorization management can be handled via an API.

Users with the Space Administrator and Role Administrator role can create scoped roles. First, you choose an existing role as a reference role, then assign a scope, and finally assign users. Assigned users appear in all spaces of the scope. From now on, they can execute the corresponding actions on all objects of these spaces.

A Data access control dynamically restricts the data user-specific during the consumption based on criteria that are determined at run-time. The reference table or view that maps users to corresponding restriction criteria are defined at design-time. The following types of criteria can be used when defining a Data Access Control:

• Single Values (for example, user A: country 'US', user B: country 'CA')
• Operator and Values (for example, user A: for years before 2020, country 'US' or country 'CA', for years after 2019, country 'FR' and product 'X'.)
• Hierarchy (one or multiple hierarchy nodes in a parent-child hierarchy)
• Hierarchy with Directory (nodes of a more complex form of hierarchy that may contain time-dependent external characteristics)

The values can be defined by an authorization administrator and implemented by a another user, the data engineer. If the data engineer should have no edit authorization on the permission table, create the permission table in a dedicated permissions space and share it with the administration space in which the data access control is created and assigned. You can share a protected view with a consumption space for business users.

A data access control is defined based on a view that lists criteria and authorized users.

Users with the DW Space Administrator role (or equivalent privileges) can create data access controls. Each user can only see the records that match the values they are authorized based on the permissions entity. If the permissions criteria are defined as hierarchy nodes, then all descendants of visible nodes are also visible.

• You've learned how data flows from the source application to the intelligent content through the underlying layers provided by SAP Analytics Cloud stories and Datasphere.

• You've learned about the generated content in the Datasphere spaces that support the intelligent content.

• You've learned about the authorization mechanism that supports intelligent content.