SAP has recoded version 10.0 of SAP BusinessObjects Access Control on the ABAP stack. For this reason it isn’t possible to simply upgrade your current deployments of the solution; it is necessary to install new instances of version 10.0 and migrate your data to them. SAP supports migration from the two previous releases — Access Control 5.3 and Compliance Calibrator/firefighter 4.0 (Figure 1).

Figure 1

Supported migration paths to the new version 10.0 of SAP BusinessObjects Access Control

Table 1 provides an overview of the different data objects that can be migrated. Data relating to risk analysis and remediation (RAR) and superuser privilege management (SPM) – aka firefighter – is relatively easy to migrate. The migration of firefighter tables is necessary, because in version 10.0 of SAP BusinessObjects Access Control emergency access management has turned into a fully centralized capability, including the management of owners, controllers, and firefighters.

For the limitations affecting the migration of data relating to compliant user provisioning (CUP) and enterprise role management (ERM) refer to the sidebar “Business Rules Framework Plus Rules.” It is also possible to export historic transactional data as listed in Table 1, but it can’t be imported into version 10.0 of SAP BusinessObjects Access Control. Instead, the export files can be displayed with reporting tools of your choice, if requested by your auditors. Overall, the migration of data objects from version 5.3 of SAP BusinessObjects Access Control to version 10.0 is executed in three phases: preparation, transition, and cutover.

Table 1

SAP BusinessObjects Access Control Version 5.3 data objects that can be migrated

The Preparation Phase

The focus of the preparation phase is meeting the technical requirements for the transition phase. This phase affects the following systems:

• Your current installations of version 5.3 of SAP BusinessObjects Access Control
• All your SAP back-end systems to keep connected to SAP BusinessObjects Access Control
• Installation of version 10.0 of SAP BusinessObjects Access Control instances

With respect to your current installations of version 5.3 of SAP BusinessObjects Access Control, you’re shooting for two goals: (1) you need to deploy the Java data export tool and (2) during the transition phase, you want to keep your installations of SAP BusinessObjects Access Control version 5.3 connected to SAP back-end systems that are connected in parallel to a version 10.0 installation of SAP BusinessObjects Access Control (Figure 2). The first goal requires Java 5.3 Support Package 13 only, whereas the second one requires Java 5.3 Support Package 15.

Figure 2

Support Package level 4 (or higher) of the SAP BusinessObjects Access Control 10.0 plug-ins allows for parallel connectivity to versions 5.3 and 10.0 of SAP BusinessObjects Access Control

The Java data export tool comes with the SAP BusinessObjects Access Control version 10.0 software delivery and is included in the software license. You deploy it by applying the standard procedure with the Java Support Package Manager (JSPM) tool. You launch the Java data export tool using the following URL: https://<servername>:5<instance>00/webdynpro/dispatcher/sap.com/grc~acmigapl/ GRC2010Migration.

The tool is password protected and requires a user to be set up with Access Control administrator privileges (Figure 3).

Figure 3

The Java data export tool has to be deployed on your installations of SAP BusinessObjects Access Control version 5.3

Once you deploy Support Package 15 on your installation of version 5.3 of SAP BusinessObjects Access Control, you can install the SAP BusinessObjects Access Control 10.0 plug-ins GRCPINW_V1000 and GRCGRCERP_V1000. They include all the SAP NetWeaver and HR function modules required by the SAP BusinessObjects Access Control solution. You need to include all Support Packages up to Support Package 4 in the installations of both plug-ins because earlier Support Packages do not support parallel connectivity to both versions of SAP BusinessObjects Access Control, as shown in Error! Reference source not found.. Parallel connectivity is only meant to be a temporary solution during transition and cutover to version 10.0 of SAP BusinessObjects Access Control. Technically, Support Package 4 of the SAP BusinessObjects Access Control 10.0 plug-ins contains the code of the SAP BusinessObjects Access Control 5.3 Real-Time-Agents (RTAs) VIRSANH SP16 and VIRSAHR SP14. For details refer to SAP Note 1590030.

