The ADF framework provides parameters for a bounded task flow parameters are provided in ADF, developer can give them default values with using JDeveloper.
Configurable properties are:
• Initializer: This is a managed bean method that is invoked when a task flow starts execution. The value is specified using an EL expression.
• Finalizer: This is a managed bean method that is invoked when a task flow exits. The value is specified using an EL expression.
• Save Point Restore Finalizer: This is a managed bean method that is invoked when a task flow restores a save point. This is used for adding any custom method which is required to run after the execution of the framework code for a save point. If you need a quick brush up on how to define a save point in a task flow, refer back to the topic entitled Using save points in a task flow.
• URL Invoke: Bounded task flows using JSPX documents may be called directly from a browser URL. This property defines which task flow is browser accessible and which task flow can only be accessed from within an ADF application. The following are the possible values for this flag:
i. url-invoke-allowed: URL invocation is allowed.
ii. url-invoke-disallowed: URL invocation is not allowed. If attempted to invoke task flow through URL, the ADF Controller will return a HTTP 403 status code in this case.
iii. calculated: This is the default value for the URL Invoke property. This option will allow URL invocation if the bounded task flow uses the view activity as default activity and does not use any task flow initializer.
• Library Internal: This property controls the visibility of a task flow when packaged in an ADF library. This helps developers to expose only those task flows that are indented for reuse.
• Parameters: The Parameters section allows you to define input parameters for the task flow. Parameterization makes a task flow more generic and reusable. You can specify parameter name, type, and value. For example, when you define a task flow to display employee details for a department, you can parameterize the task flow to accept the department id from the caller so that it can be reused for any department.
• Return Value: This feature allows you to define the return parameter value to the caller. You can specify return the parameter name, type, and return value. For example, suppose you are displaying the task flow in a pop up that can be used to search and select particular an employee row. The task flow should return the selected employee row to the caller in this case, which can be declaratively achieved by using this feature.
To learn how to specify (input or return) parameters for a bounded task flow, read developers guide or stay in touch for my another blog entry about it :)
• Train: This option, if set to true, generates a train model for the task flow activities. The train model can be used as a data model for various train components in the UI. For example, consider a typical shopping cart site that processes a transaction in multiple steps. You can use the train feature provided by ADF for such implementations. The train component summarizes the multiple steps (view activities) of a task flow as a navigational component in the UI.
• Task Flow Reentry: This option decides whether or not a user can re-enter the task flow by clicking on the browser's back button. The possible values are as follows:
i. reentry-allowed: Allows re-entry to the task flow.
ii. reentry-not-allowed: Disallows re-entry to the task flow.
iii. reentry-outcome-dependent: The re-entry permission for the task flow depends on the outcome that was received when the same bounded task flow was previously exited via the task flow return activities. Note that a task flow can take multiple return activities. If the previously used task flow return activity has a re-entry flag marked as reentry-allowed, then the framework allows re-entry this time as well. The framework disallows re-entry in all other cases.When an end user re-enters a task flow using a browser's back button, and the re-entry is allowed, the framework will re-initialize the task flow state. This includes re-initialization of input parameters used in the task flow, reinitialization of the transaction state, and re-execution of the default activity. The framework discards all the changes that are made before re-entry.
• Critical: If you mark a task flow as critical by setting the value to true, the framework treats the task flow with extra care.
i. If the application is configured to use implicit save points (configured in adf-config.xml), the framework will generate implicit save points on entry to all task flows that are marked as critical.
ii. The framework will keep track of uncommitted data changes for critical task flow and warn the user if the person tries to exit from the task flow without committing changes.
• Transaction: This property helps to declaratively manage transactions for a task flow. The possible transaction attributes are as follows:
i. No Controller Transaction: The bounded task flow neither participates in existing transactions nor starts a new transaction. As the framework does not track pending changes for this setting, you will not be able to use declarative features available with Task Flow Return to commit changes to the database.
ii. Always Use Existing Transaction: The bounded task flow will always participate in an existing transaction. If no existing transaction is found in progress, then an exception is thrown when the task flow is initialized.
iii. Use Existing Transaction If Possible: The bounded task flow either participates in an existing transaction if one exists, or starts a new transaction upon entry of the bounded task flow if no transaction exists.
iv. Always Begin New Transaction: The bounded task flow always starts a new transaction when entered. The new transaction completes when the bounded task flow exits.
These transaction attributes re not simple as explained just one sentence, for more details read developers guide or stay in touch for my another blog entry.
• Share Data Control with Calling Task Flow: Check this property to share the data control with the calling task flow. You should not turn on this property if the transaction type is set as Always Use Existing Transaction or Use Existing Transaction If Possible.
• No Save Point on Task Flow Entry: On task flow entry, the framework will create model save points to store the current state of the model layer if you set the transaction as Always Use Existing Transaction or Use Existing Transaction If Possible. This save point is used later to restore the model state on the exit of the task flow if the task flow return activity is configured for restoring the save point (the Restore Save Point option in Task Flow Return activity). Apparently, save point creation on task flow entry is not really required if the task flow does not need to roll back the changes on exit. The No Save Point on Task Flow Entry option allows you to optionally prevent the creation of an ADF model save point on task flow entry.
References & Further Readings :