Tuesday, November 24, 2009

Integration in Oracle ADF with ADF Task Flows and ADF BC Imports

Inspired by a question about LOV reusability from one of my readers, I decided to post one more blog in integration series. Today I will refactor application and extract shared entity into common Model project, I will create shared LOV component as well. You can read my previous postings for the same topic from this blog - Building and Integrating Oracle ADF 11g Applications with OjDeploy Utility. I will describe how you can reuse your Model components from shared projects using ADF BC Import functionality (Import Functionality in Oracle ADF BC).

Download updated application - ADFIntegration6.zip. This sample contains one more project - CommonModel. It contains shared EO for Department and one LOV VO.

Originally, I had following Model structure for LocalApp application:



And following Model for RemoteApp application:



Let's say I got a requirement to join Employees VO in RemoteApp with Department table and declare LOV component on DepartmentName attribute. This means I need to have Departments EO available in RemoteApp. However, I already have this EO in another LocalApp application, if I will create again in RemoteApp it will be duplicate. This means I should extract Departments EO from LocalApp into common project and use it through ADF Library JAR import. I have created common Model project and declared Department EO there along with LOV component for Departments:



I deploy CommonModel project into ADF Library JAR as it is described in my post above and import it into LocalApp through Business Components Imports:



Now I can remove Departments EO from LocalApp Model and use it through imported library. You can see that Departments EO is included now from com.redsamurai.model package:



The same for RemoteApp project, I have included there same ADF Library JAR:



And I can use shared Departments EO in Association relationship between Departments and Employees EO's:



Probably you already noticed that LOV component is imported together with EO:



Then I can use it while declaring LOV for DepartmentName attribute:



Finally, before running my application, I will update its skin setting to fusion. My original application was developed with previous JDeveloper release, however I want to use new skin, I can change it trinidad-config.xml file:



On runtime I can see Employees table joined with Departments and DepartmentName LOV column rendered:


11 comments:

Anonymous said...

Hi
When you changed from blaf-plus rich skin to fusion skin, did you face any issue with the labels on different components ? When I switched, the labels are appearing in white color and thus not visible in a panel box with a light theme.

Andrej Baranovskij said...

Hello,

No, for me it worked smoothly...

Andrejus

fakintoye said...

hi Andrejus,

I am trying to use ADF library jars to break up a relativily large project... but i keep getting this problem, where i exit jdeveloper, come back in... and all the imports are gone... or not displaying any imported components. Do you have any idea what might cause this.

Thanks

Andrej Baranovskij said...

Hmm..., it was happening for me in previous JDev version, but never in current release. Which JDev version you are using?

Andrejus

fakintoye said...

Hi Andrejus

I'm using 11.1.1.2.0

Thanks

femi

fakintoye said...

Hi Again

I'm using the current release... 11.1.1.2.0. Do you have any idea what the problem might be?

Thanks, Femi

Andrej Baranovskij said...

May be you have cycle dependencies between your JAR's, this can cause problems.

Andrejus

fakintoye said...

hi again Andrejus,

My name is Femi, a Nigerian fellow you met at OOW '09, we discussed briefly on the best method for breaking up a fairly large ADF project into sub-modules that could be integrated into a larger application for deployment. Do you have (or can you recommend) a layout for such an application, perhaps with a BC project with core components which can be deployed as an ADF library and inherited by the BC components in the respective projects of the sub modules. I know you have a session on the topic scheduled for ODTUG '10... but that's a loooong way to wait for my current project.

I'd appreciate any pointers...

Thanks

Andrej Baranovskij said...

Hi Femi,

Nice to talk to you again, can you send me email about this topic?

Regards,
Andrejus

Srini Rangarajan said...

We have the following use case:

DeptVO - contains a hierarchy of departments (standard dept table + parent_dept_no to reflect hierarchy)
EmpVO - lists the employees belonging to the department.

Our requirement is to present a Tree Table as follows:

Root Dept
|_____Child 1 Dept
| |__Emp1
| |__Emp2
| |__GrandChild Dept
| |__Emp3
|
|_____Child 2 Dept

On this tree table, when a 'Dept' type is created, it should add to the Dept table (through Dept VO) and when a 'Emp' type is created it should add to the Emp table (through the EmpVO).

How should we model our VOs, Viewlinks and map it to the tree definition?

Srini Rangarajan said...

We have the following use case:

DeptVO - contains a hierarchy of departments (standard dept table + parent_dept_no to reflect hierarchy)
EmpVO - lists the employees belonging to the department.

Our requirement is to present a Tree Table as follows:

Root Dept
|_____Child 1 Dept
| |__Emp1
| |__Emp2
| |__GrandChild Dept
| |__Emp3
|
|_____Child 2 Dept

On this tree table, when a 'Dept' type is created, it should add to the Dept table (through Dept VO) and when a 'Emp' type is created it should add to the Emp table (through the EmpVO).

How should we model our VOs, Viewlinks and map it to the tree definition?