In a Fusion web application containing ADF Business Components, most of your validation code is defined in your entity objects. Encapsulating the business logic in these shared, reusable components ensures that your business information is validated consistently in every view object or client that accesses it, and it simplifies maintenance by centralizing where the validation is stored.

Another benefit of using declarative validation (versus writing your own validation) is that the validation framework takes care of the complexities of batching validation exceptions, which frees you to concentrate on your application's specific validation rule logic.

In the model layer, ADF Model validation rules can be set for the attributes of a collection. Many of the declarative validation features available for entity objects are also available at the model layer, should your application warrant the use of model-layer validation in addition to business-layer validation. For more information, see Using Validation in the ADF Model Layer .

When you use the ADF Business Components application module data control, you do not need to use model-layer validation. Consider defining all or most of your validation rules in the centralized, reusable, and easier to maintain entity objects of your business layer. With other types of data controls, ADF Model layer validation can be more useful.

Entity object validation rules fall into two basic categories: attribute-level and entity-level.

Transaction commit processing happens in three basic phases:

1. Ensure that any invalid entity rows on the pending changes list are valid.

2. Post the pending changes to the database by performing appropriate DML operations.

3. Commit the transaction.

If you have business validation logic in your entity objects that executes queries or stored procedures that depend on seeing the posted changes in the SELECT statements they execute, they should be coded in the beforeCommit() method described in What You May Need to Know About Row Set Access with View Accessors. This method fires after all DML statements have been applied so queries or stored procedures invoked from that method can "see" all of the pending changes that have been saved, but not yet committed.

Because a composed child entity row is considered an integral part of its composing parent entity object, any change to composed child entity rows causes the parent entity to be marked invalid. For example, if a line item on an order were to change, the entire order would now be considered to be changed, or invalid.

Therefore, when the composing entity is validated, it causes any currently invalid composed children entities to be validated first. This behavior is recursive, drilling into deeper levels of invalid composed children if they exist.

JBO-28200: Validation threshold limit reached. Invalid Entities still in cache

1. In the Applications window, double-click the desired application module.
2. In the overview editor, click the Configurations navigation tab, select the configuration hyperlink for which you want to adjust the validation threshold.
3. In the overview editor for application module configurations (on the bc4j.xcfg file), click the Properties tab, and click Add Property.
4. In the Add Property dialog, select the jbo.validation.threshold property and click OK.
5. In the overview editor, in the Properties list, enter a new value for the jbo.validation.threshold property and save your changes.

oracle.jbo.server.DBTransaction::setValidationThreshold(12)

When an entity object's validation rules throw exceptions, the exceptions are bundled and returned to the client. If the validation failures are thrown by methods you've overridden to handle events during the transaction postChanges processing, then the validation failures cause the transaction to roll back any database INSERT, UPDATE, or DELETE statements that might have been performed already during the current postChanges cycle.

When an entity row is in memory, it has an entity state that reflects the logical state of the row. Figure 10-1 illustrates the different entity row states and how an entity row can transition from one state to another. When an entity row is first created, its status is New. You can use the setNewRowState() method to mark the entity as being Initialized, which removes it from the transaction's list of pending changes until the user sets at least one of its attributes, at which time it returns to the New state. This allows you to create more than one initialized row and post only those that the user modifies.

The Unmodified state reflects an entity that has been retrieved from the database and has not yet been modified. It is also the state that a New or Modified entity transitions to after the transaction successfully commits. During the transaction in which it is pending to be deleted, an Unmodified entity row transitions to the Deleted state. Finally, if a row that was New and then was removed before the transaction commits, or Unmodified and then successfully deleted, the row transitions to the Dead state.

Figure 10-1 Diagram of Entity Row States and Transitions

Description of "Figure 10-1 Diagram of Entity Row States and Transitions"

You can use the getEntityState() and getPostState() methods to access the current state of an entity row in your business logic code. The getEntityState() method returns the current state of an entity row with regard to the transaction, while the getPostState() method returns the current state of an entity row with regard to the database after using the postChanges() method to post pending changes without committing the transaction.

