In this post I will try to explain one of the most important layers in the ADF Architecture, the Business Service. Nobody explains this architecture better than Oracle. ADF BC (Business Components) layer is one very important way to implement the Business Services (others notable methods being Web Services, BPEL and Java). When you are making applications which interact with database directly, its almost certain that you will be using ADF BC.
For people coming from OAF Background (Oracle Application Framework, which is used for Oracle Apps page development) this is similar to BC4J, Business Component for Java.
So whats ADF BC and how does it help you? Well, in a nutshell it encapsulates your Database Objects, Validations on them, LOVs, handles Primary Key(PK) and Foreign Key(FK) relationships, enables you to build Query Criterias used in Search forms, making master detail forms, and a lot more. You can do all of the above declaratively saving you a lot of precious time in tight schedule projects. Imagine you have to write Java code for all the mandatory columns in a table, implementing FK and PK relationships... you get the idea...
ADF BC implements the above features with the help of EO (Entity Object), VO (View Object), Associations, View Links, Validation Rules etc..
EOs correspond to a Table or a View; but it Must have a Primary key, if there is no Primary Key it will use ROWID as a Primary Key.
VOs corresponds to a Query, it can be a Read Only or Updatable VO. Updatable VOs are based on EOs so that the underlying data can be modified. Rule of Thumb: If your intention is to Create,Update or Delete the records use Updatable VO else you can use Read-Only VO.
Associations are used to make relationships between two EOs e.g., a 1-* (1 to Many) , 0..1 - * (0..1 to Many). If there is a FK relationship between 2 tables, this relation is automatically created (when both the EOs are created at the same time using "Business Components from Table" Wizard).
View Links use the Association of underlying EOs to relate the VOs. In Short, View Link is to VOs what Association is to EOs.
Application Module holds various VOs and View Links which are used to display data to the user. But as DML operations can only be done through EOs, the work of Updating the Database is delegated by VOs to the EOs. Application Module holds the transactions together for all the DML operations on any/all of its VOs. It acts like a boundary for your transactions. You can issue commit, rollback on a Application Module to commit or rollback the changes on all the VOs. One of the main feature of Oracle ADF is that you can run its Application Module even without building a web page. As you can guess this is used to check if the problem is with the Data or Page or Bindings.
Time for some Action now:
Create an Fusion Application "AdfBc" in the package "oracle.test.adfbc" as shown below:
Keep clicking Next and Finish the project, you should see 2 Projects, Model and ViewController. Basically Model will contain all the ADF BCs components ("Back End" which communicates with Database to maintain the consistent state of the data validations etc) and ViewController will have web pages, controller and bindings, everything related to "Front End", what user sees.
Right Click on Model -> New -> Business Tier -> ADF Business Components -> Business Components from table -> Ok.
In the next screen chose HR Connection which gives access to Employee, Department tables in XE database.
This will invoke another Screen in which you will have to chose the Tables on which you want to base your application on. Search for Employees and Departments table and shuttle them to right hand side and click Next.
Note: We have created them together to take advantage of the PK - FK relationship between the two tables which exists at database level. This also works with multiple tables, so as long as you have the right FKs you don't have to worry about defining Associations and View Links for all of them.
In the "Updatable View Objects" Shuttle both the EOs to the Right Hand Side as we may want to Update any of these tables and click Next.
Notice, How the name is changing as automatically to EmployeesVO and DepartmentsVO (this is because of the property set in).
In "Read-Only View Objects", don't do anything, just click next. In the Application Module chose the default values and click Next -> Again Next and Finish. Finally the Model should look as shown below.
Notice how Associations and View Links are created even though we did not create them explicitly. This is because of the Foreign Key. Lets take "EmpDeptFkAssoc" as an example. Double click on "EmpDeptFkAssoc" -> Relationship -> Press the Edit Icon to open the following screen
Automatically 0..1 to * cardinality is created. If Employees.Department_Id column was a Not Nullable column it would have created 1 to * cardinality.
Check what all VOs have been added in Application Module. It should look similar to below:
Please note that Employees3 is under Department1 as in Master Detail relationship. Click on "AppModule" on the right hand side, click on EmployeesVO on the left and shuttle to the right to create Employees4. This should look like below:
Right Click on the "AppModuleAM" on the "Run". Double click on Departments1 to see following screen.
Now Double click on "EmpDeptFkLink1" to bring a Master detail like Form as shown below.
Now Click on Employees3 to bring Following screen.
Please note that on Employees3 there is Just 1 record. This is because this Employee record is a Subset of Department Non 10, which only has 1 record. Even if you search for another Employee by clicking on Find you will not get any records except for Employee No 200.
To search any employee we will have to Double click on Employees4. You can see all the Employees.
So, needless to say that when you are building a Master Detail Form you will have to use Employees3, if you are building an employee search Form to select all employees you would need Employees4.
Notice how the records change in the Detail table when one navigates the Master Table. In the first Departments1 navigate to any Department with help of arrows and notice how records in "EmpDeptFkLink1" and "Employees3" change accordingly.
This was just a warmup exercise, next we will see how to take advantage of ADF BCs to create LOVs, Validations, Master - Detail Form, Search Form etc.
For people coming from OAF Background (Oracle Application Framework, which is used for Oracle Apps page development) this is similar to BC4J, Business Component for Java.
So whats ADF BC and how does it help you? Well, in a nutshell it encapsulates your Database Objects, Validations on them, LOVs, handles Primary Key(PK) and Foreign Key(FK) relationships, enables you to build Query Criterias used in Search forms, making master detail forms, and a lot more. You can do all of the above declaratively saving you a lot of precious time in tight schedule projects. Imagine you have to write Java code for all the mandatory columns in a table, implementing FK and PK relationships... you get the idea...
ADF BC implements the above features with the help of EO (Entity Object), VO (View Object), Associations, View Links, Validation Rules etc..
EOs correspond to a Table or a View; but it Must have a Primary key, if there is no Primary Key it will use ROWID as a Primary Key.
VOs corresponds to a Query, it can be a Read Only or Updatable VO. Updatable VOs are based on EOs so that the underlying data can be modified. Rule of Thumb: If your intention is to Create,Update or Delete the records use Updatable VO else you can use Read-Only VO.
Associations are used to make relationships between two EOs e.g., a 1-* (1 to Many) , 0..1 - * (0..1 to Many). If there is a FK relationship between 2 tables, this relation is automatically created (when both the EOs are created at the same time using "Business Components from Table" Wizard).
View Links use the Association of underlying EOs to relate the VOs. In Short, View Link is to VOs what Association is to EOs.
Application Module holds various VOs and View Links which are used to display data to the user. But as DML operations can only be done through EOs, the work of Updating the Database is delegated by VOs to the EOs. Application Module holds the transactions together for all the DML operations on any/all of its VOs. It acts like a boundary for your transactions. You can issue commit, rollback on a Application Module to commit or rollback the changes on all the VOs. One of the main feature of Oracle ADF is that you can run its Application Module even without building a web page. As you can guess this is used to check if the problem is with the Data or Page or Bindings.
Time for some Action now:
Create an Fusion Application "AdfBc" in the package "oracle.test.adfbc" as shown below:
Right Click on Model -> New -> Business Tier -> ADF Business Components -> Business Components from table -> Ok.
In the next screen chose HR Connection which gives access to Employee, Department tables in XE database.
This will invoke another Screen in which you will have to chose the Tables on which you want to base your application on. Search for Employees and Departments table and shuttle them to right hand side and click Next.
Note: We have created them together to take advantage of the PK - FK relationship between the two tables which exists at database level. This also works with multiple tables, so as long as you have the right FKs you don't have to worry about defining Associations and View Links for all of them.
In the "Updatable View Objects" Shuttle both the EOs to the Right Hand Side as we may want to Update any of these tables and click Next.
Notice, How the name is changing as automatically to EmployeesVO and DepartmentsVO (this is because of the property set in).
In "Read-Only View Objects", don't do anything, just click next. In the Application Module chose the default values and click Next -> Again Next and Finish. Finally the Model should look as shown below.
Notice how Associations and View Links are created even though we did not create them explicitly. This is because of the Foreign Key. Lets take "EmpDeptFkAssoc" as an example. Double click on "EmpDeptFkAssoc" -> Relationship -> Press the Edit Icon to open the following screen
Automatically 0..1 to * cardinality is created. If Employees.Department_Id column was a Not Nullable column it would have created 1 to * cardinality.
Check what all VOs have been added in Application Module. It should look similar to below:
Please note that Employees3 is under Department1 as in Master Detail relationship. Click on "AppModule" on the right hand side, click on EmployeesVO on the left and shuttle to the right to create Employees4. This should look like below:
Right Click on the "AppModuleAM" on the "Run". Double click on Departments1 to see following screen.
Now Double click on "EmpDeptFkLink1" to bring a Master detail like Form as shown below.
Now Click on Employees3 to bring Following screen.
Please note that on Employees3 there is Just 1 record. This is because this Employee record is a Subset of Department Non 10, which only has 1 record. Even if you search for another Employee by clicking on Find you will not get any records except for Employee No 200.
To search any employee we will have to Double click on Employees4. You can see all the Employees.
So, needless to say that when you are building a Master Detail Form you will have to use Employees3, if you are building an employee search Form to select all employees you would need Employees4.
Notice how the records change in the Detail table when one navigates the Master Table. In the first Departments1 navigate to any Department with help of arrows and notice how records in "EmpDeptFkLink1" and "Employees3" change accordingly.
This was just a warmup exercise, next we will see how to take advantage of ADF BCs to create LOVs, Validations, Master - Detail Form, Search Form etc.
No comments:
Post a Comment