PRPC Reporting
User Guide
Version 6.2 SP2
Copyright 2012
Pegasystems Inc., Cambridge, MA
All rights reserved.
This document describes products and services of Pegasystems Inc. It may contain trade
secrets and proprietary information. The document and product are protected by copyright
and distributed under licenses restricting their use, copying distribution, or transmittal in
any form without prior written authorization of Pegasystems Inc.
This document is current as of the date of publication only. Changes in the document may
be made from time to time at the discretion of Pegasystems. This document remains the
property of Pegasystems and must be returned to it upon request. This document does not
imply any commitment to offer or deliver the products or services described.
This document may include references to Pegasystems product features that have not been
licensed by your company. If you have questions about whether a particular capability is
included in your installation, please consult your Pegasystems service consultant.
For Pegasystems trademarks and registered trademarks, all rights reserved. Other brand or
product names are trademarks of their respective holders.
Although Pegasystems Inc. strives for accuracy in its publications, any publication may
contain inaccuracies or typographical errors. This document or Help System could contain
technical inaccuracies or typographical errors. Changes are periodically added to the
information herein. Pegasystems Inc. may make improvements and/or changes in the
information described herein at any time.
This document is the property of:
Pegasystems Inc.
101 Main Street
Cambridge, MA 02142-1590
Phone: (617) 374-9600
Fax: (617) 374-9620
www.pega.com
Document: PRPC Reporting User Guide
Software Version: 6.2 SP2
Updated: 2-3-2012
Page 1 PRPC Reporting User Guide (v6.2 SP2)
Overview
This document provides recommendations for how to develop an organizational
strategy for reporting within applications developed using Pegasystems’ PRPC
product, and framework solutions built using PRPC.
This document is organized around the following core questions that customers
often have regarding reporting, which should drive the development of their
organizational strategy:
What are the use cases and requirements for reporting? How will reporting
be used, and what kinds of reports are required? What factors should I
consider in designing a report?
What are the organizational roles required for reporting? Who should fill
them? What background should they have? What training or other
information do they need to be successful?
What reporting features are available in PRPC? Which reports should I
build within PRPC, and which reports should I build with other tools? How
does reporting in PRPC compare to reporting with other tools?
How is data represented and stored in PRPC? How should we optimize the
PRPC database in order to make reports easier to create and run more
efficiently? How do I include data from external databases (other than the
PRPC database) in my PRPC reports? How can I migrate PRPC data to a
data warehouse, or access PRPC data with other reporting tools?
How do I control and administer access to and execution of reports? How
do I manage the impact of reporting on the performance of my PRPC
applications?
This document is intended as the introduction to PRPC reporting for all customer
audiences interested in reporting: business sponsors, business analysts, end user
managers, developers, and database administrators. At the end of each section is
a list of references to more detailed articles on key topics that should be read by
each of these audiences. Most of these references are to articles on the Pega
Developer Network (PDN). If you wish to browse all of the PDN articles on
Reporting, go to the Reporting Table Of Contents.
Reporting Use Cases and Requirements
PRPC is used to build an extremely wide range of applications, all of which have
different reporting requirements. Some general themes occur across these
applications, however, since most PRPC applications involve the processing of
cases or work items:
Reports are used in two common ways, which serve different purposes, are
used by different users, and have different performance characteristics:
Page 2 PRPC Reporting User Guide (v6.2 SP2)
o Many reports are used to retrieve information that is then
embedded in controls like grids within forms which end users use
to create, update, and complete a case or work item, or else used
to retrieve data for internal processing, such as updating worklists.
Embedded reports tend to run very quickly because they retrieve a
limited amount of information that is relevant to a single case or
work item, and they are executed each time the form is opened.
Requirements for these reports will be very specific to the type of
cases or work being processed, and the design of the user interface
for the application.
Figure 1: Report results embedded as a chart within Case Manager portal
o Ad hoc reports are run on demand, typically by analysts and
managers, to provide insight into organizational measures like
overall workload and status, organizational performance, key
performance indicators, trends over time in workload, etc. They
often involve summarizing large amounts of information over days,
weeks, or months. While they can be very dynamic, there are often
common patterns in the way such reports analyze loads, quality,
performance, etc. The performance impact of ad hoc reporting on
the database and the rest of the application can be quite variable.
Reports vary in terms of whether they show detailed or summarized
information:
o List-type reports show, on each row, detailed information about an
individual case, work item, product, or other type of data. For
example, a user may ask for a list of their current open work items,
Page 3 PRPC Reporting User Guide (v6.2 SP2)
and see a list like this:
Figure 2: A list-type report
o Summary-type reports show, on each row of the report, counts,
totals, averages, or other data summarized from multiple cases or
work items. For example, a user may ask for a summary of cases
by the operator or user who entered them, based on whether they
were resolved in a timely manner, and see a report like this:
Figure 3: A summary-type report (with chart)
o As Figure 3 shows, summary reports may also use a chart or graph
to display the summarized information. Available chart types
include bar charts, column charts, line charts, pie charts, bubble
charts, and gauges.
Here are some key questions to consider when creating or modifying a report:
Page 4 PRPC Reporting User Guide (v6.2 SP2)
What question(s) will the report answer? Make sure the report
answers important questions to which business users really need answers.
Who is it for? Who is the audience for the report? What type of reports,
and what level of detail are they comfortable reviewing?
Is there an existing report that (almost) does this already? It is
almost always easier (and more reliable) to modify an existing report,
rather than create a new one.
Where is the data? Productivity in creating reports, and accuracy and
reliability of results, depends on knowing where the required data elements
are in the application data model.
Recommendations
You can get insight into the types of ad hoc reports you might want by
looking at the out-of-the-box management reports shipped with PRPC. For
example, you will see that most of the out-of-the-box management reports
display information about cases or work items, and assignments. See the
references below, and review the descriptions of these reports, to help you
think about what types of reports you might need.
Developers should always consider using copies of these reports as starting
points for implementing similar ad hoc reports.
End users and developers who will be building or modifying reports should
be provided with a data dictionary for the application. The data
dictionary should list the different types of data within the application most
likely of interest for reporting, and names and descriptions of the fields or
columns within each data type most likely of interest. This will provide end
users and developers with the context needed to assure them that the
fields referenced on the report are those they are familiar with.
Because the performance impact of ad hoc reporting on the database and
the rest of the application can be quite variable, you should try to estimate
the number of potential users and the frequency of report use that you will
require, especially for reports that summarize large amounts of information
over large time frames.
Additional Information
Topic Recommended For Developers DBAs Managers
& Analysts
Listings and descriptions of out-of-the-box reports in PRPC Listings and descriptions of out-of-the-box reports in framework solutions -- See the Implementation Guide for each solution
Organization Roles and Training
The following organizational roles are key for reporting:
Page 5 PRPC Reporting User Guide (v6.2 SP2)
Application Developers (Developers) will be responsible for building
embedded reports, reports that analyze the design and structure of the
application itself, and in many cases ad hoc reports, especially more
complex ad hoc reports. They must be:
o Trained in PRPC.
o Very familiar with database concepts.
o Very familiar with the design of the application, and particularly of
the application data model, so that they understand the meaning
and content of all relevant data elements that will be included on
reports.
Business analysts and end-user managers (End users) who will be
frequently developing reports themselves or customizing existing reports
must be:
o Familiar with the business processes which the application supports.
o Familiar with the application data model, so that they understand
the meaning and content of all relevant data elements that will be
included on reports.
Database administrators (DBAs) will be responsible for maintaining the
PRPC database, and monitoring report usage. In addition to their usual
background, they should have basic training in PRPC so that they
understand how application data is stored in the database.
Recommendations
Pegasystems offers courses on reporting for PRPC version 5.5+. These
courses are highly recommended for any developers creating reports, and
also for business analysts and other end users who will be frequently
creating reports.
Application developers, business analysts, and end-user managers who will
be developing or modifying reports should view the short, 1-2 minute on-
line tutorial videos on reporting listed below.
Additional Information
Topic Recommended For Developers DBAs Managers
& Analysts
See the Pegasystems’ training catalog for: PRPC v5 Reporting Course PRPC v6 Reporting Course
Review these tutorial videos on Report Definitions:
1 – Introduction 2 – Using the Report Browser 3 – Scheduling Reports 4—Creating, Editing, and Viewing Reports: Basics 5 – Adding Columns and Calculations 6 – Reordering and Sorting Columns 7 – Changing the Filter Conditions in a Report
8 – Working with Summary Reports 9 – Working with Charts
Page 6 PRPC Reporting User Guide (v6.2 SP2)
Reporting Features in PRPC
PRPC provides a range of powerful reporting features both for developers, and also
for business analysts and managers, who can satisfy their own reporting needs,
creating a range of both simple and complex reports in seconds.
Report Definitions, List Views, and Summary Views
In PRPC versions prior to version 6, two different report designers were provided
to define list reports and summary reports: List Views and Summary Views.
Starting in version 6, a single, easier-to-use report designer, called Report
Definition, can be used to create any kind of report.
Report Definitions are created using an intuitive, WYSIWYG design interface.
Intelligent defaulting of options and pre-defined reusable report element reduce
the number of steps and the likelihood of errors when creating Report Definitions.
For example, the use of pre-defined joins shipped with the product for all common
data classes lets developers create reports without having to define joins. A
Report Wizard is also provided to lead less experienced users through the steps
needed to create a report.
Report Definitions include a wide range of both simple and sophisticated features,
including:
List-type and summary-type reports, and a range of charts.
Automatic drill down and drill up or summarization, which is also
customizable.
Pivot tables.
Custom formatting of the rows and headers of reports.
Top/Bottom n.
A wide range of built-in functions for use in defining calculated columns,
and the ability for developers to easily add custom functions for end users.
The ability to automatically generate sophisticated SQL such as sub-
SELECTs, and EXISTS(), NOT EXISTS(), and HAVING clauses, without
having to know SQL, through the ability to define and reference columns
from sub-reports.
Report Definition is the preferred report designer, and contains many features not
available with List Views and Summary Views. As of version 6.2 SP2, however,
there are some List View and Summary View features not yet available for Report
Definitions.
Page 7 PRPC Reporting User Guide (v6.2 SP2)
Accessing and Running Reports
In PRPC versions prior to version 6, List View and Summary View reports are
accessed and run from the Monitor Activity page of the Manager portal:
Figure 4: The Monitor Activity page in the Manager Portal in PRPC v5.5
In version 6 of PRPC, reports are accessed and run from the Report Browser,
which makes it easier for users to browse, search, organize, and run existing reports. It
allows users to access and run any kind of report (Report Definition, List View, or Summary
View). It lets users easily create their own reports, and share them with other users.
Also, starting in version 6.2, users can schedule reports to run on a one-time or recurring
basis, and either enter a list of users to receive the results thru email or let other users
subscribe themselves to scheduled reports of interest to them.
Page 8 PRPC Reporting User Guide (v6.2 SP2)
Figure 5: The Report Browser in the Case Manager Portal in PRPC v6.2
Out-Of-The-Box (OOTB) Reports
As mentioned above, PRPC provides a large number of pre-defined, or out-of-the-
box reports, that can be used as is, or easily modified, to provide customer
management with summary and detailed views of cases, work, assignments, etc.,
that can be used to monitor and analyze status, performance, and quality.
Manager portals shipped with PRPC also provide customizable dashboards that can
be used to display any desired reports for use in monitoring operational data and
key performance indicators.
Security and Performance
Report Definitions, List Views, and Summary Views all take advantage of PRPC’s
extensive security features to control access to these features based on user roles
and privileges. In addition, Report Definitions give developers extensive control
over what commands are available and what design changes, if any, end users are
allowed to make to a report.
Report Definitions also provide customizable resource governors that automatically
interrupt database queries if limits on rows retrieved or elapsed time are
exceeded. List-type reports offer paging options to allow a user to page through
large sets of results a few rows at a time, for better performance.
Both the access to commands and features, and the resource governor limits, can
be defined at the application, class, and individual report levels, using the
Page 9 PRPC Reporting User Guide (v6.2 SP2)
template reports pyDefaultReport and pyDefaultSummaryReport. See the section
below on Report Administration for more information.
Business Event Processing
An alternative to traditional reports and dashboards, PRPC allows developers and
authorized managers to define business events in PRPC that provide immediate
notifications to users who subscribe to the event (thru emails, RSS feeds, SMS,
etc.), or take other actions. The developer or manager defines the conditions
which will trigger the event, which can refer to a single change to a case or work
item, or else to a pattern of changes to multiple cases or work items occurring (or
not occurring) over a specified period of time.
Recommendations
Developers, business analysts, and end users managers should review the topics
listed below.
Additional Information
The Table Of Contents for PDN Reporting articles is
http://pdn.pega.com/Devnet/PRPCv5/KB/24217.asp#100. Selected key
articles are listed below.
Topic Recommended For Developers DBAs Managers
& Analysts
Listings and descriptions of out-of-the-box reports in PRPC Listings and descriptions of out-of-the-box reports in framework
solutions -- See the Implementation Guide for each solution
Creating Report Definitions (v6)
Creating List Views and Summary Views (v5) Modifying Report Definitions in the Report Viewer (v6) Using the Report Browser (v6) Creating trend reports with Report Definitions (v6) Creating trend reports with Summary Views (v5) How to schedule reports and subscribe to scheduled reports (v6)
Differences between Report Definitions, List Views, and Summary Views
How to create and subscribe to business events
Page 10 PRPC Reporting User Guide (v6.2 SP2)
How PRPC Data Is Stored and Accessed
How Data Is Stored
Most reporting is performed against cases and work items, plus other,
associated types of data such as work assignments. Each of these types of
data is referred to as a class of data in PRPC, and an individual case or
work item is referred to as an instance of that class. Each case or work
items includes many fields of information, referred to as properties, such
as customer or product names, the date when the item was created, its
current status, etc.
All of this data is stored in a relational database (DB) managed using a
database management system (DBMS) product such as Oracle, SQL
Server, UDB, etc. Classes, instances, and properties are conceptually
similar to the tables, rows, and columns in the database. Physically, they
may be stored differently in the database, as discussed below.
The data entered or displayed in application user interface forms is initially
stored in memory on what’s known as the clipboard (which is not visible
to the end user). When an end user clicks OK or Submit to save changes,
the data is then written to the database. A case or work item is written as
a single row within a table in the database. See the following diagram:
Figure 6: Data As Stored At Different Stages Of Its Use
Report Definitions can also access and report on data not in the PRPC
database, but stored in external databases. This requires using PRPC’s
integration features to define tables in external databases as classes within
the PRPC application.
As indicated above, the data for a class instance representing a case or work item
is stored in a single row or record of the database table for that class. However,
the data model for a case or work item may be quite large and complex, including
multiple levels of hierarchically embedded sets of fields (PRPC refers to these as
pages, page lists, and page groups).
Page 11 PRPC Reporting User Guide (v6.2 SP2)
Most of the database operations that PPRPC performs (opening a case or work
item from a worklist or workbasket, saving changes to a case or work item,
reading a business rule, etc.) are optimized through PRPC’s architecture which
uses a single binary large object (BLOB) field within the record to store all of
the data for the case or work item.
The use of a BLOB field to store (in a proprietary compressed form) all of the data
for a case or work item offers the following powerful advantages:
BLOBS can hold any amount of information since there are no physical size
constraints on the BLOB fields, such as maximum column lengths or page
sizes. BLOB values are compressed by PRPC (using a proprietary internal
algorithm) for low storage overhead.
BLOBs deliver agility that lets customers Build for Change®, PRPC’s
number one goal for this architecture. No matter how complex the data
model, all of the data for a case or work item is stored in a single field.
This means that business analysts and developers are able to dynamically
change their data model or add new pieces of information to a business
process, in real time if necessary, without having to involve DBAs in
making database changes. Not only that, but the BLOB makes it easy to
maintain multiple versions of the data model over time, and allows for
different cases with different data models to all be stored in the same
table.
BLOBs deliver high performance. It is faster to retrieve a case and place all
of its information in memory on the clipboard for use by the application,
and also faster to save changes to that information. Instead of having to
retrieve data from multiple tables using joins, and then perform complex
object-relational mapping of the retrieved information to place it into
memory on the clipboard, PRPC can simply read a single record out of the
database, decompress the BLOB field value and load the data, which is
already structured in the format required by the rest of the application, into
memory and onto the clipboard.
The use of the BLOB to store case and work data is highly optimized for
performance and flexibility in operations on individual cases or work items.
However, reports (and other list-centric activities like such as displaying work lists
and work queues, finding open items by Customer or Policy ID, etc.) retrieve not
the entire contents of the BLOB, but only specific properties from multiple cases or
work items through database queries using the SQL language. PRPC reports
generate appropriate SQL queries automatically for the user, based on their
description of the desired report. Retrieving specific properties directly from the
BLOB for many instances can be inefficient. Because of this, PRPC offers a hybrid
data storage model in which data can be stored as relational database columns
as well as in the BLOB, offering the best of both approaches.
More technical readers will want to review Appendices 1 and 2 for more
information.
Page 12 PRPC Reporting User Guide (v6.2 SP2)
Recommendations
Optimize properties that will be used in ad hoc PRPC reports, or any PRPC
reports retrieving or aggregating more than a few hundred class instances,
by exposing these properties as database columns or building
declarative indices for much better performance.
If you want to export the some or all of the data from the PRPC database
to an external data warehouse, where it will be combined with data from
other systems of record to provide enterprise-wide reporting to
management, use Pegasystems’ Business Intelligence Exchange (BIX)
product to extract the desired data from the PRPC database.
PRPC provides an option that lets reports query a replica of the PRPC
production database, called an Alternate DB. This option uses the DBMS’
replication services to maintain an exact copy of the data in the production
database in the replica. The use of this option eliminates the impact of
report query processing in the production database, although it adds a very
slight cost to database commits within the production database. If your
production database is highly loaded, and you are concerned about the
impact of reporting, especially ad hoc reporting, on production processing,
you should consider this option.
Additional Information
Topic Recommended For Developers DBAs Managers
& Analysts
How to expose a property as a database column
How to create declarative indices
Accessing multiple databases
About BIX
BIX Frequently-Asked Questions
Page 13 PRPC Reporting User Guide (v6.2 SP2)
Report Administration
PRPC automatically collects usage statistics for reports run from the Report
Browser in the Log-ReportStatistics class. Standard reports are provided in this
class to use in analyzing this information, and customers may either customize
these reports or define their own additional reports to analyze this information.
In addition, PRPC provides a number of general-purpose tools for monitoring PRPC
applications and analyzing performance. DBAs and developers may use these
tools also to monitor the performance impact of reports and troubleshoot any
discovered issues:
The Performance Analyzer (PAL), can be used during all the major steps
in the life cycle of an application. It is designed to provide the developer
with insight into the performance profile of the application processes that
they are building during the time that they are building them. PAL is also
designed to be used during the testing stages for QA, as well as for
performance and scale testing. Finally, it is available for use in production,
to help identify production issues. It facilitates the collection of counters
and timer readings, stored in the requestor, that an application developer
can use to analyze performance issues in a system. For example, the
DBTrace feature within PAL creates a detailed log of SQL statements sent
to the PegaRULES database.
The System Management Application (SMA) is a flexible and powerful
tool that monitors PRPC system functions using Java Management
Extensions (JMX).
The Autonomic Event Services (AES) product. AES is an independent,
self-contained system that gathers, monitors, and analyzes performance
and health indicators from multiple SmartBPM systems across the
enterprise. AES combines server-level and BPM-level enterprise monitoring
in a single web-based tool. AES is not only a monitoring console, but also
an intelligent agent that can predict and notify administrators when system
performance or business logic problems occur. AES provides suggestions
and administration tools to correct them.
Recommendations
Analyze the report usage statistics to determine where you need to
optimize.
Optimize and index columns frequently used in filtering, sorting, grouping,
and ranking.
Set appropriate resource limits on rows retrieved and elapsed time in the
pyDefaultReport and pyDefaultSummaryReport templates (Data Access
tab).
Turn paging on by default in the pyDefaultReport template (User
Interactions tab).
Page 14 PRPC Reporting User Guide (v6.2 SP2)
Make sure appropriate filter conditions, especially on time frame, are
always included in the pyDefaultReport and pyDefaultSummaryReport
templates.
Make sure the option to show actual instead of simulated data is unchecked
on the pyDefaultReport and pyDefaultSummaryReport templates (User
Interactions tab), and encourage users to make editing changes using
simulated instead of actual data.
Make sure the option to display unoptimized properties in the Data Explorer
is unchecked on the pyDefaultReport and pyDefaultSummaryReport
templates (User Interactions tab).
Additional Information
Topic Recommended For Developers DBAs Managers
& Analysts
Overview of the Performance Analyzer (PAL)
Running the DBTrace feature
About AES
About the System Management Application (SMA)
Performance guidelines for the PRPC production database
Detecting and remedying report performance problems
Page 15 PRPC Reporting User Guide (v6.2 SP2)
Appendix 1: Data Access Options For PRPC
Reporting
This appendix provides additional details about options available for accessing
data for PRPC reports.
1. Direct access of unexposed properties in BLOB using stored
procedures
Description: SQL generated by PRPC reports invokes a stored procedure
to access properties in BLOB field by opening and parsing the BLOB. This
option is only available for use with Report Definitions in PRPC version 6.2
SP2+. This method offers the following advantages:
Requires no changes to application design, or to the PRPC database
schema, and no implementation or maintenance effort. PRPC
automatically uses this method to read properties only available in
the BLOB.
Results are live and consistent with data of record.
Report Definitions that result in poor performance using this method
are automatically interrupted at the database level using user-
customizable resource governors on elapsed time and rows
returned.
No impact on performance of work processing and database
commits.
2. Column exposure and declarative indices
Description: Top-level BLOB properties to be used for reporting are added
as database columns to the class table; these exposed columns are
updated in addition to the BLOB each time an instance update is committed
to the database. BLOB properties in embedded pages, page lists, and
page groups to be used for reporting are stored in columns within separate
tables called declarative indices. This normalized representation using
declarative index tables allows rows in these tables to be automatically
joined to their corresponding class tables using appropriate foreign keys.
Adding an exposed column or a declarative index in PRPC version 6.2+ is
very straightforward and can be done by simply right-clicking any property
and selecting the Optimize For Reporting option in the Designer Studio.
However, the newly added column or table(s) must also be populated with
values for existing class instances, which for a class with large numbers of
instances may take several minutes or even hours.
Available in all PRPC versions.
Available for use by all PRPC reporting rules: Report Definitions,
List Views, and Summary Views.
Those BLOB properties exposed in database columns (either in the
class table or in a declarative index) are available for external
reporting tools as well and can be accessed using regular SQL.
Page 16 PRPC Reporting User Guide (v6.2 SP2)
Requires no changes to application or data model design. SQL
generated by PRPC reports automatically access exposed columns
and declarative index tables where they exist.
Properties can be exposed at any point during an application
lifecycle.
Results are live, transactional integrity is preserved, and results are
consistent with data of record.
For higher performance, exposed columns and columns in
declarative index tables can be indexed within the DBMS.
Performance is equivalent to any well-written SQL executed against
a well-tuned database.
This “hybrid” database design leverages the agility and efficiency of
BLOBs whenever possible, while allowing data to be exposed for
transparency and efficiency of SQL queries in reports as desired.
NOTE:
PRPC does this automatically for a set of properties common to most
classes. Most class tables in the PRPC database include a small set of
properties that are automatically exposed as columns within the table: a
key column (pzInsKey), and other core PRPC attributes such as
pxCreateDateTime, pxObjClass, etc. The column named pzPVStream
contains the BLOB. See the diagram in Figure 3.
This means that technically, PRPC offers a hybrid data storage model
that combines the power, flexibility, and high performance of the BLOB for
transaction processing with the traditional relational model for flexibility
and performance in processing ad hoc reports.
3. Business Intelligence eXchange (BIX)
Description: The above options may not be satisfactory if you wish to
access most or all of the properties in the BLOB, or if you want to export
the some or all of the data from the PRPC database to an external data
warehouse, where it will be combined with data from other systems of
record to provide enterprise-wide reporting to management:
Page 17 PRPC Reporting User Guide (v6.2 SP2)
Figure 7: Integrating PRPC Data In A Data Warehouse
Pegasystems provides an add-on product called the Business
Intelligence Exchange (BIX), that can be used to extract any or all data
from any BLOB fields in the PRPC database to an external database or data
warehouse for reporting (or to other output formats including XML or
comma-delimited files). BIX runs as a batch process, and so the extracted
data is not identical in real-time to that in the PRPC database. The extract
process can, however, be run as frequently as desired.
BIX has been tested and certified by Pegasystems as accurately
reading and extracting information stored in Pegasystems’ BLOB
fields, and does so as efficiently as possible.
BIX is easy to set up and maintain. A user interface is provided
within PRPC for selecting data elements using graphical pick lists,
filtering which records to extract, viewing the history of extractions
performed and monitoring exception conditions.
BIX is architected to run as a separate process independently of
PRPC. It only needs access to the PRPC database. BIX can be run
on a separate server, and extracts can be run even when PRPC is
not running.
Any and all data in PRPC database BLOB fields may be extracted,
including work, assignments, history, logs, system rules and other
system data.
Filtering options make it easy to select which class instances to
extract based on any properties of a class. A special option makes
Page 18 PRPC Reporting User Guide (v6.2 SP2)
it easy to select only those instances that have been created or
updated since the last extract.
External reporting tools can use SQL to access the extracted data if
it is output to a data warehouse, since BIX normalizes the data as it
writes it to the destination database (as it does when writing to
declarative indices within the PRPC database).
Page 19 PRPC Reporting User Guide (v6.2 SP2)
Appendix 2: Technical Notes On Data Storage In
PRPC
This section is intended for DBAs and developers only, and may be skipped by
other readers.
PRPC is an N-Tier JEE application that uses relational DBMS to manage two logical
databases:
Enterprise Rule Repository: The Enterprise Rule Repository holds all the
process models, business rules, user screens, case definitions, service
levels, data models etc. that define the way your application runs. When
users save a change to a class’ data model, to a process flow, or to a
decision table, what they’re really saving is a record to the Enterprise Rule
Repository.
Work Database: Logically separate from the Enterprise Rule Repository is
the Work Database, which stores information about cases and work items
in process and completed, such as status, date created and last updated,
customer info, attachments, work assignments, etc. Cases and work items
are never deleted from the database by PRPC.
These databases are logically separate. Physically, they can reside in separate
schemas or even separate databases, although this is not generally
recommended.
Page 20 PRPC Reporting User Guide (v6.2 SP2)
Figure 9: PRPC Multi-Tier Architecture
The following diagram shows the core classes/tables involved in representing and
storing work-related information in the PRPC database, and their relationships:
Figure 10: Core Classes/Tables Involved In Case/Work Processing