For example, if you start with a new row, both getEntityState() and getPostState() return STATUS_NEW. Then when you post the row (before commit or rollback), the row will have an entity state of STATUS_NEW and a post state of STATUS_UNMODIFIED. If you subsequently remove that row, the entity state will remain STATUS_NEW because for the transaction the row is still new. But the post state will be STATUS_DEAD.

An application module provides a feature called bundled exception mode which allows web applications to easily present a maximal set of failed validation exceptions to the end user, instead of presenting only the first error that gets raised. By default, the ADF Business Components application module pool enables bundled exception mode for web applications.

You typically will not need to change this default setting. However it is important to understand that it is enabled by default since it effects how validation exceptions are thrown. Since the Java language and runtime only support throwing a single exception object, the way that bundled validation exceptions are implemented is by wrapping a set of exceptions as details of a new "parent" exception that contains them. For example, if multiple attributes in a single entity object fail attribute-level validation, then these multiple ValidationException objects will be wrapped in a RowValException. This wrapping exception contains the row key of the row that has failed validation. At transaction commit time, if multiple rows do not successfully pass the validation performed during commit, then all of the RowValException objects will get wrapped in an enclosing TxnValException object.

When writing custom error processing code, you can use the getDetails() method of the JboException base exception class to recursively process the bundled exceptions contained inside it.

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select the object for which you want to add a validation rule, and then click the Add icon.

   • To add a validation rule at the entity object level, select Entity.

   • To add a validation rule for an attribute, expand Attributes and select the desired attribute.

   When you add a new validation rule, the Add Validation Rule dialog appears.

3. In the Add Validation Rule dialog, select the desired type of validation rule from the Rule Type dropdown list.
4. Use the dialog settings to configure the new rule.

   The controls will change depending on the kind of validation rule you select.

   For more information about the different validation rules, see Using the Built-in Declarative Validation Rules.

5. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and a precondition expression.

   For more information, see Triggering Validation Execution.

   Note:

   For Key Exists and Method entity validators, you can also use the Validation Execution tab to specify the validation level.

6. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails.

   For more information, see Creating Validation Error Messages.

7. Click OK.

When you add a validation rule to an entity object, JDeveloper updates the entity object's XML document to include an entry describing what rule you've used and what rule properties you've entered. For example, if you add a range validation rule to the DiscountAmount attribute, this results in a RangeValidationBean entry in the XML file, as shown in the following example.

  <Attribute
    Name="DiscountAmount"
    IsNotNull="true"
    ColumnName="DISCOUNT_AMOUNT"
    . . . 
    <validation:RangeValidationBean
      xmlns="http://xmlns.oracle.com/adfm/validation"
      Name="DiscountAmount_Rule_0"
      ResId="DiscountAmount_RangeError_0"
      OnAttribute="DiscountAmount"
      OperandType="LITERAL"
      Inverse="false"
      MinValue="0"
      MaxValue="40"/>
    . . . 
  </Attribute>

At runtime, the rule is enforced by the entity object based on this declarative information.

Declarative validation enforces both entity-level and attribute-level validation, depending on where you place the rules. Entity-level validation rules are enforced when a user tries to commit pending changes or navigates between rows. Attribute-level validation rules are enforced when the user changes the value of the related attribute.

The Unique Key validator (described in How to Ensure That Key Values Are Unique) can be used only at the entity level. Internally the Unique Key validator behaves like an attribute-level validator. This means that users see the validation error when they tab out of the key attribute for the key that the validator is validating. This is done because the internal cache of entities can never contain a duplicate, so it is not allowed for an attribute value to be set that would violate that. This check needs to be performed when the attribute value is being set because the cache consistency check is done during the setting of the attribute value.

