Guide‎ > ‎Logic Design Patterns‎ > ‎

Document Processing

Context


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:
  1. 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.

  2. 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.


Solution

Business Logic can help in such cases:
  1. Form Generation can be automated with Insert From logic as described in this document.  For Conditional Forms, use derivation results in the Action rules

  2. 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.


Example

Our database contains Products that can pose dangers to others.  Such products are identified with needsUsageTerms as true.


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:

if (isNeedsUsageTerms == true && oldIsNeedsUsageTerms == false ) {

BusinessLogic.insertChildFrom(LineitemUsage.class, logicContext);



Distinguish Created vs Completed Rows

Later logic will need to differentiate created rows from those subsequently completed.  In our example, we
  1. specify logic that sets Explanation = "Please Supply", and

  2. maintain a qualified count:
    countUnresolvedUsageCount 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 Purchaseorder#constraintReadyUsage:

if (isBecomingReady && purchaseorder.unresolvedUsageCount > 0 &&
                    purchaseorder.officerItemUsageApproval != "exec approved")

ConstraintFailure.failConstraint("One or more Items need Usage Definition")



Comments