SAP BusinessObjects Planning and Consolidation (also known as SAP BPC) is designed to empower the business by reducing its dependency on the IT department for making system changes. Authentication and authorization assignments are usually an area that the IT department of a company controls. With SAP BusinessObjects Planning and Consolidation, authorized business users can directly configure security. This allows them to help themselves and avoid having the IT department become a bottleneck in setting up or making changes to the system. Typically, a power user within a line of business handles this task because he knows the users within the business and the data with which they should or should not be working. (See the article “SAP BusinessObjects Planning and Consolidation: An Overview of How It Works with SAP NetWeaver BW” for a more detailed discussion on this topic.) 

Throughout this article, we focus on the tasks an administrator or power user in the line of business performs. This includes adding a user to an application set, assigning the user to a team, and then assigning member access profiles and task profiles to that team. We discuss the best practices of setting up authorizations as well. See the “Key Terms” sidebar for definitions of user, team, task profile, and member access profile.

The user experience is almost identical (even for administration) between SAP BusinessObjects Planning and Consolidation, version for the Microsoft platform, and SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver. However, the back-end implementations are quite different. All the content and behavior we describe in this article apply just to the version for SAP NetWeaver.

Important Differences in SAP Business Planning and Consolidation Security

It is important to understand that the implementation of task profiles and member access profiles within SAP BusinessObjects Planning and Consolidation 7.0, version for SAP NetWeaver, do not use SAP NetWeaver authorization objects and analysis authorizations to implement the security model. The security model is proprietary to SAP BusinessObjects Planning and Consolidation. Connections are made to the ABAP server using service users because Active Directory users are used, not SAP NetWeaver users.

This is important to understand because the typical techniques to troubleshoot security-related issues are different. To debug and troubleshoot security related topics, such as incorrect data results due to authorization, see our SAP Professional Journal article “Debug Application Logic More Efficiently in SAP BusinessObjects Planning and Consolidation.” This article also shows you how to troubleshoot issues as these techniques apply to authentication and authorization.  

In addition, SAP BusinessObjects roles are not the same concept as ABAP roles or teams. It is important to understand that the terminology is different between standard ABAP roles.

User Management in the Admin Client

A user within SAP BusinessObjects Planning and Consolidation is a user that exists in the corporate Active Directory of a company. (Within version 7.0, the only user management repository that is supported is Active Directory.) During installation, the software requires that a domain be chosen on the Active Directory to obtain a list of possible users.

Figure 1 shows the SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver Admin client, with the Security section selected. All the authorization assignments occur within this section. Under the Users folder, you see the domain SAP_ALL. In your company, this is the domain that the software is configured to use.

Let’s take a look at adding a new user to an application set (AppSet) within SAP BusinessObjects Planning and Consolidation.

Add a New User to an AppSet

Within the Admin Console, when you click the Users folder, the action pane offers the option to add a new user to this AppSet. When you click this action, a guided wizard appears to help you select and specify the user detail (Figure 2). Click the Custom Filter button and enter the user in the screen that appears (Figure 3). Note that adding users to this AppSet does not grant the users any authorizations by default. Therefore, this step is just to designate to which users you want to grant authorizations. We discuss authorizations later in this article.

Once the user is chosen, the next step is to assign a user name and email address to the user (Figure 4). The email address is used when software has the capability to notify users of items such as work status.

Then assign the user to a team (Figure 5), task profile, or member access profile (Figure 6). This grants the authorizations to the user and controls which regions of data the user can work with as well as which tasks or actions the user can perform.

Types of Users

Now that you know how to add a user and assign security, you need to understand how to conceptually design a good security model. When designing your security model, it is best to identify the types of users you have within your business. We describe some best practices and recommendations for the types of users you can have within your line of business.

BPC end user

• Typically accesses BPC for Excel or BPC Web for running reports and entering data
• May have the ability to run Data Manager packages
• May have the ability to set locks using work status
• May have the ability to post journal entries

BPC team leader

• Has the ability to create team reports or Data Manager packages, but is restricted from updating or creating company reports such as administrators

Secondary administrator

• Maintains dimensions

Application administrator

• Builds and maintains the applications
• Typically, but not necessarily, has access to data (e.g., consultants or power users)

System administrator

• IT person responsible for NT server set up and network/internet administration
• Has technical access to data (not operational access)
• Can build AppSets
• Typically has SAP NetWeaver BW administration privileges

Having an idea of these different types of users provides you some guidelines on how you can build different teams and task profiles or member access profiles. For example, you can configure SAP BusinessObjects security using task security and member security. You can have one end user who can view and update the data for the SalesUS Entity, while another user could view and update data for the SalesItaly Entity. When you combine this with task security, you could even control what tasks that they could do, such as load data to their entity, or post journals to their entity. See the examples below for some scenarios:

End user 1

• Has the ability to run Data Manager packages
• Can plan data in Excel and Web
• Can set Work Status locks
• Can view and update all records under the parent SALESUS for the Entity dimension