Finally, you need to install the software component GRCFND_A_V1000 up to Support Package 4 (or higher) on an SAP NetWeaver application server ABAP 7.0 enhancement package 2 (7.02) Support Package 6 (Figure 2). This software component in fact contains three SAP BusinessObjects GRC applications — SAP BusinessObjects Access Control 10.0, SAP BusinessObjects Process Control 10.0, and SAP BusinessObjects Risk Management 10.0 — that you activate in the IMG as needed and licensed. Note that the Support Package level of GRCFND_A_V1000 must match the Support Package level of the plug-ins; for example, Support Package level 4 of the main application requires Support Package 4 of the plug-ins and vice versa.

Once version 10.0 of SAP BusinessObjects Access Control is up and running, you need to execute the following pre-migration tasks before you can start importing data:

• Set up system connectors. Only SAP system connectors set up in version 5.3 of SAP BusinessObjects Access Control as SAP Java Connector (JCO) connectors (not Adaptive RFC) can be migrated. All others, including affected connector groups, must be set up manually in version 10 of SAP BusinessObjects Access Control prior to the import of respective rules. You can introduce new names for your system connectors, but make sure that you apply naming transformations as supported by the export tools accordingly. You also can exclude rules from the migration that belong to system connectors that have become obsolete.
• Set up an organizational hierarchy. The concept of business units in version 5.3 of SAP BusinessObjects Access Control has been replaced by organizational hierarchies in version 10 of SAP BusinessObjects Access Control that can be shared across all three SAP BusinessObjects GRC applications installed with software component GRCFND_A_V1000. In version 5.3 of SAP BusinessObjects Access Control all mitigation controls are tied to a business unit. Thus, in order to migrate them you need to have at least a root organizational hierarchy set up in version 10.0 of SAP BusinessObjects Access Control. This setup is done in the IMG and includes the creation of a root org unit and one child org unit (). By logging on to the application via SAP NetWeaver Business Client (NWBC) and navigating to the Master Data tab, you can add a complex organizational hierarchy below your root org unit (Figure 4). Each org unit is identified by an ID as shown in Figure 5. Later, in the transition phase, you import your mitigation controls and corresponding business units. Through org unit IDs you can control in the import program where your business units will be created as subordinate org units.

Figure 4

Set up an organizational hierarchy in the SAP NetWeaver Business Client

Figure 5

Creation of root and child org units in the IMG (left) and the same root org unit displayed in the NWBC showing its ID (right), which is needed later during the import

• Create custom fields. If you were using custom fields in version 5.3 of SAP BusinessObjects Access Control, you need to create them in version 10.0 of SAP BusinessObjects Access Control using the same names before you can import any data for custom fields.
• Provide access for users. Likewise, in version 5.3 of SAP BusinessObjects Access Control you need to create a user in version 10.0 of SAP BusinessObjects Access Control for all workflow approvers and assign appropriate access privileges in the application. In addition, in version 10.0 of SAP BusinessObjects Access Control you need to set up some of your users as Access Control Owners according to their roles. This step is done in NWBC by navigating to Access Management > GRC Role Assignments > Access Control Owners (Figure 6). A user can be an Access Control Owner of one or more of the following types: Firefighter ID Owner, Firefighter Role Owner, Risk Owner, Role Owner, Mitigation Monitors, Mitigation Approvers, Firefighter ID Controller, Firefighter Role Controller, Point of Contact, Security Lead, and Workflow Administrator.

Figure 6

Setting up Access Control owners

In version 10.0 of SAP BusinessObjects Access Control, Emergency Access Management – aka firefighter – all firefighter tables are managed centrally and all firefighters log on to the SAP BusinessObjects Access Control application via the SAP GUI to start a session with a firefighter ID in a remote SAP back-end system. Consequently, you need to create user IDs for all your firefighters, owners, and controllers in the ABAP application server hosting SAP BusinessObjects Access Control version 10.0.

