SAP Business Objects GRC 10.0 Automated Monitoring Overview

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2011 SAP AG

Applies to:

SAP® Business Objects™ Process Control/SAP Process Control release 10.0 and later

Summary

Automated Monitoring of business process controls is a key feature of SAP Business Objects Process

Control (PC) 10.0, and a fast-evolving feature category in the market. SAP has considerably enhanced this

part of GRC with release 10.0, and continues to invest in this area. This document presents an overview of

the monitoring features of PC 10, and references other documents which provide a more detailed guide to

different monitoring methods available.

This document also serves to explain the rationale behind the many different monitoring methods available,

and advises customers and partners when to use which technique.

Author(s): Atul Sudhalkar

Company: Governance, Risk, and Compliance

SAP BusinessObjects Division

Created on: 1 December 2011

Last updated: 23 May 2018

Version 0.96

SAP Business Objects

Process Control 10.0

Automated Monitoring Overview


© 2011 SAP AG

Document History

Document Version Description

0.1 Briefing document prepared for internal (KM) audience

0.2 Much expanded version, intended for partners & customers. But

overview, not details: those are in separate how-to guides being drafted

concurrently.

0.3 Added placeholder sections for programmed, external partner and other

DS/BR types which require further explanation/details.

0.3a Cleaned up doc for external reviews.

0.4 Added sections on programmed and external partner data source types,

and brief descriptions of planning. This completes a first pass through

the document—although the programmed, PI and web services sections

could do with some additional information. That’s pending some more

information from products/development. The “prerequisites” section is

also empty, awaiting feedback on whether to include details on setup

and configuration in this overview, or to defer that to detailed user

guides.

0.5-0.7 Incorporated changes suggested by Jackie Wang and Aman Joshi

(PWC). Created entire section on configurations.

0.92 Fixed terminology confusion between GRC, PC, AMF and CCM (Paul

Davis’ feedback). Also expanded the external partner data source

section to include key information on the API partners need to

