ADF-TASKFLOW TRANSACTIONS

 

TaskFlow Transactions:

 In ADF transactions are defined and owned by the underlying business service implementation used within the Model layer of the application. As example ADF Business Components take out connections and transactions with the database. Such services are then exposed to the View Controller layer through an abstraction known as a Data Control for the View Controller to work with.

As our application can utilize multiple data controls, the ADF Controller (ADFc) through the facilities provided by the task flow transaction and data control scope options, allow one or more data controls to be grouped together and committed or rolled back as a group.

 The underlying business services still own the transaction and ultimately execute the commit and rollback operations, but the ADF Controller defines the boundaries of the task flow transaction, namely where the transaction starts and stops and which data controls are involved.

 For the bounded task flow transaction option itself there are only 4 options:

·  ""<No Controller Transaction>"

·         "Always Begin New Transaction"

·         "Always Use Existing Transaction"

·         "Use Existing Transaction if Possible" 

Now let’s see the different options available in transaction management in Taskflows:

Always Begin New Transaction

It is used to start a new transaction in your application. Typically this option is coupled with the isolated data control scope and a new separate data control frame.

If a bounded task flow does start with a new transaction, when it wishes to complete it must call a task flow return activity commit or rollback. These call the underlying commit() or rollback() operations on the associated data control frame, essentially committing or rolling back all data controls attached to the frame.

 Always Use Existing Transaction

 A bounded task flow that uses the "Always Use Existing Transaction" option is designed to share the transaction of the previous task flow in your application; it will not start a new transaction.

On closing it cannot make use of a commit or rollback task flow return activity, at design time such a task flow return activity will be flagged in error. Only a task flow that starts a new transaction can call these. In this case the "Always Use Existing Transaction" option will depend on its caller to finalize the transaction. Instead the "Always Use Existing Transaction" task flow simply calls a task flow return activity with its End Transaction property set to "<Default> none".

Use Existing Transaction If possible

 It is the most flexible of the transaction options and it is a combination of the "Always Begin New Transaction" and "Always Use Existing Transaction" options.

 If "Use Existing Transaction if Possible" is used with an isolated data control scope, it operates in the same manner as the "Always Begin New Transaction" with an isolated data control scope creating a new data control frame.

 If "Use Existing Transaction if Possible" is used with a shared data control scope its behaviour is dependent on if a transaction is open on the shared data control frame of the caller.

 If a transaction is open it has the same behaviour of "Always Use Existing Transaction" with a shared data control scope.

If a transaction is not open, it behaves the same as "Always Begin New Transaction" and a shared data controls scope.

 No Controller Transaction

"<No Controller Transaction>" option is restricted in its interaction with the data control frame; it does have a more liberal relationship with its relating data controls and their transactions.

·         Doesn't start a transaction on the data control frame like the "Always Begin New Transaction" option

·         Doesn't check or enforce if a transaction is open on the data control frame

·         Will not call finalize the data control frame transaction by calling the Data Control Frame commit() or rollback().

The established rules still apply for the data control scope though. If an isolated data control scope is specified for the task flow a new data control frame and data controls will be instantiated. For a shared data control scope the previous task flow's data control frame and data controls will be shared.

Developed sample application  implements one transaction for Departments,Locations and Employees entities, this sample is based on HR schema .

ADF Task Flows allow to manage transactions declaratively in View layer.

This means we can think about transactions in terms of forms available to the user.

 For example:

 if transportation information is entered into system through two screens - Source and Destination, transaction will be successful if both Source and Destination will be valid.
Transaction is opened from main page and is closed when control is returned back to main page.

If you will take closer look into bounded task flow that implements transaction, you will see here two pages and return activity defined. In Department page Department data is modified and in Employees page Employees data is modified. Modified data is saved during return from bounded task flow:

Now we have to create the ADF taskflow with .jspx page

In the bounded task flow we have to create the 2 page & name it as updateDepartment,UpdateEmployee.

Next we need to drag & drop the taskflow return activity.

Click on Task-Flow in the property we have to select the transactions.

Click on return task & go to the property inspector in this we need to click End Transaction=commit.

In the adfc-config.xml we have to create one  view & name it as Main.

Next we need to drag & drop the boundedtaskflow-[Task-Flow]

When we are Drag & drop the execute with parameter as a button,it will ask for the Edit Action Bindings.

#{bindings.DepartmentId.inputValue}

Save & Run

when we click on open Transaction it will go to the department page.

Click on Close Transaction..It will close the Transactions.

THANK YOU

                                        ASIYA AFREEN