How to change WebLogic Portal Administration Console URL?

WebLogic Portal Server provides an admin tool for each portal application. WebLogic Portal Administration Console is deployed a shared library so that each application can reference them to use it. To access the WebLogic Portal Administration Console you have to suffix "Admin" to the display name of the portal web application module. For eg. if you have a portal web application module named "CustomerService" then the WebLogic Portal Administration Console is access through http://server:port/CustomerServiceAdmin.

One of the common question is "How to change the URL to access the WebLogic Portal Administration Console for my application?" The main motive could be to customize the URL or to hide it from the users. The WebLogic Portal Administration Console shared library is registered in the weblogic-application.xml file of the Portal EAR. With in that weblogic specific descriptor there is an option to override the context-root value for the library using library-context-root-override tag. You can modify that value by directly editing the weblogic specific application deployment deployment descriptor or you can use deployment plan to override that value. The following is an example:

...

 
   tools
   CustomerServiceConsole
 

The above descriptor is located inside the META-INF folder of the portal enterprise application (EAR).

Using WLST with Oracle Fusion Middleware Products

WebLogic Scripting Tool (WLST) is the standard command-line and scritping solution for administering WebLogic Server. Now with WebLogic Server (WLS) being the core application server for the Oracle Fusion Middleware (OFMW) components, WLST is also being extended for configuring and monitoring OFMW coponents. For example now you can use WLST for configuring Oracle SOA Suite, Oracle Web Center etc. WLST can be started by invoking the corresponding Java class or using wlst.cmd/sh script under the WL_HOME/common/bin folder for WLS environments. But when WLST is being used with other OFMW components it requires additional libraries and modules.

So instead of starting WLST from the WLS folders, it should be started from the respective component folders (E.g ORACLE_HOME_for_SOA/common/bin/wlst.sh). That way all the required additional libraries and modules are loaded and you can use the extended command to configure OFMW components like Oracle SOA suite, Oracle Web Center etc. If in case you started WLST from WLS folders or by directly invoking the Java command then you might see an error similar to the following:

wls:/wl_S3001/serverConfig> deleteConnection(appName, conn-name)
Traceback (innermost last):
File "", line 1, in ?
NameError: deleteConnection


The above is an example of a general Oracle WebCenter custom WLST command deleteConnection. If the command is not recognized by WLST then you would receive a NameError. This is the indication that WLST did not understood that command. As the OFMW component specific command are exention to the basic WLST they work only when the proper libraries and modules are loaded. You can find more information about this here - http://download.oracle.com/docs/cd/E12839_01/core.1111/e10105/getstart.htm#ASADM10692

Don't want to get prompted for confirmation in WebLgic Console?

If you are using WebLogic Admin console frequently to configure resources or to manage the life cycle of the servers, you might have seen a confirmation prompt. This prompt will show not up when you are running the domain in development mode. When the domain is running in production mode they will ask confirmation for all the operations. There used to be no way to disable this confirmation page prior WebLogic Server 10.3. Now in WebLogic Server 10.3 and higher you can set a console user preference that can disable these confirmation pages.

Use the tool bar at the center (top) of the console to go to the "Preferences". Under the "User Preferences" tab you will find an option called "Ask for confirmation in operations". By default it will be enabled in production domains and you can disable it to avoid that annoying confirmation pages where will have to click either "Yes" or "No". While you are there explore the other useful preferences like "Show Inline Help" and "Show Advanced Sections" which can buy some real-estate space in the console and save you some clicks.

JDeveloper 11g is here . . .

JDeveloper 11g is now getting shipped with our very own Oracle WebLogic Server 10g (10.3). Yes, if you download Oracle JDeveloper 11g (11.1.1.0.1) you can develop Java, Java EE and Database applications. A default WebLogic Server 10g Domain will be created when installing JDeveloper which can be used to deploy and run applications. You can also build applications and run it on Apache Tomcat, IBM WebSphere, JBoss application servers.



