The ${NMS_BASE}/dist/baseconfig/product/ops folder contains sub-folders with each tool’s configuration information. Tool folders typically contain the following sub-folders:

 

This section includes the following topics:

The USER_PERMISSIONS table stores currently licensed products and grants permissions to system features and functionality based on user types.

Licensed products are listed with an action value of LICENSED.

The USER_PERMISSIONS table can also define what modes a user type has access to. In this case, any of the following actions can be defined for a user type:

For Product configured Web Workspace:

 

The Switching Entry users cannot create study sessions and will be in a sense always stuck in Real Time. If the user type is given access to a viewer and control tool, projects should consider using the USE_SHARED_STUDY_SESSION option instead.

These options are in place to minimize the demand on the services to keep track of individual study sessions used by users. The more study sessions that are active, the higher the burden on the services. Keeping the study sessions to a minimum is highly recommended and these rules should be used to do that.

Web Workspace defines access rights to elements within a switching sheet based on user type. This allows certain parts of the application or switching sheet to be edited by one user type and not by other user types. For user type permissions within Web Workspace, the user_name should indicate the user type and the action should be the actions that user type has permissions over within the sheet.

This would give the Full Operations plus Web Switching user type permissions over every aspect of a switching sheet. Use the ALL action to define this.

 

This gives the Switching Prep user type permission to use Web Switching as well as execute permissions for steps, but only when the steps are in an Isolate block. The format of the action string is: <Step Block Name>_<Step Action Name>.

There are two approaches to configuring user environments by user types. The first method creates project configuration directories for each specific user type/role/privilege; the second sets rules within configuration files to enable different tools or views based on the user type/role/privilege. The first method works best if there are significant differences between the two versions; the second method is useful with small changes to the existing configuration.

In either method, user types must be defined in the ENV_CODE table.

 

 

Creating a view-only subdirectory and changing the viewer background color for them.

As in the other method, each application or tool that requires different access or a separate view for a user type will need to be configured for that user type.

The Login Tool is responsible for determining which user type the user should log in as and verifying the password (if LDAP integration is turned off).

To configure an application (for example, Web Workspace or Configuration Assistant) to use the Login Tool, the product_name global property should be set in the tools configuration to the value as it exists in product column of the ENV_CODE table.

The following example demonstrates configuring Web Call Entry (WCE) to use the login tool:

The Login Tool has a configuration option that handles user sessions when a user logs into the system from a different client.

When set to false, if a user is currently logged into the application (or has abnormally exited within two minutes), the user will receive an error message saying the user is already logged in. The user can be released using the Configuration Assistant to reset the login.

When set to true, if another log in occurs for the same application and user, the original session will be automatically logged off. The system will not allow the user to save their work. The system will return a dialog box informing that the existing user was logged off, and that they should retry the log in. Clicking the Login button again will then log the user into the system and the new user (session) will begin.

If a user does not interact with a client after a certain amount of time, the user can be logged off automatically. This is controlled by these settings in CentricityTool.properties:

 

The main client application window for Web Workspace can be configured by using a separate XML file. For example:

 

The file should be saved as the name of the application, with docking. For example, the name of the file for Web Workspace would be Workspace_docking.xml.

The easiest way to modify this file is to arrange the windows the way you wish, then exit the system. Bring up Windows Explorer, and locate c:\Documents and Settings\[user] \.nms\system11.0.0.0.0\o.ide.11.1.1.1.33.53.67\windowinglayout.xml

From that file, cut and paste the dockingPositions element to the configuration file. Note that the <dockingPositions> element should include the attributes listed above, although they are not in the windowingLayout.xml.

The "bounds" dockingPositions attribute specifies the position and size of the master frame. The numbers are the x, y, width, and height of the master frame.

The "maximized" attribute specifies if the frame should start maximized.

The default docking for applications that do not have a specific docking configuration is defined by jconfig/global/xml/JbotTool_docking.xml.

Configure a $NMS_HOME/[project]/jconfig/license.properties file. Follow the instructions in the file to configure which projects to display on the login web page, as well as their titles.

The Table Export feature allows you to set up an action to export table data to a CSV file. The table export behavior is defined in the TableBehavior element; if not defined, the export behavior will be inherited from the system default settings found in the CentricityTool.properties file.

Besides the functionality listed in the previous Table Export Configuration, Tables can also be configured to use a panel with different copy options. This is helpful when different copy options are needed. To add this panel to a table, add the following include under the table:

