Skip to Main Content

APEX

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Using a LOV for the Start of a Tree - Pblms using LOV value for Start SQL

581481Sep 5 2008 — edited Sep 6 2008
I'm trying out my first APEX Tree using P20 and am having problems with it. The data structure is I have a clients table, an users table, a plans table and a union table (plan_users) that shows which users for a client are working on plans. An user belongs to a client and can be assigned to plans (plan_users).

client_id (key to clients table and part of the composite key for users, plans and plan_users) is available as an application item which I can reference as :FOCUS_CLIENT_ID.

I created several LOV's in the Shared Components. The PLANS_LOV returns all plans defined for the :FOCUS_CLIENT_ID. I've referenced this PLANS_LOV in the P20_ROOT_TREE which is setup to display the list of Plans for the Client as a SELECT LIST WITH SUBMIT. That seems to work and I can select the Plan.

I then modified the SOURCE for the P20_ROOT_TREE to add a select statement to take the PLANS_ID selected in the LOV and use it in a Select to bring up the owner of the plan as the starting user for the tree. This is where I get an error when executing the SOURCE select statement which looks like this:

select p.user_id id, p.plan_owner_id pid, u.user_lname name, null link
from plan_users p, users u
where p.client_id = :FOCUS_PLAN_ID and p.PLAN_ID = :PLANS_LOV
and p.user_id = p.plan_owner_id
and u.client_id = :FOCUS_PLAN_ID and u.user_id = p.user_id

I'm guessing that the problem is what I'm referencing as :PLANS_LOV in the statement below. However I cannot find any information on how to reference the returned value from the PLANS_LOV for Page 20 so I've tried this.

If this works right, then I want the user to select a PLAN from the LOV box and then see a tree displayed with all USERS hierarchically displayed beneath the Plan Owner. There may be multiple levels of users display under the Plan Owner.

Here's the DEBUG page error I get. The number 4 is the correct Plan # I want to select Users for. The title on the page is "Available Plans". - Select Plan - is the default Null Value and Test Plan One is the Plan (#4) that I selected.

Item: P20_TREE_ROOT COMBOBOX_WITH_SUBMIT
Available Plans
-Select Plan -Test Plan One
[javascript:popupURL('f?p=4000:371:1020131294804981::::P371_ID,FB_FLOW_ID,FB_FLOW_PAGE_ID:1096326828951548,101,20');|Edit]Warning: Tree root ID "4" not found.
0.05: Computation point: AFTER_BOX_BODY 0.05:
Processing point: AFTER_BOX_BODY
The query I'm using for populating the rest of the tree after the START is this statement below, but I don't think I'm getting to this point yet.

select p.user_id id, p.plan_owner_id pid, u.user_lname name, null link, null a1, null a2
from plan_users p, users u
where p.client_id = :FOCUS_CLIENT_ID
and u.client_id = :focus_client_id
and u.user_id = p.client_id
order by name
I haven't been able to find any examples of someone using a LOV as part of the START definition for a Tree. All of the examples I've seen use a fixed value (i.e. 1).

Anyone have some ideas?

Thanks!
Rob

Comments

Bob Rhubart-Oracle

Ricardo Giampaoli and Rodrigo Radtke have recorded a 2 Minute Tech Tip video based on this article. Watch it here

2813466

Nice work, It will reduce the time of integration process.

Tinotarantino-Oracle

Nice work, It will reduce the time of integration process.

This is an elegant solution to address a common problem for any application that is dependent on external metadata.

As you correctly point out, the burden is still on the external interfaces that populates the generic inbound metadata table.

Your solution isolates "the source system" dependent details to create a classic "source system agnostic" data architecture for metadata integration.

However, there is still the much larger issue of Data Governance with a large organization. Oracle-Hyperion DRM is a tool to help organizations

manage the source system dependent nature of metadata to create a "normalized" view of an organizations metadata.  The solution you present here

is a nice complement to DRM, which you also point out is another potential "external" data source.    EPMA and more recently FDMEE

have native integration with DRM (without the need to understand DRM's API or DRM's Data Structures).     I for one, would love to see how your

solution paired with DRM, where DRM acts as the central enterprise repository the entire organizations metadata management needs.  How

about a DRM to Hyperion Planning IKM !!!!!.

1 - 3
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Oct 4 2008
Added on Sep 5 2008
1 comment
491 views