Entity object validators are triggered whenever the entity, as a whole, is dirty. To improve performance, you can indicate which attributes play a role in your rule and thus the rule should be triggered only if one or more of these attributes are dirty. For more information on triggering attributes, see, Triggering Validation Execution.

Developers may define a List of Values (LOV) attribute on a view object to support displaying choice lists in the user interface. The view object's LOV attribute in turn relies on a data source view object to provide the values for display. Because the LOV feature assumes that the queried data source contains only valid values, any validation rules defined on data source view object attributes will be suppressed before the choice list displays in the user interface. Therefore, the developer who defines the LOV must ensure that the list of values returned by the data source view object contains only valid values, as describe in Working with List of Values (LOV) in View Object Attributes.

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select the Entity node, and click the Add icon.
3. In the Add Validation Rule dialog, in the Rule Type dropdown list, select UniqueKey.
4. In the Keys box, select the primary or alternate key.
5. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and a precondition expression.

   For more information, see Triggering Validation Execution.

   Best Practice:

   While it is possible to add a precondition for a Unique Key validator, it is not a best practice. If a Unique Key validator fails to fire, for whatever reason, the cache consistency check is still performed and an error will be returned. It is generally better to add the validator and a meaningful error message.

6. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails.

   For more information, see Creating Validation Error Messages.

7. Click OK.

When you use a Unique Key validator, a <UniqueKeyValidationBean> tag is added to the entity object's XML file. The following example shows the XML for a Unique Key validator.

<validation:UniqueKeyValidationBean
  Name="CustomerEORule0"
  KeyName="SCustomerIdPk">
  <validation:OnAttributes>
    <validation:Item
      Value="Id"/>
  </validation:OnAttributes>
</validation:UniqueKeyValidationBean>

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select where you want to add the validator, and click the Add icon.

   • To add an entity-level validator, select the Entity node.

   • To add an attribute-level validator, expand the Attributes node and select the appropriate attribute.

3. In the Add Validation Rule dialog, in the Rule Type dropdown list, select Compare. Note that the subordinate fields change depending on your choices.
4. Select the appropriate operator.
5. Select an item in the Compare With list, and based on your selection provide the appropriate comparison value.
6. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and a precondition expression.

   For more information, see Triggering Validation Execution.

7. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails.

   For more information, see Creating Validation Error Messages.

8. Click OK.

Figure 10-2 shows what the dialog looks like when you use an entity-level Compare validator with an entity object attribute.

Figure 10-2 Compare Validator Using an Entity Object Attribute

Description of "Figure 10-2 Compare Validator Using an Entity Object Attribute"

When you create a Compare validator, a <CompareValidationBean> tag is added to an entity object's XML file. The following example shows the XML code for an entity level validator in the OrdEO entity object.

<validation:CompareValidationBean
    Name="OrdEO_Rule_0"
    ResId="oracle.summit.model.entities.OrdEO_Rule_0"
    OnAttribute="DateShipped"
    OperandType="ATTR"
    Inverse="false"
    CompareType="GREATERTHANEQUALTO"
    CompareValue="DateOrdered">
    <validation:OnAttributes>
      <validation:Item
        Value="DateShipped"/>
      <validation:Item
        Value="DateOrdered"/>
    </validation:OnAttributes>
  </validation:CompareValidationBean>

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select where you want to add the validator, and click the Add icon.

   • To add an entity-level validator, select the Entity node.

   • To add an attribute-level validator, expand the Attributes node and select the appropriate attribute.

3. In the Add Validation Rule dialog, in the Rule Type dropdown list, select List.
4. In the Attribute list, choose the appropriate attribute.
5. In the Operator field, select In or NotIn, depending on whether you want an inclusive or exclusive list.
6. In the List Type field, select the appropriate type of list.
7. Depending on the type of list you selected, you can either enter a list of values (each value on a new line) or an SQL query, or select a view object attribute or view accessor attribute.
8. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and a precondition expression.

   For more information, see Triggering Validation Execution.

9. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails.

   For more information, see Creating Validation Error Messages.