Work Agenda configuration files are found in ${NMS_BASE}/dist/baseconfig/product/ops/workagenda/.

The WORKAGENDA_GLOBAL_PROPERTIES.inc file contains the following tool properties:

work_agenda.status_icon.##REPLACE.STATUS_<status>: Icon to display for the configured status. This can be configured for every status that needs an icon. Leave the value blank if no icon is desired.

Example:

work_agenda.default_ert_offset: - If configured, the number of ms to use as the default ERT, as calculated from the current time

work_agenda.maximum_views: The maximum number of Work Agendas

work_agenda.reading_pane_population_delay: Delay in milliseconds between row selection in the Work Agenda treetable and start of the population of the Reading Pane panel for the selected row. Default: 1000 ms -->

work_agenda.requested_completed_outage_visible_time: The complete retain period requested from the server, for display of completed rows, in number of days

work_agenda.always_show_fuzzy_outages: Whether to display outages in the fuzzy zone, even if the user is not subscribed to the Fuzzy zone. Default: false

work_agenda.keep_restored_cmi: Whether to continue calculating the CMI for restored events. Default: false

work_agenda.show_completed_outages: Whether the tool should automatically load completed events. Default: false.

work_agenda.use_active_outage_as_lead: By default, a "No" answer in the WORKAGENDA.INCLUDE_SUB_EVENTS dialog will execute the action on the lead event, even if it's a non-outage. Set this to true to perform the action on the lead active outage event, when the lead event is a non-outage or is inactive. This also affects actions that don't display the dialog, like crew assignments.

work_agenda.completed_testates: States that should be considered as completed

work_agenda.grouping_dialog_columns: List of DS_WA_ALARMS columns to be copied when event is added to the DS_EVENTS_TO_GROUP datastore. These columns will be available for display in the DLG_EVENT_GROUP (Group Events) dialog.

work_agenda.in_progress_testates: States to be considered as in progress

work_agenda.incomplete_testates: States to be considered as incomplete

work_agenda.summaryrow_feederclass: Device class named to be considered feeder heads, for the summary table

work_agenda.summaryrow_recloserclass: Device class named to be considered reclosers, for the summary table

work_agenda.summaryrow_fuseclass: Device class named to be considered fuses, for the summary table

work_agenda.to_do_testates: States to be considered as to do

Scenario: You want to change a column heading from Feeder to Circuit.

Column headings are defined in ${NMS_BASE}/dist/baseconfig/product/ops/workagenda/properties/WorkAgenda_en_US.properties in the alarms panel section. You find the line:

Scenario: You want to add a column to the Work Agenda.

If you wish to add a project specific column, do the following:

For further information, see JMService Configuration.

The next step is to configure it to show up in Work Agenda:

All of the alarms in the Web Workspace Tools menu's Alarms and Devices Lists submenu are versions of the DDSAlarms tool that have different filters. The configuration files are found in ${NMS_BASE}/dist/baseconfig/product/ops/workagenda/.

If a project wants to separate them differently, or create two instances of a list, you need to create a <StatusChangePerform> filter for the tool matching the rows to display in the table.

The following keys are used by product configuration:

The Crew Actions Tool configuration files are found in ${NMS_BASE}/dist/baseconfig/product/ops/crew/.

Crew Actions provides a mechanism for filtering crews based on control zone level; this filtering is capable of listening to the Work Agenda and filtering crews based on the event zone. The functionality is found in a Filter sub-menu description in CREW_ICONS_MENUBAR.inc:

Related files and settings:

Scenario: Your project does not require filtering by event zone.

Event Details configuration files are found in ${NMS_BASE}/dist/baseconfig/product/ops/eventdetails/.

Scenario: You need to add a new drop-down list to the Event Details window. You will create a value called animals that will contain choices of lions, tigers, and bears.

Note that while the Configuration Assistant can add new values to an event details drop-down menu, it cannot create the new list. Therefore, for the first option, you need to add it directly to the database using SQL Developer or an alternative SQL tool of your choice.

Scenario: You want to create a validation rule that requires the user to choose an animal in order to close Event Details.

The Update Events window is a Work Agenda dialog box that allows users to update Event Details information for multiple jobs at the same time. The Update Events configuration files are found in ${NMS_BASE}/dist/baseconfig/product/ops/workagenda/.

The data that is displayed in Trouble Summary is populated by TSService on a timer controlled by the -period command-line option. Product configuration counts all outage, non-outage, and planned outage jobs. Change your version of the TJ_JOBS view to exclude other job types, if desired. The Trouble Summary offers the following configurable parameters.

