Designing the case structure

4 Topics
Release 1
Pega Platform 8.3.1
The case structure is one of the most important considerations when designing an application. Designing the case structure
encompasses identifying the individual business processes and how you represent each process (cases, subcases,
subflows). A poorly designed case structure may cause refactoring if present or future requirements become challenging to
implement.

After completing this module, you should be able to:

Identify
● cases given a set of requirements
Compare parallel processing options
●
Explain advantages and disadvantages of subcase and subflow processing
●
Determine when to use tickets
●
Topics

Case identification
How to identify cases
A case type represents a group of functionality that facilitates both the design time configuration and run-time processing of
cases. Pega Platform provides many features that support case processing, such as the case life cycle design (including
stages and steps), reporting, and security.

The LSA decides which Pega Platform features to use—processes (flows) , subprocesses (subflows), data objects, child
cases (subcases), or other components—when designing a solution.

In some applications, a case type is easily identified as it represents a single straightforward business process. However, in
other situations, producing a robust design with longevity may require careful consideration.

In the Pega Platform, other dependencies on the design include reporting, security, locking, extensibility, and specialization.
Consider all requirements before creating the design since this forms the foundation for the application.

The case design begins by identifying the processes in the application. Next, you determine if child cases are warranted,
including any additional processes that may benefit from case management. As you identify case types, consider
specialization needs for these case types. Also carefully consider future extensibility requirements before implementing the
case designs.

For example, a Purchase Request process involves identifying a list of the items, and quantity of each item to be purchased.
The list of items is reviewed and then forwarded for approval by one or more approvers. Then, the list of items is ordered.
When the items are ultimately received by the original requestor, the process is complete.

You can use several case designs to represent this business process:

A single Purchase Request Case for the entire process, with subprocesses for each line item
A Purchase Request case to gather the initial request that when approved spins off a single Purchase Order Case
A Purchase Request case to gather the initial request with Purchase Order child cases for each line item

All provided solutions may be initially viable, but the optimal solution takes into account current and possible future
requirements to minimize maintenance.
Guidelines for identifying cases
Basic questions to consider when identifying cases include:

Does the case represent the item(s) that require processing?

Is there a benefit to splitting the case (process) into multiple cases or child cases, or are parallel processes (parallel
flows) sufficient?
Is an additional case or child case really required?
If a child case is created, a general rule is that the processing of the main case depends on the completion of the child
case(s). Does this hold true?
Are there other present or future requirements, such as reporting and security, that may be more easily implemented by
adjusting the case design?

Carefully consider all of the questions. Some situations may not require additional cases(s) and could instead result in an
inefficient use of resources and an overly complex solution. Because creating cases involves additional processing, always
ensure you have a good reason for creating additional cases.

The previous Purchase Request example above illustrates these points:

If there were security requirements based on the approval of individual line item types, you might need to implement the
case design solution with child cases for individual line items.
If there is no specific requirement for line item processing, the simple solution involving subprocesses for each line item
might be suitable.
Adding a Purchase Order case may be unnecessary unless there was a requirement specifically stating the need for it
(for example, special reporting requirements).

Case identification may be straightforward or there may be situations where additional cases or processes could be
advantageous. An example of this is data that may support the case processing, such as customer or account data. In
situations where using the infrastructure provided by case processing for data—such as an approval process, security, or
auditing—may be advantageous, then providing a case may be more suitable than updating the data directly.

Case processing
Case processing
Requestors execute the majority of case processing in Pega Platform. Each requestor executes within its own Java thread.
The separate Java threads allow multiple requestors to perform actions in parallel. The most common requestor types are
initiated by Services, Agents, or different users logging on to the system to process cases.

The case design determines how efficiently the case is processed. An efficient case design accounts for steps or processes
that can be performed in parallel by separate requestors. One example is leveraging subprocesses to gain approval from
different users. Each approval process is performed by separate requestors. A more complex example is queuing tasks to a
standard agent in a multinode system. There are limitations to this type of parallel processing. Limitations differ with the case
configuration and the type of processing implemented.

The two major types of parallel processing options are same-case processing and child case (subcase) processing.

