What is the 'HierarchySingularTask' table how is it used within a Hierarchy?
search cancel

What is the 'HierarchySingularTask' table how is it used within a Hierarchy?

book

Article ID: 180292

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

Information about the 'HierarchySingularTask' table and how it is used within a Hierarchy is explained in this article.

Environment

ITMS 8.x

Resolution

There is a database table called HierarchySingularTask that tracks any tasks that must be performed once on each immediate node within a hierarchy. These tasks include: when hierarchy managed items are deleted or the security on an item or folder is modified. Additionally if the core setting ‘TrackRoleDeletionForHierarchy’ is enabled, it will also track any security role deletion.

When a replication occurs a separate rule is sent containing all the singular tasks to be performed at the destination. When the source NS receives a status code of 0, indicating that the replication process has completed successfully, it will delete the contents of the HierarchySingularTask table. If the replication fails, it will not clear the contents of this table.
 
If an item has never been replicated to the child NS before then the individual permissions applied to items are replicated along with the item. However when carrying out a differential replication and calculating the hash to determine whether an item has changed between source and destination, the security portion of the items XML is excluded from the hash calculation.
 
Security permission modifications to an item are tracked separately via the HierarchySingularTask table because they are likely to change more often than the item itself, and this prevents the item itself (which may be quite large) replicating unnecessarily just because the permissions on it have been modified.
 
When security permissions are changed for a replicated item, an entry is made into the HierarchySingularTask table for this item, and at the next differential replication only the security permissions portion of the items XML is sent to the child NS, preventing unnecessary transfer of data between servers.
 
Items and the below mentioned resources are only tracked for deletion if they have been previously replicated (at least once) to the destination server.  
 
When an item is deleted on the parent NS, it will first check whether the item exists in the db table ‘HierarchyPublished’ as this table only lists items which have been replicated.
 
In NS versions 7.0 Sp5 and earlier, only configuration and management items were being tracked when deleted, not resources or Security objects. In NS 7.1 and later this has been extended to track deletions for selected resources types. An element was added to the XML of resource type definitions called ‘TrackHierarchyDelete’. This element is now set to ‘True’ for the following Resource Types in NS 7.1 and later:
 
1. ‘Package’ - Base Resource Type for Packages, owned by NS Core
2. ‘Software Package’ - Software Management Solution Packages
3. ‘Software Command Line’ - Software Management Solution Command lines, associated with above Software Package