About Validation Levels

The validation framework lets you validate business logic written for attributes, entities, and business objects.

Attribute validation occurs when the value of an attribute is changed by a setAttribute method (for example, setDname). Figure 1 shows a client application editing the DEPT table. When the user changes the value of the DNAME field and moves to another field in the same row, the setDname method fires and invokes attribute-level validation rules for DNAME. (The effect is the same when an attribute value is set programmatically.)

Figure 1: Move to Another Column in the Same Row to Fire Validation Rules

Entity validation is invoked before moving from one row to another. It is useful for validating values of two or more related attributes, and for deferring validation of individual fields until values for the entire row have been entered. Figure 2 shows a client application editing the DEPT table. When the user changes the value of the DNAME field and moves to a field in a different row, Dept.validateEntity fires and invokes entity-level validation rules for the Dept Entity Object. (The effect is the same changes are made programmatically.)

Figure 2: Move to Another Row to Start Commit Cycle

You can also invoke entity validation explicitly by calling methods in the Business Components API such as Entity.validate, Transaction.validate, ApplicationModule.validate, or Transaction.commit.

The framework invokes entity validation to validate business objects. Validation code written on the top-level Entity Object performs validation checks on any contained Entity Objects. The framework invokes rules on contained objects before invoking rules on top-level objects. Code you add to validation methods executes before or after framework code depending on whether you place it before or after the call to a framework method (such as super.validateEntity).

At commit time, the Application Module invokes the validate method on each business object that requires validation, which in turn lets each contained entity invoke its validate method, and so forth. For example, Figure 3 shows a business object that represents a purchase requisition. If the association was defined as a composition, then entity-level validation code attached to RequisitionHeader (the top-level Entity Object) cascades and validates the other Entity Objects in this business object.

Figure 3: Validation Rules Cascade From Parent Entity Object

An entity requires validation when any of its attribute values changes. If there are container entities accessible through ownership associations, then each container will also require validation. For example, if the RequisitionShipments entity in the figure above requires validation, the RequisitionLines and RequisitionHeader entities would also require validation.

Figure 4: If a Contained Object Must be Validated then its Containing Object Must be Validated

In Figure 4, if an attribute value in ShipmentD changes, it invokes setValidated(false) on LineA, which invokes setValidated(false) on ReqHeader. ReqHeader, the top-level entity in this Business Object, is added to the transaction's list of invalid entities.

During the commit cycle, the transaction calls validate on ReqHeader, which in turn calls validate on LineA, which calls validate on ShipmentD. On successful validation, ShipmentD calls setValidated(true)and removes itself from LineA's list of invalid entities. LineA then performs its own validation, resets its invalid flag, and removes itself from ReqHeader's list. ReqHeader then performs its validation and on success, removes itself from the transaction's list.