The Transition Phase

During the transition phase you keep all your target systems connected to your installations of both versions of SAP BusinessObjects Access Control until all data is migrated and all functionality is verified. You proceed as follows:

• Use the Java data export tool to selectively export data from your SAP BusinessObjects Access Control 5.3 instances
• Use the ABAP data export tool to export firefighter tables and reason codes from your SAP backend systems
• Use the import program delivered with version 10.0 of SAP BusinessObjects Access Control to import the export files
• Execute required post-migration tasks
• Verify imported data and test all scenarios in scope

The Java Data Export Tool

The Java data export tool comes with the following features facilitating data selection, data transformation, and overall control:

• Filters and application of filters to dependent data
• Data transformation
• Save filters and transformations in variants
• Preview of all data to be exported
• Export of previews to Microsoft Excel
• Lists duplication of data
• Lists dependent data components
• Export files are created on application server
• Generation of a log file during the export

The following example illustrates how filters are applied to dependent data: In the data model of SAP BusinessObjects Access Control, critical roles and profiles depend on system connectors. If you apply a filter on SAP system connectors and choose to apply dependent objects on the connectors as well, you automatically restrict the export of critical roles and profiles that belong to the selected system connectors. You can also use these types of filters to exclude rules that belong to systems that have become obsolete.

The flow diagram in Figure 7 shows the required steps for data export. As shown in Figure 3 the export of configuration and master data is done separately from the export of transaction data. The latter is typically done at the end of the cutover phase when all user access to your SAP BusinessObjects Access Control 5.3 installation has been disabled and transaction processing has stopped. The export of configuration and master data is organized as a three-step guided procedure (Figure 8):

1. Select objects
2. Review objects
3. Start export and results

Figure 7

Data export using the Java data export tool and data import into version 10.0 of SAP BusinessObjects GRC applications

Figure 8

Export of configuration and master data: Step 1 — Object Selection

The object selection screen organizes configuration and master data in objects and components or subcomponents. Object selections are done on a component level. Each component comes with the following icons:

• Filter: Apply filters to any column of the selected component
• Transform: Transform entries in any column of the selected component
• Preview: Preview data to be exported considering all filters and transformations in the lower part of the screen
• Dependents: List all dependent data components

With these features you can export data very selectively and perform a series of exports and imports until all required data is finally migrated.

The ABAP Data Export Tool

Use the ABAP data export tool to export firefighter tables and reason codes. It is delivered with the GRCPINW_V1000 plug-in and started as ABAP program /GRCPI/GRIA_EXPORT_AC_DATA in transaction SA38 (Figure 9). The export tool appends to all exported data a column with the system ID that you enter beforehand in the export tool. This system ID must match the connector name you are using for the source system in the SAP BusinessObjects Access Control 10.0 customizing. The File Path specifies the export location. Select the Fire Fighter (SPM) checkbox. The same program is used to export Compliance Calibrator 4.0 default rule sets.

Figure 9

Use the ABAP data export tool to export firefighter tables and reason codes from your SAP back-end systems

The Import Program

The import program is delivered with version 10.0 of SAP BusinessObjects Access Control. The program guides you through the required steps, as outlined in Figure 7. It is started in transaction SA38 by entering its name, RAC_MIGRATION_DATA_IMPORT. Then make the following selections:

• Step 1. Select a GRC version: Check Import GRC 5.3 Data
• Step 2. Import configuration data: Enter the path to export files on your application server and click Get Files. This action lists all export files containing configuration data (no master data) found in this location (Figure 10). Then select the files you want to import. Check the Append Data check box, unless you want to overwrite data that has already been imported or came in through activation of Business Configuration (BC) sets during execution of post-installation tasks. You can also skip this step if you have already imported all configuration data you need, but want to add more master data.

