IBM FileNet P8 Content Manager: Administrative Tools and Tasks

Getting Started with IBM FileNet P8 Content Manager

Install, customize, and administer the powerful FileNet Enterprise Content Management platform

• Quickly get up to speed on all significant features and the major components of IBM FileNet P8 Content Manager
• Provides technical details that are valuable both for beginners and experienced Content Management professionals alike, without repeating product reference documentation
• Gives a big picture description of Enterprise Content Management and related IT areas to set the context for Content Manager
• Written by an IBM employee, Bill Carpenter, who has extensive experience in Content Manager product development, this book gives practical tips and notes with a step-by-step approach to design real Enterprise Content Management solutions to solve your business needs       

The following will be covered in the next article.

• A discussion of an Object Store and what’s in it
• An example of creating a custom class and adding custom properties to it

FEM must run on a Microsoft Windows machine. Even if you are using virtual machine images or other isolated servers for your CM environment, you might wish to install FEM on a normal Windows desktop machine for your own convenience.

Domain and GCD

Here’s a simple question: what is a P8 Domain? It’s easy to give a simple answer—it’s the top-level container of all P8 things in a given installation. That needs a little clarification, though, because it seems a little circular; things are in a Domain because a Domain knows about them.

In a straightforward technical sense, things are in the same Domain if they share the same Global Configuration Database (GCD) . The GCD is, literally, a database. If we were installing additional CE servers, they would share that GCD if we wanted them to be part of the same Domain.

When you first open FEM and look at the tree view in the left-hand panel, most of the things you are looking at are things at the Domain level. We’ll be referring to the FEM tree view often, and we’re talking about the left-hand part of the user interface, as seen in the following screenshot:

FEM remembers the state of the tree view from session to session. When you start FEM the next time, it will try to open the nodes you had open when you exited. That will often mean something of a delay as it reads extensive data for each open Object Store node. You might find it a useful habit to close up all of the nodes before you exit FEM.

Most things within a Domain know about and can connect directly to each other, and nothing in a given Domain knows about any other Domain.

The GCD, and thus the Domain, contains:

• Simple properties of the Domain object itself
• Domain-level objects
• Configuration objects for more complex aspects of the Domain environment
• Pointers to other components, both as part of the CE environment and external to it

It’s a little bit subjective as to which things are objects and which are pointers to other components. It’s also a little bit subjective as to what a configuration object is for something and what a set of properties is of that something. Let’s not dwell on those philosophical subtleties. Let’s instead look at a more specific list:

• Properties: These simple properties control the behavior of or describe characteristics of the Domain itself.
  • Name and ID: Like most P8 objects, a Domain has both a Name and an ID. It’s counterintuitive, but you will rarely need to know these, and you might even sometimes forget the name of your own Domain. The reason is that you will always be connecting to some particular CE server, and that CE server is a member of exactly one Domain. Therefore, all of the APIs related to a Domain object are able to use a defaulting mechanism that means “the current Domain”.
  • Database schemas: There are properties containing the database schemas for an Object Store for each type of database supported by P8. CM uses this schema, which is an actual script of SQL statements, by default when first fleshing out a new Object Store to create tables and columns. Interestingly, you can customize the schema when you perform the Object Store creation task (either via FEM or via the API), but you should not do so on a whim.
  • Permissions: The Domain object itself is subject to access controls, and so it has a Permissions property. The actual set of access rights available is specific to Domain operations, but it is conceptually similar to access control on other objects.
• Domain-level objects: A few types of objects are contained directly within the Domain itself. We’ll talk about configuration objects in a minute, but there are a couple of non-configuration objects in the Domain.
  • AddOns: An AddOn is a bundle of metadata representing the needs of a discrete piece of functionality that is not built into the CE server. Some are provided with the product, and others are provided by third parties. An AddOn must first be created, and it is then available in the GCD for possible installation in one or more Object Stores.
  • Marking Sets: Marking Sets are a Mandatory Access Control mechanism, Security Features and Planning. Individual markings can be applied to objects in an Object Store, but the overall definition resides directly under Domain so that they may be applied uniformly across all Object Stores.
• Configuration objects:
  • Directories: All CM authentication and authorization ultimately comes down to data obtained from an LDAP directory. Some of those lookups are done by the application server, and some are done directly by the CE server. The directory configuration objects tell the CE server how to communicate with that directory or directories.
  • Subsystem configurations: There are several logical subsystems within the CE that are controlled by their own fl avors of subsystem configuration objects. Examples include trace logging configuration and CSE configuration. These are typically configured at the domain level and inherited by lower level topology nodes. A description of topology nodes is coming up in the next section of this article.