End user 2

• Can post journals for SALESITALY
• Cannot perform any other activities

The combination of member access profiles and task profiles determine overall SAP BusinessObjects Planning and Consolidation access. (We discuss how to configure member access profiles and task profiles later in this article. However, you should have an understanding of the logical flow for security.)

Recall that users come from Active Directory domains and groups. These users are then assigned to an AppSet. Following this, you can assign the users to teams or directly to member access profiles and task profiles. The diagram in Figure 7 describes this logical flow.

Add a New Team to an AppSet

As noted earlier, the best practice is to assign users to teams. Teams are simply groups of users. Adding new teams is simple. From the AppSet hierarchy, expand Security and click Teams. From the action pane, click Add new team (Figure 8).

The first step in building a team is to choose the team name and description. Typically, it is best to use a name and description that describes the security that you plan to assign to this user. For example, you could name the team East Side if granting access to the east region (Figure 9).

After you define the team, you can assign users and member access profiles to the team. It is important to note that there is a check box next to the users when assigning them to a team. You can only check one user, which designates the team leader (Figure 10).

Figure 10

Assign users to a team

A team leader has special privileges, including the ability to:

• Save to a team folder
• Manage Data Manager packages within a team folder
• Maintain transformation and conversion files within a team folder

For example, all users as part of a team can open a report that is in their team folder. Only the team leader can save a report to the team folder. Likewise, any user assigned to the team can execute a Data Manager package assigned to the team folder. However, only the team leader can create and save Data Manager packages to that team folder. Finally, any user can read transformation files and conversion files. Only the team leader can save transformation and conversion files to a team folder.

Once users are assigned to the team, you can then assign member access profiles and task profiles to the team (Figure 11). This grants which authorizations members of this team have.

Figure 11

Assign member access profiles and task profiles to a team

Task Profiles

Task profiles control the actions or tasks a user can perform. To add a new task profile, click Task Profiles under Security of the left side of the screen and click Add new task profile in the action pane (Figure 12).

Figure 12

Add a new task profile

The first step is to give the task profile a name. This is typically a name that describes what tasks you’re assigning (e.g., reporting power user). After you specify the name, you have to choose what type of administrator functions you want to make available to this task profile (Figure 13). After you specify the admin role, you select the tasks for the role as shown in Figure 14.

Figure 13

Specify the admin role

Figure 14

Assign tasks and roles to a task profile

Three types of roles are available for task profiles:

• System Admin: Creates, modifies, or deletes AppSets. It also defines security.
• Primary Admin: Performs all the admin tasks except create, modify, or delete AppSets
• Secondary Admin: Allows users to manage dimension members and maintain locks

Table 1 shows the tasks that are assigned to each role by default. It is important to understand what each role can do because this the role controls how you create task profiles that grant access to administrative tasks.

Roles can be cumulative (e.g., System Admin and Primary Admin). Therefore, you can grant all administrative tasks to a single task profile. However, this is not a best practice when taking into account the best practices around segregation of duties for Sarbanes-Oxley compliance.

Member Access Profiles

Member access profiles control to which region of data a user can read or write. Typically, member access profiles are assigned to end users or power users (not administrators) because financial planners are typically end users who create budgets and forecasts.

Member access profiles grant specific access to the applications within an AppSet. Before creating a member access profile, it is important to designate which dimensions within an application are secured. For example, Figure 15 shows that Entity and Category are secured dimensions. You can set this up by using the Modify Application task that we described in our previous articles.

Figure 15

Define secured dimensions for an application

After the dimensions are secured, you can create a member access profile to define the region of data to which a user has access within an application. To create member access profiles, click Add new member access profile (Figure 16).

Figure 16

Add a new member access profile

The member access profile wizard walks you through the steps to assign data authorizations. First, assign the different read, read and write, or deny access for each dimension and application combination (Figure 17). Each application in the AppSet has its own tab.

Figure 17

Assign data authorizations within a member access profile

In the Dimension drop-down menu, you can see the available secured dimensions. You should only see secured dimensions for each application within this list. You can choose Category multiple times inside the same application if you want to grant access to different sections of a category or if you want to grant read access to one category and write access to a different category. You can also choose whether a user has read access or write access, or deny access to a particular member within an application. Then you can then assign users or teams to the profile before saving.

Authentication vs. Authorization

Once users have authorizations set up, they can log on to a particular AppSet. When first logging on, the user’s user name and password are checked by authenticating against Active Directory. When this is complete, the user is connected to SAP BusinessObjects Planning and Consolidation. The users’ task profiles and member access profiles are checked to see what tasks they can perform and with which regions of data they can work.

When defining this security model, it is best to start with evaluating your different user types before you begin implementing your security model. Conceptually understanding the tasks that users perform and the types of users you have is important and will save you lots of time when defining security. Typically, an SAP BusinessObjects Planning and Consolidation power user grants the member access profiles. This power user also grants access to the task profiles. This allows the business to own and maintain SAP BusinessObjects Planning and Consolidation.