Groups > Group Manager Utility > Creating a Group Hierarchy

Creating a Group Hierarchy

The following procedure explains a basic workflow for creating a group hierarchy. Creating a group hierarchy in the Group Manager utility depends in large part upon your specific needs. Be sure to have a clear idea of what purposes your group hierarchy will serve before you start to create it.

Note: If an option on the Group Manager utility menu bar is dimmed, that option is not applicable to the selected hierarchical level. When you are at the appropriate hierarchical level for an action, dimmed menu options become available.

For more information, see the following subsections below:

1. Before You Begin

The creation of a group hierarchy requires some preliminary steps. Make sure that you have taken the following steps:

If you have taken the steps above, proceed to 2. Select a Group Service.

2. Select a Group Service

To select the group service to which your group hierarchy will apply, go to the CygNet\Utilities directory and open the Group Manager utility (GrpMgr.exe), then do one of the following:

If you are done adding a group service, proceed to 3. Create a Component Hierarchy Root.

3. Create a Component Hierarchy Root

A component hierarchy root is the parent node for all group hierarchies and components. Once a component hierarchy root is created, define its hierarchies and components.

To Create a Component Hierarchy Root

  1. Using the Group Manager utility, select your chosen Group Service (for instance, MYSITE.GRP), right-click it, and select Add Root.
  2. Enter a descriptive name for the component hierarchy root and click OK.
  3. Continue adding hierarchy roots to suit your needs.

Add Component Hierarchy Root

If you are done adding all of the component hierarchy roots you need, proceed to 4. Create a Navigation Hierarchy Root.

Back to top

4. Create a Navigation Hierarchy Root

A navigation hierarchy root can contain multiple navigation hierarchies. Navigation hierarchies determine the hierarchical relationship between child nodes, which are views, levels, and components. A navigation hierarchy does not have to use every defined rule or component available, which lets you change the sort order of rules and components without changing the actual navigation hierarchy.

Once created, you cannot move navigation hierarchies, views, levels, or components up or down the hierarchical tree in the Group Manager. If hierarchies, views, levels, or components are in an incorrect order, you must delete them in the Group Manager and then re-add them in the correct order. You can, however, rename hierarchies, views, levels, and components.

To create a navigation hierarchy, first create a navigation root, then add rule-based, component-based, or Web navigation views, and finally create levels that are made up of rules or are linked to components.

To Create a Navigation Hierarchy Root

Note: Depending on your specific needs, you might or might not need to set up a GRP Web navigation hierarchy. If you want your Web application to only display CygNet Vision or CygNet Studio files, you do not need to set up a GRP Web navigation hierarchy. If you want your Web application to interact with the GRP in any other way, you must set up a Web navigation hierarchy. For more information, see Web.

  1. Using the Group Manager utility, right-click the Hierarchies node and click Add Hierarchy. The following dialog box opens:

Add Navigation Hierarchy

  1. Type a useful Description for the hierarchy.
  2. If you want to create a Web hierarchy, check the Create Web Hierarchy box. The CygNet Web administrator then associates the Web application with the Web root.
  3. If you want to create a navigation root for each view, in addition to a single navigation root for all child views, check Create Additional Root for Each View to designate each view as a navigational starting point. This is useful when creating custom views for different users or for Web applications.
  4. Click OK.
  5. Continue adding navigation hierarchy roots to suit your needs.

If you are done adding all of the navigation hierarchy roots you need, proceed to 5. Add a Navigation View.

Back to top

5. Add a Navigation View

Now that you have a navigation hierarchy root, add a view to your navigation hierarchy. Each actual hierarchy is called a view because it is one perspective or view possible from a collection of defined facility or device attributes. You can have different views within the same hierarchy.

A rule-based view begins with a Summary level but has no Facilities level. A component-based view begins with a Summary level and ends with a Facilities level. Each other level in a view is made up of one or more rules or components, depending on the kind of view you choose.

Note: Although both rule-based views and component-based views are supported by CygNet, best practice recommends using rule-based views instead of component-based views. Rules provide a more comprehensive and fine-tuned way to create views.