Same-case processing
Same-case processing occurs when multiple assignments associated with the same case are created. Each assignment is
initiated through a subflow (subprocess) that is different from the parent flow (process). Multiple assignments for a single
case are initiated through Split Join, Split For Each, or Spin-off subprocesses. The Split Join and Split For Each
subprocesses pause and then return control to the main flow, depending on the return conditions specified in the subprocess
shape. The Spin-off subprocess is not meant to pause the main flow as it is an unmanaged process.

All of these subprocess options may result in multiple assignments being created, leading to different requestors processing
the case (assuming they are assigned to different users). One limiting factor is locking. The default case locking mechanism
prevents multiple users from processing (locking) the case at the same time. This has been alleviated in the Pega Platform
with the introduction of optimistic locking. Optimistic locking allows multiple users to access the case at the same time, and
only locking the case momentarily when completing the assignment. The drawback is that once the first user has submitted
changes, subsequent users are prompted to refresh their cases prior to submitting their changes. The probability of two
requestors accessing the case at the same time is low, but the designer should be aware of this possibility and the
consequences, especially in cases where the requestor is a nonuser.

Child case (subcase) processing

The primary difference between chld case (subcase) and same-case processing is that one or more child cases are
involved. The processes for each child case may create one or more assignments for each child case. Locking can be a
limiting factor when processing these assignments. If the default locking configuration is specified for all child cases, then all
the related cases including the top-level case are locked while an assignment in any child case is performed. This can be
alleviated by selecting the Do Not Lock Parent configuration in the child case types. Locking is a significant difference
between subprocess (subflow) and child case (subcase) parallelism.

With the correct locking configuration, simultaneous processing may take place without interruption for child cases
(subcases), whereas a possibility exists for interruption when subprocesses (subflows) are involved.
This behavior must be accounted for, especially when automated tasks such as agents are involved. A locked top-level case
may prevent the agent from completing its task, and error handling must be incorporated, allowing the agent to retry the task
later on. If a design leveraging child cases with independent locking was used such that the agent operated on the child case,
it minimizes the possibility of lock contention. In general, lock child cases independently of the top-level case unless there is
a reason for also locking the top-level case.

When waiting for the child cases to complete processing, a wait step is used to pause the top-level case. If multiple child
cases of the same type are involved, you configure the same wait shape to allow the top-level case to proceed after all those
child cases are resolved or reach a specific status.

If different types of child cases are involved, a ticket is used in conjunction with the wait shape to allow the top-level case to
proceed only after all child cases, regardless of their type, are completed. The AllCoveredResolved ticket is used and is
triggered when all the covered child cases (subcases) are resolved. You configure the ticket in the same process (flow) as
the wait shape, and you place the ticket in the process (flow) at the location at which processing should continue. Configure
the wait shape as a timer with a duration longer than the time to raise the ticket.

Child case and subprocess comparison

You have many factors to consider when deciding on a suitable case design. The following table summarizes some
advantages of leveraging a design incorporating multiple cases or child cases (subcases).

Factor Consideration

Security Class-based security offers more options for security refinement using multiple cases.
Data security increases as child cases only contain data pertinent to their case.

Reporting Reporting on smaller data sets may be easier and offer potential for performance increase (the may
be a disadvantage if a join is required).

Persistence You have the ability to persist case data separately.

Locking You have the ability to lock cases separately and process them without interruption (significant in
cases involving automated processing).

Specialization This can be extended or specialized with a class or leverage Case Specialization feature.

Dependency Case processing can be controlled through the state of top-level or child cases.
Management

Performance There is pure parallel processing since separate cases may be accessed using separate
requestors.

Ad hoc You can leverage the ad hoc case processing feature.

processing

Advantages of a single case design involving only subprocesses are listed in the following table.

Factor Consideration

Data Data is readily available; no replication of data is necessary.

Reporting All data is readily accessible for reports.

Attachments All attachments are readily accessible (additional configuration is required for child cases).

Policy Implementing this feature is easier. Managing “Suspend work” when multiple cases are involved is more
Override complex.
Case hierarchy design: Injury and illness
Case design
Consider the following requirements by an automobile manufacturing company automating an Illness and Injury Reporting
application.

Like many corporations, the automobile manufacturing company must log work-related fatalities, injuries, and illnesses. For
example, if an employee contracts tuberculosis at work, then the illness must be logged in the company's safety records.

