Question
Cognizant
NL
Last activity: 12 Nov 2021 3:52 EST
flow class and new case design
.I am having doubt about the correct and recommended approach . Need some suggestion .
- Suppose we have a Road Assistance case
- The road assistance case has 5 steps for Truck and 4 steps for Car.
For similar functionality I have following questions
- Do we follow open/closed principle for flows also?
- Should flows mostly be created in work class ?
- For the example given above what approach is recommended
- should we use when condition to drive the control to the assignment based on type of vehicle?
OR
- we would have Page type property(Vehicle)[ORG-APP-Data-Vehicle] design time inside pyWorkPage. The class of that page would be (org-App-Data-Vehicle-Truck/Car) based on selection user vehicle selection at runtime .The flow inside org-App-Data-Vehicle-Truck class will have 5 steps and the flow inside org-App-Data-Vehicle-Car would have 4 steps. If a new type vehicle would be added a new class would we added that would have flow for that type of vehicle .
OR
- We should create separate case type for each vehicle type.
.I am having doubt about the correct and recommended approach . Need some suggestion .
- Suppose we have a Road Assistance case
- The road assistance case has 5 steps for Truck and 4 steps for Car.
For similar functionality I have following questions
- Do we follow open/closed principle for flows also?
- Should flows mostly be created in work class ?
- For the example given above what approach is recommended
- should we use when condition to drive the control to the assignment based on type of vehicle?
OR
- we would have Page type property(Vehicle)[ORG-APP-Data-Vehicle] design time inside pyWorkPage. The class of that page would be (org-App-Data-Vehicle-Truck/Car) based on selection user vehicle selection at runtime .The flow inside org-App-Data-Vehicle-Truck class will have 5 steps and the flow inside org-App-Data-Vehicle-Car would have 4 steps. If a new type vehicle would be added a new class would we added that would have flow for that type of vehicle .
OR
- We should create separate case type for each vehicle type.
Maantic
IN
Steps that you have mentioned, are they single forms/assignments or individual stages?
Cognizant
NL
both scenarios can happen
Scenario 1:
These are assignments ,car has 4 assignment and truck has 5 assignment
scenario 2:
These are individual stages
You can suggest for both the scenarios.
Ernst & Young LLP
MT
Short answer is - it depends.
Remember that you can specialize a rule (Flow/SLA/routing/notification) of the same class using different methods - a. Conditional rules, b. Circumstance c. (in your case) Case type specialization.
Such methods helps and considered useful when you are handling "not too much" specialization/variation across the process. The basic problem with this approach is rule maintenance becomes challenging as scope of specialization grows or become more complex significantly over the time.
Class specialization is rather a better approach when you're "expecting" more specialization requests across the process from your client in future.
For example, you can have this class structure Org-Work-RoadAssist, Org-Work-RoadAssist-Car, Org-Work-RoadAssist-Truck. You can either choose Car or Truck process as a baseline process (in this case, consider car process as baseline process) and define stage rule(s) with required steps in Org-Work-RoadAssist class. You don't need to specialize any rule in -Car class. For -Truck class, you can save the stage rule, or steps(flow rules) in -Truck class from -RoadAssist class and apply the required specialization there (e.g. add/remove steps from stage rule).
Also, security and reporting requirements are two other factors that helps to decide between these two approaches.
Short answer is - it depends.
Remember that you can specialize a rule (Flow/SLA/routing/notification) of the same class using different methods - a. Conditional rules, b. Circumstance c. (in your case) Case type specialization.
Such methods helps and considered useful when you are handling "not too much" specialization/variation across the process. The basic problem with this approach is rule maintenance becomes challenging as scope of specialization grows or become more complex significantly over the time.
Class specialization is rather a better approach when you're "expecting" more specialization requests across the process from your client in future.
For example, you can have this class structure Org-Work-RoadAssist, Org-Work-RoadAssist-Car, Org-Work-RoadAssist-Truck. You can either choose Car or Truck process as a baseline process (in this case, consider car process as baseline process) and define stage rule(s) with required steps in Org-Work-RoadAssist class. You don't need to specialize any rule in -Car class. For -Truck class, you can save the stage rule, or steps(flow rules) in -Truck class from -RoadAssist class and apply the required specialization there (e.g. add/remove steps from stage rule).
Also, security and reporting requirements are two other factors that helps to decide between these two approaches.
While it is still possible to define access to instances of the same class depending on the context using Access When or Attribute base access control, but the whole thing becomes much easier to develop and maintain if the you two separate classes, particulay if in future the access requirement becomes more complex.
Hope it helps.