Designing the case hierarchy
3 タスク
１時間 30 分
シナリオ
Metro Delivery Company (MDC) is a B2B company whose core business is delivering same-day Intracity shipments originating from registered business partners to their destination.
Analyze the key requirements for this application. The key requirements to consider are:
Processes
- Business partner registration to enable business partners to register with MDC.
- Truck vendor registration for partnerships with MDC to provide trucks for shipping.
- Delivery requests to enable business partners to request trucks to ship goods.
- Truck requests to accommodate the goods of business partners.
- Invoices to business partners to receive payments for registration, delivery service, and vendor payment.
Extensibility
These processes must be built to support extensibility for moving services.
Reporting
Reports on the number of products delivered by the partner; profit reports need to be available.
Security
Data must be secured between the city managers and accountants.
Review all viable design options and list the pros and cons of each to recommend the most appropriate case structure for the application.
The following table provides the credentials you need to log in to the Delivery Service application. However, this challenge is mainly meant for evaluating the design options, and there are no specific implementation tasks.
| Role | User name | Password |
|---|---|---|
| Admin | admin@deliveryservice | rules |
詳細なタスク
1 Identify design options
Single Case with subprocesses (subflows)
A single Delivery Request Case cannot fulfil the process requirements due to Case locking issues, which prevent multiple users from updating the Case simultaneously. Although the extensibility and reporting requirements are easily met, and the UI might be satisfied with independent Data Objects tracking each request, updating the status of each request requires extra work. Optimistic locking can solve the problem, but it might not be optimal, because it could detract from the user experience during Case processing.
Single Case with child Cases (Subcases)
Another alternative is a Delivery Request top-level Case with multiple instances of Truck Request Subcases (depending on capacity). Each Truck Request can initiate an Invoice Case. Modifying the default locking scheme to lock Subcases independently of their parent solves the locking problem and allows parallel processing without interruption.
A hierarchical child Case is not best practice because delivery requests are initiated by either a gold, silver, or bronze partner, the leftover capacity on a truck cannot be utilized because one truck request cannot be a child of another delivery request Case initiated by a different partner.
Multiple Cases (with subflows/processes)
Another viable approach is to create multiple top-level Cases for delivery requests, truck requests, and invoice generation. Partner and vendor registrations can be separate Cases initiated through a web embed on the MDC website. A delivery request Case can initiate multiple instances of truck request Cases, depending on the capacity of the shipment. Each truck request can then initiate an invoice Case.
Circumstanced top-level Case (with subflows/processes)
A fourth alternative is to provide delivery partners with a self-service request feature by using a web embed channel in the delivery request Case circumstance. When the delivery partner places an order from the Place Order stage, it moves to Freight Fulfillment to place the truck request. This requires an additional screen to capture delivery partner details on the Case and could be a security constraint too.
As such, this is not a suitable design.
2 Evaluate design options
Pros and cons of each design option
| Design | Pros | Cons |
|---|---|---|
| Single Case with subprocesses (subflows) |
|
|
| Single Case with child Cases (Subcases) |
|
|
| Multiple Cases (with subflows/processes) |
|
|
| Circumstanced top-level Case (with subflows/processes) |
|
|
3 Recommend the best design option
A delivery Case with Multiple Cases (with subflows / processes) is preferred because:
- MDC has three departments: Truck Management, Delivery Services, and Finance. Creating different applications with Cases for each application provides modularity, and the applications can be run independently.
- Delivery request and truck request Cases promote reusability and extensibility.
- Individual processes for different departments/LOBs can be established, making routing and approvals easy.
- Using web embeds for partner and vendor enrolments as separate Cases.
- Application locking requirements should be considered.
- Each Case offers more specialization options, making the application more accommodating of future requirements.
The Case hierarchy design decisions will be used as inputs to generate the Pega Blueprint™ for the specified business requirements. For more information about Blueprint and development best practices, see Pega Blueprint.