I have to extend a .Net 4/C# case management application that uses Oracle 11g to handle legal cases.
I have minimal budget, my experience with Oracle and a very junior C# developer to accomplish this. The additional module will be used by no more than 20 people on an intranet.
The existing rules are generally like this:
- in order to complete an action there must be property a, property
b, property c present in a table with a clearly defined relationship
to the table where the new insert must be validated - For legal cases new business rules are more like "everything is an exception"
More formally restated as data entries in other tables may or may not affect the outcome of future transactions based on unknown conditions
The existing application uses Microsoft Workflow to implement the business rules. This has proven to be unwieldy, almost unusable for us. Drools and their commercial equivalents are equally complicated and will not achieve the goal of allowing managers to understand their business logic.
- it would be a benefit if the business logic could be seen by users in a report without having to read C# comments or code.
- logic can be added or disabled quickly without taking the web application down
- fairly easy to implement given we have limited budget and skill sets
This brings me to the old fashioned idea of holding the business logic in the database as a series of decision tables. Is this still done or has the idea that the efficiency of holding the business logic in the application so obviously better?
Edit: Workflow is implemented as a service. My understanding is that it was aimed at long running workflows. In our case users press the save button and the workflow runs. Our issues are
– Painfully slow to develop with on our machines, freezes, crashes
– difficult to debug
– now and again the workflow manager throws errors for a few hours for no reason we can find
– touch one workflow and you have to change 14 other files
– application is slow for users, part of which we have traced to the workflows.
Validating in the database starts to look good because the validation is all based on data in the database.
@catcall There are 10 or 12 lawyers who do not use the application but have 8 or 10 admins do the data entry.
We just finished the desktop upgrade but the boss does not believe that programmer contractors should have better equipment than staff. So Windows XP with 4 cores and 3 GB of ram is the best we can do.
I will investigate if there is any classification of types of business logic. Some of it can be done more efficiently in the application. Other types might be more easily changed and configured on the database side.
Best Answer
"People" is a fuzzy term when you're talking about legal applications. Supporting 20 lawyers is a lot different than supporting 1 lawyer, 4 paralegals, and 15 staff.
And that's one reason why. Within case management, certain kinds of things are simply deterministic. Timing of responses, deadlines for filing, things like that. But the rules that govern were written by lawyers for lawyers. Companies that build case management software have lawyers on staff to read the rules for procedure (which change over time) and to verify that their software complies with the rules.
Some of them have a lot of lawyers.
Other kinds of things are governed by whimsy. For example, some case management packages let users "template" their tasks. Entering something like "Deposition" on the calendar might also calendar a series of earlier tasks that have to be done to prepare for the deposition. Under the pressure of multiple, incompatible deadlines, parts of a task chain get dropped or given short shrift.
Now, to (finally) get to your question . . .
Decision tables in the database are a viable solution. In fact, decision tables constitute a database whether they're stored in Oracle or in application code. There are obvious trade offs to storing decision tables in application code.
But decision tables in the database are probably not a viable solution for you. The problem you have, if I understand you correctly, is that you think you might need to simplify the architecture to decision tables in order to eliminate (or at least to greatly reduce) the use of Microsoft Workflow. With just two of you and a minimal budget, success will be difficult at best.
I can suggest two things.