Oracle ADF Interview Questions and Answers

The Oracle Application Development Framework (Oracle ADF) is an end-to-end application framework that builds on J2EE standards and open-source technologies to simplify and accelerate implementing service-oriented applications. If you develop enterprise solutions that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces, Oracle ADF can simplify your job. Used in tandem, Oracle JDeveloper 10g and Oracle ADF give you an environment that covers the full development lifecycle from design to deployment, with drag-and-drop data binding, visual UI design, and team development features built-in.

Oracle ADF is state of the art technology to rapidly build enterprise application. ADF is a mature J2EE development framework and many other products under Oracle Fusion Middleware stack are built upon ADF 11g.

ADF (Application Development Framework) provides variety of inbuilt components that minimizes the need to write code allowing users to focus more on features and business aspects of the application. With WebCenter and SOA plugins, we can also integrate WebCenter Services and SOA into your application making it rich and extensible.

Following are the advantages of using:

• It supports Rapid Application Development.
• It is based on MVC architecture
• Declarative Approach (XML Driven)
• Secure
• Reduces maintenance cost and time
• SOA Enabled

ADF Lifecycle has Nine phases as follows:

Initialize Context: In this phase value of associated request, binding container and lifecycle are set.

Prepare Model: In this phase model is prepared and initialized. In this phase page parameters are set and methods in the executable section of the page definition of the ADF page are executed.

Apply Input Values: This phase handles the request parameters. These may come by adding the request parameters in the URL or as a result of HTML form post action. A list of events is build using these request parameters. These are actually mapped to the bindings in the pageDef. This phase resolves the list of request parameters bind to attributes in the page def. This results into a list of updated Values which is used in Update Model phase.

Validate Input Values: This phase validates the list of values built in the Apply input values field with model.

Update Model: After validation of input values data model is updated with the list of values created in apply input values phase.

Validate Model Updates: Updates in the previous phase are then validated by calling the associated lifecycle’s binding container.

Process Component Updates: This phase handles any events in the list built during the apply input values phase. Named events as well as all the events tied to the databinding’s created in the pagdef are handled in this phase.

Metadata Commit: This phase commits the runtime metadata changes to the model. This phase is always executed before prepare render phase.

Prepare Render: This is the final phase where page is sent for rendering. prepare Render event is sent to all the registered listeners. This notification signals bindings to prepare or process the data for rendering. Binding container is also refreshed. This helps in updating any changes that happened during validation phases.

PPR is Partial Page Rendering, similarly to Ajax. It is used to dynamically refresh the part of page.It is done with the use of partial triggers. For a component to trigger another component to refresh, the trigger component must cause a submit when an appropriate action takes place.

Following three main component attributes are used to enable partial page rendering:

autoSubmit: When the autoSubmit attribute of an input or select component is set to true, and an appropriate action takes place (such as a value change), the component automatically submits the form it is enclosed in.

partialSubmit: When the partialSubmit attribute of a command component is set to true, clicking the button or link causes the page to be partially submitted.

partialTriggers: All rendered components support the partial Triggers attribute. Use this attribute to list the IDs of components whose change events are to trigger this component to be refreshed.

The Oracle ADF lifecycle integrates with the Java Server Faces request lifecycle, adding all that it takes to set up the binding context, prepare the binding container, validate and update the ADF model, persist MDS changes and prepare the response.

Developers who need to listen and interact with the request cycle may use an ADF Phase Listener to do so. Unlike the Phase Listener you define in the faces-config.xml file, the ADF Phase Listener allows you to listen to the standard and the ADF phases. The ADF Phase Listener is defined in Java – of course – and configured in the adf-settings.xml file you need to create.

ADF PagePhaseListener can be used always and for anything

In Oracle ADF framework developer can use standard JSF listener or special ADF listener which supports additional ADF-specific page cycle extensions. Listeners can be used to customize the ADF Lifcycle.

validators: If somehow you need to create your own validation logic to meet your business needs. You can either create a validation method on the page’s backing bean (if you want custom validation for a component on a single page), or create JSF validator classes (if you want to reuse the validation logics by various pages in the application). In the real world, of course creating the custom JSF validator classes would be adopted for ADF application for better reuse and maintantence.

convertors: converters are used for converting the values from one type to another,like decimal to bigdecimal or from string to date or date to string.

