Supporting multiple profiles | HCL Digital Experience

When you install HCL Digital Experience, a default configuration profile (wp_profile) is created. You can now create and maintain multiple profiles to create multiple independent portal instances; to create new profiles, and delete the old to recover from configuration problems; to create custom profiles to easily expand your cluster's capacity; or to update a Deployment Manager profile to handle portal servers without manual preparation steps. To support multiple profiles you must first prepare your system, create profiles, run configuration tasks on the profiles, and then maintain the profiles if you install maintenance packages. You might also need to update the configuration archive or delete a profile that is no longer required.

About this task

With the multiple profile feature, you can install HCL Digital Experience once and then create multiple profile instances based on the original installation. You can create additional profiles immediately after installation if you want each profile instance to use the unmodified version of the HCL Portal configuration. If you want to create a customized environment that you want to use as the basis for the additional profiles, you can create the additional profiles after you install and configure HCL Portal.
There are several considerations for having multiple Portal profiles based on one (1) set of Portal binaries:
Note: The term "Portal binaries" refers to the files under the directory PortalServer as opposed to the files in wp_profile/PortalServer.
  1. When installing updates to any of the Portal profiles sharing the same binaries, all Portals sharing those binaries have to be stopped. The applyCF.sh process must be run and completed on all profiles before those profiles are usable. In some cases, administrators may not want to simultaneously update all profiles to the same level but it is a requirement for all profiles (in the multiple profile context) to be at the same DX level.

    However, multiple profiles can also be a "pro" in this context since the IBM Installation Manager (IIM) installation of the fix package (CF) need only be done once. While the IIM portion of the process need only be done once, the applyCF.sh function will still need to be done for each profile.

  2. When maintaining multiple profiles, Portal administrators must take great care when dealing with both the file system and database for each profile to insure that the correct profile instance is being used.
  3. When a WebSphere or Portal administrator is using the WebSphere Deployment Manager to change or update a profile, care must be exercised that the correct profile is being accessed on the deployment manager.
  4. When administering Portal resources via the WebSphere deployment manager, care must be taken to insure the proper resource is being referenced. For example, with multiple profile support, there may be multiple Portal clusters in the same WebSphere deployment manager. Resources like dynacaches are scoped to each cluster. So, there would be multiple instances of each dynacache scoped to the appropriate cluster. Care must be taken to ensure that the correct dynacache is being addressed.

Before you create new profiles, you must delete any existing search collections.

Tip: Release data cannot be shared between multiple profiles. Each profile must have its own database for release.