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.