Period of time (in seconds) between automatic updates of the Outage Summary information. This only makes the tool reload information from the database. It has no effect on how often TSService recalculates the data.

If set to 0 then periodic updating of Outage Summary is disabled.

Delay in milliseconds between row selection in the Outage Summary tree-table and start of the population of the Damage Summary panel for the selected control zone.

Character string used as a separator between individual control zone names when constructing full zone name. For example, OPAL/Stark/Lake would be the full zone name for the Lake control zone when / used as a separator.

Number of control zone hierarchy levels to be displayed in Outage Summary table.

Value '-1' would cause full control zone tree to be displayed.

Default: 4

 

Viewer configuration consists of defining the various model layers and defining application properties that control the Viewer behavior. The Viewer configuration is read by the application server and, consequently, updates to Viewer configuration require restarting WebLogic to deploy.

Viewer configuration consists of defining the various device layers and defining various properties that control the Viewer behavior. The layer configuration is read by the application server.

The layer definitions are found in ${NMS_BASE}/dist/baseconfig/product/ops/viewer/xml/SPATIALLAYERS_LAYERS.inc.

Scenario: You want to remove all SCADA-controlled fuses from the Underground Fuses layer and add them to a new SCADA Fuses layer for display in the Viewer. (This scenario is based on the characteristics of the OPAL model.)

Conductor priority and highlight coloring is defined by SPATIALLAYERS_CONDUCTOR_PRIORITY.inc:

The codes are listed in priority order. Therefore, if a conductor is both FAULTED (third line) and GROUNDED (fourth line), the conductor will color as FAULTED.

The highlight_color is an optional definition of the highlight that will appear around the conductor with the indicated status. The highlight color will display for the first matching status with a highlight color, regardless of the main conductor color being used. If no status with a highlight_color matches, no highlighting will occur. All RGB colors are supported.

 

 

If you wish to set big symbols for digital measurement symbols, add the following Symbol definition to SPATIAL_LAYERS_BIG_SYMBOLS.xml:

If you wish to only set big symbols for some measurement keys or if you wish to use different scales for different symbols, define each symbol using the following syntax:

where # is the measurement key from the SCADA system. For example:

The Viewer's GUI configuration is defined in ${NMS_BASE}/dist/baseconfig/product/ops/viewer/xml/VIEWER_GLOBAL_PROPERTIES.inc.

Scenario: You want to change the background color of the Viewer drawing area.

The color and thickness of the study mode border for light/dark themes can be modified by changing these properties of the ColorScheme.properties file:

Note that the hex values above include an alpha value so it is semi-transparent and the border does not obscure the items underneath it.

Scenario: You want to change the background color of the Viewer drawing area.

to

 

 

 

The Hide/Display dialog can be configured to have the Viewer show (or not show) conditions based upon attributes or condition status.

 

The key is to configure the data_source, which should match the previous step. The RefreshCommand will refresh the viewer with the new settings.

Add the search entry datastore. The name of the datastore must be in the format of DS_VIEWER_XX_SEARCH_DATA.

In VIEWER_SEARCH_DATASTORES.inc, add the line:

Next add the text field(s) for the user to enter the search criteria to DLG_VIEWER_SEARCH (modify a copy of an existing search):

Then add this to the SEARCH_ACTION section:

The config options are:

More information about the ViewerSearchCommand is available in the online JBot Command Reference; see page 17-15 for information on the online documentation.

Next, determine if you can use an existing _SEARCH_RESULT dialog or you need a new one. You can use an existing dialog if you the result set is compatible with an existing dialog. For example, if you have a special query that returns certain devices, you can use DLG_VIEWER_DEVICE_SEARCH_RESULT. However, if you wish to display different columns in the result, you will need to create a custom result dialog. In that case, copy and modify a dialog that is close to what you require.

Ensure that the dialog you require is configured in the ViewerSearchCommand under the "dialog" parameter.

