The PTOBJECTCOUNTERS Table: A Lifesaver in ALUI

Throughout the life cycle of an AquaLogic User Interaction portal installation, a variety of unexpected and unwelcomed events can occur. One of the most frustrating types of these issues can occur through the deletion of an administrative object that has some unforeseen dependencies. Unfortunately, when an admin object in ALUI is removed there is no way to re-create it in the portal and have it maintain its original object id.

An example of a deleted admin object causing other issues in the portal occurred at my client site last Fall. An administrator had deleted an old Publisher portlet that was in the process of being replaced by another portlet. A few days after this portlet was deleted, users started noticing that certain links in other Publisher portlets would result in a gateway error. After some detailed troubleshooting it was determined that multiple Publisher links throughout the portal were gatewayed through the removed portlet. Since that portlet with the referenced ID did not exist, the link was failing and the gateway error was being returned. In short, we needed to restore the deleted portlet to allow the gatewayed links to function properly.

An attempt was made to export and import the object through a PTE file from the test environment portal. This method did not work as the old portlet was imported but with a different object ID. The only "supported" way of restoring the old object with the proper ID is to restore the entire portal database. This is really not an option for certain portals that feature a highly active user base where content is changing hour-by-hour. A full restore of a database from two days earlier could result in several unwanted repercussions, including:

• Lost content that would have to be re-crawled or re-imported


• All portlet and community preferences that had been changed in the past two days would be lost


• Non-synched portal users created in the last 48 hours would need to be re-created.


• A whole slew of other issues that makes this option one to avoid if at all possible

In this emergency situation I decided to utilize the rarely used PTOBJECTCOUNTERStable in the portal database. This table simply functions as a counter mechanism for objects of different classes. When a new administrative object is added to the portal, the NEXTOBJECTID field of the PTOBJECTCOUNTERS table is referenced to determine the next object ID to use for the specified object class. This table is in place to prevent object ID conflict issues throughout the portal.

To fix the Publisher issue in my client's portal, I used SQL Enterprise Manager to change the NEXTOBJECTID value of the record associated with CLASSID of 43 (the class ID for portlets in the portal) from the existing value (which I copied to re-use after the fix) to the ID number of the removed portlet. I could determine the ID of the deleted portlet object by looking at the gateway URL referenced in the Publisher links that were not functioning properly. Once the ID number was changed, I re-imported the PTE file from the test environment. The portlet object was created with the proper ID and immediately all broken Publisher links in the portal were working without issue. I then changed the NEXTOBJECTID value back to the original value to ensure that all new portlets would be assigned a unique object ID.

This is just an example of a way the PTOBJECTCOUNTERS table can allow an administrator to correct object ID issues in the portal. PTOBJECTCOUNTERS is a simple table in design but an integral table in the makeup of the ALUI portal platform and can be a lifesaver at times.