To Add a Non-Web Navigation View

Note: Ignore the Summary and/or Facilities levels that result from creating a non-Web navigation hierarchy view. They are predefined nodes used by the system.

  1. Using the Group Manager utility, right-click any node that is identified in the Category column as Hierarchy and click Add View. Exactly which hierarchy node you choose depends on where you want to place the new view. The following dialog box opens:

Navigation View Definition

  1. Type a useful Description for the view.
  2. Ignore the Facility Type List drop-down menu and Browse button. These are only for use with a Web navigation view.
  3. Select either Component-Based View or Rule-Based View. You can include both component-based views and rule-based views within a single navigation hierarchy, although it might not make sense to use both together. Best practice recommends using rule-based views only. For more information, see Nodes in a Tree View.
  4. If you want to have an All… category for the last level of a component view, check Create (All…) entry on last level. This enables viewing of all last-level facility or device attributes in a component view. For instance, your view might have a Texas level and an Arizona level, each with its own facility attributes (meter IDs, for example). The All… option would allow you to view all facility attributes (meter IDs, for example) for both Texas and Arizona at the same time instead of having to toggle between the two state levels.
  5. Click OK.
  6. Continue adding non-Web navigation views to suit your needs.

To Add a Web Navigation View

Note: Depending on your specific needs, you might or might not need to set up a GRP Web navigation hierarchy. If you want your Web application to only display CygNet Vision or CygNet Studio files, you do not need to set up a GRP Web navigation hierarchy. If you want your Web application to interact with the GRP in any other way, you must set up a Web navigation hierarchy. For more information, see Web.

  1. Using the Group Manager utility, right-click any node that is identified in the Category column as Hierarchy and click Add View. Exactly which hierarchy node you choose depends on where you want to place the new view. The following dialog box opens:

Navigation View Definition

  1. Type a useful Description for the view.
  2. Click the Facility Type List down arrow and select a Facility Type List. The Facility Type List is specific to the Web Overview and Report pages and defines the uniform data codes (UDCs) that are applicable to a given facility type. Each navigation view can have its own type list. If the drop-down menu is empty because no Facility Type List is defined, click the Facility Type List Browse button and follow these sub-steps to define a Facility Type List:
    1. Click Add next to Facility Type Lists to show the Add Facility Type List dialog box.
    2. Type a useful Description and click OK.
    3. Beside the Facility Types field, click Add.
    4. In the Facility Type Definition dialog box, type a Facility Type. Enter the table entry in all UPPERCASE letters. This must be a valid facility type in your system. The types are stored in the SYSFCTYP table in the Table Reference Service (TRS). You can also see a list of types by displaying the properties for a facility and clicking the Type browse button. An example of a common facility type is REMDEV.
    5. In the Facility Type Definition dialog box, type a list of UDCs for the facility. They must be all UPPERCASE and comma delimited. For example, CFGARGN, CFGCH4, CFGCO, CFGCO2.
    6. When you are done, click OK.
  3. Select either Component-Based View or Rule-Based View. You can include both component-based views and rule-based views within a single navigation hierarchy, although it might not make sense to use both together. Best practice recommends using rule-based views only. For more information, see Nodes in a Tree View.
  4. If you want to have an All… category for the last level of a component view, check Create (All…) entry on last level. This enables viewing of all last-level facility or device attributes in a component view. For instance, your view might have a Texas level and an Arizona level, each with its own facility attributes (meter IDs, for example). The All… option would allow you to view all facility attributes (meter IDs, for example) for both Texas and Arizona at the same time instead of having to toggle between the two state levels.
  5. Click OK.
  6. Continue adding Web navigation views to suit your needs.

If you are done adding all of the navigation views you need, proceed to 6. Add a Level.

Back to top

6. Add a Level

Now that you have a navigation view, add a level. You can have many different levels within the same view. If the view is rule based, its levels must be rules. If the view is component based, its levels must be components.

Important: If you are adding levels to a Web-based navigation hierarchy, be sure to see To Define a Summary and/or Facilities Level for a Web-Based Navigation Hierarchy.

