Defining Data Types in Pega's App Express

To conclude the four step procedure for setting up applications with App Express, we will touch upon pre-defining data type classes. To quickly recap how Pega explains the notion of data types, this is what they have written in the glossary documentation:

Data types define and hold data for your application. For example, a Customer data type might be used to manage customer contact information. It might include the customer´s name, email, phone number, and so on.

In other words, the data type called Customer acts as a reusable container for a set of properties. Which properties exactly is of lesser importance for now. Remember that each data type can be extended - and typically will evolve - over time as the application grows. Common questions for determining data types could be:

• What information does this application need to capture from its users and how do we commonly call this set of properties?
• What other information sets might each case type produce or require during processing?

Here´s an example list of data types for ABC´s Booking application:

Reuse Layer

Apart from the Name and Description the wizard expects you to choose a Reuse layer. This selection will tell PRPC to create the corresponding Data-class below that level in the class hierarchy. Implementation has the smallest scope and is specific to this application (ABC-Travel-Data). Enterprise will allow you to reuse this very same data type across other applications on the same system (ABC-Data) as well. Here we´ve decided that Airport and Customer are of concern to any Pega application, where as the Itinerary and Leg are just related to and thus placed within the Traveling app.

Practical Approach

It will take some previous experience in or outside of PRPC to determine useful data types upfront. The related science of data modeling is sometimes under-appreciated, but can make the difference in a maintainable application versus a "spaghetti incident" of unorganized and unclear properties.

My advice is to draw up pictures or even UML diagrams of any entities one can think of in your functional domain. These neither need to be exhaustive nor 100% correct. Just draw a circles around the general notions that even the competition would understand and have.

Engage the business and collaborate with any domain expert to identify a high-level taxonomy if you will. These terms could be a good indication that the application would need a data type for that term or at least some property in your high-level data model.

It proofs to be useful to organize a brainstorm session with the well-experienced few. Start out listing all functional types the group can think of; then scratch the smaller insignificant types. Technical types such as any enumerations can be introduced later as needed.

In conclusion, perhaps the group didn´t think of all applicable data types right away. Don´t worry because you can define those later on; through the Data Explorer on the left side panel. Do make sure you create those directly on the "trunk" and not in some branch ruleset of your application or else you could run into trouble.

---

This is the fourth article in a series about the screen flow steps in Pega´s App Express:

1. Application settings
2. Business objectives
3. Case types
4. Data types

[Edgar] (4/7/2017 4:10:33 PM)