Object model: the basics

Author: Anna Dowling

The following outline will give the reader a summary of the main domain objects associated with the NOC Portal application.

• company_config - The Noc Portal is configured using the company_config domain. This assigns all of the default display options for the application specific to which Customer is using it. For example American Tower would have a separate company_config set up to Extenet. Only one company_config object can be active per application.
• ticketer_config - The ticketer_config domain stores the cluster settings associated with a specific customer and the database profile from which these are pulled.
• marker_color_config - The marker_color_config domain stores the settings for alarm marker colors that get displayed on the map. For example, the Critical alarm color is red.
• database_profile - The database_profile domain stores entries for the database server connections to other application databases which are used in the NOC Portal. These are set at a company_config level per customer.
• cluster - The cluster domain stores entries for all of the carrier specific regions (i.e. AT&T - Southern CA). In terms of the Noc Portal application, these are configured on a customer basis subject to their snmp_config within the application. This ticketer_config is then stored in the active company_config object.
• cluster_group - The cluster_group domain stores references to a group of clusters that can be configured to show multiple clusters (i.e. by region, or with multiple carriers)
• cluster_group_cluster - The cluster_group_cluster domain is a join table which stores the relationship between the cluster table and the cluster_group table.
• network_element_communication_failure_identifier - Used to store information about identifiers used to determine whether a network element is suffering a communication failure. For example: An element with an alarm present with an alarm identifier of 'linkDown' will have suffered a communication failure and this should be displayed on the client.
• pmstate - The pmstate table contains all of the Preventative Maintenance Workflow States which we want to display tickets for in the Noc Portal, it also contains the marker color assignments for these states which are displayed on the map.
• pmworkflow - The pmworkflow domain is in a hasMany relationship with the pmstate table. The pmworklfow object is then assigned to the active company_config on a per customer basis.
• sql_query - The sql_query domain stores all of the queries which are used to display alarms, network elements and tickets on the map.
• uploadable_file - The uploadable_file domain stores the reference to any file uploaded to a network_element via the portal. It also stores the location of the file on the filesystem.
• cluster_uploadable_file - The cluster_uploadable_file domain is a join table which stores the relationship between the cluster and uploaded files associated with that cluster.
• map_overlay - The map_overlay domain stores the reference to the kml map overlay associated with a specific location on the map. There are currently three different map_overlay_types used in the noc portal. These are FIBER, WEATHER_WARNING and WEATHER.
• shiro_user - The shiro_user domain stores user account details for the Noc Portal application.
• shiro_role - The shiro_role domain stores user role information associated with access limitations in the Noc Portal applications. For example the role Administrator has access to the admin pages in the Noc Portal etc.
• shiro_user_shiro_role - The shiro_user_shiro_role domain is a join table which stores the relationship between the shiro_user table and the shiro_role table, creating the link between users and their assigned roles.
• shiro_user_cluster - The shiro_user_cluster domain is a join table which stores the relationship between the shiro_user table and the cluster table, creating the link between users and their assigned clusters.
• shiro_user_cluster_group - The shiro_user_cluster_group domain is a join table which stores the relationship between the shiro_user table and the cluster_group table, creating the link between users and their assigned cluster groups.
• shiro_role_permissions - Permissions are assigned through the table shiro_role_permissions. This is done at a database level to populate this field. This table stores a reference to the shiro_role_id and a permissions string for the grails gsp view permissions.

The following assessment is to test your knowledge of the basic object model outlined above for the NOC Portal.

This assessment assumes that you have a basic working knowledge of MySQL and have completed the MySQL assessment prior to this.

1. Connect to a qa database and locate the noc_portal application database. (If you need assistance in establishing this connection please contact a member of the team.)
2. In the MySQL prompt, Describe the contents of the following tables: cluster, cluster_group, map_overlay, marker_color_config.
3. Join an entry of the shiro_user table to the shiro_role table.
4. Join an entry of the cluster table to the cluster_group table.
5. Determine whether AT&T - Southern CA is a neutral_host_cluster or not.
6. Locate the active company_config entry for the Noc Portal.
7. Locate the associated pmworkflow and pmstate assignments for this active company_config entry.
8. Locate the active database_profile entry for the ticketer application.
9. Find the uploaded files directory on one of the application handlers for the Noc Portal using the relative table in the database. (If you need assistance in establishing this app handler connection please contact a member of the team.)
10. Find the relevant ticket_config entry associated with the active company_config.
11. Join an entry of the shiro_user table to the cluster table to determine an cluster assignment for that user account.
12. Join an entry of the shiro_user table to the cluster_group table to determine a cluster_group assignment for that user account.