Figure 10

Import Configuration Data: Step 2 — Select files containing configuration data

• Step 3. Import data: Kick off import of selected files and review the log files after completion of the import.
• Step 4. Select process type: Master data is imported by process type (Figure 11). If you want to import RAR-related master data, enter the org unit ID of your org hierarchy that becomes the parent org unit for all the business units contained in your export files.

Figure 11

Import Program: Step 4 — Select the process type for Master Data import

• Step 5. Import master data: Works as step 2, but for master data.
• Step 6. Import data: Works as step 3, but for master data.

Post-Migration Tasks

After completing the import you need to execute a number of post-migration tasks. If you imported SAP connectors, the imported program has created a Remote Function Call (RFC) destination for each connector. However, passwords of the RFC users can’t be migrated; rather, you need to enter them manually in transaction SM59. It is also a good idea to check all configuration parameters in the IMG navigating to Governance, Risk, and Compliance > Access Control > Maintain Configuration Settings. Also check whether the connectors are assigned to the correct integration scenario in IMG navigating to Governance, Risk, and Compliance > Common Component Settings > Maintain Connectors and Connection Types / Maintain Connection Settings.

Before you can run an access risk analysis based on the migrated rule set you need to generate the rules by running program GRAC_GENERATE_RULES in the background using SE38. Then, run the synchronization programs for authorizations (GRAC_PFCG_AUTHORIZATION_SYNC), roles (GRAC_ROLEREP_ROLE_SYNC), profiles (GRAC_ROLEREP_PROFILE_SYNC), and user (GRAC_ROLEREP_USER_SYNC). Now you are ready to run your first access risk analysis.

If you were using Condition Groups and Role Approver Criteria in SAP BusinessObjects Access Control version 5.3’s Enterprise Role Management (ERM), you need to manually re-create them as BRF+ rules in version 10.0 of SAP BusinessObjects Access Control.

During the migration version 5.3 of SAP BusinessObjects Access Control’s ERM and CUP role repository (Table 1) are merged into the single version 10 of SAP BusinessObjects Access Control’s Business Role repository. In both, the ERM and Business Role repository roles are attached to a methodology process. However, roles that were imported from the CUP role repository are not attached to a methodology process. As a result, these roles are not editable after the import. Therefore, you need to assign a methodology process for these roles. In NWBC navigate to Access Management > Role Mass Maintenance > Role Update, select all CUP roles, choose All Attributes and Update and, in the next screen, Reapply Role Methodology.

Finally, reimplement all workflows in IMG in Governance, Risk, and Compliance > Access Control > Workflow for Access Control leveraging custom function modules or BRF+ rules as initiators, CADs, and routing rules. This process also includes the template-based configuration of email notifications for all relevant workflow events sent to involved stakeholders.

The Cutover Phase

Once you have validated your data in version 10 and tested all your use cases in scope you are ready for the cutover. From a technical perspective, this refers to the execution of the following activities in your version 5.3 installation:

• Disable all user access
• Complete all background jobs
• Close all open workflow tasks
• Export historic transaction data using the Java data export tool (Figure 12) and keep it available upon request from your auditors
• Shut down the instance

Figure 12

Export of historic transaction data using the Java data export tool

As you disable user access to version 5.3 of your SAP BusinessObjects Access Control instance, you enable it to version 10.0 of your SAP BusinessObjects Access Control instance, and your users start working on the new release.

Frank Rambo, PhD

Frank Rambo, PhD, is managing a team within SAP’s Customer Solution Adoption (CSA) organization working with customers in the SAP analytics area with the objective to drive adoption of new, innovative solutions. Prior to this position, he worked eight years for SAP Germany as a senior consultant focusing on SAP security and identity management. Before he joined SAP in 1999, Frank worked as a physicist in an international research team. He lives in Hamburg, Germany.

You may contact the author at frank.rambo@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.