Certain extreme events, such as death, must be reported to the regulatory agency immediately. These reports are called
submissions. Submission processes and requirements differ by country. Some countries have additional rules, based on
state or province. Typically, these rules are more stringent forms of the national guidelines. There are also some guidelines
that are specific to injury type. A small subset of injuries requires injury-specific fields to be filled in. For example, with
hearing loss, the actual assessment of the loss, measured in decibels, must be recorded.

The Illness and Injury Reporting application must support two processes.

First, any injury or illness must be recorded. This is a guided and dynamic data-entry procedure that is specific to the
regulations of the country in which the plant is located. The culmination of these entries is an electronic logbook.

Second, the application must generate a summary of submission records for every plant per year. Each record summary
must be verified, certified, and posted. Notably, severe events must be reported to the regulatory body of the corresponding
country, and the status of this submission must be tracked. The reports of these record type are separate—there is never a
need for a list of records that is a mix of Injury Records, Annual Summaries, and Submissions. However, because
summaries are a culmination of injury records, and submissions are spawned by injury records, assuming that injury record
information is included in summary or submission report is reasonable.

The following images illustrates the requirements:

Design a case structure to support this application.

Solution
You probably identified three independent case types with no subcase relationships:

Illness Injury is for logging each illness or injury event

Annual Summary is to track the end-of-year report for each plant
Submission is for those events that must be reported to the regulatory agency.

Discussion
An Annual Summary appears to be only a report, but you create a case because the requirements explicitly state that the
status of these reports must be tracked, indicating a dedicated process. Furthermore, these reports must contain static
information. While the original content may be derived from a report, this content must be fixed and persisted.

Create a Submission case since the requirements stated that the Submission process, and status of each submission, must
be tracked. Submission tracking is performed independently of the original injury record, and so is best kept as a separate
case.

You might consider that Submission could be a subclass of Injury Illness, but Submission is not a type of illness injury.
Submission is a case that is spawned by an Illness injury case. Also, Submission is not a subcase of Illness Injury since the
Illness Injury is not dependent on the Submission processing being completed.

Case hierarchy design: Warranty and recall

Case design
Consider the following requirements for an automobile manufacturing company automating a warranty claim application. Two
primary processes are supported by the application: a Warranty Claim process and a Recall process.

For a warranty claim, a customer brings a car to the dealership because something is not working correctly. The dealer
assesses the problem with the car, enters the claim details into the application, and then receives verification from the
application that the repair is covered under warranty. The dealer is subsequently compensated for the work by the car
manufacturer.

Every warranty claim includes one or more claim tasks. Each claim task represents the work that must be completed to
resolve the claim. Most warranty claims are simple and have a single Pay Dealer claim task. Some warranty claims require
more complex processing if disputes are involved.

Recalls are separate from warranty claims. Recalls cover the entire process from initially notifying customers when a recall is
necessary to compensate the dealer for the work completed to support the recall. One particular type of claim task is a "Part
Return". This claim task stands apart from others in that it requires an additional set of business rules and the process is
different.
Design a case structure to support this application.

Solution
At least two cases are possible: Recall and Warranty Claim.

Recall has no dependencies but does have a distinct process. You might represent Recall as a stand-alone case.

You have several design options for the Warranty Claim case.

One option is to create a stand-alone Warranty Claim case with conditional subprocesses spawned for each type of claim
task. This approach is easy to implement, but it limits extensibility and the ability to specialize the claim tasks.
 Another option is to create the Warranty Claim case with a subcase for each claim task. This design option offers the
flexibility to create specialized claim tasks such as Parts Return. The Warranty Claim case is the parent, or cover, case of the
Claim Task case since the Warranty Claim depends on all Claim tasks resolving before the warranty Claim case can be
resolved.

You represent the Parts Return case type as a subclass of the ClaimTask class to indicate that PartsReturn is a specific type
of ClaimTask case. This is an important distinction between subclasses and subcases. The hierarchy for subcases is
established in the Case type rule, similar to the composition relationship between pages in a data model. A subclass
indicates an is-a relationship and is indicated as such in the class structure.

Not enough information is provided in the requirements to determine which solution is more suitable for the Claim Task case
design. If there are many specialization or extensibility requirements for the application, the latter design for the Claim task is
a more suitable design.
This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.
Quiz duration
5 mins

Designing the case structure -- Mon, 10/12/2020 - 09:54

To get the full experience of this content, please visit https://academy.pega.com