The ADF Faces architecture is designed such that application developers don’t need to write JavaScript code themselves for most of the use cases they build. JavaScript in ADF Faces applications therefore should be used as an exception rather than the rule.

Backing beans are JavaBeans components associated with UI components used in a page. Backing-bean management separates the definition of UI component objects from objects that perform application-specific processing and hold data.

Backing Beans are merely a convention, a subtype of JSF Managed Beans which have a very particular purpose. There is nothing special in a Backing Bean that makes it different from any other managed bean apart from its usage.What makes a Backing Bean is the relationship it has with a JSF page; it acts as a place to put component references and Event code.

Backing Beans: A backing bean is any bean that is referenced by a form. Backing Beans should be defined only in the request scope

Managed Beans: A managed bean is a backing bean that has been registered with JSF (in faces-config.xml) and it automatically created (and optionally initialized) by JSF when it is needed. The advantage of managed beans is that the JSF framework will automatically create these beans, optionally initialize them with parameters you specify in faces-config.xml.

ADFc-ADF Controller: ADFc The controller component in ADF is an extension of the JSF navigation model and promotes modularization and reuse. In addition, ADFc provides declarative transaction handling and clearly defined process boundaries.

ADFm-ADF model: ADFm The binding layer and model are represented by data controls and the binding container object. ADFm is built on JSR-227 and abstracts the view layer model access from the implementation details of the underlying business service.

ADF task flows provide a modular approach for defining control flow in an application. Instead of representing an application as a single large JSF page flow, you can break it up into a collection of reusable task flows. Each task flow contains a portion of the application’s navigational graph. The nodes in the task flows are activities. An activity node represents a simple logical operation such as displaying a page, executing application logic, or calling another task flow. The transactions between the activities are called control flow cases.

Taskflows are of two categories: Bounded and UnBounded.

Differences between Bounded and UnBounded taskflows:

• Bounded taskflows can be secured but Unbounded can’t.
• Bounded taskflows can accept parameter and return values but unbounded taskflows don’t support parameters
• Bounded taskflows has a single-entry point or a default activity but unbounded taskflows have multiple entry points.
• Bounded taskflows can be called from other bounded/unbounded taskflows but unbounded cannot be called or reused.
• Bounded taskflows support transactions unbounded don’t

Entity object: An entity object represents a row in a database table. You can compare it with an EJB in J2EE world. It simplifies modifying table row data by handling all data manipulation language (DML) operations for you. It can encapsulate business logic for the row and all DML goes via entity object so you can ensure that your business rules are consistently enforced. You associate an entity object with another entity object to reflect relationships in the underlying database schema. The relationship between two EOs is called Entity Association.

View object: A view object represents a SQL query. You use the full power of the familiar SQL language to join, filter, sort, and aggregate data into exactly the shape required by the end-user task. When end users modify data in the user interface, your view objects delegate the work to entity objects to consistently validate and save the changes. You can create view level relationships between different view objects and it is called as View Link.

View Links are useful when you have master-child hierarchies and you want to reflect that in the data visible to your client.

Application module: An application module is the transactional component that clients use to work with application data. It defines an updatable data model and top-level procedures and functions (called service methods) related to a logical unit of work related to an end-user task. Application Modules include one or move View Objects, along with their associated View Links.

A data control is essentially a bridge that makes data from a source available to the user interface in an ADF Fusion Web Application. You can use the objects in the data control to create databound user interface components.

The most commonly used types of data controls include the following:

ADF Business Components Data Control: This type of data control is generated by JDeveloper when you create an application module in your ADF Business Components application.

JavaBean Data Control: This type of data control obtains the structure of the data from POJOs (plain, old Java objects).To create a JavaBean data control, right-click a Java class file (in the Application Navigator), and choose Create Data Control.

EJB Data Control: The EJB data control is essentially the same as the JavaBean data control, except that it uses features inherent in the EJB architecture to obtain the structure of the data.You can create an EJB data control from the New Gallery. Expand the Business Tier node, select Data Controls, choose EJB Data Control, and click OK.

URL Service Data Control: A URL service data control lets you access and consume the data stream from a specified URL. This type of data control is not updateable.You can create a URL Service data control from the New Gallery. Expand the Business Tier node, select Data Controls, choose URL Service Data Control, and click OK.

