How to implement cascading LOV's in search criteria

Cascading LOV is a common requirement. It is dependencies of an LOV on the selected value of another LOV. In this post, I will explain how cascade LOV can be implemented in a search criteria form.

Use Case:

Searching all the employees reporting to a manager in a department. For this, cascading LOV has to be used to define the dependencies between departments and the list of all employees in that department. i.e one LOV on DepartmentId and another LOV on ManagerId to retrieve all the employees in the selected DepartmentId LOV.

Steps:

1. Create Read Only view Objects on Employees, Departments table. (hr schema is used)

     Say EmployeesVO and DepartmentsVO

2. Define a view criteria (findByDepartmentId) in EmployeesVO to filter all the employees based on a DepartmentId.

 

3. Add DepartmentsVO and EmployeesVO as view accessors to EmployeesVO. In the added Employees view accessor, shuttle the view criteria(created in step #2) to the right. Provide the value for the bind variable as DepartmentId.

4. Define LOV's on DepartmentId (wrt Departments view accessor) and ManagerId (wrt Employees view accessor). Once a Department is selected in Department LOV, DepartmentId attribute will hold the value of selected department. This selected value is passed to the findByDepartmentId view criteria as defined in the above steps.

5. Define a view criteria (findByDepartmentMgrId) in EmployeesVO, which will be dragged and dropped as a query component on jspx page.

6. In the view controller project, create a jspx page. Drag the view criteria defined in the above step as query component. 

7. Run the jspx page. Dept Id LOV will show all the departments, while Mgr Id LOV will show all the employees for the selected Department. After selecting the Dept Id and Mgr Id values, click on Search button. The resultant table will show all the employees reporting to the selected manager of the selected department.

Sample Workspace:
Download the sample workspace from here.

Navigate to a different page upon successful login in web center portal application

In this post, I will describe how can an end user navigate to a different page upon successful login in a WebCenter Portal application.  By default the user is navigated to home.jspx page. But if the user wants to navigate to a different page, he/she can configure it in faces-config.xml.

By default the generated faces-config.xml file in a web center portal application looks like:  

Upon successful login, the home page is displayed:

Modify in faces-config.xml, such that the navigation-case points to a different page (ex: About Us)

Upon successful login, the user will be navigated to About Us page:

How to set classpath in weblogic server

Developers like me might have struggled to figure out a way to set some jars in the CLASSPATH of the weblogic server to access and load the correct Java classes when the server starts. So, I thought of putting my solution in this blog, which might be useful for some developers.

Basically you need to modify the WEBLOGIC_CLASSPATH environment variable in commEnv.cmd file located at <WL_HOME>\common\bin. 
In my case it is C:\11.1.1.6\wlserver_10.3\common\bin\commEnv.cmd

Append the WEBLOGIC_CLASSPATH variable at the end with the location of jars to be loaded as below:

set WEBLOGIC_CLASSPATH=%JAVA_HOME%\lib\tools.jar;%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;%FEATURES_DIR%\weblogic.server.modules_10.3.5.0.jar;%WL_HOME%\server\lib\webservices.jar;%ANT_HOME%/lib/ant-all.jar;%ANT_CONTRIB%/lib/ant-contrib.jar;C:\Users\uagarwal\Downloads\lib\tdgssconfig.jar;C:\Users\uagarwal\Downloads\lib\terajdbc4.jar;

Here, I have set 

C:\Users\uagarwal\Downloads\lib\tdgssconfig.jar; 

C:\Users\uagarwal\Downloads\lib\terajdbc4.jar; 

at the end of the WEBLOGIC_CLASSPATH. 

Alternatively, you can put the jars in <WL_HOME>\server\lib where other jars are present. But don't forget to restart the server, in order to pick the latest classes by the server.

Using managed property to evaluate bindings

In this post, I will describe how to get hold of DCBindingContainer using managed property.

Managed property is a bean attribute that is exposed through getter and setter methods in a managed bean. The <managed-property> element is a child of <managed-bean> element in adfc-config.xml. It calls its equivalent setter method defined in the managed bean upon bean initialization. Managed property must have a name and a value.

                                                  Managed property can be defined in adfc-config.xml to have an expression always evaluated and ready for use. For example, a managed property can be used to evaluate #{bindings}, which is used to get hold of DCBindingContainer.

For this, define a managed bean and register the bean in adfc-config.xml file. In adfc-config.xml, select the bean, where a managed property has to be defined. Click on Add(+) button to add a managed property:

 

after the modification, the source code looks like:

In the bean define getter and setter for the managed property as:

You can use (DCBindingContainer)getBindings to get hold of DCBindingContainer as shown above.

How to modify end point URL's in an ADF/WebCenter application

Developers might have came across situations where they need to modify WSDL end point URL's, some properties or constants pertaining to a server before deploying their ADF/WebCenter application on different servers. Modifying these every time before deployment is a pain. So there should be some repository where you can define all these end point urls and properties, OR some mechanism such that the deployment process takes care of pointing to correct end point url's and properties before deploying on respective server.

There are many ways to achieve this. I will describe a few, which I implemented in some of my projects.

1. Deploying a .properties file as shared library on respective servers

2. Using build.xml file to modify the properties/URL's before deployment

3. Reading the properties/URL's from a db table.

All the above implementations have their own pros and cons. In this blog I will describe how to use properties file to change the WSDL end point URLs. With my next blog I will describe how to read the properties from a db table.

Create a simple project in the application which will contain the properties file. The project structure is as shown: 

Create a properties file that contains all the properties pertaining to all the servers.

Create a WAR deployment profile for the project. WAR profile will be deployed as Shared Library on respective servers. Create a JAR profile as well for the project, for successful compilation of main application.

 

You need to create and set MANIFEST.MF file to describe the above shared library. 

 

Sample MANIFEST.MF file with shared library name: WrsTsrMgrSharedProbLib

While deploying this WAR package, select Deploy as a shared Library option.

After successful deployment, you can see shared library WrsTsrMgrSharedProbLib under deployments.

Add the JAR created above in the main application for its successful compilation. However, this jar should not be packaged inside EAR archive during deployment. For this, uncheck it from WAR contributors of the main application as shown.

One last configuration required in main application is to register the shared library in the weblogic.xml file. This will allow the consuming applications to access the properties file at run time.

 

 You can access the properties file as below to change the end point URL in service.java file.

Where getProperty method(defined in an utility class, PropertiesUtil) is:

Developers need to deploy the properties file once before deploying the main application on respective servers. It is not required to deploy the shared library always before the main application deployment, unless and until any property is changed. However, if the shared library has to be deployed, the main application should be brought down and started again to pick the latest changes.

Another approach to modify the end point urls or properties is to write a build script that should be ran before deployment. The build file will change all the properties appropriately using the Replace ant task.

Great WebCenter Tutorial

I found an excellent tutorial on WebCenter by Yannick Ongena. It is very helpful for novice webcenter developers.
Blog: http://www.yonaweb.be/webcenter_tutorial/introduction 

Very easy to get started with WebCenter after reading this tutorial. The concepts are very well explained with a lot of screen shots.

Another blog from Yannick Ongena for installing webcenter:
http://yonaweb.be/installing_webcenter_11g_ps3_scratch 

How to pass Oracle Table Type Object from Java Code to Oracle Stored Procedure

I had a requirement to pass Oracle Table Type Objects to a Store procedure. In this blog, I will explain how we can pass the Table type object from Java code.

The table type objects I used are: 

JTF_NUMBER_TABLE               //Table type of Number Type       JTF_VARCHAR2_TABLE_100  //Table type of Varchar2(100) Type

These two objects are input parameters to the stored procedure.

If you have Number, String Array as shown below:

Number[] srContactPointId = new Number[4];
String[] contactType = new String[4];   

These can be passed as Table type Object using the following code.

//Getting hold of the transaction

DBTransaction txn = (DBTransaction)wrsAmImpl.getDBTransaction();
OracleCallableStatement cstmt = (OracleCallableStatement)txn.createCallableStatement(cs, 1);

//Getting the Connection Object
Connection conn = cstmt.getConnection();

//Creating oracle.sql.ArrayDescriptor Object for corresponding Table Type Object.

ArrayDescriptor numberDescriptor =  new ArrayDescriptor("APPS.JTF_NUMBER_TABLE", conn);

ArrayDescriptor stringDescriptor =  new ArrayDescriptor("APPS.APPS.JTF_VARCHAR2_TABLE_100", conn);

//Creating oracle.sql.ARRAY object to be passed to the Oracle Stored Procedure

ARRAY contactPointId = new ARRAY(numberDescriptor , conn, contactPartyId);

ARRAY contType = new ARRAY(stringDescriptor , conn, contactType);