10. Click OK.

Figure 10-3 shows what the dialog looks like when you use a List validator with a view object attribute.

Figure 10-3 List Validator Using a View Object Attribute

Description of "Figure 10-3 List Validator Using a View Object Attribute"

When you validate using a list of values, a <ListValidationBean> tag is added to an entity object's XML file. The following example shows the CustomerEO.CountryId attribute, which uses a view object attribute for the List validator.

<validation:ListValidationBean
      Name="CountryIdRule0"
      OnAttribute="CountryId"
      OperandType="JBO"
      Inverse="false"
      ListValue="oracle.summit.model.views.CountryVO.Id"/>

The List validator is designed for validating an attribute against a relatively small set of values. If you select the Query Result or View Object Attribute type of list validation, keep in mind that the validator retrieves all of the rows from the query before performing an in-memory scan to validate whether the attribute value in question matches an attribute in the list. The query performed by the validator's SQL or view object query does not reference the value being validated in the WHERE clause of the query.

It is inefficient to use a validation rule when you need to determine whether a user-entered product code exists in a table of a large number of products. Instead, Using View Objects for Validation explains the technique you can use to efficiently perform SQL-based validations by using a view object to perform a targeted validation query against the database. See also Using Validators to Validate Attribute Values.

Also, if the attribute you're comparing to is a key, the Key Exists validator is more efficient than validating a list of values; and if these choices need to be translatable, you should use a static view object instead of the literal choice.

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select where you want to add the validator, and click the Add icon.

   • To add an entity-level validator, select the Entity node.

   • To add an attribute-level validator, expand the Attributes node and select the appropriate attribute.

3. In the Add Validation Rule dialog, in the Rule Type dropdown list, select Range.
4. In the Attribute list, select the appropriate attribute.
5. In the Operator field, select Between or NotBetween.
6. In the Minimum and Maximum fields, enter appropriate values.
7. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and a precondition expression.

   For more information, see Triggering Validation Execution.

8. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails.

   For more information, see Creating Validation Error Messages.

9. Click OK.

When you validate against a range, a <RangeValidationBean> tag is added to the entity object's XML file. The following example shows the ItemEO.Quantity attribute with a minimum quantity of one and a maximum of 99.

<validation:RangeValidationBean
      Name="QuantityRule0"
      OnAttribute="Quantity"
      OperandType="LITERAL"
      Inverse="false"
      MinValue="1"
      MaxValue="99"/>

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select where you want to add the validator, and click the Add icon.

   • To add an entity-level validator, select the Entity node.

   • To add an attribute-level validator, expand the Attributes node and select the appropriate attribute.

3. In the Add Validation Rule dialog, in the Rule Type dropdown list, select Length.
4. In the Attribute list, select the appropriate attribute.
5. In the Operator field, select how to evaluate the value.
6. In the Comparison Type field, select Byte or Character and enter a length.
7. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and a precondition expression. For more information, see Triggering Validation Execution.
8. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails. For more information, see Creating Validation Error Messages.
9. Click OK.

When you validate using length, a <LengthValidationBean> tag is added to the entity object's XML file, as shown in the following example. For example, you might have a field where the user enters a password or PIN and the application wants to validate that it is at least 6 characters long, but not longer than 10. You would use the Length validator with the Between operator and set the minimum and maximum values accordingly.

    <validation:LengthValidationBean
      OnAttribute="pin"
      CompareType="BETWEEN"
      DataType="CHARACTER"
      MinValue="6"
      MaxValue="10"
      Inverse="false"/>

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select where you want to add the validator, and click the Add icon.

   • To add an entity-level validator, select the Entity node.

   • To add an attribute-level validator, expand the Attributes node and select the appropriate attribute.