The above matching syntax ($(my_name: DS_VIEWER_MY_SEARCH_DATA.MY_NAME) will translate into a like, equals, soundex, or upper() version of the columns as needed. However, if there is a need to not follow the sort options, but search for something directly, just use the datastore name as a replacement value without the colon:

When the mouse is hovered over a condition symbol (that is, a tag, note, document, call, clue, or damage assessment), it will display information about the condition. This can be modified by using a custom Java class that extends com.splwg.oms.client.viewer.Tooltip. See the example, demo.CustomTooltip, as part of the OPAL project. Variables are specified by enclosing them within ${}. They can either refer to text that is included in Viewer_en_US.properties, or else the datastore associated with the condition. To see all the available columns in the datastore run a datastore report (Creating the JBot DataStore Report).

If you desire additional Trace To <device> options, add them to the DLG_VIEWER_TRACE.xml in the following way:

For example, we will use the new keyword EXAMPLE and a device class called example_device_cls.

There are a few limits that work together:

This will be the largest number of maps that the client will try to request from the server.

This is the largest number of devices that can be returned by the server. The server keeps a tally of the number of objects as it puts together the map list, and if it is exceeded, it returns an error. This means that there is some extra load put on the server to load the maps (especially if the maps have not been loaded before), but, because it fails before trying to send the results back to the client, it is still rather quick.

Finally, there is the WebLogic maxmessagesize, which is the maximum size of an object that can be transferred. This results in a failure after returning 50 MG to the client (or whatever the max is set to by the project).

The point of these settings is to keep the user from choosing too many maps, and minimizing the impact if too many are chosen. If the first limit is hit, there is no load on the server. If the second is hit, there is some load, but the server gives up before things get unreasonable. You do want to avoid routinely hitting the maxmessagesize; you will receive a more generic error message, and the server goes through all the work to return the maps, only to fail when the return size is too large.

You can determine how large the maps are by various debug settings.

Enabling the warn_if_over_bytes setting in CentricityTool.properties will log the size of large messages requests. You can see if the return values are close to the 50 MB default maxmessagesize.

Another helpful setting is the VIEWER_TIMING client debug, which Bug 26307332 added printing the number of object and vertices downloaded. This can be enabled through the help menu.

One thing to note: You really do need to experiment with those limits to determine the appropriate settings for max maps.

If a project has maps with less objects and vertices per map, then the limits can be safely raised. If the maps are large and many vertices, then the product values might be too high. So you cannot assume that the product values are safe (and raising them is risk) so you need to find a limit that works for the project.

Tooltips are rendered using html of various datastore values. The configuration can be modified by overriding Tooltip.java. To use a project specific configuration modify this line in the viewer configuration:

There is an example in the opal configuration, which is a copy of the product configuration in OPAL/jconfig/java/src/demo/CustomTootip.java.

So to use that version, copy CustomTooltip.java to your project and modify the viewer configuration to:

See CustomTooltip.java for details.

The data to display, most labels, and date ranges, etc, are configurable using standard JBot commands. However, if a project wants to customize the graph further, it can be done by overriding the Oracle JET components by saving project specific versions to $NMS_CONFIG/jconfig/public_html.

The files that generally could be overridden are:

 

The JBot Commands that populate this are PopulateGraphCommand and PopulateOutageGraphCommand.

Feeder Load Management Global Properties may be modified as follows:

Scenario: Configure Feeder Load Management to refresh every 90 seconds.

The Model Management application provides a user interface for viewing status of model build related events (full builds, patches, and pending maps) and initiating a model build scripts. The tool may be configured to run the model build scripts in the background or to run them synchronously and display the result in a dialog.

Scenario: You want to configure the Model Management application to rerun model build patches in the background.

 

 

 

 

The result of summary queries are stored in DS_SUMMARY data store and the column names are output of the queries executed. All columns are stored as string values. You can either use them as it is or provide your own definition like #DER_ON as below definition.

All SQL queries that are being used by DMS Summary tool are defined in this file. You need to make sure these queries are executable without errors. The queries are having placeholders that are replaced by required data by the tool at run time as described below. Alternatively, you can replace the placeholders with the required data.

This is replaced by the control zones for which the user is subscribed to.

This is replaced by the devices (feeders) selected in the left pane of the DMS Summary tool.

 

 

Application configuration for Right-To-Left languages, such as Arabic, is configured through the CentricityTool.properties and the ImageLocalize.properties files.

Note that symbology file tooltips may be localized by editing the .sym files. See Chapter 8, Building the System Data Model, for details on sym files.

Text direction is defined in ${NMS_BASE}/dist/baseconfig/global/properties/CentricityTool.properties.

The ImageLocalize.properties file is used to override the XML files that define images/icons. The file is located in ${NMS_BASE}/dist/baseconfig/global/properties/. The file has defined image files that will be flipped if RTL is set in CentricityTool.properties. You may also substitute other files by adding a substitution statement.

Scenario: You want to substitute an image for the info_ena.png () file.