To Add a Level to a Rule-Based View

  1. Using the Group Manager utility, right-click a rule-based View and click Add Level.
  2. At the Hierarchy Level dialog box, define the level's rule(s). For more information, see Defining Rules.
  3. When you are done defining your level, click OK.
  4. Continue adding rule-based levels to suit your needs.

To Add a Level to a Component-Based View

  1. Using the Group Manager utility, right-click a component-based View and click Add Level.
  2. At the Select Components for This Level dialog box, define, edit, and add component(s) to the level. The component(s) you define here appear under the Components node in addition to being a child of this view. For more information, see Defining Components.
  3. When you are done defining your level, click OK.
  4. Continue adding component-based levels to suit your needs.

To Define a Summary and/or Facilities Level for a Web-Based Navigation Hierarchy

Note: The following procedure only applies to Summary and/or Facilities levels within a Web-based view.

  1. Right-click the Summary or Facilities level you want to define and click Properties. The following dialog box opens:

Hierarchy Level Definition

  1. If you want to change the Default Description (Summary or Facilities), check Override Desc and type a new description in the Override Desc text box.
  2. At the Default UDCs field, click the Browse button and select default UDCs. Default UDCs are specific to the Summary or Facilities Web pages. These UDCs are displayed for each level. Select as many as you require.
  3. At the Default Page IDs field, click the Browse button to select additional default page IDs. Page IDs identify the pages that are displayed when a user is at a particular level in a hierarchy. If you want to (re)set to the default page IDs, click Set To Default. The CygNet Web administrator can also add and change page IDs in the CygAdmin.asp page.
  4. When you are finished, click OK.

If you have completed your entire group hierarchy, including all roots, hierarchies, views, levels, and components, proceed to 7. Build Your Hierarchies. The resulting hierarchy might have many different navigation hierarchies with many different views and many facility and device attributes defined by various rules and components.

Back to top

7. Build Your Hierarchies

When you are done constructing your entire component hierarchy (that is, all navigation hierarchies, views, levels, rules, and/or components), you must build the hierarchy. After your initial build, you must also rebuild your hierarchy any time you modify it in any way. The build process collects relevant facilities and organizes them according to the navigation hierarchy structure(s) you defined and it (re)loads all of your hierarchies into the GRP for use in your CygNet system.

In effect, steps 1 - 6 above create a draft of your hierarchy (or hierarchies) and step 7 implements your new hierarchy (or hierarchies). Once you've built, you can view various group nodes and their properties in the GRP, although editing nodes in the GRP service is discouraged.

You might need to rebuild your hierarchies occasionally. Rebuilding hierarchies is necessary in the following situations:

When you rebuild a hierarchy, the rebuild deletes existing hierarchy components and rules and then rebuilds them. The normal hierarchy building (or rebuilding) process will check for and correct any recursive parent/child relationships detected. Additionally, if any improper node relationships are detected, they will be fixed.

There are several build options. For more information, see the Build entries in User Interface. If you click Cancel, you must initiate a rebuild of the hierarchy again for the rebuild to take effect.

To Build Your Hierarchy

Note: The Build All for Group Service option can be run from a command line. The other build options cannot be run from a command line.

Scheduling Hierarchy Builds

Syntax

C:\CygNet\Utilities\GrpMgr.exe -r SITE.SERVICE

Example

In the example below, SITE01 is the site name and GRP is the name of the Group Service. This command-line parameter allows the group manager build option to be scheduled using the Microsoft Windows scheduler.

C:\CygNet\Utilities\GrpMgr.exe -r SITE01.GRP

You can also schedule hierarchy rebuilds using a third-party scheduler such as Microsoft Windows Scheduled Tasks. This rebuilds all hierarchies in the specified group service.

Syntax

GrpMgr.exe -r SITE.SERVICE

Example

GrpMgr.exe -r MYSITE.GRP

Back to top

Let us know how we can improve this topic.

CygNet at weatherford.com

© 2020 Weatherford. All rights reserved.