3. In the Add Validation Rule dialog, in the Rule Type dropdown list, select Regular Expression.
4. In the Operator field, select Matches or Not Matches.
5. To use a predefined expression (if available), you can select one from the dropdown list and click Use Pattern. Otherwise, write your own regular expression in the field provided.

   Note:

   You can add your own expressions to the list of predefined expressions. To add a predefined expression, add an entry in the PredefinedRegExp.properties file in the BC4J subdirectory of the JDeveloper system directory (for example, C:\Documents and Settings\username\Application Data\JDeveloper\system##\o.BC4J\PredefinedRegExp.properties).

6. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and a precondition expression. For more information, see Triggering Validation Execution.
7. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails. For more information, see Creating Validation Error Messages.
8. Click OK.

Figure 10-4 shows what the dialog looks like when you select a Regular Expression validator and validate that the Email attribute matches a predefined Email Address expression.

Figure 10-4 Regular Expression Validator Matching Email Address

Description of "Figure 10-4 Regular Expression Validator Matching Email Address"

When you validate using a regular expression, a <RegExpValidationBean> tag is added to the entity object's XML file. The following example shows an Email attribute that must match a regular expression.

<validation:RegExpValidationBean
    Name="EmailPrimaryRule0"
    OnAttribute="EmailPrimary"
    Pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}"
    Flags="CaseInsensitive"
    Inverse="false"/>

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select the Entity node, and click the Add icon.
3. In the Add Validation Rule dialog, in the Rule Type dropdown list, select Collection.
4. In the Operation field, specify the operation (sum, average, count, min, or max) to perform on the collection for comparison.
5. Select the appropriate accessor and attribute for the validation.

   The accessor you choose must be a composition association accessor. Only accessors of this type are displayed in the dropdown list.

6. Specify the operator and the comparison type and value.
7. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and a precondition expression. For more information, see Triggering Validation Execution.
8. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails. For more information, see Creating Validation Error Messages.
9. Click OK.

When you validate using a Collection validator, a <CollectionValidationBean> tag is added to the entity object's XML file, as in the following example.

<validation:CollectionValidationBean
    Name="OrdEORule01"
    Accessor="ItemEO"
    CollAttribute="Quantity"
    OperandType="LITERAL"
    Inverse="false"
    CompareType="GREATERTHAN"
    CompareValue="5"
    Operation="min"/>

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select where you want to add the validator, and click the Add icon.

   • To add an entity-level validator, select the Entity node.

   • To add an attribute-level validator, expand the Attributes node and select the appropriate attribute.

3. In the Add Validation Rule dialog, in the Rule Type dropdown list, select Key Exists.
4. Select the type of validation target (Entity Object, View Object, or View Accessor).

   If you want the Key Exists validator to be used for all view objects that use this entity attribute, select Entity Object.

5. Depending on the validation target, you can choose either an association or a key value.

   If you are searching for an attribute that does not exist in the Validation Target Attributes list, it is probably not defined as a key value. To create alternate keys, see How to Define Alternate Key Values.

6. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and the validation level (entity or transaction). For more information, see Triggering Validation Execution.
7. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails. For more information, see Creating Validation Error Messages.
8. Click OK.

Figure 10-5 shows a Key Exists validator that validates whether the MembershipId entered in the PersonEO entity object exists in the MembershipBaseEO entity object.

Figure 10-5 Key Exists Validator on an Entity Attribute

When you use a Key Exists validator, an <ExistsValidationBean> tag is created in the XML file for the entity object, as in the following example.

<validation:ExistsValidationBean
      Name="CustomerId_Rule_0"
      ResId="oracle.summit.model.entities.OrdEO.CustomerId_Rule_0"
      OperandType="EO"
      AssocName="oracle.summit.model.entities.assoc.SOrdCustomerIdFkAssoc"/>

When using declarative validators you must consider how your validation will interact with expected input. The combination of declarative validators and view accessors provides a simple yet powerful alternative to coding. But, as powerful as the combination is, you still need to consider how data composition can impact performance.

Consider a scenario where you have the following:

• A ServiceRequestEO entity object with Product and RequestType attributes, and a view accessor that allows it to access the RequestTypeVO view object

