Design patterns

Divide and conquer is a recognized computational problem-solving algorithm. The algorithm divides the work into smaller, independently solvable units, which the algorithm can further break down. When each child unit of work is completed, it notifies its parent unit of work. When the final child unit of work of a parent receives a notification, that parent then notifies its parent, and so on. Eventually, the parent that does not have any parent, meaning the top-level Case, observes that every child unit of work is complete. When that happens, the algorithm stops.

The significant advantage of the divide-and-conquer approach is that the algorithm can process sibling units of work in parallel, reducing the overall time to complete the work compared to sequential processing. This approach also offers a greater opportunity for reuse.

In the business processing realm, a key advantage of the divide-and-conquer approach is that the algorithm can direct different units of work to the appropriate CSRs, groups, or Work Queues with the necessary skills to complete the work efficiently. Established goals and deadlines can assist in completing the work and visualizing the degree of work completion relative to a complex Case, for example, a claim.

The following diagram shows a sample representation of the divide-and-conquer design pattern in the context of a Booking application. The diagram demonstrates how the Event Booking Case uses the divide-and-conquer Case design pattern to complete the work of different child cases in parallel. An Event Booking Case can generate Hotel Booking, Weather, Parking, and Shuttle child Cases. The Event Booking Case can be resolved when every child Case is resolved.

The data-instance-first design pattern demonstrates how data related to a Case persists before the Case is created. For example, you use a Web embed, it is unnecessary to create a Case immediately. Instead, you can persist Case data before creating the Case. In this example, a mashup interface is configured as a Display a page action instead of a Create a new Case action.

If the Process run concerns the capture and persistence of data by a single actor, then the data-instance-first design pattern is the best method to apply. You can use the Pega landing page concept to capture data. If required, you can create a Case after the data from the View data class is persisted.

The following diagram shows that you do not need to create a Case before creating a data instance that references the Case or that the Case references. With the data-instance-first design pattern, you can persist the data instance first, followed by the creation of the Case. The application can capture data by using landing pages or a Pega Web embed and then process and persist the data. If necessary, the system can also update the data. If required, you can create a new Case instance.

The Case-instance-first design pattern in a Pega Platform™ is akin to the object-action interface for core programming languages. In this design pattern, you perform an action on an existing object.

The case-instance-first design pattern is observable in scenarios where the context of a case instance is crucial for carrying out specific actions or transactions. For example, think about a Purchase Order (PO) process. In this context, creating a PO is necessary to start subsequent actions for example approval and billing. Therefore, both approval and billing actions are carried out within the context of the purchase order case, demonstrating the application of a case-instance-first design approach. This pattern makes sure all necessary actions align contextually with the case instance, promoting a coherent and efficient workflow.

The following diagram is a visual representation of an existing Case instance updated by action, for example, update, add, or delete in the context of the existing object. This diagram also shows a scenario where existing Case instances refer to data stored outside the Case.

The limited-availability-and-concurrency Case design pattern is a variant of the object-action approach pattern. You want to associate several items, for example, data or Cases, with an existing item, for example, a Case.

For example, CSRs can make reservations in an application for a ferry that transports vehicles. A Trip Case represents the ferry. CSRs apply to reserve space on a particular trip for themselves and their vehicle.

The limited-availability-and-concurrency design pattern differs in that:

• There is limited capacity. For example, there is a limit to the number of passengers and vehicles that the ferry can carry.
• Concurrency management is critical.

Regarding concurrency management, suppose two CSRs each make reservations simultaneously for the same trip. There is only enough remaining capacity to honor one of the reservations; the other reservation attempt goes to the end of a waiting list.

Are Reservation child Cases the optimal solution to this problem?

If the capacity of a ferry is 500 passengers, creating that many child Cases is not practical. A more efficient approach is to insert or update Reservation data instances. Reservation data instances reference the Trip Case. Create a utility to check the availability of seats or any other required validations. All these operations occur at the data instance level, and Case instance updates happen only at the end of the scenario. In this example, update the Trip Case after all seats fill up or at the departure time of the trip.

Writing a single row to a single database table takes less time than running a lock-query-save-commit-unlock Process.

The following diagram shows an example of one or more limitations that regard the number of data instances a Case can manage. Because multiple concurrent CSRs can access the data instances, CSRs maintain a data instance queue to identify the precise order in which CSRs enter, update, or delete data instances. The system processes data instances in the correct sequence and validates the availability for each before persisting them or updating an associated Case instance. When the availability becomes low, and the concurrency is high, measures to avoid over-consuming the capacity limits of the Case are necessary

Sibling Cases that interact with one another at the same level in the Case hierarchy (such as two top-level Cases or two child Cases with the same parent Case) represent the parallel-Case processing design pattern.

For example, Benefits Enrollment and Paycheck are two child Cases of an Onboarding Case. If the two Cases need you to modify an employee record, and both Cases need the updated data, then the decision to implement the interacting Cases as a sibling relationship requires planning on how best to implement that relationship. Options include using the Update a Case flow shape, a common database table, or the Queue-For-Processing method in an activity.

There are situations where a parent/child relationship between two Cases is unsuitable. Instead, the two Cases are at the same hierarchy level (siblings) and need to perform an update, either one-way or bi-directional. The following diagram shows how the exchange of data can occur between two-top level Cases or between two child-sibling Cases after the system propagates the data to them from their parent Case:

You can carry out a Microjourney with one of the Case design patterns discussed in the previous sections, or you can carry it out with a data-instance-only design pattern.

The data-instance-only design pattern shows that some functional requirements need capturing of the data and persisting in the required format at the required location. Other objects can reference and process the persisted data.

For example, you take a functional requirement to capture and display the office locations of a global mobile sales and service company. Office administrators can add, delete, modify, or update office locations whenever the company extends (or changes) its service locations. According to the business scenario, office location is an important attribute that customers must select when raising a service request. Office location contributes to the calculations of service fees and taxes to pay for the services used. You can implement this business scenario with a data-instance-only design pattern.

The following diagram shows the capturing of data using different Channels and persisting the data into the system. Other objects can reference captured data and process it as part of the Case Life Cycle, but the data never converts to a Case Type.

Check your knowledge with the following interaction: