Often during a design discussion, we hear questions /
discussions like, why do we need a sub case for this task, cant this be done by a
sub flow? Whatever a sub case can do, sub flow can do the same, let’s not
complicate by having sub cases. Contrary, we also hear, design a sub case, we
can extend it later if required. All of these questions / discussions are valid,
but not directed or supported. Here is a small article, describing when to use
which Design Paradigm, which would help us make above design discussions
directed and supportive with data points
Given the capabilities for each, there are many ways to
compare pros and cons of each. However, the scenario or requirements should be detrimental
of the design paradigm.
- Sub Flows, in this discussion
represent Sub Process / Spin Offs / Split for Each / Split for Join
- “Task” has to be read either as Sub Flow or Sub
case depending on the context
Dependency Management:
Is the a requirement to Start off the “Task”, when certain conditions are met. Example: StartLoanEvaluation “Task”
needs to be performed only after Customer submitting required Proofs for Source
of Income.
Sub Flows: Not Achievable.
Sub cases: Achievable.
Data Propagation:
·
Is the requirement to not show /save unwanted
data to the “Task” or to show / save as much data as required to perform the “Task”.
Example:
To perform an Assessment of a loan, Assement officer should know about Loan
Details / Income and expenditure details, but not required to know about applicant’s
personal details.
Sub Flows: Not Achievable.
Sub cases: Achievable. Using Data Propagation, we can select the data
properties to be copied into sub cases.
·
Is the requirement not to have stale data while
performing the “Task”
Sub Flows: Achievable.
Sub cases: Not Achievable. We need to write custom code to fetch data
from parent to child case.
Specialization:
·
Is the requirement to Specialize flow rules
Sub Flows: Achievable.
Sub cases: Not Achievable.
·
Is the requirement to Specialize Class rules
Sub Flows: Not Achievable.
Sub cases: Achievable.
Storage:
·
Is the requirement to store the details of the “Task”
in separate table. Example: Store
all Underwritten claims to a different table
Sub Flows: Not Achievable.
Sub cases: Achievable.
Security:
·
Is the requirement to have different secured strategies
for the “Task”.
Sub Flows: Not Achievable.
Sub cases: Achievable.
Reporting:
·
Is the requirement to have fine grain report for
the “Task”
Sub Flows: Not Achievable.
Sub cases: Achievable.
Policy Override:
·
Is the requirement to suspend only the “Task”,
when certain conditions are met
Sub Flows: Not Achievable.
Sub cases: Achievable.
·
Is the requirement to suspend not only the “Task” but also the origination flow, when
certain conditions are met
Sub Flows: Achievable.
Sub cases: Not Achievable.
If we can have each box ticked off and then a simple math
would help us decide which one should our design have, Sub Case or Sub
Flows.
Hope the above article is covers most of the required stuff. Please
leave a comment with your practical experiences on how useful this article was
and also any thing needs further explanations.
Feedback's are welcomed in the form of comments.
Vamshi
