System Architect Essentials I

Working with PMF

Lesson: Introduction to Data Elements
July 2, 2012

PRPC V6 2 2
 Introduction to Data Elements

© 2013 Pegasystems Inc. 1

 Introduction to Data Elements

Now that we have elaborated our case into steps and stages, we can start to expand upon this
framework and create functional elements that end users can use to process and resolve cases. To
do this, we need to create user interfaces to present and collect information, data elements to store
that information, and business policies to act upon it.
Normally, as part of a Pega solution implementation, we would progress from our process to creating
user interface drafts, or mock-ups. This allows the implementation team to design the appearance
and flow of a solution without the need to create lots of other rules – namely, those that implement
the data elements and business policies that we just mentioned.
However, to more effectively teach the basics of Pega solutions, we will switch that order slightly. In
this course, we discuss data elements and data modeling first, before moving on to the user
interfaces, and ultimately business policies.
To understand how Pega solutions process cases, we need to understand how PRPC handles data.
To do that, we start with the fundamental unit of data: properties.

© 2013 Pegasystems Inc. 2

 Introduction to Data Elements

In a Pega solution, we want to allow end users to create, process, and resolve cases. This requires
information – we collect information important to the case, which we then use to make decisions to
best process and resolve the case. Without data, we don’t have a case to process.

© 2013 Pegasystems Inc. 3

 Introduction to Data Elements

In a Pega solution, we want to allow end users to create, process, and resolve cases. This requires information –
we collect information important to the case, which we then use to make decisions to best process and resolve
the case. Without data, we don’t have a case to process.
For example, if we want to create a case to process a change of address for a customer – say for a checking
account or an insurance policy – we need data: the identity of the customer, the current address, and the new
address.

© 2013 Pegasystems I 4
 Introduction to Data Elements

As part of our implementation of a case, we create a data model to represent and store information.
The fundamental unit of the data model – the entity that stores the data we collect from and present
to an end user – is called a property. In the next lesson, we will learn how a property relates to the
over-arching data model. For now, however, let’s just focus on what a property is, and how PRPC
uses it to store data.

© 2013 Pegasystems Inc. 5

 Introduction to Data Elements

When we look at data, we generally look at it in one of two ways: as a series of independent,
unaffiliated elements, or as a grouping or collection of related elements.
If a patient asks their doctor for their weight, the doctor puts them on a scale and answers their
question with a number.
Now, if instead they ask their doctor about their health, they get much more information – not just
their weight, but other information, such as: how their weight compares to the population in general,
their blood pressure, their pulse, and the results of a blood test or two. By reviewing all of this
information, the doctor can answer the question “How am I?”
So, we have two different types of information, depending on the question we ask: a single value –
our weight – or a grouping of information.
In a Pega solution, data is treated the same way; as either a discreet, single value with no intended
correlation with any other value, or as a collection of related values. This distinction is explained by
the mode of a property.
As a general rule, system architects worry about two types of modes for a property: value modes and
page modes. Value modes describe a single piece of information, such as weight, while page modes
describe an aggregation of information, such as a patient.
For the rest of this lesson, we will focus on the value modes – specifically, single-value properties. In
the next lesson, we discuss the page modes, and how they relate to value-mode properties. PRPC
also supports two other types of property modes: Java objects and Java properties, which are more
advanced topics and beyond the scope of this course.

© 2013 Pegasystems Inc. 6

 Introduction to Data Elements

Within our solution, we can use one of three value modes: Single Value, Value List, or Value Group.
That sounds complex, but really isn’t. Let’s look at some examples to better understand what each
mode represents.
A property of mode Single Value – also known as a single-value property – represents a single piece
of information, with no implied relation to any other information. Name is an example of a single-
value property.
A Value List is an ordered grouping of related information. If you wanted to discuss someone’s
employment history – where the order is important – you could look at the job title as an ordered list.
The first item in the list might be “Associate Editor”, the second might be “Editor”, and the third
“Senior Editor”. Each is still a single piece of information, but there’s a clear relationship between all
three, and we need a way to identify each one.
A Value Group is an unordered grouping of information. If we ask someone for their telephone
number or email address, they might respond with the question, “which one?” So, it’s important to
qualify which telephone number we want: the number for their telephone at home, or their telephone
at work, or the number for their mobile telephone. We don’t usually need to know all of their numbers
– we only dial one number at a time – but it’s important to have access to all of them, so we know
which one we need to dial. That means we need to be able to identify the contextual meaning of each
number: home, work, or mobile.
So, if we were to refer to each of these data elements, we might do so thusly:
• Name,
• Job Title (1), Job Title (2), or Job Title (3),
• And Phone (Home), Phone (Work), or Phone (Mobile).

