[Index]

Model: data/HierarchyNode

Data Partitioning

Data in the multi-tenant system is "partitioned" by a means of fully configurable hierarchy nodes. In the example below, the system hosts two managed service providers "Varidion" and "VS-OPS". "VS-OPS" hosts two customers: "VS-Corp" and "GenCorp". "VS-CORP" in turn operates from locations Boston, Brooklyn, Chicago and New York.

The system has the ability to model the hierarchical nature of various businesses and manage the allocation of infrastructure (such as network devices - refer to the topic on Network Device Allocation and Bundling.), users and other entities in the system by creating hierarchy nodes, hierarchy node types (for example: provider, reseller, customer, shared building, site, division, branch, and so on) and hierarchy rules (for example: a site can only be created under a customer) that can be applied to various models in the system.

Devolved administration is enabled by creating administrators with different roles for different types of hierarchy nodes. For example:

• An administrator is responsible for the setup of the overall system.
• Provider administrators own and manage infrastructure and define services available to resellers.
• Resellers offer the infrastructure and services to customers or enterprises.
• Customers and enterprises are grouped into various groupings.
• Groupings such as divisions or branches belong to customers.
• Physical locations hold users and phones.
• End users consume services and manage their own configurable settings.

The flexible mechanism is used to define as many levels as needed. Hierarchy node instances of different types can be created and the required business rules can be defined.

Parent-Child Relationships

All entities in the system reside at a specific hierarchy and the data displayed is within the scope of the specified hierarchy. This means that every entity in the system - including users, device models and network components - has a parent hierarchy defined. A user is for example provisioned with a specific hierarchy node in a parent-child relationship. User names must be unique within a specific hierarchy.

Data Access

Data security in the system is achieved by data partitioning and user roles.

With data partitioning, the system ensures that administrative users who access the system can only view and perform operations on instances of entities that are provisioned at their parent hierarchy, in other words at the same hierarchy level as they are, or at sub-trees of that hierarchy. The system restricts access to resources based on user's parent hierarchy and this restriction is enforced in API middleware for every operation that is requested. This partitioning is enforced across the various system interfaces, for example loaders, API, and the GUI.

This for example ensures that an administrator for "VS-Corp" cannot view or affect data in customer "GenCorp" within the system. The "VS-Corp" administrator can only see and affect entities assigned to "VS-Corp" or lower, for example Boston, Brooklyn, Chicago and New York in the above diagram.

A user's role defines, via an access profile, the fine-grained permissions to the specific entities that the user can see and how the user can interact with these. The permissions include details of each entity type in the system, as well as the relevant privileges related to that entity type. For further details on user roles and access profiles, refer to the topic on Role Based Access.

From data partitioning, the hierarchy will determine the specific instances of the various entities that the user can interact with; while the role and access profile assigned to the user determines the permitted operations that can be performed on these instances.

Navigating the Hierarchy

Navigate through the hierarchy by using the hierarchy bar at the top of the page. Each hierarchy node selection from a drop-down list on the bar that is a parent node may further enable a drop-down list to select its child node. The hierarchy bar is not refreshed automatically when for example Customers or Sites are deleted by another administrator user on another browser. The bar is refreshed when refreshing the browser.

Use the tree view icon on the hierarchy bar at the top of the page to show a tree view of the entire hierarchy. Choose a hierarchy node on the tree to navigate to that node.

The hierarchy level to which an object belongs is indicated in a list view of the objects in the Hierarchy column. The hierarchy is indicated in a dot notation, for example sys.ucs.VS-P1.VS-OB.GenCorp.GenCorp-EMEA.GenCorp-London.

Manage the Hierarchy Structure

The system is typically configured with a pre-defined structure of supported business entities like Providers with Customers who in turn manage one or more Sites. Supported business structures are configured by managing individual hierarchy nodes, hierarchy node types and business rules that define the hierarchy structure in accordance with hierarchical business structures.

A hierarchy node can be created to be any of the hierarchy node types defined in the system.

Business rules that define the structure of the business, for example that a site has to be created under a customer, or in the case of a shared building, that a customer is created under a site, are defined using rules for managing the hierarchy structures:

• Hierarchy Node Rules: Rules for the operations that can be performed on hierarchy node types under specific hierarchy node types. For example, only a Site hierarchy node type can be added under a Customer hierarchy node type.
• Hierarchy Model Rules: Rules for the operations that can be performed for each type of entity (model type) under specific hierarchy node types For example, a Site node can only be added under a Customer hierarchy node type.
• User Role Rules: Rules for hierarchy node type under which a user with a given role can be created. For example, a site administrator can only be created under a Site hierarchy node type.

Business entities such as Customers are modeled by system designers by linking hierarchy nodes to the core system components. Such business entities are made available in Feature Packages.

Depending on the feature packages that are installed on the core system, different types of administrators will typically devolve management of the business entities modeled in the system. For example, global administrators can manage service provider administrators on a system that is hosted for multiple service providers, or directly manage customers or enterprise administrators. Service provider administrators may for example be able to manage reseller and customer administrators. Customer administrators in turn may manage sites where users and phones are located, or further devolve this to site administrators.

The hierarchy node types, hierarchy node rules, hierarchy model rules and user rule rules depend on the feature packages installed. Refer to the topic on Feature Packages.

Also refer to the topics on Hierarchy Node Type, Hierarchy Node Rules and Hierarchy Model Rules.

Add a Hierarchy Node

The hierarchy can also be navigated by using the navigation button and selecting a node on the hierarchy tree. The default root value is shown on the hierarchy bar.

1. To create a new hierarchy node, choose General Administration > Hierarchy Node to open the Hierarchy Node list view.
2. To create an upper level hierarchy node, click Add on the button bar to open the Hierarchy Node input form.
3. Enter a Name and Description for the node.
4. From the drop-down list, choose the required Hierarchy Node Type to which to add the node. Note that if left blank, the hierarchy node will be added at the system level.
5. Click Save when complete to add the node.
6. To create a node in the hierarchy under this top level node, refresh the browser page, check the check box adjacent to the required node, and add a node under this hierarchy.
7. Add elements under hierarchy nodes as required. The system can now be used from the context of a hierarchy element.
8. Manage (add, delete, or modify) the hierarchy from the General Administration > Hierarchy Node menu option.

HierarchyNode instances allow the hierarchical organization of data and devices in VOSS.

Model Details: data/HierarchyNode