(This is an excerpt from Lesson 8 “Oracle BPM and ADF (Part 1)” from Avio Consulting’s new self-paced online Oracle BPM Developer Workshop training.)
Understanding ADF’s architecture is an essential step to understanding how to use it with Oracle BPM. This describes the different layers of ADF’s architecture and how they tie to Oracle BPM.
ADF Model View Controller (MVC) Architecture
ADF is built on a Model View Controller design pattern that separates the data from how the end users interact with the data.
In MVC, the Business Services layer represents the underlying data that is exposed and manipulated. The View layer represents the web based user interface (UI) forms that end users interact with. The Model layer is the connection between the Business Services and the View layers, taking what the end users see and change on the View’s UI forms and connects it to the Business Service’s source(s) of the data.
View Layer
The View layer represents the forms that you create in JDeveloper that is also known as ADF Faces. There is a misconception that ADF is just the View or user interface layer shown to end users as a part of a web based application. While the View is important, it is just one part of the architecture.
Controller Layer
The Controller layer is handled by task flows modeled in ADF’s task flow diagram shown below. During a single interaction with an end user, a single page might be presented and the end user simply clicks the button that submits the one form. The Controller layer’s important because there are also frequently multi-page interactions with an end user before they finish what they are doing.
The Controller layer models this UI page interaction using ADF’s visual drag and drop Task Flow Diagram. In the above example, the interaction between the UI forms, the routing rules and the methods invoked are modeled. This example has a method named “SetCurrentRowWithKeyValue” automatically invoked that retrieves database information based on the ID key passed into the task flow. The end user is then shown the form associated with the “taskDetails1” view activity on the diagram. If the end user selects the “Address” button on the form, the “router1” router activity automatically determines if the end user should see the US based address user interface form (the “US_Address” view activity) or the non-US based address user interface form (the “Address_jspx” view activity).
You might already be familiar with ADF’s concept of “unbounded” and “bounded” task flows. Bounded ADF task flows have only one entry point where unbounded task flows can have many entry points. Although ADF supports unbounded task flows, the human tasks associated with the interactive activities in an Oracle BPM process only can use bounded task flows. From an Oracle BPM perspective, the Controller layer’s task flow diagram models the interaction an end user has when a BPM human task is invoked by an Interactive activity in the BPM process.
Model Layer
The Model layer is the binding that connects and provides the actual data to the user interface components represented by the View layer. The sources of this data are the business services in the ADF architecture diagram shown above. The Oracle BPM process payload is exposed as a business service via the human task business service. Similarly, the database bound ADFbc database wrappers called Entity Objects and View Objects are bound to the Controller via the ADFbc Application Modules that are exposed as a business service.
It’s these business services that are used to populate the fields on the UI forms. As the fields are added to the UI forms, they are automatically bound in this ADF Model binding layer using business services. It is this business services layer that is exposed in the Data Control tab shown below.
This Data Control tab is important because it abstracts where the data is coming from. In the above screenshot, this data control tab’s “ADF_UI_OnBoardNewEmployee” node represents the data coming from and going back into the BPM payload via the human task named “OnBoardNewEmployee”. The “AppModuleDataControl” node shown above represents the data coming from and going back into the ADFbc database data source (using the “EmployeesView1” in this case). You might just as easily also have information coming from web services, EJBs, and Java POJOs. Because of the Model layer’s Data Control tab shown here, the source of the data is transparent as you add the fields, dropdown lists and tables to a form.
Connecting the Dots
To tie it all together from an Oracle BPM and ADF design perspective:
- BPM Project, Process and Data Objects – As a process is built with interactive activities, process data object variables are added that represent the payload of information being passed into and out of the interactive activities.
- Business Services – Business services expose the human tasks for the interactive activities. In addition to the human tasks, web services, EJBs, Java POJOs and other sources of data and operations are also exposed. A business service that exposes a human task is exposed in the ADF project. In this case, a human task business service is created.
- Model Layer – The Model layer consists of two parts. The first part of the Model layer is called the data control – this is responsible for coupling the Model layer to the underlying data source. As the name implies, this is what is exposed in the ADF form’s data control tab and is created when a human task is added to an ADF project. When this occurs, the data control for the human task is automatically added in the data control tab. The second part of the Model layer is the binding. It is this binding that connects the individual UI form’s components to the underlying data control. Together, the data control and the binding constitute the Model part of the architecture.
- Controller Layer – When the ADF project based on the human tasks is created, the task flow diagram is also automatically created in the ADF project. This task flow represents the Controller portion of the architecture.
- View Layer – When the ADF UI form is created, it can be populated with the human task’s payload elements provided by the human task business service. Similarly, elements bound to ADFbc, EJBs, Java POJOs, web services and other business services can be added to the form. It is transparent to the end user where this heterogeneous mix of data sources is coming from. Each UI form is automatically associated with the view activities in the Task Flow diagram. These ADF UI forms represent the View portion of the architecture.