Task Flow Transaction Handling Inconsistent between JDeveloper R1 & R2.

Question

We have a solution developed using Jdeveloper 11.1.2.1.0.
To describe the use case I will use the HR schema.
The user must be able to view Regions and navigate to Countries and Locations in a hierarchical way. At each level he must be allowed to view and maintain the detail of the current record at that level. The user must also be able to navigate directly to a level and perform a search to view the data and from there be allowed to to view and maintain the detail of the current record at that level.
So I have created the following design to achieve this and take into consideration that I need to reuse my task flows that maintain the data.
Business Services (Model Project)
1. HierarchyAM, containing Read Only VO’s of the various levels nested by association/view link.
2. Region + Countries + Locations
3. Search#Level#AM, A separate AM for each level, containing the Read Only VO per level.
4. Maintain#Level#AM, A Separate AM for each level, containing an updateable VO per level.
UI (View Controller Project)
I created the following BTF’s (To try and keep the post short as possible I will only provide detail for a single level to explain the issues)
*1. HiererchyBTF*
a.     Contains a fragment.
b.     Added RegionHierarchyBtf, CountryHierarchyBTF, LocationHierarchyBTF to the above fragment as dynamic regions.
c.     Task flow transaction <No Controller Transaction>, isolated.
*2. RegionHierarchyBTF. (The same BTF’s are created for each level in the hierarchy)*
a.     Contains a fragment.
b.     Exposed HierarchyAM<RegionRoVO>
c.     Task flow transaction <No Controller Transaction>, shared.
d.     Includes a call to the EditRegionBTF.
*3. SearchRegionBTF (The same BTF’s are created for each level in the hierarchy)*
a.     Contains a fragment.
b.     Exposed SearchRegionAM<RegionRoVO>
c.     Task flow transaction <No Controller Transaction>, isolated.
d.     Includes a call to the EditRegionBTF.
*4. EditRegionBTF*
a.     Contains a fragment.
b.     Exposed MaintainRegionAM<RegionVO>
c.     Task flow transaction <Use Existing Transaction if Possible>, isolated.
Runtime behaviour with above configuration.
1.     Running the HiererchyBTF and navigation the levels works in all versions.
2.     Calling an edit BTF allows me to edit the current record and successfully commit the data in all versions.
3.     Calling an edit BTF for the same record immediately thereafter, allows me to edit the record and commit the data successfully in all versions.
4.     Running any of search BTF’s and calling the edit BTF works in all versions.
Runtime behaviour and changing the EditRegionBTF task flow transaction to Shared.
1.     Running the HiererchyBTF and navigation the levels works in all versions.
2.     Calling an edit BTF allows me to edit the current record in the table and successfully commit the data in all versions.
3.     Calling an edit BTF for the same record immediately thereafter, allows me to edit the record and commit the data successfully in 11.1.1.4.0 & 11.1.1.6.0 only. If I perform the same scenario in 11.1.2.1.0 I receive the following exception.
a.     JBO-25003: Object MaintainLocationAM of type ApplicationModule is not found.
4.     Repeating the process, but after editing the first record, edit the second record in the table the error is not encountered. If, after successfully editing the second record and committing the data successfully, I again edit the first record I edited, I receive the same exception as in point 3.
5.     Running any of search BTF’s and calling the edit BTF works in all versions.
For the purpose of having a reusable edit task flow, I need to have the task flow transaction configuration as <Use Existing Transaction if Possible>, shared. This enables me to have the edit task flow as a parent as well as a child task flow and use the task flow functionality irrespective if it is controlling the transaction or not.
My questions are;
1. Is my design acceptable for the solution I am developing, I am more specifically questioning my separation of the AM’s to achieve loosely coupled task flows.
2. Is there a bug (I have done a search on MOS) that details this behaviour.
3. As, in my opinion, this is a common requirement, why is there inconsistency between the versions.
The demo for each version can be made available.
Regards.
Leon.
Edited by: Leon Dorfling on Feb 21, 2013 1:44 AM

Answer 1

Hi Frank,
+1. Its the first sting I stumbled on reading your post. Unless the read-only view object AMs are shared across users (application scope) I don't see why you want to have them in a separate AM. I don't see a benefit in a purely read-only view object that is not backed up by entities and thus would follow Oracle's recommendation to always use entities with view objects.+
The read-only vo's are based on eo's. I separated the AM as the search use cases are independent of one another. So my understanding, from a performance perspective, is to not have all the read-only vo's of the entire hierarchy of products in a single AM if I am only going to access one of them. If I do not understand correctly, can you please assist me in better understanding.
+2. For sure this behavior doesn't sound right and should be filed. You may want to check 11.2.3 in case it has been fixed in there already.+
As posted by Chris, I have through MOS found that it has been fixed in a later version.
Btw.: "Calling an edit BTF for the same record immediately thereafter, allows me to edit the record and commit the data successfully" how do you call this task flow dynamic region or task flow call activity ?
The BTF's are called using a backing bean.
Regards
Leon.