Question
Case Type Creation (Best Practice)
Consider the below described situation:
Framework Layer Cases: Org-FW-ABCFW-Work-X, Org-FW-ABCFW-Work-Y
Implementation Layer Cases: Org-Impl1-ABC-Work-X, Org-Impl2-ABC-Work-Y
The process followed by the two cases at the Implementation Layer is pretty much same (at this moment) - Case Creation, Case Processing, Case Closure (the three stages). The primary difference among these two implementation is the underlying data structure.
As a best practice, where (and why) should the case type rule be created:
1. One case type rule at the Org-FW-ABCFW-Work class level.
2. Two case type rules at the Org-FW-ABCFW-Work-X, Org-FW-ABCFW-Work-Y level
3. Two case type rules at the Org-Impl1-ABC-Work-X, Org-Impl2-ABC-Work-Y levels
Please highlight any issues that we are generally encountered in either of the aforementioned options.
Thanks.
If two case types are actually going to perform exact same steps on two different datasets - then one best practice approach keeping reusability in mind would be to:
- Create a single case type (single work class)
- Create an abstract data class structure (for holding two types of data as concrete classes under the abstract class). Create UI rules under abstract class with a name that you would be then specialising under two child concrete classes.
- Build the case type to process data of the Abstract data class type - meaning refer pages with the abstract class name
- At runtime, at the start of the case, point the page of abstract data class with an object instantiated from relevant concrete class that you had like this case to process.
In simple words, you would be using Polymorphism concept to create a reusable Case that processes a data instance decided at runtime.
However, depending upon number of steps and complexity of business rules in your case type this may not be best approach and may cause issues down the line in maintenance..
Hello Tuhinguha,
Generally, it comes down to reuse. You want to build things at the lowest common layer. So if your case type rules are going to be essentially the same, build them at the Org-FW-ABCFW-Work layer. Then if as things evolve you need to customize them you have the flexibility of doing so at either the Org-FW-ABCFW-Work-X/Y or Org-Impl1-ABC-Work-X/Y layers, as needed. If you see the stub you are currently using is really just that and you know for a fact that they will be fundamentally different once you start building out your current set of requirements, then maybe the generic stub doesn't make sense.
The "best practice" really depends on your situation, so it's really more important that you understand the concepts behind reuse and the reason for the FW and Impl layers. If you get that, combined with your understanding of your business requirements, you'll be far more equiped to answer your question than we are.
Thanks,
Mike