• A RequestTypeVO view object with a query specifying the Product attribute as a bind parameter

The valid list of RequestTypes varies by Product. So, to validate the RequestType attribute, you use a List validator using the view accessor.

Now lets add a set of new service requests. For the first service request (row), the List validator binds the value of the Product attribute to the view accessor and executes it. For each subsequent service request the List validator compares the new value of the Product attribute to the currently bound value.

• If the value of Product matches, the current RowSet object is retained.

• If the value of Product has changed, the new value is bound and the view accessor re-executed.

Now consider the expected composition of input data. For example, the same products could appear in the input multiple times. If you simply validate the data in the order received, you might end up with the following:

1. Dryer (initial query)

2. Washing Machine (re-execute view accessor)

3. Dish Washer (re-execute view accessor)

4. Washing Machine (re-execute view accessor)

5. Dryer (re-execute view accessor)

In this case, the validator will execute 5 queries to get 3 distinct row sets. As an alternative, you can add an ORDER BY clause to the RequestTypeVO to sort it by Product. In this case, the validator would execute the query only once each for Washing Machine and Dryer.

1. Dish Washer (initial query)

2. Dryer (re-execute view accessor)

3. Dryer

4. Washing Machine (re-execute view accessor)

5. Washing Machine

A small difference on a data set this size, but multiplied over larger data sets and many users this could easily become an issue. An ORDER BY clause is not a solution to every issue, but this example illustrates how data composition can impact performance.

You can use Groovy script to implement business rules that are executed in response to entity-level triggers.

1. In the Applications window, double-click the entity object you want to add a trigger to.
2. In the overview editor, click the Business Rules navigation tab.
3. On the Business Rules page, select the Entity-Level Triggers node, and click the Create New Trigger icon.
4. Select the appropriate trigger point from the Type dropdown list.
5. Enter a Groovy expression.
6. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the expression fails.

When you create a trigger, a <Trigger> tag is added to the entity object’s XML file, as shown in the following example.

 <Trigger
    Name="BeforeUpdate">
    <validation:ExpressionValidationBean
      Name="BeforeUpdateExpression0"
      OperandType="EXPR"
      Inverse="false">
      <validation:TransientExpression
        Name="ValidationRuleScript"
        trustMode="untrusted"
        hasReturn="false"
        CodeSourceName="ItemEORow"/>
    </validation:ExpressionValidationBean>
 </Trigger>

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select where you want to add the validator, and click the dropdown of the plus icon to select New Validator.

   • To add an entity-level validator, select the Entity node.

   • To add an attribute-level validator, expand the Attributes node and select the appropriate attribute.

3. In the Add Validation Rule dialog, in the Rule Type dropdown list, select Expression.
4. Enter a validation expression in the Expression field.
5. Optionally, click the Validation Execution tab to enter criteria for the execution of the rule, such as dependent attributes and a precondition expression in the Expression field. For more information, see Triggering Validation Execution.
6. Click the Failure Handling tab and enter or select the error message that will be shown to the user if the validation rule fails. For more information, see Creating Validation Error Messages.
7. Click OK.

@ValidatorExpression(name="PaymentOptionIdRule0", attributeName="PaymentOptionId")
def PaymentOptionId_PaymentOptionIdRule0_ValidationRuleScript_ValidationRule()
{
String acctnumber = newValue;
 sumofdigits = 0;
 digit = 0;
 addend = 0;
 timesTwo = false;
 range = acctnumber.length()-1..0
  range.each {i ->
  digit = Integer.parseInt (acctnumber.substring (i, i + 1));
  if (timesTwo) {
   addend = digit * 2;
   if (addend > 9) {
    addend -= 9;
   }
  }
  else {
   addend = digit;
  }
  sumofdigits += addend;
  timesTwo = !timesTwo;
 }
 modulus = sumofdigits % 10;
 return modulus == 0;
}

