Working with Bindings in a Task Flow Finalizer

Sometimes we need to access the business service layer in a task flow finalizer. For example, in order to clean up some resources we have to invoke an application module method in a finalizer. But a task flow finalizer is not an activity, therefore it can't have its own page definition file and we are not able to use the bindings layer in order to invoke the application module method. So, we have to get a reference to the application module instance and work with its methods directly. That's not really cool. This is kind of a rule violation. Let's see what we can do about that.

We're going to manually create a page definition file for the task flow finalizer and we are going to access the binding container in the finalizer method programmatically. So, in order to create a page def file we are going to drag-n-drop the AM method to the task flow diagram as a method call:

Jdeveloper is going to create a page def file for the method call and it's going to register the page def file in the DataBindings.cpx. So, in the DataBindings.cpx we'll have a page map:

 <page path="/WEB-INF/task-flow-definition.xml#task-flow-definition@someAMMethod"
   usageId="com_cs_blog_finalizerbindings_view_task_flow_definition_task_flow_definition_someAMMethodPageDef"/>

Actually we can remove it as we don't need it at all. And we'll have a page definition usage:

 <page id="com_cs_blog_finalizerbindings_view_task_flow_definition_task_flow_definition_someAMMethodPageDef"
   
path="com.cs.blog.finalizerbindings.view.pageDefs.task_flow_definition_task_flow_definition_someAMMethodPageDef"/>

Having done that, we can remove the fake "someAMMethod" method call in the task flow definition.
Now we are ready to implement a managed bean method for the task flow finalizer:

 public void taskFlowFinalizer() {
  //Get the current binding context
  BindingContext bc = BindingContext.getCurrent();
  
  //Find our binding container by name (page id in the DataBindings.cpx)
  DCBindingContainer dcb = 
    bc.findBindingContainer("com_cs_blog_finalizerbindings_view_task_flow_definition_task_flow_definition_someAMMethodPageDef");
  //Execute the method
  OperationBinding oper = dcb.getOperationBinding("someAMMethod");
  oper.execute();       
  }

That's it!

Entity Level View Accessors

In one of my previous posts I explained what happens behind the scene while working with View Accessors. Usually we define view accessors in the same view object definition where we define lists of values. However, it is also possible to define view accessors at the entity definition level. In that case we can use an entity level view accessor when defining lists of values in the entity based view objects. This is a pretty convenient feature in terms of reusing. So, a proper view accessor  can be defined only once at the entity definition level and it’s going to be available for reusing in all view objects that are based on this entity definition.
But besides convenience, this feature can also be useful in terms of performance. For each view accessor definition the framework at runtime creates an internal lookup VO instance according to the view definition linked to the view accessor. This is shown on the following diagram.

There are two VO definitions on the diagram - VO1 and VO2. Both of them are based on the same entity definition. There are three view accessors on the diagram. Two of them are defined at the view object definition level and the rest one is defined at the entity definition level. All view accessors point to the same lookup view object definition. The framework at runtime is going to create three internal view object instances. One instance per view accessor definition. Note, that lists of values that are based on the entity level view accessor will share the same lookup view object instance, which means they are going to reuse the same query results and share the same query collection cache.
So, view accessors, defined at the entity level can be considered by ADF developers as a promising technique.


That's it!