Document processing are business activities that involve filling out multiple forms. Together, these forms might comprise an application, for example an insurance application. Common characteristics of Document Processing include:
- Conditional Form Generation: questions on an initial "cover" document (form) might engage logic to determine which detail forms are required.
For example, you might be required to complete special forms if you attempt to purchase controlled substances (see example below). Or, you might need to complete special forms if you are applying for insurance and engage in high-risk hobbies, to determine the actual risks you are undertaking - the cover document might ask short "do any of these apply" questions, and your are conditionally taken to a details page if there are any 'yes' answers.
In such cases, your logic might be required to create child row instance(s) to capture the detail form data, per conditions based on the cover document.
- Multiple Sessions: the Business User may need to do research / consulting to respond to all the questions. Since this may require days, it is not practical to hold locks open, so there is typically a series of database transactions to complete a Document Processing activity, possibly engaging multiple users in a workflow.
Note: you typically define a Constraint ensuring that the created Forms have been satisfactorily completed.
Business Logic can help in such cases:
- Form Generation can be automated with Insert From logic as described in this document. For Conditional Forms, use derivation results in the Action rules
- Multiple Sessions can be addressed by using the Ready Flag.
The simplest way to illustrate this is with an example taken from the BusLogicIntro database.
contains Products that can pose dangers to others. Such products are identified with
Create LineitemUsage Rows
When such products are ordered, Business Logic creates
LineitemUsage rows for each such Product. Each row represents a "Business Form" that must be filled out by either the current user, or another user in a Workflow.
In our example, the row might explain the "usage" of the dynamite (e.g., an unusually aggressive approach to building a garden).
In our database, this form is trivial: it simply requires an
Explanation to be entered.
We specify Place Order logic via by declaring an Action Rule on Lineitem:
&& oldIsNeedsUsageTerms ==
Distinguish Created vs Completed Rows
Later logic will need to differentiate created rows from those subsequently completed. In our example, we
- specify logic that sets
Explanation = "Please Supply", and
- maintain a qualified count:
Count ("lineitemUsages where explanation = 'Please Supply'")
Constrain setting Ready unless rows Completed
Our Make Ready transaction needs to have a constraint that assures that
LineitemUsage rows were actually entered (i.e., the form was filled out). So, we define a
"One or more Items need Usage Definition"