The default WebLogic Server Domain must be used for running and debugging web applications from within the JDeveloper design time. ADF 11g applications require a Java EE 5 container and currently WebLogic Server 10g (10.3) is certified,

A key information to know if you are currently using JDeveloper is that migration to JDeveloper 11g is supported only from JDeveloper 10.1.3.4. So you might want to first upgrade to 10.1.3.4 if you are still in other versions.

You can download Oracle JDeveloper 11g here - http://www.oracle.com/technology/software/products/jdev/htdocs/soft11.html

If you want to get started with JDeveloper 11g, here are few tutorials from Oracle by Example Series (OBE) - http://www.oracle.com/technology/obe/obe11jdev/11/index.html

More step-by-step instructions guides are available for common tasks as the Cue cards here - http://www.oracle.com/technology/products/jdev/11/cuecards/index.html

Fly Like a Rocket using JRockit JVM

JRockit is the first JVM designed to run server-side applications. It is now the high performance JVM used in the core of Oracle Fusion Middleware. With its deterministic nature for performing garbage collection, it is now used on many time driven and high through application architectures like Algo Trading, Military Asset Tracking, Transportation & Logistics etc.

With its wide adoption, rich tool set and high performance, JRockit is now used for Enterprise Application Servers, Portal Servers, Integration Servers, Enterprise Service Bus, Identity Management Servers, Time Driven & Complex Event Processing Applications etc.

Oracle WebLogic Server installations are bundled with 2 flavors of JVM. On all Intel based installers in addition to Sun's Hotspot JVM, Oracle's JRockit JVM is also included. The default JVM for a WebLogic Domain is configured when a Domain is created using the Configuration Wizard or WLST. But all the built-in tools comes with WebLogic Server are configured to JRockit JVM. If the Domain is selected to run in Production Mode the JVM selection will default to the bundled JRockit SDK whereas Sun SDK will be selected for the Domains configured in Development Mode.


After the fact that you create the domain if you want to change your server(s) JDK to JRockit, you can do so by modifying the server's start up scripts. The server start up scripts startWebLogic.cmd/sh and startManagedWebLogic.cmd/sh both rely on a setup script for environment setting - setDomainEnv.sh. You can include an environment variable (JAVA_VENDOR) definition either on top of that script or on the shell to modify the JVM that the server(s) should use.

Windows:
set JAVA_VENDOR=BEA

*nix:
export JAVA_VENDOR=BEA

After this variable is set, the server(s) should start using JRockit JVM. You can find out the version of JVM used by the server on its log output or stdout. Some of the non-standard command-line options are not supported by all JVM vendors. So you might want to refer to JRockit's documentation for JRockit specific command-line options.



JRockit provides lot of tools that you can use to get more inside and realtime information from the applications running on JRockit JVM. These tools are packaged as JRockit Mission Control. I will write more about JRockit Mission Control and the tools included in that package on my future entries.

Oracle JRockit in not only for WebLogic Server and WebLogic Suite of products. You can use this for any Java application. JRockit is a certified and compatible with Java application complied using Sun SDK.

To find out more about JRockit go to the official FAQ page - http://www.oracle.com/technology/software/products/jrockit/FAQ.html

To download JRockit go to - http://www.oracle.com/technology/software/products/jrockit/index.html

Identity Management At Ease

I always wonder how companies manage to keep user information in sync with their many IT resources. Whenever a new employee or contractor joins a company, his/her information must be inserted into all the systems such as Network, Email, Packaged Applications such as Expenses, Human Resources, Travel, Procurement etc. The above mentioned systems a small subset of what companies might use. The system might have been either purchased or home grown. There needs to be a central place from where we should be able to insert the user information or provision the user information into all these systems. Creating a bunch of request to different administrator and having them individually deal with their system can be a logical approach. But keeping track of all the individual requests associated with the main request to provision the user to all the IT system and getting approvals when needed demands for an automated way in which this should be done. The same applies when an employee or contractor leaves the company. Their information should be de-provisioned or removed from all the systems. According to Gartner, the time IT spend in creating or removing user information constitutes around 10% where as dynamically modifying user privileges with resources constitutes the rest of 90%.

