IBM Workplace Web Content Management
Content Repository
Overview
IBM Workplace Web Content Management (IWWCM) allows one to render and manage content within WebSphere Portal. Content is stored in a content repository maintained and accessed using one of the following DBMS types:
- Cloudscape (default)
- DB2 v8.1
- UDB on z/OS 7.1
- Oracle 9i
- DB2/400 (iSeries)
- IBM Content Manager
- SQL Server
Each IWWCM instance requires a separate repository and a unique set of tables.
IWWCM uses a proprietary set of indexes which are maintained on the physical disk of the installed node by IWWCM, and exist for the sole purpose of managing and retrieving content within IWWCM.
----------
| HTTP |_________
| Server | |
---------- |
| -------------
| | Directory |
| | Server |
| -------------
| |
---------- ---------- |
| Portal |___ | Portal |_______|
| DBMS | | Server |
---------- |--------|
________ | IWWCM |_______
| ---------- |
| |
----------- ---------
| IWWCM | | IWWCM |
| Indexes | | DBMS |
----------- ---------
The content repository consists of the following tables:
AJPE Object definitions AJPE_RESOURCES Binary objects, such as bitmaps and other files
Both tables must coexist in the same instance.
For Cloudscape, tables can be found under....
$PORTAL_HOME/wcm/ilwwcm/db/WCMDB.
AJPE
Object definitions are stored as XML within the XML_CONTENT CLOB column.
CREATE TABLE [SCHEMA].AJPE
(
"ID" BIGINT NOT NULL ,
"LAST_MODIFIED" TIMESTAMP NOT NULL,
"XML_CONTENT" CLOB(16777216) LOGGED NOT COMPACT NOT NULL,
"COMPONENT_TYPE" VARCHAR(256) NOT NULL
)
"IN "[TABLESPACE]" ;
The primary key, ID, is a generated HEX value.
AJPE_RESOURCES
Binary objects are stored within the BYTE_CONTENT BLOB column.
CREATE TABLE [SCHEMA].AJPE_RESOURCES
(
"ID" BIGINT NOT NULL ,
"LAST_MODIFIED" TIMESTAMP NOT NULL,
"BYTE_CONTENT" BLOB([MAX_SIZE]) LOGGED NOT COMPACT NOT NULL,
"COMPONENT_TYPE" VARCHAR(256) NOT NULL,
"IDENTITY_TYPE" VARCHAR(256) NOT NULL
)
IN "[TABLESPACE]" ;
The primary key, ID, is a generated HEX value.
MAX_SIZE establishes the maxmimum object size and corresponds to the property jdbc.resource.maxSize in the aptrixjpe.properties file. The default is 10 MB. These settings must match. Do not change one without changing the other.
IWWCM Indexes
IWWCM indexes...
- Link object definitions and physical objects into the content framework for rendering content
- Map the content to the authorizations maintained in the Portal User Management API (PUMA) and the WebSphere Member Manager (WMM).
They are physically located under...
$Portal Home/wcm/ilwwcm/system/indexes
The following situations will warrant (and sometimes require) index regeneration:
- Repository configuration changes
Index regeneration will be required when IWWCM is configured for a different repository, or when any changes are made to the configuration of the current repository. WPSconfig.sh will remove the existing indexes during the config-wcm-repository task.
- Abnormal program termination
Index regeneration is required when IWWCM or WebSphere Portal has been abnormally terminated. Normally, IWWCM will recognize that it has been terminated abnormally, and will perform this process automatically when WebSphere Portal is restarted.
- Following syndication/subscriber rebuild with large amounts of content
Manual index regeneration is often required when a large amount of content has been loaded into IWWCM through syndication during a rebuild. The recommendation is that after syndication rebuild completes with a large amount of content, stop WebSphere Portal, manually remove the IWWCM indexes from...
$Portal Home/wcm/ilwwcm/system/indexes
...and restart WebSphere Portal. The indexes will be rebuilt at this time, and the objects will be validated.
Index regeneration with a large repository can take an extended amount of time. All indexes must reside in the same location. They can be recreated based on the defined content in the repository during startup.
Performance
To reduce seek and latency times between index lookups put the IWWCM indexes on a separate file system on a separate physical drive.
Set JVM Heap Size large enough to put copies of IWWCM index reads into memory. If you get "Out Of Memory" exceptions or experience poor performance, try increasing heap size. For a non-iSeries production system, set maximum JVM Heap Size set to at least 1024. With iSeries, the JVM Heap is managed by the operating system, and should be left at zero.
Implementation of Clusters for High Availability
For High Availability (HA), configure Portal to be in a cluster configuration. In a cluster, maintenance can be performed on one node while the other node is active.
IWWCM nodes being configured for syndication be at the same IWWCM level
In an IWWCM cluster a copy of IWWCM from the primary node is made on each secondary node. Because each IWWCM node is not directly aware of the others, changes made on one node will not be reflected on another node until syndication occurs. This can cause content within the cluster to get out of sync, especially if there are multiple authors using IWWVCM.
After creation, by default, secondary nodes point to the primary node repository. Each secondary node must be reconfigured for a separate repository.
Use a staging server to provide a central location for developing content, and then syndicate to all nodes in the cluster.
Syndication can be activated as needed, or can be automated to occur automatically as changes are made. There is no limit to the number of nodes that can be syndicated to. But consideration must be made when large amounts of content is syndicated.
If there are a large number of receiving nodes, there could be a lag before all nodes have the changes reflected. To minimize a lag when there are a large number of nodes requiring syndication, consider using a syndication tree. As each node receives updates, it branches off and updates additional nodes. By doing this, you can optimize your ability to update multiple nodes quickly.
Moving content between active nodes
Because object definitions are managed in complex XML within the AJPE table, syndication is the only supported method for moving content between the repositories of active IWWCM nodes, and avoid moving content using database utilities or other data movement applications.
Import/export utilities built into database management systems can often remove any special characters within the XML source, or truncate the length, given the variable nature of XML. Other database movement utilities may also have the same effect. For disaster recovery, standard database backup and restore procedures are advised.
For transferring content from the default Cloudscape repository to another supported repository, the tasks transfer-wcm-to-existing-repository and transfer-wcm-to-new-repository are used. Never export raw object definitions across platforms (this presents issues regarding EDCIDC translation when a z/OS system is involved), or carriage return/line feeds between Windows/Unix platforms.
To enable syndication in a cluster, configure a Virtual Host within the Deployment Manager, to allow access to the individual IWWCM nodes within the cluster...
- Open the WebSphere Administrative Console.
- Go to...
Environment | Virtual Hosts | default_host | Host Aliases | New
- Add the hostname and port that correspond to the Web Container HTTP Transport (for instance, www.setgetweb.com, port 9081).
- Access the IWWCM Authoring portlet on each of the individual nodes and configure syndication. For example,...
http://www.setgetweb.com:9081/wps/portal
- Use IWWCM syndication to populate each IWWCM repository in the cluster.
Rendering in a cluster
Local rendering is the default method for each node. The synchronization process in the Deployment Manager handles the updates between nodes regarding portlet configuration.
For rendering content that exists on a remote IWWCM node, configure the Remote Rendering portlet using Virtual Hosts or an HTTP server.
A third method of rendering is Servlet Rendering, which is a method used for embedding IWWCM links into traditional Web pages. Rendering is not performed with a WebSphere Portal installation. For this configuration, the URL of the IWWCM content is placed within a traditional Web page. This URL then shows up as a link on your page, and can be accessed through a standard browser.
Repository configuration
After IWWCM repository settings are written to wpconfig.properties file, the following tasks are run...
WPSconfig.sh create-wcm-tables Create the tables (if they do not already exist). WPSconfig.sh config-wcm-repository Configure the repository (existing repository entries are removed).
After configuration has been completed, the aptrixjpe.properties and connect.cfg files will reflect the new repository settings. IWWCM does not use wpconfig.properties when it runs. IWWCM uses its own configuration files stored within...
$Portal Home]/wcm/connect/config
IWWCM specific configuration files include...
Any time the IWWCM repository changes, the config-wcm-repository task must be run. This includes resetting passwords for the repository access.
Repository configuration commands
create-wcm-tables Creates WCM tables in a new database. remove-wcm-repository Removes the repository configuration from IWWCM. Data is left intact. config-wcm-repository Configures the IWWCM repository. This will be run for any repository changes (drivers, password, userids, and so on). transfer-wcm-to-existing-repository Transfers the Cloudscape repository to a repository that was manually created. transfer-wcm-to-new-repository Transfers the Cloudscape repository to a new repository, and creates the tables. transfer-wcm-filesystem-to-cloudscape Transfers IWWCM version 2.0 content from a file system into a Cloudscape repository.
See also
- IWWCM product page
- IWWCM Information Center
- WebSphere Portal Information Center
- developerWorks blogs
Workplace Web Content Management is a trademark of the IBM Corporation in the United States, other countries, or both.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.