• Pointers to components:
  • Content Cache Areas: The Domain contains configuration information for content caches, which are handy for distributed deployments.
  • Rendition Engines: The Domain contains configuration and connectivity information for separately installed Rendition Engines (sometimes called publishing engines).
  • Fixed Content Devices: The domain contains configuration and connectivity information for external devices and federation sources for content.
  • PE Connection Points and Isolated Regions: The domain contains configuration and connectivity information for the Process Engine.
  • Object Stores: The heart of the CE ecosystem is the collection of ObjectStores.
  • Text Search Engine: The Domain contains configuration and connectivity information for a separately-installed Content Search Engine.

In addition to the items directly available in the tree view shown above, most of the remainder of the items contained directly within the Domain are available one way or another in the pop-up panel you get when you right-click on the Domain node in FEM and select Properties.

The pop-up panel General tab contains FEM version information. The formatting may look a little strange because the CM release number, including any fix packs, and build number are mapped into the Microsoft scheme for putting version info into DLL properties. In the previous figures, 4.51.0.100 represents CM 4.5.1.0, build 100. That’s reinforced by the internal designation of the build number, dap451.100, in parentheses. Luckily, you don’t really have to understand this scheme. You may occasionally be asked to report the numbers to IBM support, but a faithful copying is all that is required.

Topology levels

There is an explicit hierarchical topology for a Domain. It shows up most frequently when configuring subsystems. For example, CE server trace logging can be configured at any of the topology levels, with the most specific configuration settings being used. What we mean by that should be clearer once we’ve explained how the topology levels are used. You can see these topology levels in the expanded tree view in the left-hand side of FEM in the following screenshot:

At the highest level of the hierarchy is the Domain, discussed in the previous section. It corresponds to all of the components in the CE part of the CM installation.

Within a domain are one or more sites. The best way to think of a site is as a portion of a Domain located in a particular geographic area. That matters because networked communications differ in character between geographically separate areas when compared to communications within an area. The difference in character is primarily due to two factors—latency and bandwidth. Latency is a characterization of the amount of time it takes a packet to travel from one end of a connection to another. It takes longer for a network packet to travel a long distance, both because of the laws of physics and because there will usually be more network switching and routing components in the path. Bandwidth is a characterization of how much information can be carried over a connection in some fixed period of time. Bandwidth is almost always more constrained over long distances due to budgetary or capacity limits. Managing network traffic traveling between geographic areas is an important planning factor for distributed deployments.

A site contains one or more virtual servers. A virtual server is a collection of CE servers that act functionally as if they were a single server (from the point of view of the applications). Most often, this situation comes about through the use of clustering or farming for high availability or load balancing reasons. A site might contain multiple virtual servers for any reason that makes sense to the enterprise. Perhaps, for example, the virtual servers are used to segment different application mixes or user populations.

A virtual server contains one or more servers. A server is a single, addressable CE server instance running in a J2EE application server. These are sometimes referred to as physical servers, but in the 21st century that is often not literally true. In terms of running software, the only things that tangibly exist are individual CE servers. There is no independently-running piece of software that is the Domain or GCD. There is no separate piece of software that is an Object Store (except in the sense that it’s a database mediated by the RDBMS software). All CE activity happens in a CE server.

There may be other servers running software in CM—Process Engine, Content Search Engine, Rendition Engine, and Application Engine. The previous paragraph is just trying to clarify that there is no piece of running software representing the topology levels other than the server. You don’t have to worry about runtime requests being handed off to another level up or down the topological hierarchy.

Not every installation will have the need to distinguish all of those topology levels. In our all-in-one installation, the Domain contains a single site. That site was created automatically during installation and is conventionally called Initial Site, though we could change that if we wanted to. The site contains a single virtual server, and that virtual server contains a single server.

This is typical for a development or demo installation, but you should be able to see how it could be expanded with the defined topology levels to any size deployment, even to a deployment that is global in scope. You could use these different topology levels for a scheme other than the one just described; the only downside would be that nobody else would understand your deployment terms.

Using topology levels

We mentioned previously that many subsystems can be configured at any of the levels. Although it’s most common to do domain-wide configuration, you might, for example, want to enable trace logging on a single CE server for some troubleshooting purpose. When interpreting subsystem configuration data, the CE server first looks for configuration data for the local CE server (that is, itself). If any is found, it is used. Otherwise, the CE server looks for configuration data for the containing virtual server, then the containing site, and then the Domain. Where present, the most specific configuration data is used.

A set of configuration data, if used, is used as the complete configuration. That is, the configuration objects at different topology levels are not blended to create an “effective configuration”.

CE has a feature called request forwarding. Because the conversation between the CE server and the database holding an Object Store is chattier than the conversation between CE clients and the CE server, there can be a performance benefit to having requests handled by a CE server that is closer, in networking terms, to that database. When a CE server forwards a request internally to another CE server, it uses a URL configured on a virtual server. The site object holds the configuration options for whether CE servers can forward requests and whether they can accept forwarded requests.

Sites are the containers for content cache areas, text index areas, Rendition Engine connections, storage areas, and Object Stores. That is, each of those things is associated with a specific site.