Starting SAP Analytics Cloud as an Administrator

Before you roll out SAP Analytics Cloud to your users, it’s important to perform several administrative activities.

This blog post mainly focuses on tasks for administrators who set up SAP Analytics Cloud and presents all necessary tools to perform this setup.

Before starting with SAP Analytics Cloud, you should first plan your initial activities. This is essential to make sure that your users later have a seamless user experience. The following questions will be discussed throughout this post:

How many users will work with the solution?
Do you want to provide single sign-on (SSO)?
Which data sources and connection types will be used?
Do you want to reflect your organizational structure in SAP Analytics Cloud?
What should your folder structure look like?
What will your operational concept look like? Who will be allowed to create content, and who will consume it?
Do you need additional development or quality tenants of SAP Analytics Cloud?

These questions not only provide a first idea for topics you have to consider before implementing the solution but also allow you to gain a realistic estimation of the effort needed to do so. Ahead, we’ll discuss these questions from a high-level perspective. Not all of them can be answered by using examples or scenarios.

Users and Single Sign-On

The number of users is important for system usage. If you’re planning to have a high number of users working with SAP Analytics Cloud (more than 100 users), you should seriously consider using SSO and setting up a structured operational concept. On top of that, it may also make sense to have the organizational structure reflected within SAP Analytics Cloud’s file structure.

The user creation process itself has to be planned accordingly as well. SAP Analytics Cloud has its own user management because the solution can also be used standalone. While users can always be created manually, you can alternatively use CSV import, copy and paste, or import from Active Directory to create new users. When using SSO, you can fully automate the process.

Because SAP Analytics Cloud offers various license types that include additional functionalities, you should plan up front how you want to assign those licenses to your users. You can always change the assignments later.

When planning to establish SSO, several prerequisites must be met within SAP Analytics Cloud. Especially when the number of users is high, SSO should be set up correctly because you can also use it to assign authorizations via teams and roles to users. If the standard roles delivered by SAP do not match your requirements, you should create custom roles first. Teams allow you to assign authorizations on folders and files (i.e., stories or applications). These control if users are permitted to see content or even modify and delete it.

In general, the following applies to the usage of your own identity provider to establish SSO:

The identity provider must comply with the SAML 2.0 protocol.
You have to determine a unique attribute on which the user is mapped between SAP Analytics Cloud and the identity provider. In a lot of cases, this is either an email address or a unique user ID.
If you want to assign roles and teams, you must configure additional SAML tags in your identity provider. Those tags contain all roles that the user owns and all teams the user belongs to. Therefore, they must be created and maintained in the identity provider.
If you want to use the identity provider to authenticate against your data sources (e.g., SAP Business Warehouse), you have to make sure that both SAP Analytics Cloud and the data source use the same identity provider.
If you don’t want to use your own identity provider, SAP Analytics Cloud ships the SAP Cloud Identity Services by default. Users are then completely managed in SAP Analytics Cloud.
The status of a user and all assigned roles and teams are checked on each login. If you want to unassign a user from a team, you only have to do this within your identity provider and SAP Analytics Cloud will automatically apply the change.

The configuration of a custom identity provider is described in detail in the product help, which you can access at this URL: http://s-prs.co/v502610.

Data Sources and Structures

Depending on the data source and connection type, you may have to perform additional configurations in SAP Analytics Cloud. Those can be the creation of new connections or setting up the SAP Analytics Cloud agent.

If you want to reflect your organizational structure within SAP Analytics Cloud, you should make sure to plan this accordingly and before you start implementation. In general, SAP Analytics Cloud has its own authorization management tools. Although the backend authorizations are fully respected when using a live connection, you can still assign authorizations in SAP Analytics Cloud to determine the visibility of and additional rights for stories, folders, or other objects. However, those authorizations can’t override the backend rules. Nevertheless, they can be used to hide specific objects from people who are not authorized to see that data, for example.

When using a live connection, all data authorizations are driven by the data source. If a user can access a story built on a live connection, it can still be the case that he won’t see any data. In this case, he doesn’t have the necessary authorizations in the backend and will be presented with an error message.

There are multiple functionalities in SAP Analytics Cloud to implement your organizational structure. On the one side, you can use teams to group multiple users. You can then assign access rights for objects like stories, applications, models, or folders to those teams. Every member of a team then automatically inherits these access rights. If a user is removed from the team, he automatically loses all associated access rights. You can also assign team membership via SSO so that you don’t have to maintain this manually in SAP Analytics Cloud.

On top of that, the solution offers a full folder structure in which all stories, applications, models, and other elements are contained. You can also use these folders to reflect your organizational structure and use team authorizations to make them visible to the appropriate user groups. An example of such a folder structure is shown below.

Folders can always be created, edited, moved, copied, or deleted. They are a very strong mechanism to maintain content and meet organizational needs.