implement. Incorporated MZ’s comments (for the most part—still

planning to add an example or two to section 4.2

0.93 Incorporated Jackie’s comments on 0.8.

0.95 Added cautionary note to BRF+ integration section, per Daniel Chang’s

feedback. Also added two examples of rules to the appendix.

0.96 Redacted potentially sensitive information.


© 2011 SAP AG

Typographic Conventions

Type Style Description

Example Text Words or characters quoted

from the screen. These

include field names, screen

titles, pushbuttons labels,

menu names, menu paths,

and menu options.

Cross-references to other

documentation

Example text Emphasized words or

phrases in body text, graphic

titles, and table titles

Example text File and directory names and

their paths, messages,

names of variables and

parameters, source text, and

names of installation,

upgrade and database tools.

Example text User entry texts. These are

words or characters that you

enter in the system exactly as

they appear in the

documentation.

<Example

text>

Variable user entry. Angle

brackets indicate that you

replace these words and

characters with appropriate

entries to make entries in the

system.

EXAMPLE TEXT Keys on the keyboard, for

example, F2 or ENTER.

Icons

Icon Description

Caution

Note or Important

Example

Recommendation or Tip


© 2011 SAP AG

Table of Contents

1. Business Scenario............................................................................................................... 1

1.1 The SAP Business Objects GRC Solution ................................................................... 1

1.2 Automated Monitoring .................................................................................................. 1

1.3 Usage: Planning and Testing ....................................................................................... 2

1.4 Usage: Monitoring......................................................................................................... 2

2. Background Information ..................................................................................................... 3

2.1 Automated Monitoring Overview .................................................................................. 3

2.2 Queries and Events ...................................................................................................... 3

2.3 Data Sources ................................................................................................................ 4

2.4 Business Rules ............................................................................................................. 4

2.5 Architecture ................................................................................................................... 5

2.6 The Business Context .................................................................................................. 6

2.7 Planner ......................................................................................................................... 6

2.8 Scheduler ...................................................................................................................... 6

2.9 Event Monitor ................................................................................................................ 6

2.10 Legacy Automated Monitoring ...................................................................................... 6

3. Prerequisites ........................................................................................................................ 7

3.1 Systems Installation and Activation .............................................................................. 7

3.2 Post-installation Configurations .................................................................................... 8

3.3 Master-data Preparation ............................................................................................. 14

4. Monitoring Methods .......................................................................................................... 15

4.1 Data Sources and Business Rules ............................................................................. 15

4.1.1 Design-time .................................................................................................... 15

4.1.2 Runtime .......................................................................................................... 33

4.2 Data Source and Rule Types ..................................................................................... 35

4.2.1 SAP Query Data Sources and Rules ............................................................. 35

4.2.2 Configurable Data Sources and Rules .......................................................... 36

4.2.3 BW Query Data Sources and Rules .............................................................. 45

4.2.4 ABAP Report Data Sources and Rules ......................................................... 46

4.2.5 Netweaver Process Integrator-based Data Sources and Rules .................... 46

4.2.6 Web Services-based Data Sources and Rules.............................................. 47

4.2.7 SoD Data Sources and Rules ........................................................................ 47

4.2.8 Event-driven Data Sources and Rules ........................................................... 48

4.2.9 ABAP Programmed Data Sources and Rules ............................................... 48

5. Frequently-asked Questions ............................................................................................ 48

6. Appendices ........................................................................................................................ 49

6.1 Appendix A - Configurable Rule Example .................................................................. 49

6.2 Appendix B - Change Analysis Example .................................................................... 54

6.3 Appendix C - Performance Impacts of Change Logging ............................................ 63

7. Acknowledgements ........................................................................................................... 65

8. Copyright ............................................................................................................................ 66

SAP Business Objects GRC 10.0 Automated Monitoring Overview

May 2018 1

1. Business Scenario

1.1 The SAP Business Objects GRC Solution

The topic of Governance, Risk and Compliance Management covers many enterprise-wide

perspectives, including regulatory compliance, risk measurement and mitigation, monitoring to ensure

good governance, and other similar concerns. The assumption is that the basic business processes

necessary for running any business—purchasing, sales, hiring and promotion, etc.—are already in

place. Today’s managers have a different set of questions to answer, which are more difficult

because they are not so well understood or addressed as the core processes. SAP BusinessObjects

Governance, Risk and Compliance (GRC) solutions attempt to answer these in a way that can be

scaled across the organization and stay with SAP customers as they grow in sophistication in their

practice of GRC.

1.2 Automated Monitoring

This document focuses on one specific aspect of GRC: automated monitoring of backend systems

and processes. Customers of GRC use automated monitoring in many situations, covering

configurations, master data and transactions; SAP BusinessObjects Process Control 10.0 (PC)

provides a range of techniques to address these needs. While particularly well-suited to monitoring

SAP’s backend applications, PC provides a sound platform for monitoring other applications as well.

Such other applications include ERP and related software suites from other vendors, but can also

include IT management, physical access management, software used for tracking movement of goods

and managing logistics, and so on.

SAP partners also provide products which integrate with SAP GRC products to provide joint solutions

for diverse needs. Many such solutions are showcased on the SAP Ecohub website. Some of these

are relevant to automated monitoring with PC, but this document focuses on the monitoring

capabilities in PC 10.0, while calling out features that facilitate integration with partners.

SAP GRC is also actively working to define joint solutions in tracking employees’ training and

certification status in sensitive jobs (HR LoB), risk management for Banking (Banking and Finance

Industry Solutions), and so on. Most such solutions include automated monitoring as a key capability,

and these solutions provide configuration content for PC and Risk Management products that are

focused on automated monitoring.

The following figure depicts how GRC fits into the corporate IT landscape, and into a corporate

governance and compliance strategy.


May 2018 2

Note that, in this view, monitoring is front and center in any effective GRC practice. The possible

solutions shown at the top of the picture include content plays which might involve joint solutions with

other divisions within SAP, partnerships with other software vendors, or a partnership with consulting

partners who provide domain expertise by industry, region, or line-of-business practice.

1.3 Usage: Planning and Testing

The Planner module of PC 10.0 helps control owners and testers test the effectiveness of existing

controls, and plan compliance activities over a specified period. Tests of effectiveness can be manual,

using well-understood procedures, but these can also be semi- or fully automated tests. The

techniques described in this document can also be used to perform some controls, and can help

control owners gather information relevant to performing their jobs.

1.4 Usage: Monitoring

Beyond the Auditors’ perspective in testing controls, there are many situations in which customers

want to ensure that business processes meet their expectations. As explained in this document, PC

enables customers to capture their expectations of how these controls should be configured, and how

transactions should occur. Correct configurations ensure that business process steps that those

configurations control will always comply with customers’ intentions; broader transaction monitoring


May 2018 3

can then be used to cover those situations where configuration-based controls are not enough, or to

look for fraud at the margins.

In a sense, automated (or semi-automated) monitoring can also help individuals perform the control

function. For instance, a person responsible for reviewing and approving purchases might want to

look at background information on the requester, vendor, pricing trends, etc. before making a decision.

Workflow can route the requisition itself to his or her inbox, but PC automated monitoring can provide

the additional information needed to actually reach good decisions.

2. Background Information

2.1 Automated Monitoring Overview

To monitor any system in your IT landscape, PC first has to be able to extract data from it. The data

could be anything: configurations, master data, transactions, usage logs, or any state held in memory

or persisted by the remote application. GRC must know the location of the system, how to reach it

(the communication protocol), how to authenticate itself to the remote system (login credentials),

where in the system the data of interest resides, and so on.

The previous figure graphically depicts the complete process for setting up and using automated

monitoring in PC 10.0. The remainder of this document will focus on only the first step: defining Data

Sources and Business Rules. Along the way, though, features are called out which help tie these

rules into the overall context in which they run, and for that reason you may find it helpful to refer back

to this figure at various points along the way.

2.2 Queries and Events

The monitoring methods available to PC customers fall into one of two broad classes: query-driven or

event-driven. PC initiates query-driven monitoring, typically via the scheduler. This is why some

practitioners also call it schedule-driven monitoring, although that is somewhat of a misnomer: such

monitoring can also be initiated by the planner, or by a user on an ad-hoc basis. The key


May 2018 4

characteristics of these monitoring methods are that the monitored system is passive—all action is

initiated from the PC side. The data might come from a query, a report, a function invocation, or from

any other technical source, but the semantics are those of a query: PC invokes a particular source

(query or otherwise), passes context parameters to it, and receives back data of a known schema.

Event-driven monitoring, by contrast, is not initiated by PC. An external system decides when

something is significant enough to be communicated to PC, and initiates data transfer by raising an

event. PC treats such events as data sources much the same as a query-driven data source, and

makes the event details available to business rules for further evaluation. Partners have explored this

interface to help customers monitor and remediate problems such as inappropriate network traffic or

unusual usage patterns in application logs.

2.3 Data Sources

To encapsulate information about the monitored system, PC has specialized objects called Data

Sources. Data sources come in many variations (described below), to match the many different types

of information customers might want to extract, from different types of monitored systems. But as PC

Data Sources, they also present a uniform look-and-feel to the rest of PC, so that the variability of the

different types is hidden from the higher levels of the monitoring function.

PC leverages many standard tools in the Netweaver ABAP (“Basis”) stack, such as RFC destinations,

RFC services, web services framework, etc. Section 4.2, Data Source and Rule Types, describes all

the types of data sources supported in PC 10.0 and their characteristics, and briefly discusses the

situations in which each would be suitable.

2.4 Business Rules

Data extracted by such data sources also can be made more business friendly, by hiding the technical

details and giving more descriptive names and appearance to the data they extract. Such business

user friendly data is then made available to Business Rules, which then determine whether the data

presented represents a problem requiring remediation. Business rule definitions can be simple (“A

one-time vendor should not be used more than once in a quarter”) or involve additional calculations,


May 2018 5

grouping and aggregation (“Total spend on a one-time vendor must never exceed $10,000”), complex

logic, or even specialized user-defined functions.

Again, PC leverages NetWeaver tools: the rule engine uses Business Rule Framework (BRF+)

(previously known as Formula Derivation Tool or FDT). Section 4.2, Data Source and Rule Types,

describes how rule characteristics vary depending on data source types, and the implications of each.

2.5 Architecture

This document give a high-level overview of architecture for business users of SAP BusinessObjects

Process Control 10.0.

Section 2.1 gave an overview of the end-to-end process of defining monitoring rules and using them in

GRC PC 10.0. But as most of this document focuses on the first step: defining data sources and

business rules. That is because the first step is unique to automated monitoring, while the remaining

steps are more about all the other PC functionality.

The following figure is a conceptual diagram of the architecture.

Monitored systems are backend applications such as SAP ERP, CRM, etc. For legal reasons, this

document uses only SAP applications in examples of monitored systems, although PC 10.0 can be

and is successfully used to monitor a wide selection of non-SAP backend applications.

Data sources are PC abstractions which connect to specific queries and programs in monitored

systems. Data source definitions can be configured to connect to multiple systems, although each

actual invocation of a data source must be configured against only one specific system. There are

nine different types of subscenarios which have dedicated data sources supported in PC 10.0.

Business rules encode the actual monitoring logic the rule designer wants. A business rule is

designed to work against one data source (although one data source can serve more than one

business rule). That’s because the rule engine (in which rule designers express their monitoring

intent) needs to know which fields are available for building the rule, and that depends on the data

source being used.

The purpose of a Data Source object in GRC is to know how to talk to an actual data source (such as

a query) in a remote system, and provide the data to associated rules. In ABAP, the standard


May 2018 6

mechanism for doing this is by means of a system connector, which is defined in the SM59

transaction.

2.6 The Business Context

Customers use PC 10.0 to perform and test controls, and to monitor configurations and master data

settings. In this document, the term “monitoring” is used as a simple proxy for all such activities. In

PC master data structures, such controls are defined in the context of specific business processes and

organizational structures. More precisely, even more global “central” controls are expected to be

instantiated in a “local” context before they can be monitored.

On the other hand, monitoring rules are usually very similar across different organizational units, and

can often be shared between different business processes. A monitoring rule for purchase requisition

approvals, for instance, could be relevant to a budgetary control for purchasing, but also for financial

controls for accounts payable. Such rules re-use makes maintenance much easier.

To enable this, controls are monitored by assigning rules to the “local” incarnations of controls. The

business process and organizational unit associations of local controls provide the business context,

and the control’s timeframe sets the time boundaries for the monitoring rule. PC allows customers to

use these environment variables, historically called Organization-Level System Parameters (OLSP). A

better term would be environment variables or context variables.

The idea is that monitoring rules should not assign explicit values to parameters in the query for

company codes, plant codes, purchasing organizations, sales organizations and the testing period.

Instead, PC binds values to most of these parameters from the context, or OLSP. Test period end

dates come from the scheduler.

2.7 Planner

Use of monitoring rules via the planner is similar to their usage through the scheduler, with one

difference: the scheduler allows repeated execution of monitoring rules on a schedule, while the

planner permits only a single execution.

2.8 Scheduler

Monitoring rules can also be used for configuration, master data and transaction monitoring. For

controls which reside in backend systems, PC monitoring can ensure that the control’s configuration is

correct; for transactions which lack a built-in control, PC can catch improper transactions.

The scheduler allows users to fire rules (strictly, all rules assigned to a control in the context of a

business process, org unit and regulation) on a specified schedule and frequency.

2.9 Event Monitor

The PC Event Monitor is the complement of the Scheduler. As is explained in section 4.2.8, Event-

driven Data Sources and Rules, not all data sources are triggered on a PC-specified schedule. PC

provides an event interface, by which external systems can decide when a transaction or combination

happens which needs to be presented to PC for monitoring. In such cases, PC only needs to wait for

such events to be communicated to it via an event interface.

The purpose of the Event Monitor is to allow users to instruct PC which events they want PC to be

prepared to receive via the Event Monitor.

2.10 Legacy Automated Monitoring

The previous release, PC 3.0, had a reasonably powerful monitoring engine. More than 150

monitoring rules were delivered with the product, many of them GRC ABAP reports deployed on


May 2018 7

backend ECC systems to be monitored. Many customers customized these delivered rules, or

created their own.

PC 10.0 represents an advancement in monitoring capabilities in response to customer demands. To

ensure continuity of functionality for PC 3.0 customers who upgrade to 10.0, and to protect their

investment in any custom rules, PC 10.0 includes a compatibility module which runs PC 3.0 rules

without modification. Any rules present at the time of upgrade from PC 3.0 (SAP-delivered,

customized or customer defined) will continue to work as assigned to controls, and as scheduled.

Furthermore, customers can use the new features in PC 10.0 automated monitoring for creating new

rules even as they continue to use old PC 3.0 rules through the Legacy Automated Monitoring rules

compatibility module.

3. Prerequisites

3.1 Systems Installation and Activation

GRC PC 10.0 software should be downloaded from SAP Service Marketplace, and installed on a

Netweaver 7.02 system (check SAP Service Marketplace for up-to-date information). For automated

monitoring, the GRC BusinessObjects Process Control 10.0 (PC) application must be activated, as

shown in the figures that follow.


May 2018 8

It is assumed that a backend application system already exists that you wish to monitor. As stated

previously, the examples in this document use SAP applications. However, PC 10.0 can be used to

monitor any system, although additional middleware may be necessary.

3.2 Post-installation Configurations

To monitor backend systems, most of the customization work happens in connector configuration.

The following figure depicts the steps needed.

Creating RFC destinations (called “connectors” in GRC) is standard Netweaver functionality, accessed

via transaction code SM59. With such connectors, you then configure PC to know which connectors it

should use for automated monitoring. The following figure shows the transaction SPRO in the PC

system.


May 2018 9

Use the path Governance, Risk and Compliance Common Component Settings Integration

Framework. The first of the links in the highlighted box, Create Connectors, is a shortcut to SM59 for

creating or maintaining connectors.


May 2018 10

The next link, Maintain Connectors and Connection Types, takes you to the following screen.

The three highlighted connector types are of interest in automated monitoring. Local system

connectors are used to integrate with the SAP BusinessObjects Access Control application for

monitoring segregation-of-duty violations (see section 4.2.7). Web service connectors are used for

external partner data sources (see section 4.2.6). SAP system connectors are used in all other cases.

The next step is to define which of the connectors previously defined in SM59 can be used in

monitoring.

In the system used to capture the screenshot examples, SMEA5_100 is a connector to an ECC

system. Note in particular the third column that lists the name of a connector which is defined in the

monitored system, and which is configured to point back to the GRC system being configured here.

That is, in the highlighted row, SMEA5_100 is a connector in the GRC system, and it points to an ERP

system which is to be monitored. SM2 is a connector on the (remote) ECC system, which points back


May 2018 11

at this GRC system. The GRC plug-in in the monitored system uses this “source connector” to call

back with results of monitoring in some situations. For the most part, PC users need not be

concerned with when such callbacks need to happen (see the Technical Settings subsection in section

4.1.1.2), but it is necessary to complete the configuration step.

Next examine the Define Connector Group screen, as shown in the following figure.

No configuration should be needed here, but it is shown for context. All the connector configurations

for automated monitoring should belong to the configuration group called Automated Monitoring

(shown highlighted).

Return to the Define Connectors screen, and the system connector used for your monitored system.

In the example, that connector is SMEA5_100, which points to an ECC system.

Now choose the link Assign Connectors to Connector Groups.

Assign the connector in question to the “AM” connector group.


May 2018 12

Next choose Maintain Connection Settings, as shown in the following figure.

A screen displays, asking which Integration Scenario you want.

Choose “AM” for automated monitoring. The following page displays.


May 2018 13

The highlighted box shows nine entries called “sub-scenarios”—these are different types of data

sources and business rules supported in GRC PC 10.0, and covered in more detail in section 4.2,

Data Source and Rule Types. To create a specific data source type (say, “configurable”) for a system

to be monitored, the corresponding connector must be “linked” to that sub-scenario. Select the sub-

scenario you want (“configurable” in the example), and then choose Scenario-Connector Link in the

left-hand panel, as follows.

The following screen displays.


May 2018 14

If the connector you want to use for that scenario is not already in the list for that sub-scenario, choose

New Entries to add it. We recommend the following pattern for convenience.

System Type Sub-scenarios to enable for system connector

ABAP applications such as ERP, CRM,

etc.

ABAP Report, SAP Query, Configurable, Programmed

SAP Business Warehouse BW Query

Non-SAP system which is web services

enabled

External Partner (also known as web services, or GL-

MQT)

Netweaver Process Integrator (for

connecting to other systems)

PI

Same GRC system SoD Integration

Note that the Event sub-scenario is not in the table. GRC receives events via a special Web services

interface (different from the one used by the Web services data source type above). This is handled in

more detail in section 4.2.8.

3.3 Master-data Preparation

Before monitoring rules can be scheduled to run, they must be hooked up to the regulations, controls,

business processes, etc. which are master data for PC.

NOTE: Setting this information up is a prerequisite for using automated monitoring, but it is not

exclusively related to automated monitoring. For more information, see the PC documentation.


May 2018 15

4. Monitoring Methods

This section explains the overall process of defining monitoring rules, and implementing them against

backend systems. It discusses in detail the differences between the many supported techniques (sub-

scenarios), and explains when to use them.

The goal of this document is to give only an overview of automated monitoring in PC 10.0 without

some of the details of design-time activities. This document focuses on explaining the features rather

than the details of the design itself.

4.1 Data Sources and Business Rules

Section 1.2 includes a graphic of the overall monitoring process. This section describes in much more

detail the first step in that figure: defining data sources and business rules.

Data Sources in PC 10.0 encapsulate many different ways PC can extract data out of monitored

systems, while still presenting a uniform interface to rule designers who want to filter and manipulate

the data they extract. Business Rules hold the processing logic for such filters, calculations and the

logic to determine if any extracted data represents a problem which control owners need to review or

remedy.

In PC 10.0, many of the key monitoring capabilities come from the wider range of data source types

available to users, and the increased power and sophistication of those types previously available in

PC 3.0.

Most of the other advances lie in the flexibility and power of the rule engine used to define Business

Rules. As said previously, the rule engine in PC 10.0 is the Netweaver BRF+ engine, with a

specialized user interface (UI) for routine usage in PC.

4.1.1 Design-time

The overall process of creating data sources and business rules is the same for all the varieties

described in further detail in section 4.2. There are, of course, variations but the overall process has a

strong underlying theme.

All design-time user interfaces are located under “Rule Setup” in the top-level toolbar, as highlighted in

the following figure.

The Rule Setup user interface may contain many sections, depending on your role and how it is

configured in your system. The following figure shows only the Continuous Monitoring section, which

may be one of several sections visible to you..


May 2018 16

4.1.1.1 Creating Data Sources

Choose Data Sources in the previous picture. The Data Sources screen displays. The screen lists the

data sources previously configured in this system. You can create a new data source by choosing the

Create pushbutton.

A Data Source is defined across three tabs, of which the first two are significant to the functionality

itself. The third tab is purely for documentation and links to outside systems.

Name and Description: The Data Source name should be something descriptive which will help you

to find the data source, and help document its purpose. The description can expand on the name, but


May 2018 17

we suggest that the name itself should be constructed to be as useful as possible. Note that like many

data types in Process Control and Risk Management applications, the name itself is not a key field in

the database sense, and PC does not enforce uniqueness of names. The key for most of these

master data types is a generated number, which is can be seen in the first figure of section 4.1.1.1 as

the column titled Object ID.

Validity Dates: Validity dates determine the range of dates over which data sources, rules, controls,

and so on, can be put to use in monitoring. The “Valid From” field defaults to today’s date, and the

“Valid To” date defaults to infinity (that is,12/31/9999). Carefully consider the values you save here—

picking odd dates is more likely to constrain your use of monitoring rules later. If you do not have

clear reasons to pick a specific validity start date, it would be wise to use the first of the year (or the

first of any earlier year).

Status: Data sources start with the status “New”. You can change most attributes of the data source

while it is in this status, but you cannot use it to support rule creation or any other downstream activity.

From “New”, a data source can be changed only to “In Review”; after review, it can become “Active”,

which is the state in which it can be used to create monitoring rules.

Search Terms: These are tags which can help in finding the right data sources, for instance when you

want to update or edit a data source, or you want to find one to reference when creating business

rules. The list of tags available is set up during customizing. You can assign up to five tags for most

master data elements, but they can be chosen only from the drop-down list, which in turn only includes

terms created during customizing.

Use the Object Field tab to define more functionally relevant attributes of the data source.

The “Sub Scenario” dropdown list shows nine options; these are the different types of data sources

available in PC. These are described further in section 4.2, Data Source and Rule Types.

From an end-user perspective, the job of a Data Source in GRC is to provide a business-user friendly

view of technical data sources (such as tables, fields, views, queries, reports, etc.) in monitored

systems. In keeping with this objective, you can replace the default descriptions with more descriptive

text. For instance, the following figure shows the vendor master table LFA1.


May 2018 18

The short description field is not always very descriptive, so PC 10.0 allows rule designers to replace it

with something more meaningful. The highlighted column shown in the following figure is editable,

allowing the designer to replace the default text with something better suited.

Connectors

For most sub-scenarios, you must define a “main” connector that points to the backend system

against which PC will try to validate your definition. The only exceptions are the SoD Integration (see

section 4.2.7) and Event (see section 4.2.8) sub-scenarios.

It is important to understand that the only purpose of the “Main Connector” is to validate the data

source definition, and to provide helpful prompts and value help, where available, during data source

and rule design. You can add additional connectors, since it is recommended that you define and test

monitoring rules against test systems before finally putting them into production against production

backend systems.


May 2018 19

The following figure shows the Attachments and Links tab.

4.1.1.2 Creating Business Rules

Business rules filter the data stream coming from data sources, and apply user-configured conditions

and calculations against that data to determine if there is a problem which requires attention. In PC

this is called a deficiency.

The nature of the business rule depends strongly on the data source type, which is why the process of

creating a business rule begins with data source selection, as shown in the following figure.

Unfortunately, this makes it difficult to give a general overview of business rule creation. The following

screenshot shows the full range of power in a business rule, but this range is available only with a few

data source types. Section 4.2, Data Source and Rule Types, describes the individual data source

types and their corresponding business rule types.


May 2018 20

Basic Information

The name, description, validity dates, status and search terms fields are exact analogs of the

corresponding fields in data sources, which were described in 4.1.1.1, Creating Data Sources, and will

not repeat here.

The Category and Analysis Type fields are dependent on the data source type, and are addressed in

section 4.2, Data Source and Rule Types.


May 2018 21

Data for Analysis

A data source offers several fields for the business rule to use in filtering or finding deficiencies. Since

many business rules might use the same data source (in fact, we recommend that as a good practice),

it is likely that any one business rule might only want to use a few of the fields offered by the data

source. This screen lets you pick the ones of interest, simplifying your downstream tasks.

In the Programmed data source/rule type, this step is skipped, as explained in the following sections.


May 2018 22

Filter Criteria

Of all the business rule fields picked in the previous step, some will be useful mainly in filtering out

data that is not of interest. The most common situations involve transaction dates (you may be

examining only those transactions posted in the last quarter, for instance), company codes,

transaction types, and so on. You should pick such fields as filters, and define filter conditions against

them. This is a standard SAP screen and is common to many applications.

Note: The appearance of the top part of this screenshot above differs from the previous screenshots in this section. This is because previously created rules were used to illustrate the remainder of this document. The tabs correspond one-to-one with the steps in business rule creation, with matching names.


May 2018 23

Deficiency Criteria

A deficiency is a condition which requires human attention. This section of the business rule lets you

define such conditions. There are two main ways to do this: you can treat everything pulled back by

the data source as requiring human review (analysis type Review Required, described below in

section 4.2.4, ABAP Report Data Sources and Rules), pick a specific field and define a logical

condition against it (for example, document amount exceeding a set limit), or define a calculated field

deficiency, which represents an arithmetic/logical operation on any of the available fields. Calculated

fields are explained fully in the next section.

For all such deficiency criteria, you can choose a value check or blank check. Blank check restricts

you to say whether a field should be populated or blank. Value check assumes the field has a value,

and allows you to define a wide range of conditions using the usual logical operators such as equal to,

less than, between, and so on.

You can define three conditions, corresponding to three levels of deficiency: low, medium and high.

The Deficiency Description column allows you to configure what to call each deficiency level.

Note that the previous screenshot shows two deficiency criteria. It is possible to have multiple

deficiency criteria, each possibly with their own calculations. The rule interprets these criteria as a

logical inclusive OR: each row of data returned by the data source (and, of course, matching filter

criteria) is evaluated separately by each deficiency criterion. A row of data is judged deficient if any of

the criteria classify it as such.

We recommend that a separate deficiency be defined when there are multiple criteria, each of which

has its own conditions. PC 10.0 reports data rows which match a deficiency condition grouped

together by that deficiency condition, making it easier for control owners to understand the problems

and act upon them. In the previous example, it would have been technically possible to compound the

logical conditions into a single deficiency, but harder for the control owner to subsequently interpret

and act upon.

Conditions and Calculations

Use this tab to define the calculations necessary to compute the value of a “calculated field”

deficiency.


May 2018 24

GRC PC 10.0 uses BRF+, the standard Netweaver rule engine, to allow users to define calculations.

You can configure very powerful processing using this rule engine, and the goal was to make it easy

to configure relatively simple rules (calculate an average of two fields, say, or compare two dates), and

yet provide a path to configure more complex rules if needed.

The “Calculations” tab (or corresponding wizard step when creating the rule) allows three types of

calculations: a Field Value calculation, a currency conversion, or grouping and aggregation (as shown

in the following screenshot).

Field Value Calculation

PC 10.0 provides a simplified user interface for relatively simple conditions and calculations, and

advises customers to use the full BRF+ workbench to define more complex calculations. For full

documentation on BRF+ and the BRF+ workbench, consult the NetWeaver documentation.


May 2018 25

The following screenshot shows the simplified GRC user interface to BRF+ functionality.

One important restriction is that the definition of a calculated field in the deficiency criteria screen

(above) is one-to-one related to the definition of the calculation itself in the conditions and calculations

tab. This means that any significant computation which requires intermediate variables is too complex

to handle here—it would be necessary to define such complex rules in the BRF+ workbench.

One decision method offered by BRF+ is directly incorporated into the PC rule interface: the decision

table. This is called a “pattern” in the PC 10.0 interface, and is available only for the change log check

category of business rule. The point of using a decision table is to enable multi-field deficiency criteria

via logical combinations. The decision table is standard BRF+ functionality, incorporated into our UI.

This is explained more fully in section 4.2.2.1, Change Log Data Sources and Rules.


May 2018 26

Currency Conversion

A key feature of the PC 10PC rule engine is the ability to convert currency amounts. This feature uses

core Netweaver support for currency conversions, and leverages the same underlying currency tables

and features as used in ECC, CRM and other SAP applications.

To use this feature, a deficiency criterion must be of type Amount, and the same must be true of one

of the fields available in the rule.


May 2018 27

The following screenshot shows a deficiency field of type Amount. Notice that the deficiency is not

directly one of the rule’s fields (from the Data for Analysis tab/wizard step); rather, it is a “calculated

field”, created by choosing the Calculated Field pushbutton.

For that deficiency, the next tab (or next step in the creation wizard) lets you define the actual

calculations (as shown in the following figure).

Grouping and Aggregation

The screenshots in the section on Currency Conversion also include grouping and aggregation. The

other deficiency in that example, Total Number of Payments to One-time Vendors, is intended to find


May 2018 28

the number of payments made to each one-time vendor, and then apply the configured thresholds to

determine if that violates policies.

The calculations tab (or wizard step) shows how this is setup.


May 2018 29

The grouping is on Vendor number, and the aggregation method used is Count—which simply counts

how many times each vendor (the grouped-by field) appears in payments.

Grouping and Aggregation can also be combined in sequence with other calculation methods. The

deficiency criterion of the previous example looks at the total amount paid to each one-time vendor,

and it does so by first converting the amount into a standard currency (US Dollars in the example),

and then groups by vendor and totals the (converted) amounts.

Notice that the grouping/aggregation calculation is the second in the sequence, with currency

conversion being first—we want to convert to a single currency before adding.

BRF+ Workbench

To leverage the full power of BRF+, first create a stub PC Business Rule, and use the generated rule

ID (not the name—see section 4.1.1.1, Creating Data Sources).

Accessing the BRF+ workbench depends on your system setup (NWBC, Portal, and so on.) For this

document, BRF+ was launched from SAPGUI by using transaction code BRF+. First you must know

the technical ID of the rule you created, which you can see in the following screenshot of the GRC PC

Business Rule finder page. The technical object ID of each rule is displayed in the left-most column.

This technical ID serves as the base, or first part, of the BRF+ rule ID in the BRF+ workbench. The

easiest way to find the corresponding BRF+ rule in the BRF+ workbench is to paste this ID, add the

wildcard character ‘*’ to it, and then search. In the left-hand panel of the BRF+ workbench screenshot,

there are two BRF+ rules with the same base ID as the GRC PC 10 rule. This is because BRF+

creates new versions of every such rule each time it is changed. In general, you would want to use

the last version, which would be sequentially the highest number in the list of matching rules.

Having found the rule in BRF+ workbench, you can now enhance it to include any BRF+-supported

logic.


May 2018 30

Note: The above information is provided to enable you to define more powerful processing rules in BRF+ workbench, as needed. Note that this requires great care in design and implementation. BRF+ is extensible in many ways, and at the extreme end you will essentially be writing code. Whatever custom processing you define, you must take care not to change the input and output parameters—those are used in the integration between PC and BRF+. You must test the custom BRF+ rule to make sure it does what you want, and that the performance impact is acceptable.

Output Format

This section is common to all business rule/data source types, and arranges the output of any

detected deficiencies in the left-to-right column order specified. You can also hide unwanted columns

here.


May 2018 31

Technical Settings

These primarily affect the execution and performance of monitoring. Most data sources (although not

all) will allow users to cap the maximum amount of data they will process, as a performance

management feature. Since performance can be difficult to predict and manage—too much depends

on the size of tables, network issues, etc.—we strongly advise all customers to test the performance of

any monitoring rules before putting them into production.

Note that most monitoring rules can be run in synchronous or asynchronous mode.

Ad hoc Query

As you define some types of data sources and business rules, you can run them to test if they are

working correctly. This is useful for configurable business rules and data sources, which are designed

and implemented directly from the GRC PC 10.0 user interface. For programmed, SAP query, ABAP

Report. and other data source and business rule types, these are not as useful, since the key design

and testing activities for those types occur elsewhere, and GRC PC 10.0 mainly reflects the

implementation done elsewhere.

For configurable rules, however, ad hoc queries are very useful indeed. The following screenshots

show two modes of ad hoc query operation: one that collects the data as the data source would, and

another that applies the rule logic to filter the data and then apply deficiency logic.


May 2018 32

Attachments and Links

This part is the same as in Data Sources, described previously.

4.1.1.3 Assigning Rules to Controls

Monitoring rules need to be assigned to local controls. The mechanics of the process are briefly

described here.

The Business Rule Assignment link brings up the following page.

The search widget at the top of this page lets you search for local controls—that is, controls assigned

to a particular organization node. The next step is to select it in the middle part of the screen, by

clicking on its row. You then modify the business rules assigned to it by choosing the Modify

pushbutton, and then choosing the Add pushbutton in the bottom portion of the screen. A screen

displays that allows you to search through Business Rules in the “Active” state, which you can then

assign to the local control. You can also modify existing assignments and maintain frequencies of

monitoring or compliance checks.

Once this assignment step is complete, you will be able to schedule the monitoring rule in the

Automated Monitoring scheduler.


May 2018 33

4.1.2 Runtime

The previous activities described how to set up monitoring rules and associate them with controls.

Aside from ad hoc queries in (some types of) rules and data sources, the Planner and Automated

Monitoring Scheduler provide the only means of running rules.

4.1.2.1 Scheduling

The monitoring scheduler is also on the Rule Setup page introduced in section 4.1.1, Design-time,

above. The relevant section looks approximately like the following figure. The exact list of links which

appear in any section depends on the role you have.

Select the Automated Monitoring link. The following screen displays.

Use this page to schedule all schedule-driven rules (once they are assigned to a local control as

described above). The only exception in GRC PC 10.0 is the Event data source and business rule.

The Scheduler page displays all currently scheduled jobs. You can create a new monitoring job by

choosing the Create Job pushbutton, which walks you through the process. The following screenshot

gives an overview.


May 2018 34

The top of the screen shows that scheduling is a 5-step process, and the wizard guides you through it.

The most important thing to note about the scheduler is that you can run jobs as frequently as hourly,

and as infrequently as annually.

4.1.2.2 Monitoring Jobs

Job schedules can be created as shown in the previous section, and schedules, once created, can be

viewed from there as well. But this page focuses on the job itself, rather than the results of any

execution of the job. Results can be seen from the Job Monitor, shown in the following figure.

The results of any job can include sensitive data, and GRC PC 10.0 restricts visibility by users’ roles.

Thus the ability to see the job monitor does not equate with the ability to look at the detailed results of

a job.


May 2018 35

4.2 Data Source and Rule Types

This section describes each of the nine data source and rule types. The goal is to explain the

differences, the unique characteristics of each, and where each will be most useful. This document

does not provide step-by-step guidance on how to set up each—that is contained in nine different

how-to guides, one for each type.

4.2.1 SAP Query Data Sources and Rules

SAP Query is a Netweaver query tool. On ABAP backend systems to be monitored, queries

previously defined in the SAP Query UI (SQ01/SQ02) can be invoked from the GRC system via RFC,

and their results gathered and presented to the rule engine in GRC PC 10.0. The following

screenshot shows the transaction SQ01.

The following two screenshots show the relevant sub-scenario for Data Source definitions.


May 2018 36

Conceptually, this is the simplest of the data source types. The remote data source is a query defined

in a well understood query engine, and the results are returned as a result set not unlike what SQL

engines return. Of course, SAP Query runs SAP’s own OpenSQL. But whether you want to use

either an SAP-delivered query (SAP ERP ships with a large number of queries), or define one of your

own, the methods are quite widely known.

In defining a data source against a previously-defined SAP Query, the designer has to point to a

particular backend system which is to be monitored. PC queries the set of available queries in that

backend system (including wildcard searches), looks up the query metadata, and makes its results

available to the GRC PC 10.0 rule engine.

To create any Business Rule, the first step is always to select the (active) Data Source on which the

rule will operate. Since this fixes the sub-scenario, you do not have to pick the sub-scenario for any

Business Rules—it is always inherited from the Data Source.

For SAP Query Business rules, you can define two categories of business rule, as follows.

The Exception category means that any data returned by the data source is always considered an

exception. The Analysis Type field decides whether to treat all such exceptions as deficiencies to be

remedied (“Set Deficiency Indicator”), or as something a human must review to determine if it requires

a remedy.

The other category, “Value check” (not shown), implies that there are deficiency criteria which explicitly

need to be evaluated, and that you will then be expected to configure in the “Deficiency Criteria” and

“Conditions and Calculations” steps of the create rule wizard (or the corresponding tabs in a previously

created rule).

4.2.2 Configurable Data Sources and Rules

A configurable data source defines a query against tables in the monitored ABAP backend system

(such as ECC/ERP, SRM, and so on). This differs from the SAP Query data source (described

previously), which merely references the query logic previously configured in SQ01 on the monitored


May 2018 37

system. In this case, the GRC user can completely define the query in the GRC UI, on the GRC

system, and have it execute remotely on the monitored system. This has two advantages: you don’t

need to modify a production backend system to define it, and you can test and update it without

affecting two different systems: GRC and the monitored system.

This section also explains the Change Log option, which tells PC to reconstruct past configuration and

master data settings over the timeframe of the control, and validates all such past and present settings

against the user-configured monitoring rule.

Having picked the “Configurable” sub-scenario, you next pick a connector to the backend system

against which you want to define the query (see section 4.1.1.1). Next, look up the main table for your

query by searching against the list of tables in the monitored (remote) system. As the following

screenshot shows, you can monitor against Transparent, Cluster and Pooled tables. You can also

use wildcards to search against table names or descriptions.


May 2018 38

Having picked the main table, you can next pick related tables to bring in additional information. PC

10.0 looks up the main table’s relationships to other tables from the monitored system’s data

dictionary.


May 2018 39

Again, you can use wild cards to search for tables. Note that PC 10.0 already filters the list of tables

to include only those which have related information. The “Reference” or “Dependent” tables option

define the direction of the relationships: dependent tables are those which refer to (as foreign keys)

the key fields of your main table (primary keys), while reference tables are the opposite—they hold the

primary keys to which your main table refers as foreign keys.

You can join multiple related tables together in such a compound data source, with the constraint that

the join conditions are restricted to being equality relationships between like-type fields. For the most

part, it is expected you will join primary keys to foreign keys. PC 10.0 looks up known relationships

from the data dictionary and pre-populates the join conditions area as you go, as shown in the

following figure.


May 2018 40

As suggested in the previous screenshot, it is possible to go beyond relationships explicitly stored in

the data dictionary, by adding or removing join conditions. But all join conditions are constrained to be

equality conditions between fields of the same type.

Joining tables is unavoidable for any system which uses relational databases, of course. But if the

tables being joined are large, the execution of such a query consumes many cycles, and rule

designers have to be careful in what queries they craft here. Many issues impact performance, so

SAP strongly advises customers to test their monitoring rules for performance before deploying into

production. The tool itself restricts rule designers to joining no more than 5 tables in a single data

source (query), and warns the designer as they approach this limit.

Section 6.1, Appendix A - Configurable Rule Example, explains the business logic behind the previous

example, and also shows the corresponding business rule definition, including the use of currency

conversion and grouping and aggregation.

4.2.2.1 Change Log Data Sources and Rules

A change log rule is a variation on the configurable rule defined previously, and hence is presented as

a subsection of that type in this document. It is intended to be used for monitoring configuration and

master data tables only.

In short, SAP applications have extensive change-tracking mechanisms for database tables, which

guarantee that all changes are captured, even if they are of very short duration. These mechanisms

cover changes made directly in the system, and also changes transported into the system. This

guarantee is very important for GRC customers, whose primary goal is to ensure that business

processes comply with policies.

Change Log data sources and business rules parse the data in the change logs of configuration and

master data tables, and reconstruct any past settings over the timeframe of the control. So a change

log business rule allows you to check the validity of a configuration or master data setting at any time,

with confidence that all changes made to that setting will be found and tested for correctness. Wrong

configurations are caught, no matter how transiently they were in effect.

Section 6.2, Appendix B - Change Analysis Example, shows a detailed example of such a change log

monitoring rule.

Performance Impact of Change Logging

Configuration and master data tables have different change tracking mechanisms, and PC 10.0

parses the correct information for appropriate table types. Master data uses the Change Document

mechanism, while configuration tables rely on DBTABLOG based change tracking.

Customers often comment that standard IT practice is to turn configuration table logging off globally,

and turning this setting on raises concerns about performance impacts. This is addressed in more


May 2018 41

detail in section 6.3, Appendix C - Performance Impacts of Change Logging.SAP guidance on this

matter has always been that as long as only configuration/customizing tables are being logged, and a

reasonable purging/archiving strategy is used for DBTABLOG, there should not be any discernible

impact on performance or memory of enabling logging in production systems. ECC ships with low-

volume tables enabled for logging, so enabling such logging is unlikely to degrade performance

Finally, recent customer experience suggests that purging (and, optionally, archiving) the DBTABLOG

table about every 13 months provides customers the benefits of PC 10.0 change analysis, without a

sizeable impact on database size (about 300 MB/half-year, according to one customer).

Change Tracking: Logs versus Polling

In SAP Basis, every time a table is changed, the change is logged in a table as long as (a) logging is

enabled, and (b) the table being changed is marked for logging. This eases the challenge of change

monitoring: instead of ever more frequent monitoring to make sure even transient changes are not lost

(“lost” in the sense of not showing up on review), secure that even with only monthly or quarterly

monitoring, they will catch every single change.

SAP BusinessObjects PC 10.0 leverages this facility, allowing customers to monitor key configurations

only occasionally (say, monthly), secure in the knowledge that no change will escape notice, even if it

was a transient change. Some other products use polling, in which the table in question is queried

frequently, and the state is compared to prior states to detect changes. This method runs the risk of

missing a change if two or more changes occur between two reads of the table by the monitoring rule.

For customers who are unable to use Basis change logging, GRC PC 10.0 does support a polling-

based fallback option. But we believe that (a) logging changes via Basis functionality does not impose

any significant burden on the monitored system, and (b) frequent polling may adversely impact the

system being monitored. If used extensively, it may be worse to do polling than to enable change

logging.

If Basis monitoring is not enabled, customers must schedule the polling program as a background job

in the monitored system (delivered with the GRC plug-in); choosing a polling frequency which best

balances the need to catch changes against the impact on performance. If Basis change logging is

enabled after polling has been scheduled, the GRC plug-in recognizes the redundancy and stops

polling.

Definition of Change Log Rules

Change log based rules (whether using Basis logging or GRC polling) can be based on either

“configurable” data sources, or “programmed” ones. (Again, we emphasize that the word

“configurable” refers to the fact that users can configure the logic of the query, rather than have to

program it in ABAP or SQL.) Such change-log-based rules can be used to monitor either

configurations (via the DBTABLOG functionality mentioned above), or master data (by a different

document master system of tracking changes). The design of this feature shields the rule designer

from the complexities of log analysis; they simply find the right tables and fields to monitor, and the

GRC code tracks down the additional information needed to reconstruct past settings from change

logs.

Once the data source is ready and active, you can define a monitoring Business Rule on it. It is in the

process of defining the rule that the user must indicate that the rule in question is a change log type

rule. Thus, change log rules can only be defined:

1. For configuration and master data tables

2. Based on either “configurable” or “programmed” type data sources


May 2018 42

The rest of the rule definition is similar to configurable rules, with one exception. For change log rules

based on configurable data source types (but not for programmed data source types), PC 10.0

provides an analysis type of “pattern”, which allows users define a multi-field deficiency criterion using

a decision table.


May 2018 43

The decision table is BRF+ functionality, and the following figure incorporates BRF+ widgets to define

the contents of the decision table. Refer to BRF+ documentation for details, but note that multiple

rows in the decision table are treated as clauses to a logical “OR” expression. Column within such a

table are treated as clauses to a logical “AND” expression. For example, use the letter C to denote the

contents of a single cell in such a decision table, with row and column numbers in the subscript. Thus,

C3,4 would refer to the third row, fourth column. Then the decision table is evaluated as:

(C1,1 AND C1,2 AND C1,3…) OR (C2,1 AND C2,2 AND C2,3) OR …


May 2018 44

Table Handlers

When using change analysis, one additional configuration requirement requires additional explanation.

When interpreting the change log, the GRC backend plug-in needs a handler to interpret the change

log entries. Sometimes more than one table handler is registered for the table in question, and it can

be difficult to determine which handler to use. Sometimes you may have to pick between two or three

handlers to determine which one is appropriate. The correct handler for your situation will be the one

which makes your deficiency fields available for use in change analysis rule.


May 2018 45

4.2.3 BW Query Data Sources and Rules

SAP Netweaver Business Warehouse (BW) has a query tool which you can use to define queries

against BW info objects and info cubes. If you want to monitor your business processes by looking at

data extracted to BW, you can create BW queries. Definition of BW Query data sources is very similar

to SAP Query ones described in section 4.2.1, SAP Query Data Sources and Rules.

However, there is one critical difference in the way the BW queries must be set up. Unlike

transactional systems, the whole purpose of data warehouses is to enable users to analyze data

intensively. The BW queries can be designed to allow follow-on analytics even after the query returns

results. Automated monitoring cannot use those features, since the recipient of the results in this case

is the GRC product, not directly the user. So the BW query used for PC 10.0 automated monitoring

must be of a more restricted type. For use with PC 10.0 automated monitoring, BW Queries should be

constructed with the following constraints:


May 2018 46

1. BW characteristics of interest must be arranged in the row area in Query Designer. The

characteristics are a list of output fields which will appear as “data for analysis“ in a GRC data

source.

2. BW key figures must be arranged in the columns area in Query Designer.

3. Free characteristics in Query Designer may not be used.

4. Characteristic restrictions should not be used for query filters.

5. Only Single Value and Selection Option variable presentations of query filters should be used.

6. All query filters and selection fields must be optional—GRC monitoring rules do not require

filters to be specified, so the underlying BW query must also make this optional.

7. In Query Designer’s row area, the result row setting must be Always Suppress.

8. Versions 7.X and 3.X of BW query designers are not supported.

4.2.4 ABAP Report Data Sources and Rules

ABAP reports are widely used to monitor transactions, configurations, master data, and so on, in SAP

applications. In the past, customers implementing GRC products have wanted to leverage their past

investment in such reports, and automated monitoring has had an ABAP report data source type for

the past two releases. This data source has had two key limitations: in the past, we could only invoke

the report through a previously-defined report variant; and the results of the report execution are only

available as an image—suitable for human review, but not for automated detection of deficiencies.

With release 10.0, PC automated monitoring is now able to bind values (for example, company codes)

to report parameters. Use of report variants is still supported, but not always needed. As before,

results are viewable as an image, PDF document, or spreadsheet.

ABAP reports have a range of behaviors, some of which are not suitable for PC 10.0 automated

monitoring. PC 10.0 must invoke ABAP reports remotely, so first of all the report must be able to run

as a background job on the monitored system, and its results must be able to be stored as a spool job.

Secondly, it must not use additional popup screens for user input, after its declared parameters are

bound to values. It is difficult to know which reports qualify under these circumstances, so the PC

team has written a program to help qualify ABAP reports for use in automated monitoring. The how-to

guide for this data source and business rule type describes the qualification program and other details.

4.2.5 Netweaver Process Integrator-based Data Sources and

Rules

SAP GRC can monitor non-SAP applications, and the Process Integrator-based data source is one of

several suitable for this purpose.

Netweaver Process Integrator (PI, formerly known as Netweaver XI) is SAP’s preferred platform for

integrations. PI supports common protocols such as JDBC and ODBC, and customers who have

non-SAP applications in their system landscape can use PI to either query directly against the

underlying databases of these applications via JDBC/ODBC, or even integrate at the code level, if

appropriate.

The Monitoring API

PC 10.0 provides a four-method Monitoring API to integrate with PI, grouped into two design-time

functions and two run-time functions. Design-time functions are useful to rule designers, and run-time

functions are used to execute the rules so defined. This section describes the API at a conceptual

level, although the technical names of implementing functions and proxies may well be different. The

descriptions in this section are also relevant to other data source types.

The four methods can conceptually be called GetQueryList, GetSignature, ExecuteQuery and

TestQuery. The first two are the design-time methods.


May 2018 47

GRC calls the remote system via GetQueryList to get a list of queries or other data-retrieval functions

on offer from the remote system for use in monitoring. This list is then displayed to the rule designer

to create GRC data source objects.

Once the rule designer has picked a particular query from the list, GRC calls the GetSignature method

to retrieve meta-data about the input parameters the query expects, and the results it returns. These

are reflected in the data source attributes, and become available for designers to use in defining filter

criteria, deficiencies and output formats.

The TestQuery method is used for ad hoc queries from data sources and business rules, although

note that this method is not always available due to technical reasons.

The ExecuteQuery method is called to actually run the query once scheduled, or executed via the

Planner. The key difference between TestQuery and ExecuteQuery is that TestQuery calls are not

logged or audit-trailed, while all scheduled executions are.

PI Implementation of the Monitoring API

GRC PC 10.0 includes a PI implementation of the Monitoring API described previously. So customers

or partners who want to create PI-based queries (for instance, to query directly from a non-SAP

database via ODBC/JDBC) can define such queries in PI, and use the GRC-supplied implementation

of the Monitoring API to integrate those into GRC PC monitoring rules.

PI rules may use asynchronous communication between GRC PC 10 and PI, which requires a

callback endpoint in GRC PC.

The associated user guide describes how to configure PI-based rules in more detail.

4.2.6 Web Services-based Data Sources and Rules

These are also called “External Partner” data sources, since they have historically been used by SAP

GRC PC partners to enable easier monitoring of different backend applications. In the IMG

configuration screens, you will also notice the term “GL-MQT”, which again reflects this history. GRC

PC 10.0 generalizes to web services what used to be proprietary interfaces for such partners to

implement. This API is the same as described above in section 4.2.5, Netweaver Process Integrator-

based Data Sources and Rules, with the exception that the Test method is not available for partners to

implement.

The method implementations are, of course, the responsibility of the partner product (or custom

middleware). In web services, it is usual for the implementer of a service to publish a WSDL definition

of the service, to which the caller then adapts. In our case, however, PC 10.0 has a fixed outbound

proxy, and we have published the WSDL which the proxy expects the partner to implement. These

are described in SAP Note 1549031.Further details can be found in the associated user guide.

4.2.7 SoD Data Sources and Rules

The GRC Access Control 10.0 (AC) solution includes extensive segregation of duty risk analysis rules,

which conform to the rules interface of the GRC PC automated monitoring framework. Such rules can

be run in the context of PC local controls, as described in section 4.1.1.3. One key constraint is that

the two GRC products—Process Control and Access Control—should both be installed in the same

system.

AC provides one rule to use with PC 10.0 for monitoring, which takes a fixed set of parameters and

returns a single set of results. This can only be used as-is within PC 10.0.

Further details can be found in the associated user guide.


May 2018 48

4.2.8 Event-driven Data Sources and Rules

Event-driven data sources and rules are different from all the others in one respect: they are not

initiated by GRC PC on a schedule (or by the GRC PC user). Instead, some external program or

agent must decide when an event has occurred which needs to be communicated to GRC PC for

monitoring and evaluation.

GRC PC provides a web services interface which a partner product can call to raise such events to

GRC PC. GRC PC must first be configured to expect such an event in the so-called Event Registry

(part of IMG customizing), and the configuration includes a description of the event payload, or the

contained attributes and their data types. When actual events are received, GRC PC first validates

the payload (XML) against the registered event meta-data, and only those events with payloads which

pass muster are processed further. The event interface is a synchronous method, and only success

or failure is communicated back.

Details about how to configure these data sources, how to obtain the WSDL for the web service, etc.

can be found in the associated user guide.

4.2.9 ABAP Programmed Data Sources and Rules

Some monitoring rules might require complex processing beyond the capabilities of the query and rule

engines described in this document. Such situations can be addressed by writing custom ABAP

programs to deploy on the backend system being monitored. Such programs must conform to the

overall design framework prescribed for automated monitoring, and must be registered in the GRC

plug-in for monitored systems. These are very similar to ABAP reports, but since they adhere to a

pattern prescribed by the GRC plug-in, they can be better leveraged by GRC PC for monitoring. To

emphasize this distinction, we call them ABAP Reports for GRC.

Once again, the conceptual framework is the Monitoring API as described above in section 4.2.5,

Netweaver Process Integrator-based Data Sources and Rules. Any ABAP report for GRC must

implement (extend) a defined base class, and the programmer must create an entry in a specified

table with the program (class) name, parameters, etc. The necessary classes and tables are part of

the GRC plug-in for Netweaver ABAP systems, which must be installed in the system to be monitored.

GRC PC 10.0 can then look up the relevant ABAP reports for GRC and their meta-data, and provide

GRC PC rule designers with the information they need.

Details about how to write such ABAP reports for GRC, how to register them with the GRC plug-in

(RTA), etc. are found in the associated user guide.

5. Frequently-asked Questions


May 2018 49

6. Appendices

6.1 Appendix A - Configurable Rule Example

The SAP ERP purchasing process enables customers to define strict rules for how their company

manages purchasing, to prevent fraud, comply with financial regulations, and so on. Specifically for

our example, the creation of vendors is very tightly controlled, with specific criteria which the system

helps purchasing managers to enforce. But for practical reasons, it is sometimes necessary to bypass

such checks, and to enable this, SAP ERP supports the concept of a “one-time vendor”. The idea is

that for an exceptional situation, there is a way to bypass the rules and push through a purchase

quickly.

This sets up a conflict: on the one hand, customers need the flexibility that one-time vendor use

permits; on the other hand, like any other freedom, this flexibility can be abused. Some customers

have policies which limit the use of one-time vendors to a set amount limit, or limit the number of times

a one-time vendor can be used. These requirements are “outside the system”; that is, they are not

configured into SAP, nor are they enforced preventively. This makes sense, since if preventive rules

could be defined, then one-time vendors would not be needed at all.

PC automated monitoring provides a solution for this. Customers can set up a monitoring rule which

expresses usage limitation guidelines such as frequency of use or amount limits. The following

example illustrates this.

In section 4.2.2, we showed how to build a configurable data source. Picking up the narrative from

there, the following screenshot shows a PC Data Source which helps query the relevant information.

This is a configurable data source, meaning that the query logic driving it is defined in the PC system

itself, although it will run against a remote backend system. It is looks up the main vendor table


May 2018 50

(LFA1), and joins it to the financial table BSAK to look up related payments for each vendor. The join

conditions are automatically populated from the data dictionary as the related table is selected.

You then pick the fields from the two tables you wish to examine, in the lower half of the picture above.

In this example, the interesting fields are company code, clearing date, vendor number and amount

(not all of these fields are actually visible in the figure). As noted previously, the data source can (and

probably should) include more fields than the ones you need for one rule—the idea is to share data

sources across multiple rules.

The next step is to define the business rule. The following screenshots show a previously configured

business rule, so this will vary very slightly from your experience in building a new business rule, as

mentioned earlier.

The previous picture shows how you pick the fields of interest for the business rule you are defining,

from the presumably larger set of fields the data source has to offer.

The next step is to define the filter criteria, as shown in the following screenshot.

The company code parameter should be bound to the corresponding OLSP parameter, so that control

owners for particular organizational units automatically see data only for their own unit. In the

previous picture, we show how to only look at payments made to one-time vendors.


May 2018 51

The following picture shows the next tab (and also the next step in defining the rule), where you define

the deficiency criteria.

For the rule shown here, two “calculated fields” were created (see section 4.1.1.2, Creating Business

Rules): the first one will hold the total amount paid to each vendor in the test timeframe, and the other

will count the number of payments made to each vendor. The lower half of the figure above shows the

conditions for determining whether there is a low, medium or high deficiency based on the total

amount paid to the vendor. The following screenshot shows the definition of the other deficiency

criterion, based on total number of payments made to a vendor.

Note that the name of the deficiency is descriptive, to help the control owner understand what the data

is showing. The deficiency description in the bottom half is similarly descriptive.

The next step is to actually define the calculations needed for these “calculated” deficiency fields.

Note again that we chose in this example to calculate the deficiency from the fields on offer from the

data source. If you happen to have a data source whose existing fields already offer the deficiency

criteria you need, your task is correspondingly simpler, since you don’t need a calculated field: you

simply use one of the existing fields to define your low, medium and high deficiency conditions.


May 2018 52

As you can see in the previous picture, conditions and calculations are defined separately for each

calculated deficiency field. For the amount-based deficiency criterion, it makes sense to first define a

currency conversion step, since we want to be able to set the limits in a specific currency while

evaluating payments made in any currency. The next screen shows the definition of the conversion.

In the this figure, we are telling PC to take the amount in one of the data source fields, “Amount in

document currency”, and convert it to US dollars as of the fixed date of 17 October 2011. Alternately,

you could use the “Clearing date” field in each such payment by picking the second option (“By date

field” above), or relate it to the date of execution of the rule (the date of rule execution, the first of the

month in which the rule is executed, and so on).

The next step is to add up all payments to a single vendor, having first converted to a common

currency. The following figure shows the definition screen for this conversion.


May 2018 53

As you can see, we group by the vendor number, and sum up the individual payments to the vendor.

Note that we have checked the box “Show Detail”.

Skip next to the “Ad hoc query” tab, to show the results. Running the rule in “data collection” mode,

we see the raw data the data source will present to the rule, below.

The key to note is that there are several one-time vendors used, with more than one payment to many

such vendors. The amount paid to these vendors is also in two different currencies. It so happens

that a particular vendor is always paid in the same currency in the above picture, but that doesn’t

matter—PC converts each payment, so would be able to handle the same vendor paid in different

currencies as well.

Executing the ad hoc query again in “apply rule” mode, we see the following results.


May 2018 54

In this screenshot, the first column, Sequence Number, shows how many distinct rows of data remain

after grouping. In this figure there are four distinct vendors left, so only four rows—those are the ones

with a number in the first column. For those rows (that is, with a number in the first column), the far

right column shows the aggregated value (the sum, in our example) of payments to that vendor,

converted when necessary into US dollars. For those same rows, the second column shows the level

of the deficiency, as per the condition defined three steps earlier.

The remaining rows in the figure (that is, the rows with no number in the first column) are the “details”,

showing the individual payments to that vendor which have been grouped and aggregated in the other

rows (that is, the rows with a sequence number in the first column). This corresponds with the “Show

Detail” checkbox mentioned two steps earlier.

The definition and operation of the other deficiency criterion, on the total number of payments to a

one-time vendor, are similar and are not shown.

6.2 Appendix B - Change Analysis Example

Summary

This section describes how Process Control 10.0 reconstructs past configuration and master data

settings of monitored systems, and enables customers to assert their compliance requirements in a

flexible, user-configurable rules engine. The functionality is shown in the context of an actual

customer example, based on the widely-used Sales & Distribution (SD) module of SAP ERP.

PC 10 releases a major upgrade in automated monitoring of key backend configurations and master

data settings. As before, PC is able to extract and analyze changes to important configurations and

master data (we’ll just call them “configurations” for convenience). But where PC 3.0 presented each

logged change individually for evaluation (“Is this change of vendor account number a deficiency?”),

now it can put together all changes which went into effect together, so that customers can make more

meaningful evaluations. This is important, because typical configurations have multiple fields which

can be changed individually; sometimes, the combination of the fields could be the deficiency

candidate.

This becomes clearer with a specific example. The Sales & Distribution module of SAP ERP has a

credit check configuration setting which gives customers lots of flexibility managing credit settings for

their customers. There are many configurations (many tables and fields can be configured), and all of

these interact in many and subtle ways, as is typical in ERP applications. To illustrate the use of PC

10 monitoring, though, we will focus on just one aspect: configuring the credit check types to be

performed for particular categories of customers for specific company codes/sales areas.

The transaction in question is OVA8 in SAP ERP systems:

http://www.sap-img.com/sap-sd/credit-management.htm


May 2018 55

The user starts by picking the sales category, or creating a new one:

For our purposes, we just select the first one and choose View Details (or Ctrl+Shift+F2).

The Change View: View for Maintenance of Automatic Credit Control screen displays.


May 2018 56

Without entering into the subtleties of Sales & Distribution, “static” checks count outstanding orders,

open or delivered (but not yet paid) against a customer’s credit limit; document value limits credit

extension to sales upto the configured “maximum document value” limit. Customers report that typical

valid settings are complex combinations of these fields. For instance, the following screenshots are

both valid settings, per one major customer:


May 2018 57

That is, customers can be subject to a static check, or be limited on the maximum amount of a single

sale, but not both. As routine maintenance causes SAP customers to change these settings to match

evolving business strategies, the goal of GRC is to ensure that any deviations from acceptable or valid

combinations can be flagged, without bogging the customer down in a flood of false positives.

Using “F1Technical Details” against the individual fields tells us that these settings are to be found in

the table T691F, with field names CMPAA, CMPAB, and so on.

It is a relatively straightforward matter to look up the tables in question, and define the criteria for

monitoring. The credit check setting is compliant with policies if the following condition is true,

deficient otherwise:

(Static_check = true AND status_block <> TRUE) OR

(Document_value_check = true AND Max_doc_value NOT NULL)

Of course, any real monitoring rule will most likely be even longer, but the above condition is enough

to show that the PC 10.0 rule engine can deal with the type of complexity involved. More clauses

won’t make the condition any more complicated—just longer.

The real challenge, of course, a simple check like this would go against the current state of the setting,

in table T691F and related views. It tells us nothing about the past. This is never going to be fully

reliable, since the monitoring rule can only be executed a finite number of times—what if the setting

was changed to an invalid one for a short period, and then changed again to something that’s valid?

What companies need is a way to capture every setting that was ever in effect over the timeframe

being monitored (for example, last quarter, or last year), and apply the monitoring rule against such

reconstructed settings over the whole timeframe. Thus, if the PC 10.0 control to which the monitoring

rule is assigned has a timeframe of FY2010, the rule should reconstruct all SD Credit check

configurations for FY 2010 from the change logs, and apply the monitoring rule against those

reconstructed settings.

SAP Basis provides extensive capabilities for logging changes to such configurations. In transaction

RZ11, we look up parameter “rec/client” (see also section 6.3, Appendix C - Performance Impacts of

Change Logging).


May 2018 58

Separately, in transaction SE11 we look up the table in question (T691F):

Looking at the technical settings (highlighted button) shows the per-table flag which tells Basis to log

changes.


May 2018 59

With these two settings enabled, the ERP backend will log changes to the table in question, and PC

10.0 AMF can monitor the logs to reconstruct past settings.

The next few screenshots describe how to set up and test a monitoring rule for change log analysis of

SD Credit checks.

Navigate to the Continuous Monitoring section of the Rule Setup screen in PC 10.0.


May 2018 60

Create next a Data Source pointing to the T691F table, in a suitably prepared ERP backend system.


May 2018 61

Run it against the “SM EA5/100” system mentioned previously.

Next define a Business Rule monitoring this data source. Again, the following screenshots illustrate

this.


May 2018 62

Note that analysis type of “pattern” here refers to the fact that customers can define a deficiency

criterion which is a pattern over multiple fields, not just the single-field deficiency criterion.

The system then prompts the user to define a handler for the table, and helpfully prompts with

appropriate responses. Finally, the pattern itself (such as the one shown in the example) is shown in

the following figure.

Some people find it more convenient to define/edit the pattern via a spreadsheet, which is a feature

offered in the screen above:

Moving to the ad hoc query tab, we can run the rule or underlying query (data source) in a few

different ways:


May 2018 63

6.3 Appendix C - Performance Impacts of Change

Logging

Summary

There’s no reason to think change logging will measurably degrade performance. It’s certainly

possible, but ECC ships with only configuration and other low-volume tables marked for logging.

Customers who have enabled table logging and stayed within the guidelines of SAP Note 608835

(only log configuration tables, monitor DBTABLOG size, purge/archive periodically) have not had seen

in impact on performance from table logging.

Detailed Problem Statement

Many customers use DBTABLOG and related functionality to manually monitor changes to their

production system configuration, since it is a very reliable method of catching all changes. But it

requires some experience and technical knowledge to use the right tools and interpret the data, which

is why many other customers keep change logging switched off—if they’re not using it to monitor for

changes, there’s no reason to incur the overhead of having it on.

In part by learning from customers who have been using change log information, SAP GRC developed

the ability to monitor such changes. With release 10.0, customers are offered a convenient and

powerful way to tell GRC which critical configurations they want to monitor against inadvertent or

https://service.sap.com/sap/support/notes/608835


May 2018 64

fraudulent changes. With table logging turned on and GRC PC 10.0 installed, customers can be

confident that changes to their key configurations will never “fly under the radar”.

This delivers extremely useful functionality, and is a compelling reason to change the long-standing IT

practice at many customers of keeping change logging turned off. Many customers have enabled

logging without experiencing any difficulty.

One concern that has surfaced lately is that table logging is controlled by two switches: one is global

(the “rec/client” parameter), and the other is at the individual table level. The screenshots below

illustrate this.

Once the global switch is turned on, how many tables are already enabled for logging? It turns out

that ECC ships with logging enabled for over 31,000 tables. Most customers consider this number

strikingly large, not surprisingly.

Analysis

SAP Note 608835 is helpful in understanding the situation. As the note says quite clearly, “…you can

activate logging in your system without any problems because SAP only delivers Customizing tables

with activated logging.” As long as the customer does not enable logging for any master data or

transaction tables, the note continues, “Practice has shown that…logging does not cause any

problems in the production, Customizing and development environments.”

Interviews with SAP GRC customers who have enabled such logging in production show a reassuring

picture. Taking a cautious approach, the customers have been purging the DBTABLOG table every

https://service.sap.com/sap/support/notes/608835


May 2018 65

quarter or twice a year. These are large customers who use ECC extensively in their global

operations, yet report that over six month periods, DBTABLOG shows a growth of 200-300 MB, which

is not significant. Some customers are considering increasing the time between purges to over a year,

so that they have a full year’s changes available for examination.

Master Data Changes

Note that the above only covers configuration table changes. Master data changes are tracked via a

completely different mechanism. PC 10.0 can also reconstruct changes to master data by parsing the

separate change tracking information for master data. This mechanism is always operational for most

backend systems.

Recommendation

SAP GRC recommends that customers enable table logging in production SAP applications (ECC,

CRM, and so on) at the global level by using the “rec/client” setting. This enables logging at the table

level for over 31,000 tables in ECC, but this is not a cause for concern since most of these tables are

customizing and other configuration tables. SAP GRC recommends a pilot phase of 3-6 months

during which customers review the performance and memory impact of table logging. Archiving and

purging can then be adjusted to suit the customer’s preferences and observed impact, although we

urge customers to consider that having a full year’s worth of change information available for

monitoring can deliver benefits.

7. Acknowledgements

The author gratefully acknowledges considerable help from many colleagues. Martin Chen designed

the overall architecture of the automated monitoring features of PC 10.0. Alex Hsu defined much of

the information architecture, and succeeded Martin in architectural oversight. Jackie Wang

implemented a large part of the functionality, and also provided detailed reviews to the author very

promptly. Daniel Chang and Haiyang Yu also provided very useful feedback on the accuracy of the

information presented here, and the draft user guides written by many members of the development

team were sources of very useful information in preparing this document. Michaela Zwinakis and Paul

Davis read the entire document and gave detailed suggestions which have been incorporated into the

final version of this document. Aman Joshi of Price Waterhouse Coopers also gave detailed

suggestions, most of which are also incorporated.

8. Copyright

© 2011 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express

permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of

other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System

z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400,

AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+,

POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP,

RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere,

Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe

Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or

registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium,

Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and

implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, and

other SAP products and services mentioned herein as well as their respective logos are trademarks or registered

trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web

Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their

respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is

an SAP company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services

mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase, Inc.

Sybase is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained

in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated

companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and

SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP

Group products and services are those that are set forth in the express warranty statements accompanying such

products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Documents

SAP Business Objects GRC 10.0 Automated Monitoring Overview