Oracle Identity Manager (OIM) is a key product in the Oracle Identity & Access Management Suite which is a part of Oracle Fusion Middleware. After knowing what OIM does, my mysteries were solved about Identity Management. OIM not only ease the provisioning of user across various systems but also helps companies to keep auditing information for compliance purpose. With growing privacy concern, meeting the regulatory and the privacy requirements are mandatory for many business such as Finance, Health care etc. OIM is a hot pluggable product built on J2EE which maintains a repository which can be synced with other systems such as corporate directories, operating systems, database etc. With OIM, user information can be provisioned, de-provisioned, passwords can be managed across systems. These tasks can either be automated with no manual intervention of can be assigned with approval work flows that provides control for managers and power users.



For auditing and compliance reasons reports can be generated on access control and user information such as who has access to what and when etc. Also to ensure that only appropriate users have accessed information in enterprise OIM support a process called Attestation. Companies used to maintain mountains of documentation, reports in the form of paper files to keep track of security information in the past which is now eliminated to these niche Identity Management products.

For more information on OIM visit Oracle's product page here. I shall write more about OIM and the other products in Oracle Identity & Access Management Suite in the coming days.

Local Proxy & Federated Portals

I remember those days when Enterprise Java Bean (EJB) was a big buzz and every project want to use them. They used so much that the projects and applications that didn't demand an use for enterprise level services started implementing them. I felt like that was another 'Gold Rush' people didn't want to miss. After a while everyone started realizing that EJBs are not for everyone. Also EJBs could only be accessed remotely when they originally released in EJB 1.0. But application server vendors provided their value addition by optimizing the local access to an EJB by by-passing RMI. This gave a hint to the standards committee and they included this as a feature - Local Interfaces in the later EJB Specification 2.0. So in short Best Practices started to emerge and now you can say the usage of EJBs in IT projects got streamlined.

You could be wondering why am I taking about EJBs when the title of this blog reads 'Local Proxy & Federated Portals'. Now coming to the portal paradigm, Web Services Remote Portlet is a specification from OASIS Technical Committees which defines a web service interface for interacting with presentation oriented web services. The portal application that provides their presentation oriented services for consumption by other portal servers is called as a Producer and the later is called as a Consumer. Typically, a consumer application does not include the business logic, data, or user interface parts of the portlet: instead it simply collects the user interface markup delivered from producers and presents that user interface to users. One can use interceptors to programmaticaly customize the data on the receiver end as well.

As WSRP is a web services protocol, communication between the producer and consumer happens over SOAP. This communication involves serialization and deserialization and also intermediate buffers. This is the case even when the producer and consumer are located on the same server (runtime). Oracle WebLogic Portal 10 includes a new feature Local Proxy Mode. You can enable local proxy support by setting to true in WEB-INF/wsrp-producer-registry.xml in the consumer web application which will optimize the communication by avoiding network I/O. If the consumer finds the producer deployed on the same server then it will avoid the SOAP over HTTP and will use the local proxy. This saves the overhead from serialization and deserialization of SOAP. Internally WebLogic Portal will use the same execute thread to invoke the producer using servlet API. When local proxy mode is enabled the remote proxy can also be used by remote consumers. Java portlets or third-party portlets deployed on the same server can be integrated without requiring any modifications. This reminded me of the local interface with EJBs which evolved when people started realizing that they are consuming EJBs more locally than remotely.

You can find more information on WSRP here - http://e-docs.bea.com/wlp/docs100/federation/Chap-Details.html#wp1021292.
For information on local proxy mode see here - http://e-docs.bea.com/wlp/docs100/federation/Chap-Best_Practices.html#wp1010714.