Operational Concept

Depending on the planned system size, it may become very important to define an operational concept. This also includes the clear definition of functionalities users should be allowed to use. This can be steered by using the role concept of SAP Analytics Cloud, which allows for a very detailed setup of competences and responsibilities.

One of many options is to distinguish between story creators and viewers. By using roles and authorizations, you can determine folders in which only a small number of people can store stories or applications, but which can be accessed by a broad audience.

By using the role concept, you can steer which functionality is available to specific users. You can, for example, define a role the users of which can only consume stories and are not allowed to upload any personal data. You can also configure roles that allow users to create personal stories or applications, while an additional role would also allow users to publish the content centrally.

System Landscape

You should also consider using multiple systems in your landscape if required. If you’re planning to use SAP Analytics Cloud with a low number of users and some reports only, one productive system should be sufficient. In general, having multiple systems isn’t mandatory. However, if you’re facing complex requirements or conditions, a second instance of SAP Analytics Cloud can be of great help. Examples of such conditions are as follows:

You’re mainly planning to use live connections to your data sources, which again are separated into multiple systems for development, quality, and productive usage (i.e., in SAP BW). You want to connect SAP Analytics Cloud to all stages in your landscape.
Story creators or developers are not allowed to see productive data.
Stories should be developed in a completely isolated environment and show nonproductive data at that stage.

If one of these conditions are met, a system landscape with more than one system is recommended but still not mandatory. However, you may face additional challenges.

Whenever a strict separation of development and productive systems are desired, a system landscape with multiple systems as shown in the figure below is the preferred setup. This has the following advantages:

You can maintain different users in productive and nonproductive systems. Therefore, you don’t have to assign productive licenses to report developers.
You have an isolated environment to try out new functionality or report adjustments.
You can modify and update existing reports without having to interrupt any productive usage. Once you’re done with the adjustments, you can easily transfer the content to a productive system.
The test system license doesn’t differentiate between different license types. All users in the system can use all functionality. This allows users to try out and evaluate additional elements like planning.

This third point is particularly important in scenarios like that shown below. In this example, an SAP BW system is used as a data source. The SAP BW system is split across three instances: development system (BWD), quality system (BWQ), and productive system (BWP).

In general, SAP Analytics Cloud uses models to expose data. Those models can either contain uploaded data or represent a live data source. If a model is based on a live data source (e.g., SAP BW), it doesn’t contain any actual data but refers to a query or a view in the data source (e.g., SAP BW query).

To better understand this relation, it’s shown in the following figure.

When creating a story in SAP Analytics Cloud, only models will be used to connect to data. The model determines if the data is stored in the cloud or imported (the data resides in the cloud) or if it’s coming from a live data source (the model is just referring to the data source). Therefore, you can move from a productive data source to a nonproductive one (or vice versa) on the model level only. This can be done in the model settings, where a new data source can be indicated. When going into a story and trying to exchange the model behind a chart, the chart will be completely reset.

If a developer who isn’t allowed to see productive data wants to update a productive story, that developer first has to change the data source in the model. The developer can now open the story and start working on it. However, this change applies to all users, which means that at that moment, the story can’t be used productively. The developer first has to reset to the original data source.

This problem can be solved by using a system landscape with multiple instances because stories, applications, or models can be transported between multiple systems. This allows stories and models to be identical in multiple instances in which only the data source below the model is different. While the model in the development instance is referring to nonproductive data, the model in the productive instance shows productive data.

The next figure shows a full picture of this scenario. In this example, the SAP BW system has three instances (BWD, BWQ, and BWP). There are also three instances of SAP Analytics Cloud. All connections are live.

The Market Analysis story is first created by a developer or creator and then validated in a quality system. Afterward, it will be published for productive usage. Both the story and model carry identical names in all three instances. The only difference among all three models is the data source. The story will show nonproductive data in the first two instances and productive data in the last instance.

If the developer now wants to enhance the story, he can do so isolated in the development environment. Once his enhancements are finalized, he can transport them to the quality system and then to the productive system. When transporting content, technical names are kept the same so that existing content will be replaced. Users will automatically open the most recent version.

A note on system landscapes: It’s very common in on-premise setups to have multiple instances of a system to keep development, quality validation, and productive usage separated. SAP Analytics Cloud also offers the option to have multiple instances and transport content between them. Whether multiple instances are really needed depends on the individual situation. Especially in big landscapes or when productive and nonproductive assets are strictly separated, a landscape containing multiple systems adds significant value.

Independent of the desired setup, SAP Analytics Cloud never allows administrators to delay updates or implement their own modifications. All development and test instances are maintained by SAP like in productive systems.

Conclusion

This blog post shared the first steps that system administrators should take when setting up SAP Analytics Cloud.

SAP Community