BEA Logo BEA WLCS Release Release Number

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

 

   WLCS Doc Home   |   Installing Commerce Servers   |   Previous Topic   |   Next Topic   |   Contents

Example Applications

 

Example Applications includes the following topics:

Example Applications

Portal Reference Implementation Notes

Login

User/Group Creation

Caching Properties

Repository Considerations

exampleportal Service Manager Entry

 


Example Applications

The example applications listed here work out of the box with the Cloudscape database and reference implementation DMS.

Note: Refer to WebLogic Commerce Servers Configuration for information about making configuration changes to the system. You need to change configurations if you use a database other than Cloudscape or a DMS other than the reference implementation DMS shipped with WLCS 2.0.1. The configuration document also contains information about configuring other pieces of the system, including servlets and portals.

 


Portal Reference Implementation Notes

A good way to get an overview of the new WebLogic Commerce Servers 2.0.1 Portal Management features is to examine the exampleportal reference implementation. The following sections explain various features of the implementation.

Login

Login to the reference implementation is achieved through the <install-dir>/server/public_html/portals/repository/
_userlogin.jsp
page. The following denotes how a user is validated and their portal, group, and user personalization are determined. This assumes that the user is on the login page, which may be accessed from the example portal.

  1. Point your browser to http://<wl-host>:<port>/exampleportal.

  2. Click the key icon in the upper-right corner of the page to log in.

  3. Enter a user name and password.

  4. Validate the user against the User Management realm. These are database tables specified in the weblogic.properties file.

  5. Validate the Group Selection specified in the User Management administration tool.

User/Group Creation

Default DB Realm

  1. A user may be created through the user management tools if you're using the default realm. The user management tools also provide the option of attaching this user to a group.

  2. If a new user is created from within the portal registration page (create your profile link), this will automatically add the user and then add the user to the AcmeUsers group.

Third Party Realms

  1. A user or group may be created through implementation specific tools. For example, from a supported LDAP realm, you would use the tools that came with your LDAP server to manage your users and groups.

  2. If using a third-party realm with the example portal, the registration page for creating users should not be used.

Caching Properties

The portal reference implementation has taken advantage of two primary caching schemes to improve performance.

  1. User property information is retrieved only once during an active user's session. Be aware that if a login is in use on multiple browser instances, properties may be out of synchronization. For example, Scott is using login acme, and Tim also using login acme. They are both logged in concurrently. Scott changes acme's colors from green to red. Scott will see these changes immediately. Tim will not see these changes until he logs out and logs back in. To force a refresh on all properties each time, change the usecache attribute on the <um:getproperty> tag to false or leave the attribute out. Please refer to the <um:getproperty> tag information.

  2. The displayed portlets are cached while the user is logged in or logged out. The portlet list is refreshed on a change in login status or when the session has been invalidated. However, the values are reset after a save within add/remove portlets and portlet layout. If you wish to have the list retrieved from the database on every display of the portal, edit the <install-dir>/server/public_html/portals/repository/
    portalcontent.jsp
    .

Repository Considerations

The repository is a way to share files (images, portlets, headers, etc.) between multiple portals. The reference portal is shipped in the repository directory underneath the portals directory. If you want to create a portal, simply copy the repository directory structure to a new directory (do not copy the files within the directories). This new directory will become the working directory for your portal.

Note: Remember that you need to add the corresponding entry of the portal to the weblogic.properties file.

For example, the developer wishes to create a company specific version of the header for the new portal. Simply copy header.jsp to your new directory and modify it. During execution, the routing mechanism built into the portal framework checks the working directory for the JSP. If the file is not found, the framework retrieves the file from of the repository directory. So if you are creating portlets that will be shared across multiple portals, simply place them in repository/portlets. Two things to be aware of:

  1. The refresh of the working directory files is controlled by the portal entry within weblogic.properties. The exampleportal entry is shipped with a 120 second refresh time. This means that the new working directory files will only be picked up every two minutes. A value of -1, means that every call routed through the portal will force a refresh on the working directory. This value is used for development purposes, mostly. For performance reasons, a value of 600 (5 minutes) or more should be used for deployment.

  2. Any portlets placed within the working directory can not be shared across portals.

Setting up a portal

  1. Use the Portal Management administration tool to create the portal.

  2. Update the weblogic.properties file to include the new portal.

  3. Create a new directory under <install-dir>/server/public_html/portals by copying the repository directory structure (excluding the files).

  4. Restart the server.

exampleportal Service Manager Entry

This is a short reference explanation of the service manager entry for the example portal that ships with the product. For more information, please refer to the WLPS documentation.

Note: The bold-faced text in the entry comprises comments only. You should remove the bold text if you cut and paste this entry. If you leave it in, it will corrupt the weblogic.properties file.

weblogic.httpd.register.exampleportal=com.beasys.commerce.portal.admin.PortalServiceManager
weblogic.httpd.initArgs.exampleportal=\ servlet name
portalname=exampleportal,\ portal name defined within
the tools
homepage=/portals/example/portal.jsp,\ the home page for the
portal
defaultdest=/portals/example/portal.jsp,\ user is not
logged in, where should the framework route
workingdir=/portals/example/,\ where to check for
overridden portal/portlet files
groupname=AcmeUsers,\ default group for portal
sessioncomparator=com.beasys.commerce.portal.admin.
PortalSessionComparator,\ class to determine if the
session is valid
refreshworkingdir=120,\ how often to refresh the working
directory entries
repositorydir=/portals/repository/,\ where are the shared
files
timeout=99999,\ how long until the session and cookies timeout
allowautologin=false if the cookies are valid, should the
auto login feature be enabled