Oracle ACE Director Confirmation!

Oracle ACE Director Confirmation!

Finally, the coveted email arrived.

"I’m pleased to inform you that your Oracle ACE Director nomination has been accepted."

I cannot be more happy and proud to be part of such an elite group, I feel really honored.

I would like to take this opportunity to express my heartfelt thanks to the ACE Program and everyone who supported me into this wonderful journey, which I can say with certainty that it’s only the beginning.

Special thanks go to my sponsor, Bob Rhubart, an incredible person and an inspiring mentor, which without his support I wouldn’t have made it.

My Oracle ACE Director profile is available here.

Using ADF BC Declarative Built-in Rules (Part 10 of 10): Method validator

The last part of my tenth part series on declarative build-int rules is on the "Method" validator, an option where you can write more complex validation rules on your business domain layer.

Method validators can be defined at either the entity level or at the individual attribute level and are coded using the Java programming language that are called automatically during the validation cycle.

Method validators have three unique characteristics; they must be defined as public, they must return a boolean value and the method name must begin with the keyword "validate", for example, "validateDepartmentManager".

Let's see this validator type in an example. In the demo that will follow I will implement a validation constraint on the HR.Departments table to ensure that an employee cannot be defined as a manager of more than two (2) department.

I have created an ADF Fusion Web Application and created the basic business components that I will be using in this demo; an entity object based on the Departments HR table, a default view object for the departments entity object and a default application module.

Because my validation rule will have to count the number of departments a specific employee is a manager of, I will create a view criteria in the DepartmentsView view object to filter departments using an employee id that will be passed as a parameter.

Next let’s define an entity level validation. From the “Business Rules” tab of the Departments entity object, click the green plus button. Give a meaningful name to your validation rule (for example, "DepartmentsManagersValidationRule") and select "Method" from the "Type" drop down.

Ensure that the "Create and Select Method" check box is selected and if needed you can customize the method name. Please make sure that your customized method name begins with the keyword "validate".

Go to the "Failure Handling" tab and define your failure message. In my example I have used a message token expression to construct a dynamic error message, passing to the failure message the department id.

When you click "OK" you should get a popup message, informing you that the entity java file does not exist and whether you want to create a default java file for the selected entity object. Click "Yes".

Before we go into the entity implementation class and define the logic for our method validator, we need to create a view accessor. Why do we need this? Well, do you recall the view criteria we created above, "findDepartmentsByManagerIdViewCriteria"? We will use this to count the number of departments a manager is assigned to.

From the "Departments" entity object, go to "View Accessors" and click on the green plus button to create a new accessor. From the available view objects select the "DepartmentsView" view object and shuttle it to the right pane.

Ensure that the "DepartmentsView" view object is selected in the right pane and click on the "Edit" button to edit the view object's accessor. Move the "findDepartmentsByManagerIdViewCriteria" view criteria to the selected pane and map the "ManagerId" attribute to the "pManagerId" bind parameter.

Click "OK" to apply your changes and close the windows. Now we are nearly ready to implement our custom validator.

Go to the "Java" tab of the "Departments" entity object and click on the edit pencil icon to edit the implementation class that was automatically generated for you when you defined your custom method validator and select the "Accessors" check box. This will generate accessors for all entity attributes and view accessors into your entity implementation class which we will use in a bit.

Now we are ready to implement our validation logic. Click on the entity implementation link to open the Java class and at the end of the class you should locate your custom method validator method. The logic should look like below:

    public boolean validateDepartmentManager() {
        RowSet departmentsView = this.getDepartmentsView();
        if (departmentsView.getRowCount() > 2) {
            return false;
        } else {
            return true;
        }
    }

I am using the view accessor defined on the Departments entity object to get a hold of the view criteria to fetch the number of departments the currently selected manager is assigned to.

Run the Application module to test the "Method" validator. Open the "DepartmentsView" view object and create a new department, assigning it one of the existing managers, for example manager with manager id 200. The record should be validated successfully.

Now try creating another department using the same manager id. The method validator should return false now and you should get your custom error displayed.

Download sample application: Method Validator