© 2013 Pegasystems Inc. 7

 Introduction to Data Elements

As a system architect, the property mode we use most often is single-value, so we’ll concentrate on
that particular property mode for the rest of the lesson. However, remember that no matter which
mode we use, these concepts still apply.
When we want to store information, we first need to understand what type of information we have. Is
it a number? Text? A date or time?
To differentiate between these differing types of information, we can assign a type to a property. This
allows us to identify the type of information we want the property to store. By assigning a type to a
property, we can also ensure that users provide valid information. For example, if we ask someone to
provide their name, we want text, and not a number. If we ask their age, we want a number, not a
description such as “young” or “old”. And if we ask their date of birth, we want a specific type of
number – a date.
When we create a property, we can assign to it one of ten different types. Let’s discuss them briefly.

© 2013 Pegasystems Inc. 8

 Introduction to Data Elements

First, we already discussed one type: text. Text properties store a series of characters – sometimes
referred to as a “string” of characters – such as “Steve”, “duck, dodge & weave”, or an entire chapter
of a book. Text properties can store any allowable Unicode character – both graphical characters and
non-graphical characters such as tabs, line breaks, and carriage returns.
We also have several variations on textual data:
• Identifier, which can only store text strings that do not contain double quotation marks (“”),
tabs, carriage returns, or line breaks.
• Password, which can only store encrypted graphical characters.
• Encrypted Text, which can store encrypted graphical characters – similar to the password
type – but can be decrypted for display.

© 2013 Pegasystems Inc. 9

 Introduction to Data Elements

Then we have time-keeping types:

• Date, which stores a calendar date in the format YYYYMMDD – four digits for the year
(YYYY), two digits for the month (MM), and two digits for the day (DD).
• TimeOfDay, which stores a local time in the format HHMMSS – two digits for hours (HH),
two digits for minutes (MM), and two digits for seconds (SS). Local times are not dependent
upon a time zone.
• DateTime, which stores a UTC (Coordinated Universal Time) value. DateTime data is stored
as a combination of Date and Time Of Day formats, and all values are normalized to
Greenwich Mean Time (GMT).
With these property types, the value presented to the end user may differ from the internal
representation. An internal date of 20131202T052709 may appear to the user in a variety of formats.

© 2013 Pegasystems Inc. 10

 Introduction to Data Elements

Next, we have number types:

• Integer, which can only store positive and negative whole numbers, and zero.
• Decimal, which can store non-whole numbers. Decimals are well-suited for recording
numbers with a few decimal digits, such as currency amounts.
And finally, we have a Boolean property type, named TrueFalse. TrueFalse properties are used to
store data that must be one of two values – typically true/false, yes/no, or on/off.

© 2013 Pegasystems Inc. 11

 Introduction to Data Elements

Now that we know the types of data that we can store, let’s discuss how to create a property.
In Pega 7, we can create properties from a flow action. When we do, we enter the name of the property, select
its mode and type, and provide some basic information about how we plan to use the property. We can also
provide some basic configuration information about the property. We can define a property as a calculated value,
a required value, or a read-only value, dependent upon how we intend to use the property in the user interface.
A calculated property is computed automatically by PRPC. We’ll learn how to compute a value with a particular
type of rule called a Declare Expressions rule in an upcoming lesson.
A required property must have its value provided by the end user when completing the form. If the user neglects
to enter a value for the property and submits the form, the application returns an error message and prevents the
user from advancing until they provide a value.
A read-only property is uneditable on the form. Read-only property references allow end users to review data,
prevent them from editing the data.
When we finish, PRPC automatically creates the properties we specified, as well as the UI rule – called a section
– that it needs to display them to the user. This allows us to test the properties by running our process and
entering values into the provided fields.
But what if we need to restrict user input to a set of specific values? For example, we want users to enter an
urgency for their purchase request – but we need them to enter that urgency consistently, from one purchase
request to another.
With a property, we can define allowable values, from which the end user can choose the most-appropriate
value. This list is part of the property definition, so whenever we use this property in the UI, the user will always
have our allowed choices. Since we want to display a user-friendly label for each value, we can use a specific
type of list called a prompt list.
And the next time we view the property on the UI, we see our list of allowed values.

© 2013 Pegasystems Inc. 12