Case processing

Case processing is performed by three main requestor types: services (application), background processes (batch), and “web” users (browser). A web user can be a robot instead of a human. Each requestor executes within its own Java thread. The separate Java threads allow multiple requestors to perform actions in parallel.

Case design affects how efficiently work is processed. An efficient case design accounts for steps or processes that can be performed in parallel by separate requestors. An example is devising a way that allows different users to approve or reject the same high-cost line item at the same time without interfering with each other. A separate web requestor performs each approval. If a more scalable solution is required for the same example, queuing tasks may be accomplished to a background processor to achieve automated approval.

When multiple individuals are required to work on a case simultaneously at a given juncture, as with the Divide and Conquer Pattern, a choice must be made between same-case, subcase, and sibling case processing.

Several factors can be taken into consideration:

How important each factor depends on the situation at hand.

Locking

For user input that is very short-lived, same-case locking that allows only one contributor access to the case at a time is inconsequential. Contributors can communicate in an email or some other collaboration tool that they would like access to the case soon. It is possible for users to attach related content to a case at the same time without interfering with each other. A data instance can employ the same non-interfering approach used by the PegaSocial-Document instance that references a case. An example in the Lead System Architect mission's Booking application is FSG-Data-Pricing.

Security

Security is less of a concern for a simple case with one type of owner. If every case was owned by one persona, security would be simplified.

Creating a child case within a stage purely for the sake of security is contrary to the Divide and Conquer principle since the work itself is not being divided, only reassigned. Access is simplified for one persona, but made more complex for the N-1 other personas who must be prevented from accessing the child case. There are other ways to control access to case type based on persona.

The Access Manager landing page supports viewing and managing, to a limited extent, the relationship between access groups (personas) and case types from an RBAC perspective. For conditional access, the Access Manager allows you choose an Access When rule. An Access When rule can be used by ABAC as well.

Reporting

Reporting simplification goes hand-in-hand with security simplification. Pega does possess Report Definitions based on case stage (for example, Work- pyGetWorkinStage and pyCountByStage).

Reporting: Access to Data by the Case

Reporting complexity does not justify creating an extra case. For example, the Limited Availability and Concurrency Design Pattern make the argument for using data instances over subcases. Whether data is persisted in or outside the case BLOB has nothing to do with case design; instead, it is a data model decision.

Reporting: Access to Data for Reporting          

If security concerns justify the creation of a separate case, then reports about cases and assignments also benefit from having a separate case.

Performance

An overabundance of cases and assignments compared to simpler data instances might have a negative impact on database and RAM utilization. The Enrollment/Add a Task to a TODO list design pattern demonstrates this concern. A cruise ship that represents each passenger as a subcase consumes more resources than representing a passenger as a data instance. You want to avoid using the My Cases landing page or view a WorkQueue list, considering that a cruise ship on average carries 3000 passengers.

Multiple smaller subcases consume less clipboard memory (if not opened at the same time) compared to the same data that is stored in the BLOB of a single case. The degree to which this is a concern depends on the amount of data stored in the BLOB as opposed to outside the BLOB.

Specialization Potential

The Separation of Concerns and Single Responsibility Principles favor smaller cases because the cases are easier to break down into a modular, built-on component application. A case that adheres to those two principles are more easily specialized through higher-layer direct inheritance or same-layer pattern inheritance.

Subcase Related Content Access

In earlier versions of Pega, prior to Pega 8’s change to implementing Related Content, there existed a Case Attachments option that allowed subcase attachments to be included in a case’s attachments list, not just the attachments that reference the parent case. No such option currently exists. Only in rare circumstances does the ability to view all Related Content within a case hierarchy at one time become concerning enough to favor a single case over subcases.

Subcase Dependency Management

A capability afforded through the use of subcase that is difficult to achieve by using same-case Split-For-Each-or-Join subprocess is the ability to define a Wait shape based on case type dependency. If this type of case complexity exists, the decision to use subcases over same-case processing is made not just from a dependency management perspective, but from other perspectives as well (such as Security, Reporting, and Locking).

Policy Override (If applicable)

A rarely used Pega capability is to suspend a case based on a Declare-OnChange decision, not allowing the case to proceed until it is investigated. It is easier to suspend and unsuspend one case than every case in a case hierarchy. If this feature were critical, it might come into play regarding a case design decision. Other means can be implemented instead, such as changing to an alternate stage. The same Declare On-Change condition can be used. The difference is the action that the Declare-OnChange rule takes in reaction to the condition that is being met.

Ad hoc Processing (If applicable)

An ad hoc case, or Work-Cover-SimpleCase, defines a task or TODO list when an atypical situation arises. This option is useful when there is insufficient time to wait for the application to be updated. An ad hoc case can be converted to an official case type using the Configure for Reuse option. Note that  users would need to be trained how to use this feature.The Quick Create button is located on the My Cases landing page.

For the implementation of rules that the Case Designer might leverage, design with configurability in mind. How a case is internally designed is important. The “audience” for case design is not just Senior System Architects (SSAs) and Lead System Architects (LSAs); the audience can include anyone who is involved in developing and maintaining the application.

The Case Designer uses Smart Shapes that simplify the interface to other rules such as activities. For example, the Send Email shape allows specifying the parameters required to invoke the CorrNew activity. A more complex example is the Approve/Reject shape, which is a wrapper for the Work- parameterized pxApproval subflow that contains 19 configurable parameters. Pega simplifies the configuration of the subflow parameters by using a three-column pane as shown in the following image:

A simple example of functionality encapsulation is a Work- AllCoveredResolved subflow that consists of:

1. Single assignment with pyContinueAfterWait flow action leading to end shape with AllCoveredResolved Ticket
2. Parameters = WorkQueue, ServiceLevel, WaitReason

The Booking application makes use an FSG COE-supplied AllCoveredResolved component at the end of its Book Event case. The component avoids adding redundant Timer Wait shapes to the end of each parallel process within the Manage Event stage, where each Timer would wait for the same moment to arrive (.Event.EndDT).

A Work- Approval Queue subflow was also provided by the FSG COE. This subflow supports parallel approval configurability. It consists of the following.

1. A Work- Approvers Field Group list of class Data-Admin-Operator-ID
2. NumApprovals and NumRejections properties
3. Subflow Parameters = WorkQueue, ApprovalsNeeded, RejectionsNeeded, ApprovalPurpose
4. A Fork shape ahead of a loopback WorkQueue
5. On entry to the subflow, NumApprovals and NumRejections are set to 0, and the Approvers field group list is removed.

Operators update their own page within the Approvers Field Group List. When a threshold is met, either ApprovalsNeeded or RejectionsNeeded, the loopback flow is exited.

The Approval Queue subflow is used in the Booking application's Book Event case's FSG Approvals stage. Within the Case Designer, this subflow could be configured such two event managers approving constitutes overall approval, otherwise, two rejections constitute overall rejection. Within the provided solution, only one approval or rejection is needed.