Designing case specialization and extensibility
Archived
2 Tasks
10 mins
Scenario
Front Stage’s event booking needs are currently handled by a single application. Front Stage intends to pursue additional venues in the future. Front Stage is concerned that each additional entertainment venue could potentially require modifications to their current application.
The following table provides the credentials you need to complete the challenge.
| Role | Operator ID | Password |
|---|---|---|
| Administrator | Admin@Booking | rules |
- Analyze the key requirements to determine if the current single application design will support these requirements.
- Prepare a list of questions that can be presented to the Front Page executives asking for clarification.
- Recommend the most appropriate enterprise class structure for the application going forward.
Design considerations
The key requirement is the ability to implement business logic specific to an entertainment venue when the need arises. No requirement was stated that each venue’s data should be stored in different database tables.
Possible approaches
Three approaches are possible for this solution:
- Represent the differences between venues as data. Implement rules that are able to process this data.
- Implement venue specialization within the current application.
- Use the current application as a framework / model / template / blueprint. Create an implementation application for each venue.
Detailed Tasks
1 Detailed steps
Data driven rules
In this approach an attempt is made to model the differences between venues as either data instances or custom non-Pega rules that are treated as data. Rules are developed with the ability to react to this data regardless the venue.
Pros
Maximum scalability.
No need to create and maintain vendor-specific rules.
Cons
Highly complex to implement and maintain the data-driven rules required to satisfy each and every specialization requirement.
Single application rule specialization
The single application approach would satisfy the current routing requirements leveraging the org structure. If only a few differences are anticipated between venues, circumstancing would suffice. For more complex differences, you can use pattern inheritance and utilize venue-specific classes that have been defined. Then you can use Dynamic Class Reference (DCR ) to decide which class to create.
Pros
Single application for users to access.
Relatively simple to implement and maintain compared to data-driven rules.
Cons
Extra work required when a large number of venues are added.
Application per venue
The multiple application approach would also satisfy the current routing requirements leveraging the org structure. An application would be created for each venue. Case types within each venue-specific application would extend a case type class within the current application. Venue-specific business logic differences would be handled by saving the rule from the current application to the corresponding case type class in with the venue-specific application. Users must switch applications to create and manage cases for different venues.
Pros
Simplest possible development since venue-specialized rules are defined in a venue-specific application in venue specific rulesets and classes.
Cons
Switching between applications for each venue is required.
Reporting across multiple venue application is more difficult.
2 Recommended design approach
The single application approach is recommended since it:
- Satisfies the requirement.
- Does not require application-switching.
- Simplifies reporting.
- Supports a large number of venues when required.