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