Web Service Data Control: A Web Service data control obtains the structure of the data from the WSDL for a web service.You can create a Web Service data control from the New Gallery. Expand the Business Tier node, select Data Controls, choose Web Service Data Control, and click OK.

JMX Data Control: A JMX data control obtains the structure of the JMX MBeans from an MBean Server. You can create a JMX data control from the New Gallery. Expand the Business Tier node, select Data Controls, choose JMX Data Control, and click OK. For more information about creating a JMX data control, see the online help for the Create JMX Data Control wizard. Before you can create a JMX data control, you must first have a JMX connection.

Placeholder Data Control: A placeholder data control is a special type of data control that doesn’t require a traditional data structure. As the name implies, it is a placeholder that can be used during UI development, and then replaced with the real data control when it becomes available.

The DataBindings.cpx file contains the Oracle ADF binding context for your entire application and provides the metadata from which the Oracle ADF binding objects are created at runtime. The DataControls.dcx file is created when you register data controls on the business services. This file is not generated for Oracle ADF Business Components. It identifies the Oracle ADF model layer data control classes (factory classes) that facilitate the interaction between the client and the available business service.

trinidad.config file is created when you create a webcenter portal application. This is used to register the skin-family you are going to use for your entire application. Trinidad. skins are used when we use skin as a Jar file. This file provides a mapping between the Skin Id and the actual path where the skin exists.

Binding context is a runtime map between the data controls and page definition of pages in the application which is used to access the binding layer. It is accessible through the EL expression in your jspx pages. Binding container is a request-scoped map that is used to instantiate the page bindings. This is accessible through the EL expressions. Also, since it is request-scoped map, it is accessible during every page request.

ADF contains the following types of bindings:

Attribute Bindings: This is the binding to retrieve the value of a single view attribute in the iterator binding’s current view row. For eg; #{bindings.CustomerId.InputValue}

Tree Bindings: This is used for tables, tree-tables and trees. It is used to expose rows of a table in the iterator binding’s current range. Eg; All Customers-#{bindings.AllCustomers.labels.CustomerId}

Action Bindings: This binding type is used when buttons or command links are dropped on the user interface and require an action to be performed on them. We can use data control operations on them, for eg, Create, Delete, First, Last, Commit, Rollback etc.

Method Bindings: This binding is used when you want to use custom methods to be executed.

Iterator Binding: This binding is created by the application to access the ADF binding context. It contains a reference to the page bound data collection, helps access it and iterates over its data objects.

A view-state allocates a new viewScope when it enters. This scope may be referenced within the view-state to assign variables that should live for the duration of the state. This scope is useful for manipulating objects over a series of requests from the same view.

Valuators’ and Convertors are used to provide conversion and validation capabilities to the ADF input components respectively.

Converters convert the values on ADF forms to the type in which the application accepts them after the values are edited on the form and submitted.

Valuators’ are used to impose validations on the input components.

Restore View: The request comes to the FacesServet controller which extracts the viewed from this request.

Apply request values: The purpose of the apply request values phase is for each component to retrieve its current state. The components must first be retrieved or created from the FacesContext object, followed by their values.

Process validations: This phase makes use of the validators to validate the validation rules on the fields.

Update model values: In this phase JSF updates the actual values of the server-side model, by updating the properties of your backing beans.

Invoke application: Here the JSF controller invokes the application action to handle Form submissions.

Render response: In this phase JSF displays the view with all of its components in their current state.

Inter-portlet communication is achieved when an action in one portlet triggers a response in the second portlet. Its a communication bridge between two portlets. For eg, one portlet contains a checkbox containing list of products. When i choose a product from the list and click on submit, the other portlet displays the details of the respective product.

Contextual event ,in simple terms is a way to communicate between taskflows.Sometimes we have taskflow open in a region and have to get some values from that taskflow .This scenario can be achieved by contextual event.

Contextual Event have two parts:

Publisher Event (Producer)- As button or any component that can raise event.

Handler Event (Customer)- that listens and process event published by producer.

Oracle ADF has following components:

• ADF Business Components: VO, EO & AM
• ADF Model: DataBinding (.cpx, .xml) & DataControls(.dcx)
• ADF View: JSP, JSF, ADF Faces etc.
• ADF Controller: Task flows (adf-config.xml), faces-config.xml

This file is used for defining the permissions and privileges for various groups of users on various task flows created in the application.