SAP BusinessObjects GRC 10.0 requires users to connect systems using standard SAP communication protocols. However, this connection method results in a conflict between master data and configuration management. Although master data can be maintained directly in each of the associated systems, it is a good practice for the configuration of these systems to be handled via a more robust change management process (usually via transports in the SAP system). This is a key focus area for auditors and is especially important in the area of security and GRC, as uncontrolled changes can increase the risks to system integrity and compromise the accuracy of compliance reporting.

Connectors are a critical part of the SAP BusinessObjects GRC setup to identify the target systems for all SAP BusinessObjects GRC functionality. In previous versions, the only method to manage these connections was through direct maintenance in the required SAP BusinessObjects GRC system. Although this method was effective in facilitating a flexible system landscape, it often came under fierce criticism from audit and system administrators alike, as it did not adhere to SAP's best practice processes for technical change management.

SAP BusinessObjects GRC 10.0 is managed within the SAP NetWeaver ABAP stack; therefore, it supports the full Transport Management System as per other SAP components. Within SAP BusinessObjects GRC 10.0 the connectors are managed through a combination of standard SAP RFC destinations and additional GRC-specific configuration settings via the IMG.

Transports or Master Data? 

RFC destinations are maintained as master data elements in each individual system and are therefore not transportable. Use transaction code SM59 to create RFC destinations. Figure 1 shows the details of this RFC connection for a specific system (i.e., GRC).

Figure 1

RFC maintenance

Double-click the RFC entry to see the specific system contents (Figure 2).

Figure 2

RFC details

This data identifies the target system to the GRC system through the defined hostname or server address and is maintained directly in each SAP system. The additional configuration settings are part of the standard configuration layer and generate transport requests as standard. Using transaction SPRO and selecting SAP Reference IMG allow access to the configuration hierarchy. The relevant connector settings are located at the following hierarchy menu path: SPRO > SAP Reference IMG > Governance Risk and Compliance > Common Component Settings > Integration Framework. Figure 3 shows the available connector configuration settings.

Figure 3

GRC Connector configuration nodes

Thus, there is an inconsistency in managing connectors because the transportable configuration has a dependency on client- and system-dependent master data settings.

Maintenance Options 

As with most SAP systems, there are numerous options to manage this dependency.

Option 1: Direct Maintenance of Connector Settings Throughout the Landscape 

Option 1 allows administrators to make changes directly in the SAP system. It bypasses the Transport Management System completely and relies on manual configuration of the required settings throughout the landscape. This option aligns with the maintenance strategy employed by the previous releases of the SAP BusinessObjects GRC product while in the SAP NetWeaver Java 2 Platform Enterprise Edition (J2EE) stack. This option enables the landscape to be flexible so that only those target systems that are required are configured and visible to users. However, this method of configuration does not align with system management best practices, and managers and auditors may challenge it as noncompliant.

Option 2: Full Transport of All Settings 

Option 2 is almost the complete opposite of option 1 whereby all connector settings are managed via transports where possible. To achieve this type of connection method, the full system landscape is identified in the SAP BusinessObjects GRC development system and transported throughout. Thus, all the RFC destinations are maintained in all systems as a one-time exercise. The naming convention must match throughout the landscape in order to avoid inconsistencies and potential errors at the point that the transports are imported. This option benefits from using a controlled configuration strategy and allows for consistency in the case of a production system refresh. However, it affects users by having the entire SAP system landscape visible for selecting and reporting from the SAP BusinessObjects GRC production system.

Option 3: Multilayered Transport – Tier by Tier 

Option 3 enables control of the systems that are available to users in the production system, yet still manages the changes via transports. Effectively, it requires configuring the development system as if it were the SAP BusinessObjects GRC production system first, then repeating the exercise for the pre-production systems using the following tasks as a guide:
• Create dummy RFC destinations in SAP BusinessObjects GRC development to match the specific naming convention for the production source systems (i.e., have invalid hostnames stored in the RFCs).
• Adjust the SAP GRC development system connector settings to match only the required SAP BusinessObjects GRC production settings.
• Save these settings into a transport.
• Go to SAP BusinessObjects GRC production and set up the RFC destinations with exactly the same definition as in the SAP BusinessObjects GRC development system (i.e., the correct hostnames in the RFC destination).
• Release the transport and import to the SAP BusinessObjects GRC production system. (This activity allows the SAP BusinessObjects GRC production system to have the appropriate connector settings for the relevant source systems and the locally maintained RFC master data allows the RFCs to exist and connect to the appropriate systems.)
• Return to the SAP BusinessObjects GRC development system and adjust the connector settings to point to the correct pre-production and development source systems. 
• Save these settings into a new transport request that is marked as DO NOT TRANSPORT or deleted to prevent the contamination of the production system.

This process manages the system landscape effectively; however, the main disadvantage of this option is that for any systems in the transport path to production, the transports have to be orphaned. In other words, some transports are released from development, but should not be imported to production. This option may contravene transport strategies that mandate that all released transports should be imported into production. Depending on the individual customer standards, you may be able to maintain these pre-production systems directly as a master data update after the initial production transport has been migrated through to production, as with option 1.

Table 1 lists the pros and cons of using each of these three options.

Table 1

Transport options summary

Each of the options has its own merits, but also its own drawbacks. Depending on the individual organization's risk appetite and control environment, a case can be made for any of the approaches.

In my opinion, the multilayered transport approach outlined in option 3 has the best mix of control and pragmatism to present a clean view to the users. It does require some forethought during the initial setup and some master data maintenance for the pre-production environments but, as a compliance solution, it is the best one available.