How to determine that a task flow for the ID referenced in a dynamic region exists
By Frank Nimphius on Apr 11, 2011
When working with ADF dynamic regions, developers switch between task flows by changing the internal state of a property in the managed bean referenced from the ADF Region binding.
To read more about ADF regions, read up on this:
Unless there is a separate method in the managed bean to set the task flow ID for each task flow could be displayed in the region, there is no guarantee that the task flow ID that is passed to the bean matches an existing task flow. A requirement on OTN thus was to tell beforehand if a task flow exist for the task flow id specified at runtime. Unfortunately there is no public API available for this, so that the answer to this requirement is to use an internal packaged framework class that Chris Muir documented in a blog post:
Using a method documented by Chris, you can get to the information you need for the use case discussed in this section.
MetadataService metadataService = MetadataService.getInstance();
TaskFlowDefinition taskFlowDefinition =
Note that starting Oracle JDeveloper 22.214.171.124, the attempt of importing internal packaged classes in customer applications is handled by a new audit rule. The audit rule prevents the class that imports the internal packaged library from compiling. So to continue using internal packaged libraries, you need to disable the audit rule as explained here:
Best practices when dealing with ADF internal framework packages
Oracle is aware of that there may be a need for developers to use internally packaged classes if there is no acceptable other way, or public API to use. However, internally packaged classes and APIs may change without notice, for example for Oracle to implement enhancement requests. When working with internal classes therefore it is recommended that you
· File an enhancement request for Oracle to provide a public API for the internal API you want to use
· Create an abstraction layer, a utility class or managed bean that you use to access the internal class, instead of directly accessing the "forbidden" internal API in your application code.
· Change the internal class access in the abstraction layer to a public class once your enhancement request is implemented.
I filed ER 12345520 for the use case explained in this section.