Skip to main content

Designing the subcase hierarchy

Archived

2 Tasks

10 mins

Visible to: All users
Advanced Pega Platform 8.3.1 English
This content is now archived and is no longer updated. Progress is not calculated. Pega Cloud instances are disabled, and badges are no longer awarded. Click here to continue your progress in the latest version.

Scenario

The Front Stage application will be constructed with a single event case and child cases for each service process. There are additional decisions to make regarding the cardinality and instantiation of the child cases.

Analyze the key requirements for this application to determine the best design for the child cases and how the child cases will be started. For each child case type, review any viable alternative designs listing the pros and cons of each. Produce a recommendation for the most appropriate child case structure for the application. Key requirements to consider are:

  • Processes — The weather prep, hotel rooms request, and parking functionality must be able to execute independently.
  • Extensibility — It must be possible to specialize or extend the booking application to support different types of venues.
  • Reporting – Reports for events should be defined that display revenue, cost, and profit (profit by event type)

  • Data — Users must not be able to see financial information.
  • UI — Customer quotation, event manager review, and hotel booking screens.

Detailed Tasks

1 Solution detail

Weather child case

The amount of additional database storage required to support a weather child case, even if never accessed by a user, is inconsequential. In keeping with object-oriented programming encapsulation principle, it is desirable for the event case to delegate every task that is weather-related to a weather case. By implementing weather as a separate child case the potential exists to create a weather application on which any application, not just the Booking application, could use as a built-on application.

Hotel child cases

When a customer selects the Hotel Services option, multiple hotel child cases should be created as opposed to a single hotel child case. A child case per hotel, is preferred because:

  • Application locking requirements are fully satisfied
  • UI requirements are easier to satisfy
  • A child case per hotel design has greater specialization potential

Parking child case

When the Parking and Shuttle Services option is selected by the customer, a single parking child case should be created.

2 Alternative approach analysis

Weather

Two options for the weather process are (1) to always create the weather child case, or (2) conditionally create the child case when precipitation is expected.

Option 1: Always create a weather child case

In this option, a weather sub case is always created for every approved event. The delay to wait for the weather check date-time is implemented in the weather case.

Option 2: Conditionally create a weather child case if precipitation is forecasted

In this option, the precipitation is checked by the Event case on the intended date-time. The weather child case is created only if there is precipitation in the forecast and weather preparation is required. This option could be implemented in one of four ways:

  • Pause the Event case using a Wait shape until the desired date-time. Check the weather forecast. Conditionally create the weather case if precipitation is forecast.
  • Within a parallel or spin-off flow within the Event case, check the weather at the desired date-time. Conditionally create the weather case if precipitation is forecast.
  • Queue the check weather task to an agent. The agent performs the weather forecast at the desired date-time and conditionally creates the weather child case if precipitation is forecast.
  • Have a delayed Queue Processor check the weather forecast on the desired date-time. Conditionally create the weather child case if precipitation is forecast.

As shown in the following table, always creating a weather child case is more advantageous than conditionally creating a weather child case.

Design Pros Cons
Always creating a weather child case (Option 1)
  • All weather related data and logic to obtain forecasts is contained in the weather child case
  • Better delegation, encapsulation, and separation of concerns strategy
  • Simple case dependency coordination using AllCoveredResolved ticket
  • A weather case is created unnecessarily if weather preparation is not required
Conditionally creating a weather child case (Option 2)
  • A weather child case is created only when required
  • The history leading up to the decision to create the weather child case is associated to the event case instead of the weather case.
  • Coordination of other optional services child cases may be complicated when the weather child case is not created

Parking

The parking case is straightforward and is only conditionally created when the parking service option is selected. Due to its simplicity, no other options are considered for this.

Hotel booking

Two options for the hotel case(s) are to create a single hotel case representing all hotels or multiple hotel cases (one for each hotel).

Option 1: Single hotel case

A single hotel case is created when the hotel service option is selected. Data objects representing each hotel are contained in the hotel case.

Option 2: Hotel child cases per hotel

As shown in the following table, creating a hotel child case per hotel is more advantageous than creating a single hotel case.

Design Pros Cons
Single hotel case
  • All hotel data is contained in one case
  • Calculations may be easier
  • Data security – Other hotels have potential access to data
  • Locking is an issue
Hotel child case per hotel
  • Locking is not an issue
  • UI requirement for hotel review is easily satisfied
  • Security
  • Greater number of hotel case instances to manage



Available in the following mission:

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice