Business Rule Functionality

Purpose

Business rules represent or describe business or compliance policies, corporate policies or guidelines, external regulations or analysis of historical data. For compliance purposes, business rules describe the basis for determining exceptions or issues that may represent violation of these policies, guidelines or regulations.

Overview

Business rules represent the core business logic and related constraints to facilitate identification of control exceptions. Because business logic is removed from the mechanics of the application programming, it can be changed anytime without requiring re-writes and re-releases of the application code.

1. Specification of functionality

1.1 Business Logic

Business rules represent or describe business or compliance policies, corporate policies or guidelines, external regulations or analysis of historical data. For compliance purposes, business rules describe the basis for determining exceptions or issues that may represent violation of these policies, guidelines or regulations.

Business rules represent the core business logic and related constraints to facilitate identification of control exceptions. Because business logic is removed from the mechanics of the application programming, it can be changed anytime without requiring re-writes and re-releases of the application code.

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 determine whether data presented to them represents a problem requiring remediation. Business rule definitions can be simple (e.g. “A one-time vendors should not be used more than once in a quarter”) or involve additional calculations, grouping and aggregation (e.g. “Total spend on a one-time vendor must never exceed $10,000”), complex logic, or even specialized user-defined functions.

Once again, GRC PC leverages Netweaver tools: the rule engine uses Business Rule Framework (BRF+) (previously known as Formula Derivation Tool or FDT).

1.2 Examples

There are nine sub scenarios supported in Continuous Monitoring.

SAP Query
Configurable
BW Query
ABAP Report
Process Integration (PI)
External Partner (Web Service)
Event
SoD (Segrgetion of Duty) Integration
Programmed

Those sub scenarios are introduced in a separated documents (e.g. RKT Materials or User Guides in SAP Market Plance)

2 Design of functionality

2.1 Flow logic

2.1.1 Ovierview

2.1.2 Create a Business Rule

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 parlance, that’s called a deficiency.

The nature of the business rule strongly depends on the sub scenario of data source, which is why the process of creating a business rule begins with data source selection, as shown below.

During searching the data source, only the active data sources are shown

After the data source is chosen, the step roadmap is presented. The number of steps are various to the sub scenario of data source. These logical sequence of steps was implemented as Guided Activiry Floorplan (GAF) provided by NetWeaver Floor Plan Manager (FPM).

Here are the screenshots for step roadmap to each sub scenario. The design on how many steps to each sub scenario is based on certain technical and business consideration. For example: the step “Ad-hoc Query” is only applicable to the sub scenarios “Configurable”, “SAP Query”, “BW Query”, and Programmed” because the rest of sub scenarios don’t have the capacility to provide the query result during the implementation (technical constraint). The step “Filter Criteria” is not required in the sub scenario “Event” due to only the relevant events are received in Continuous Monitoring to the corresponding business rule (business scenario).

Sub Scenario: Configurable

Sub Scenario: SAP Query; BW Query

Sub Scenario: Programmed

Sub Scenario: External Partner; Process Integration

Sub Scenario: Event

Sub Scenario: ABAP Report; SoD Integration

2.1.2.1 Basic Information

The name, description, validity dates, status and search terms fields are exact analogs of the corresponding fields in data sources.

The Category and Analysis Type fields are strongly dependent on the sub scenario in data source, and the relationship among them are captured in Business Rule UI customization.

Connectors which are selected in the corresponding data source will be visible, also the main connector is checked and applied automatically in the business rule. If any of connectors don’t need to apply to this business rule during the runtime (Job execution), uncheck the checkbox “Applied”. But at least one connector needs to be applied in the business rule.

The status of all the new business rule starts from “New”. In order to change the status to “Active”, the status of business rule needs to be set to “In Review” first. After the business rule is active, the status can be changed either back to “In Review” or “Inactive”.

2.1.2.2 Data For Analysis

This step is only applicable to the sub scenario “Configurable”.

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.

2.1.2.3 Filter Criteria

Of all the business rule fields, some will be useful mainly in filtering out data that is not of interest. The most common situations involve transaction dates (you may only be examining transactions posted in the last quarter, for instance), company codes, transaction types, etc. You should pick such fields as filters, and define filter conditions against them.

In some sub scenarios(like programmed), the filter fields are predefined and cannot be changed.

Filters now allow you to consider both negative and positive numbers so that you can limit your selection to entries posted over 1 million and -1 million at the same time.

The filter criteria can also be determined in the runtime which the corresponding runtime value determination methods need to be implemneted first in the Metadata Lirary (IMG: SAP Customizing Implementation Guide -> Gonverance, Risk and Compliance -> Common Component Settings -> Continuous Monitoring -> Define Metadat Library).

In GRC 10.0, there are only three date-relevant runtime value determination methods implemented in Metadata Library.

Between Job Step Period from Date and Period to Date
Equal to Job Step Period from Date
Equal to Job Step Period to Date

You can check “Runtime Value Determination” and choose the runtime method to be used.

2.1.2.4 Deficiency Criteria

A deficiency is a condition which requires human attention. This section of the business rule lets you define what such conditions are. 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), pick a specific field and define a logical condition against it (e.g., document amount exceeding a set limit), or define a “Calculated Field” deficiency, which represents an arithmetic/logical operation on any of the available fields defined in the next step “Conditions and Calculations”.

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 lets you define a wide range of conditions using the usual logical operators such as equal to, less than, between, etc.

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 screenshot below shows two deficiency criteria. It is possible to have multiple deficiency criteria, each possibly with their own calculations (see below). 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.

2.1.2.5 Conditions and Calculations

For a “Calculated Field” deficiency (described in the previous section), this tab lets you define the calculation necessary to compute its value.

GRC 10.0 uses BRF+, the standard Netweaver rule engine, to let users define calculations. You can configure very powerful processing using this rule engine, and our 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 that is your need.

The “Conditions and Calculations” step (or corresponding tab when chancing the rule) allows three types of calculations: A Field Value calculation, a currency conversion, or grouping and aggregation (see screenshot below).

2.1.2.6 Output Format

This section is common to all business rule/data source types, and merely arranges the output of any detected deficiencies in the left-to-right column order specified. You can also hide unwanted columns here.

2.1.2.7 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 is notoriously 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.

Most monitoring rules can be run in synchronous or asynchronous mode. The details and implications of this are beyond the scope of this document.

2.1.2.8 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 most useful for configurable business rules and data sources, which are designed and implemented directly from the GRC 10.0 user interface. For programmed, SAP query, ABAP report and some other data source and business rule, these are not so useful, since the key design and testing activities for those sub scenarios occurs elsewhere, and GRC 10.0 mostly just reflects the implementation you did elsewhere.

For configurable rules, however, ad hoc queries are very useful indeed. The screenshots below show two modes of ad hoc query operation: just to collect the data as the data source would, and actually applying the rule logic to filter the data and apply deficiency logic.

Screenshot of Ad-hoc Query for data collect

Screenshot of Ad-hoc Query for Apply Rule

2.1.2.9 Attachments and Links

The picture below shows the step of Attachments and Links.

2.1.2.10 Confirmation

This is the final step to confirm the business rule is saved successfully. Also user can navigate to the same business rule to make the change.

2.1.3 Change a Business Rule

After finishing the business rule creation, user can open the existed business rule and make the change to it via the „Open“ button POWL or the link in the confirmation step of business rule creation.

The maintenance of business rule data was implemented as Object Information Floorplan (OIF) provided by NetWeaver Floor Plan Manager (FPM) with the equivalent tabs as the steps of creating business rule (GAF).

Screenshot of changing a business rule (Configurable)

Page tree