When you create a Groovy expression, it is saved in the entity object's XML component. The following example shows a DateOrdered attribute in an entity object. The Groovy expression is wrapped by a <validation:ExpressionValidationBean> tag. The Groovy script is enclosed in OrdEO.bcs file as indicated by CodeSourceName="OrdEORow” in the XML definition.

<Attribute
  Name="DateOrdered"
  ColumnName="DATE_ORDERED"
  SQLType="TIMESTAMP"
  Type="java.sql.Date"
  ColumnType="DATE"
  TableName="S_ORD">
  <DesignTime>
    <Attr Name="_DisplaySize" Value="7"/>
  </DesignTime>
  <validation:ExpressionValidationBean
    Name="DateOrderedRule0"
    OperandType="EXPR"
    Inverse="false">
    <validation:TransientExpression
      Name="ValidationRuleScript"
      trustMode="untrusted"
      CodeSourceName="OrdEORow"/>
  </validation:ExpressionValidationBean>
</Attribute>

Figure 10-6 shows the validation expression in the Edit Validation Rule dialog.

Figure 10-6 Validation Expression for Date Ordered Attribute

Description of "Figure 10-6 Validation Expression for Date Ordered Attribute"

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select the Entity node, and click the Edit icon.
3. In the Edit Validation Rule dialog, click the Validation Execution tab.
4. Select the attributes that will fire validation.
5. Click OK.

For example, in the SummitADF application workspace, the OrdEO entity object has an entity-level validator that requires the DateShipped attribute to be later than the DateOrdered attribute. As shown in Figure 10-7, this validator is set to be executed on the entity object only when either the DateShipped attribute or the DateOrdered attribute has been changed.

Figure 10-7 Triggering attributes on the Validation Execution tab of the Edit Validation Rule dialog

Description of "Figure 10-7 Triggering attributes on the Validation Execution tab of the Edit Validation Rule dialog"

When you specify triggering attributes on the Validation Execution tab of the Edit Validation Rule dialog, JDeveloper adds a <validation:OnAttributes> tag to the validator definition in the entity object's XML file. The following example shows the XML code for the entity-level validator for the OrdEO entity object in the core Summit ADF sample application.

<validation:CompareValidationBean
   Name="OrdEO_Rule_0"
   ResId="oracle.summit.model.entities.OrdEO_Rule_0"
   OnAttribute="DateShipped"
   OperandType="ATTR"
   Inverse="false"
   CompareType="GREATERTHANEQUALTO"
   CompareValue="DateOrdered">
   <validation:OnAttributes>
     <validation:Item
       Value="DateShipped"/>
     <validation:Item
       Value="DateOrdered"/>
   </validation:OnAttributes>
</validation:CompareValidationBean>

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select an entity-level validation rule, and click the Edit icon.
3. In the Edit Validation Rule dialog, click the Validation Execution tab.
4. Select Execute at Entity Level or Defer Execution to Transaction Level.
5. Click OK.

You cannot control the order in which attributes are validated – they are always validated in the order they appear in the entity definition. You can order validations for a given attribute (or for the entity), but you cannot reorder the attributes themselves.

1. In the Applications window, double-click the desired entity object.
2. In the overview editor, click the Business Rules navigation tab, select a validation rule or trigger, and click the Edit icon.
3. In the Edit dialog, click the Failure Handling tab.
4. In the Message Text field, enter your error message.

   You can also define error messages in a message bundle file. To select a previously defined error message or to define a new one in a message bundle file, click the Select Message icon.

   Note:

   Triggers and Script Expression validators allow you to enter more than one error message. This is useful if the validation script conditionally returns different error or warning messages. For more information, see How to Conditionally Raise Error Messages Using Groovy.

5. You can optionally include message tokens in the body of the message, and define them in the Token Message Expressions list.

   Figure 10-8 shows the failure message for a validation rule in the OrdEO entity object that contains message tokens. For more information on this feature, see How to Embed a Groovy Expression in an Error Message.

6. Click OK.