SAP Business Objects GRC 10.0 Automated Monitoring …a248.g.akamai.net/n/248/420835/18c4944d9b5c0a1c75600f0c42b2f693241...SAP Business Objects GRC 10.0 Automated Monitoring Overview
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 1
1. Business Scenario
1.1 The SAP Business Objects GRC Solution
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. SAP
BusinessObjects Governance, Risk and Compliance (GRC) solutions provide an overview of such
processes from a risk and compliance point of view, and help customers measure risks and monitor
compliance.
1.2 Automated Monitoring
This document focuses on one specific aspect of GRC: automated monitoring of backend systems
and processes, part of the Process Control 10.0 application (PC 10). Customers of GRC use
automated monitoring for configurations, master data and transactions; SAP BusinessObjects Process
Control 10.0 (PC 10) 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, and many of
these include automated monitoring with PC.
The following figure depicts how GRC fits into the corporate IT landscape, and into a corporate
governance and compliance strategy.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 2
Note that, in this view, monitoring is front and center in any effective GRC practice. For example, a
customer can monitor configurations of SAP Sales & Distribution (SD) credit checks to make sure that
even as these are changed during routine maintenance, they remain compliant with company policies
(see the appendix in section 6.2 for details). PC 10 automated monitoring capabilities enable such
monitoring of configurations and master data, and also backend transactions. The possible solutions
shown at the top of the picture include content which might involve joint solutions with other SAP
products, 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
In PC 10.0, the Planner 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
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 3
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
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.
1.5 Audience
This document aims to introduce customers and partners to automated monitoring in PC 10.0. The
topic is somewhat technical, so at times this document introduces language and concepts which might
challenge the reader.
In GRC, we call process experts, compliance and risk officers, audit professionals and senior
managers and executives ―business users‖. We use ―functional experts‖ to mean professionals who
know a particular business process well, including knowing the business process steps and
transactions, configurations and master data. The term ―technical experts‖ refers to software
professionals who understand databases, queries, web service configurations, or programming.
―Implementation experts‖ are professionals who know the PC product well—they will be responsible
for installing and configuring it, or upgrading from previous releases. Finally, ―rule designers‖ will be
implementation experts with particular expertise in configuring monitoring rules.
This is an introductory document, which we hope will be useful to all three groups of people. It should
give business users a feel for what sort of monitoring is possible, without requiring them to understand
every section. Functional experts should be able to understand most of this document, and technical
experts will no doubt want more details than we provide here. Section 5, Further Reading, gives links
to more detailed documents.
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 structured information
which the monitored system can provide on demand (or which it can proactively send to PC—see
section 2.2, Queries and Events). 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 4
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. The common characteristic of these monitoring
methods is 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 5
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
PC can pull data from remote backend systems by multiple mechanisms. To keep track of these, rule
designers create objects called Data Sources, which store the information about the actual sources of
data on remote systems which they will invoke when a monitoring rule runs.
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.
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
Once PC pulls in data from backend systems being monitored, it applies user-specified logic to decide
if there are any problem situations (which PC calls deficiencies). In PC, such user-specified
monitoring logic is stored in Business Rules.
Business rule definitions can be simple (―A one-time vendor should not be used more than once in a
quarter‖) or involve additional calculations, grouping and aggregation (―Total spend on a one-time
vendor must never exceed $10,000‖). Even more complex logic, or specialized user-defined functions
can also be configured in the rule engine.
Section 4.2, Data Source and Rule Types, describes how rule characteristics vary depending on data
source types, and the implications of each.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 6
2.5 Architecture
This document gives 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
PC 10.0. But 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–used to monitor a wide selection of non-SAP backend applications.
Data sources are objects in PC 10.0 which tell PC how to extract data from backend systems being
monitored.
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
mechanism for doing this is by means of an RFC destination , which is defined in the SM59
transaction. There are nine different types of sub-scenarios which have dedicated data sources
supported in PC 10.0, described later in this document.
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‖ labels all such activities. In PC master data
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 7
structures, such controls are defined in the context of specific business processes and organizational
structures
To enable this, controls are monitored by assigning rules to the local instances of controls. The
business process and organizational unit associations of local controls provide the business context.
PC allows customers to use these environment variables, historically called Organization-Level
System Parameters (OLSP). 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 monitoring engine. More than 150 monitoring rules were
delivered with the product, many of them GRC ABAP reports (see section 4.2.9, ABAP Programmed
Data Sources and Rules) deployed on backend ECC systems to be monitored. Many customers
customized these delivered rules, or created their own.
PC 10.0 represents an advance 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. One limitation here is that legacy rules and rules in the new PC 10.0 framework
cannot be assigned to the same control.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 8
3. Prerequisites
3.1 Systems Installation and Activation
The PC 10.0 installation guide available on SAP Service Marketplace gives details about installation
and configuration of PC 10.0. The rest of this section addresses configurations unique to automated
monitoring.
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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 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.
The next link, Maintain Connectors and Connection Types, takes you to the following screen.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 10
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 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
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 11
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.
Next choose Maintain Connection Settings, as shown in the following figure.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 12
A screen displays, asking which Integration Scenario you want.
Choose ―AM‖ for automated monitoring. the following page displays.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 13
The highlighted box shows nine entries called ―sub-scenarios‖—these are different types of data
sources and business rules supported in 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 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,
and business processes, 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 PC documentation (links in
section 5, Further Reading).
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 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, so it omits
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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 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
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
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 17
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 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). Validity dates for data sources and rules
interact with other date ranges: for controls, business process definitions, test plans, etc. PC
monitoring works only where these date ranges all overlap. If there is no specific reason to fix the
date range, it is wisest to default the valid-from date to the start of the year, and set the valid-to date to
the year 9999.
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. PC helps you do this by allowing you to replace the default descriptions with more
descriptive text. For instance, the following figure shows the vendor master table LFA1 of SAP ERP.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 18
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. Note that after you have defined the data
source, you can use that definition to monitor other systems (that is the purpose of additional
connectors). In fact, we recommend that customers create
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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 19
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.
Basic Information
The name, description, validity dates, status and search terms fields serve exactly the same function
as the corresponding fields in data sources, which were described in 4.1.1.1, Creating Data Sources.
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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 20
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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 21
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. 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 22
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). A variation on the latter
would be to 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 23
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.
The following screenshot shows the simplified GRC user interface to BRF+ functionality.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 24
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. This is easiest to understand with an example—please see section 6.2,
Appendix B - Change Analysis Example.
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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 25
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.
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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 26
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
the number of payments made to each one-time vendor, and then apply the configured thresholds to
determine if that violates policies.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 27
The calculations tab (or wizard step) shows how this is setup.
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,
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 28
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 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 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 29
Note: The above information is provided to enable you to define more powerful processing rules in BRF+ workbench, as needed. This requires 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 30
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 PC 10.0 user interface. For programmed, SAP query, ABAP report,
and some other data source and business rule types, ad hoc query is not available, since the key
design and testing activities for those types occur elsewhere, and 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 31
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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 32
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 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 33
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 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 34
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 detailed user
guides published as part of product documentation.
Section 6.3, Appendix C: Data Source and Rule Type Summary, summarizes all the subsections
below for a handy reference to data sources and business rules.
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 PC 10.0. The following screenshot
shows the transaction SQ01.
The following two screenshots show the relevant sub-scenario for Data Source definitions.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 35
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, 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 looks up the set of available queries in that
backend system (including wildcard searches), looks up the query details, and makes its results
available to the 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 36
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).
Further details can be found in the associated user guide (see section 5, Further Reading)
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
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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 37
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 tables. You can also use wildcards to search
against table names or descriptions.
Although not shown in the screenshot below, you can also monitor Pool and Cluster tables.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 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.
SAP Business Objects GRC 10.0 Automated Monitoring Overview
December 2011 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.
Technical Note: Joins as illustrated above are only possible between transparent tables. Pool and
Cluster tables can be monitored individually, but cannot be joined—not to each other, nor to
transparent tables. This sometimes shows up in unexpected ways: for instance, table T685Z is a
pricing table (ERP SD module), with a pair of pricing limit fields. Those fields are currency fields,
which requires a look up of the corresponding reference table. That reference table, unfortunately, is
not a transparent table (it is actually a structure), and so PC cannot monitor the price limit fields of
T685Z—at least, not via the configurable data source/rule type.
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.
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. That is, even if one change is
quickly followed by another, both changes are reliably logged. 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.
Technical note: Configuration changes can be transported in, and are covered by the Basis change
tracking mechanism). Master data can only be changed directly in the system. 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.
Performance Impact of Change Logging
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
detail in Note 1653464 - Enable Change Log Monitoring by Activating Table 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
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.