Defining a tool tip message on Table column label

In one of my earlier post, I explained how to define tool tip for Table Column Filter. In this post, I will explain how to define tool tip message/short description on a table column label.

- Select the column in the table for which you want to define tool tip.

- Expand Column facets node for that column and select header facet.

- Inside the header facet add an Output Text component and set it's value property same as column header text as shown:

 - The custom tool tip for the table column label can now be set on the shortDesc property of Output Text. After this modification, the column code looks like:

UI

Implementation of SelectManyShuttle component

The selectManyShuttle provides a mechanism for selecting multiple values from a list of values by allowing the user to move items between two lists. SelectManyShuttle

Use-Case:

The mapping between two entities should be persisted in a third database entity.

Say, there are three tables in an application, EMP, ROLES & EMP_ROLES. The EMP table is shown as a form layout allowing the user to navigate between the records, create a new record, update an existing record & commit all the changes. The SelectManyShuttle component is used to display all  the ROLES like Manager, President etc. For an EMP record, the user can select multiple roles and shuttle them to the right. 

When a user shuttle any Role to the right for an EMP record,  an entry is made in EMP_ROLES Table and vice versa. The EMP_ROLES table contains all the ROLES selected for an EMP record. And while navigating between the EMP records, the corresponding ROLES saved in the EMP_ROLES db table are displayed as selected.

The UI looks like:

 Steps implemented are:

1. Create a Fusion Web Application using jdeveloper.

2. Create all the required Business Components (EO, VO,VLink AM) for the above data model.
3. Don't forget to create a view link between EmpVO and EmpRolesVO, which will be used to display the pre-selected roles for an EMP record. The data model will be as shown:

4. Drag and drop the EmpVO as a form layout with navigations.

5. Drag SelectManyShuttle UI Component and bind the value property of it to a managed bean property, which evaluates the values to be displayed as selected for an EMP record as shown:

where getSelectedRoles method is:

6. When any Role is shuttle to the right, first it is saved in a pageFlowScope variable, then it is processed in the commit method as shown:

7. When user navigates between the records, getSelectedRoles() method is called, which will fetch the ROLES for an EMP record and then display them as pre-selected in SelectManyShuttle component. Partial triggers is set on the SelectManyShuttle component wrt to the navigation buttons as shown:

8. The user can clear the selection made in the SelectManyShuttle component by clicking the Clear button. The code to clear selection is as shown:

Sample Workspace:
Download the sample work space from here. 

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.