Creating Service Management Components with Modeling Gateway

Contents
casp1031
Contents
You can create service management component models using the CA Spectrum Modeling Gateway Toolkit to define service component model configurations in XML input files and import the files into CA Spectrum. Defining service management models with the Modeling Gateway Toolkit and importing them into CA Spectrum instead of creating them with Service Editor is advantageous in the following ways:
  • Modeling Gateway lets you define new models in bulk. Once you have created a particular service management model, you can use the XML input file for the model as a template for creating other models of that type.
  • You can edit service management models that are imported through Modeling Gateway either by using the Service Editor or by simply editing and re-importing the original XML file.
  • There can be an opportunity to automate the creation of service management models by producing an xml file for import that is based on an external data source. You can verify the Modeling Gateway capabilities and prerequisites. For more information, see the Modeling Gateway Toolkit section
    .
About the XML Framework
The hierarchy models (SM_Service_Mgt, SM_ServiceMgr, SM_SLA_Mgr, CustomerManager) must be arranged and named in the XML input file according to the following example.
The following example illustrates the basic framework of the XML input file. Each service management component is added within the appropriate section of the file. Service models can be created within the SM_ServiceMgr block, or within other services. Customer models and Customer Group models are created within the CustomerManager block. Finally the SLA models are created within the SLA_Mgr block.
<?xml version="1.0" standalone="no"?> <!DOCTYPE Import SYSTEM ".import.dtd"> <Import> <SM_Service_Mgt name="Service Management" containment_relation="SlmHasServiceComponent"> <SM_ServiceMgr name="Services" containment_relation="SlmContains"> </SM_ServiceMgr> <SM_SLA_Mgr name="SLAs" containment_relation="SlmContainsSLAs"> </SM_SLA_Mgr> <CustomerManager name="Customers" containment_relation="Groups_Customers"> </CustomerManager> </SM_Service_Mgt> </Import>
The following image displays the hierarchy that is represented in the OneClick Console.
SPEC--hierarchy_OneClick_Console_scr
 Although the name and containment_relation attribute values in the framework tags must be adhered to in the XML file you import, the individual service, resource monitor, customer, SLA, and guarantee models you import must have unique names. This differs from the OneClick client. Because modeling gateway uses name for uniqueness. Services with the same name are interpreted as the same model.
Service Models
Service models must be defined within the SM_ServiceMgr tag in the XML file that you import. For each landscape where Service Manager is installed, there is only one SM_ServiceMgr model with the model name, Services.
Each service model in a given landscape must be either SlmContains by the ServiceManager or SlmMonitors by another service model.
To use Modeling Gateway effectively, understand the mapping between policies and policy IDs. For example, if a service monitors other services or resource monitors, it can be configured with a service health policy (IDs 6-9). Also, you can determine a policy ID for a user-created policy by setting up the Policies table in the Service Policy Editor to display IDs.
Policies and Watched Attributes
When using Modeling Gateway to model services, the value for the MonitorPolicy_ID can be set to the id number associated with the policy the service uses. Service policy ids can be seen in the service policy editor by adding the Service Policy ID column to the service policies table. Out-of-the-box policies start at 1, user created policies start at 1000.
In addition to viewing policy ID in the service policy editor, you can see the policy id that is displayed at the following link.
http://<server>/spectrum/slm/ policyrep.jsp
Remember that when specifying the Monitor Policy_ID, verify that the AttrToWatch matches the attribute for the policy that you have selected.
 If your XML file creates a mismatch between a monitor policy ID and watched attribute (for example, watching Contact Status using policy ID 2), Service Manager puts the service in a defunct condition, which is reported as an outage and can be viewed in Service Dashboard. When a service becomes default an alarm is generated on the Service Management model. This alarm is major for services which are associated to an SLA, and minor for services which are not.
Example: Services That Monitor Resources Directly
The following XML document configures a service named “Test Service.” It monitors the contact status of two Cisco routers and generates a critical alarm if contact to either router is lost:
SPEC--example_xml_monitor_resources_directly
  • The Services model contains (has an SlmContains relationship with) Test Service. This can make the Test service a direct child of the service manager. The Test service appears under the Services icon in the OneClick navigation panel.
  • Test Service monitors (has an SlmMonitors relationship with) the 10.253.9.7 and 10.253.9.8 devices and watches their Contact_Status attributes using the Contact Status High Sensitivity policy.
  • The value of Generate_Service_Alarms is true, indicating that when the service health value is down, degraded, or slightly degraded, CA Spectrum generates an alarm for the service.
Example: Services That Monitor Resources in Resource Monitors
The following XML document defines a service, XYZ Service, that monitors two other services (Core Routers and DNS) directly. In addition, the XYZ service defines three resource monitors by specifying SM_AttrMonitor elements. The first resource monitor XYZ Condition monitors the contents of the XYZ Network container. The second resource monitor XYZ Response Time monitors an SPM test call XYZ_RTM_1. Finally, the service also defines a resource monitor, XYZ Port Status which monitors an interface model.
<SM_Service containment_relation="SlmMonitors" name="XYZ Service" Criticality="25" AttrToWatch="Service_Health" MonitorPolicy_ID="8" Generate_Service_Alarms="true"> <SM_AttrMonitor containment_relation="SlmWatchesContainer" name="XYZ Condition" AttrToWatch="Condition" MonitorPolicy_ID="2"> <Topology_Container model_type="Network" name="XYZ Network Servers" /> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="XYZ Response Time" AttrToWatch="LatestErrorStatus" MonitorPolicy_ID="18"> <RTM_Test name="XYZ_RTM_1" /> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="XYZ Port Status" AttrToWatch="Port_Status" MonitorPolicy_ID="15"> <Port ip_dnsname="10.253.50.5" identifier_name="ifIndex" identifier_value="45" /> </SM_AttrMonitor> <SM_Service name="Core Routers"/> <SM_Service name="DNS"/> </SM_Service>
Example: Using XML to Define a Service Template
If you encounter a scenario where many services share a common pattern or structure. You can define that structure in xml, and can use it as a common template. For example, you can build services to monitor a set of applications which are all different, but have common service modeling components. You can define the structure and import as many service models as you need from it. Some of the data can be added for import, or you can create empty services and resource monitors. You can add resources to them using the OneClick client.
The following syntax shows an example of the xml for a small service hierarchy that define a set of reusable service and resource definitions. The TMPL text represents wildcard test that can be changed to a more meaningful name for each set of services to be imported.
For this example, you can see a service which includes monitoring capability for some application servers, and associated database servers. As well as some additional some response time and performance monitoring. This example is not intended to match any specific requirements, but serves as an example to create an xml template for a set of services with common requirements.
<SM_Service containment_relation="SlmMonitors" name="TMPL Application Service" Criticality="10" AttrToWatch="Service_Health" MonitorPolicy_ID="7" Generate_Service_Alarms="true"> <SM_Service containment_relation="SlmMonitors" name="TMPL Application Servers" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="9" Generate_Service_Alarms="true"> <SM_Service containment_relation="SlmMonitors" name="TMPL Application Server 1" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="7" Generate_Service_Alarms="true"> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Host 1" AttrToWatch="Condition" MonitorPolicy_ID="3" Cause_List_Control="2" Special_Cause_List="0x1106f-0x11232"> // Excludes all eHealth alerts </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Server 1 Critical Processes" AttrToWatch="Condition" MonitorPolicy_ID="3"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Server 1 System Resources" AttrToWatch="Condition" MonitorPolicy_ID="3"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Server 1 Connection" AttrToWatch="Response Time" MonitorPolicy_ID="19"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Server 1 Performance" AttrToWatch="Condition" MonitorPolicy_ID="3" Cause_List_Control="1" Special_Cause_List="0x1120a,0x11219"> // Includes 2 specific eHealth alerts only </SM_AttrMonitor> </SM_Service> </SM_Service> <SM_Service containment_relation="SlmMonitors" name="TMPL Database Servers" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="6" Generate_Service_Alarms="true"> <SM_Service containment_relation="SlmMonitors" name="TMPL Database Server 1" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="7" Generate_Service_Alarms="true"> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL DB Host 1" AttrToWatch="Condition" MonitorPolicy_ID="3" Cause_List_Control="2" Special_Cause_List="0x1106f-0x11232"> // Excludes all eHealth alerts </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL DB Server 1 Critical Processes" AttrToWatch="Condition" MonitorPolicy_ID="3"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL DB Server 1 System Resources" AttrToWatch="Condition" MonitorPolicy_ID="3"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL DB Server 1 Connection" AttrToWatch="Response Time" MonitorPolicy_ID="19"> </SM_AttrMonitor> </SM_Service> </SM_Service> </SM_Service containment_relation="SlmMonitors" name="TMPL Application Performance & Response Time" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="7" Generate_Service_Alarms="true"> <SM_Service containment_relation="SlmMonitors" name="TMPL Application Response Time" Criticality="10" AttrToWatch="Response Time" MonitorPolicy_ID="20" Generate_Service_Alarms="true"> <SM_Service> <SM_Service containment_relation="SlmMonitors" name="TMPL Application Performance Criticality="10" AttrToWatch="Condition" MonitorPolicy_ID="4" Cause_List_Control="1" Special_Cause_List="0x1106f-0x11232"> // Includes eHealth alerts only Generate_Service_Alarms="true"> <SM_Service> </SM_Service> </SM_Service>
Now let us review each component in the xml to understand its purpose and how it fits within the service hierarchy that is defined by the xml. At the top of the hierarchy we have the application Service which has three direct child services:
SPEC--XML_Define_Service_Template_1
The Application Service monitors each of its child service with a high sensitivity policy. Therefore, the Application Service can have a service health equal to that of its worst direct resource.
The Application Servers service is designed to monitor child services which represent individual servers. Each server is represented by a service model with five resource monitors. The xml example contains only Application Server 1, but you could add this section for as many servers as necessary.
SPEC--XML_Define_Service_Template_2
The Application Servers service could monitor the health of individual child services with a redundancy, percentage of low sensitivity policy.
Each Application Server service; however, would monitor its resource monitors with a high sensitivity policy. The resource monitors focus on the host itself, critical processes, system resources, application connection, and application performance. You can notice that the Host resource monitor excludes CA eHealth notifications which are performance-based. The Application Performance resource monitor is only impacted by CA eHealth notifications. Both resource monitors would likely have the same host model as a resource, but are affected by different types of resource outages. This allows you to determine if the service outage is related to availability or performance.
SPEC--XML_Define_Service_Template_3
The Database Servers service has a similar structure to Application Servers. Multiple individual servers can be supported.
SPEC--XML_Define_Service_Template_4
Each individual server supports four resource monitors. These detect faults on the host model, critical database processes, system resources, and database connections. Once again, you can see that the Host resource monitor excludes CA eHealth notifications.
SPEC--XML_Define_Service_Template_5
Finally the service also includes a component for monitoring performance and response time. Application Response Time sub service would focus on monitoring SPM tests in CA Spectrum. You can use default response time policies, or perhaps develop a custom policy for average response time. The Performance sub service would detect resource faults that are based on CA eHealth performance notifications that are sent to CA Spectrum. The performance service would likely use a set of host models as its resources where CA eHealth notifications are mapped to resource alarms.
SPEC--XML_Define_Service_Template_6
This example is not designed to fit a specific scenario, but provide you with an example of how modeling gateway can be used to model common patterns in your environment.
If you are able to identify all of the resources, they can be added to the service and resource monitor elements in the xml file. Even if you are not sure of all service resources, services and resource monitors can still be imported and empty of resources. The empty services and resource monitors appear with blue icons in CA Spectrum prompting you to the need to fill in the resources.
 
Example: Define a Service Maintenance Schedule
In addition to defining the structure of a service and its resources you can also specify a maintenance schedule for service. The following XML segment defines a maintenance schedule for a service named "ABC Service", using an existing schedule model.
<SM_Service      containment_relation="MaintenenceScheduledBy"      name="ABC Service"> <Schedule name="Every day from 6 PM - 7 AM" SCHED_Recurrence="2" SCHED_Duration="46800" SCHED_Start_Hour="18" SCHED_Start_DoM="0" SCHED_DayBitMask="0" SCHED_Start_Day="0" SCHED_Description="" SCHED_Start_Year="0" SCHED_Start_DoW="0" SCHED_Start_MoY="0" SCHED_Start_Minute="0" SCHED_Start_Month="0" SCHED_Daily_Repeat_Limit="2" SCHED_Recurrence_Multiplier="1"/> </SM_Service>
Example: Define an Alarm Exemption List for a Service or Resource Monitor
You can specify an alarm type exclusion list for a service using modeling gateway. This setting applies to the service model, and can be used in lieu of any setting that is made at the policy level. This xml configuration is equivalent to specifying the alarm type exemption in the Exemptions tab of the Service Editor. If the configuration you want to specify for this service is defined within a policy, specify the policy ID.
The following XML segment specifies the three alarms (0xabcd0001, 0xabcd0001, 0xabcd0002) that are the only alarm types to affect (Cause_List_Control=“1”) the service:
<SM_Service containment_relation="SlmMonitors" name="Access Routers" Criticality="30" AttrToWatch="Condition" Cause_List_Control="1" Special_Cause_List="0xabcd0001,0xabcd0001,0xabcd0002" MonitorPolicy_ID="2" Generate_Service_Alarms="true"> <Device ip_dnsname="10.253.9.16" /> <Device ip_dnsname="10.253.9.17" /> <Device ip_dnsname="192.168.152.5" /> <Device ip_dnsname="172.19.17.174" /> </SM_Service>
The following XML document specifies a range of alarms (0xeeee0000-0xeeee002b) that can be excluded from impacting the health of the service (Cause_List_Control=“2”) the resource monitor:
<SM_AttrMonitor containment_relation="SlmMonitors" name="Access Routers" Criticality="30" AttrToWatch="Condition" Cause_List_Control="2" Special_Cause_List="0xeeee0000-0xeeee002b" MonitorPolicy_ID="2"> <Device ip_dnsname="10.253.9.16" /> <Device ip_dnsname="10.253.9.17" /> <Device ip_dnsname="192.168.152.5" /> <Device ip_dnsname="172.19.17.174" /> </SM_AttrMonitor>
Example: Associate an SLA to a Service
Service models can be associated to SLA models using modeling gateway. This association does not create any specific guarantee models, or associate the service to any existing guarantee model. Associations for guarantees must be done explicitly and can be covered later in this document.
The following sample XML shows how to associate an SLA to a service:
<SM_SLA containment_relation="SlmGuarantees" name="Acme Service Level Agreement"> <SM_Service name="Acme"/> </SM_SLA>
Example: Create a Guarantee for an SLA
Guarantee models are created within an SLA element, and can be associated to a service or resource monitor model. The following XML shows how to create a guarantee for an SLA call Acme Service Level Agreement. You can call the guarantee as Engineering Guarantee and record outage time when the Engineering service is Down.
<SM_SLA containment_relation="SlmHasGuarantee" name="Acme Service Level Agreement"> <SM_Guarantee containment_relation="SlmIsMeasuredBy" name="Engineering Guarantee" GuaranteeControl="1" GuaranteeType="0" ServiceHealthType="1" WarningThresholdPercent="80.5" ViolationThresholdPercent="99.5" GuaranteeNotes="Tracks Down Time For Engineering Service" GuaranteeDescription="Availability Guarantee for Acme Engineering" MOT_Threshold="300" MTBF_Threshold="300" MTTR_Threshold="300"> <SM_Service name="Engineering"/> </SM_Guarantee> </SM_SLA>
Guarantee business hours can be specified using xml, by defining the schedule. The following example shows how a schedule named Business Hours can be associated to the Engineering Guarantee model.
<SM_Guarantee containment_relation="SlmSchedulesGuarantee" name="Engineering Guarantee" GuaranteeType="0"> <Schedule name="Business Hours" SCHED_Recurrence="2" SCHED_Daily_Repeat_Limit="0" SCHED_Duration="25200" SCHED_Recurrence_Multiplier="1" SCHED_Start_DoM="0" SCHED_Start_DoW="0" SCHED_Start_Hour="8" SCHED_Start_Minute="0" SCHED_Start_Month="0" SCHED_Start_Day="0" SCHED_DayBitMask="0" SCHED_Start_Year="0" SCHED_Start_MoY="0" SCHED_Description="Standard Business Hours 8AM Start"/> </SM_Guarantee>
Example: Define an SLA
The SLA Manager is the top-level model for all SLAs. Each SpectroSERVER has one SLA Manager model.
In addition to creating the SLA and its guarantees, the SLA period can be defined using modeling gateway. The following XML example shows how to define an SLA period, by specifying the period schedule.
<SM_SLA_Mgr name="SLAs" containment_relation="SlmContainsSLAs" > <SM_SLA containment_relation="SlaPeriod" name="Acme Service Level Agreement" SLA_Control="1" SLA_ExpirationDate="1514696400" SLA_Notes="Manages SLA for Acme Services" SLA_Description="Acme Management Technologies Internal Service Level Agreement"> <Schedule name="Daily SLA Schedule" SCHED_Recurrence="2" SCHED_Duration="0" SCHED_Start_Hour="0" SCHED_Start_DoM="0" SCHED_DayBitMask="0" SCHED_Start_Day="0" SCHED_Description="" SCHED_Start_Year="0" SCHED_Start_DoW="0" SCHED_Start_MoY="0" SCHED_Start_Minute="0" SCHED_Start_Month="0" SCHED_Daily_Repeat_Limit="0" SCHED_Recurrence_Mutiplier="1"/> </SM_SLA> </SM_SLA_Mgr>
Example: Define a Customer and a Customer Group
Customer models must be defined within the CustomerManager tag in the XML file. Each SpectroSERVER has one Customer Manager model, and it must be named as Customers.
The following example XML document defines a customer that is named Product Development within a customer group named XYZ Group:
SPEC--example_create_customer_customer_group
Example: Import XML Input Files
You can use Modeling Gateway to import your Service Manager configuration files. Use the Modeling Gateway to test the XML document in Example: Services That Monitor Resources Directly.
Follow these steps:
  1. Create a file containing the example XML document and save it to the <
    $SPECROOT
    >/SS-Tools directory with the file name, slm_test1.xml.
  2. To run the modelinggateway tool for importing a single file, use the following syntax.
    Windows
    modelinggateway.bat -vnm vnm_name -i import_file [-o outputfile] [-debug debugfile]
    Linux
    modelinggateway -vnm vnm_name -i import_file [-o outputfile] [-debug debugfile]
    • -vnm 
      vnm_name
      Specifies the 
       host name.
    • - i 
      import_file
    Specifies the XML file name which contains the necessary input information (that is compiled with .modelinggateway.dtd.)
    If you are importing from multiple files, specify the files names that are enclosed in comma-separated {} brackets. For example, refer to the syntax sample for importing multiple files.
    • -o 
      outputfile
    (Optional) Logs the error information to the file named in the 
    outputfile
     parameter.
    If you don't specify the debug/output file names, the error information is logged to a file named
    import_file
    .log;where,
    Import_file
    is the name of the XML file.In case of multiple imports, the debug/output files are appended and you can see consolidated logs.
    • -debug 
      debugfile
    (Optional) Indicates that you would like to create a debugging output file during the import process. When using the -debug option, you can provide your own debug file name for output. If you do not supply a value for 
    debugfile
    , the debug file name defaults to the 
    import_file
     name suffixed with ".debug."
    The -debug option requires disk space on the machine where Modeling Gateway is run. For example, a large debugging output file can result when the number of models in the
    import_file
    is large or when the device models have large interface densities.
    Import Multiple Files
    The modelinggateway tool now supports import from multiple XML files. You can now specify any number of import files. 
    To run the modelinggateway tool for importing multiple files, use the following syntax:
    modelinggateway -vnm vnm_name [-user SS user][-i{importfile1,importfile2...}]|[ -cmdb]-e exportfile][-o outputfile] [-debug debugfile]
  3. If no errors are reported, device and container models are created. The output can be similar to the following output:
    Import session started Fri, December 29, 2006, at 02:53:32 EST Start parsing file slm_test1.xml Start importing file slm_test1.xml Container models created: 1 Identifying ports... Import session finished Fri, December 29, 2006, at 02:53:38 EST
Service Attributes (SM_Service)
When creating service management models with Modeling Gateway, the XML code must provide values for the service attributes (sm_service) listed in the following table.
Attribute
Description
Possible Values
containment_relation
The set of supported relations from which associations can be created.
SlmMonitors
SlmWatchesContainer
MaintenenceScheduledBy
name
The model name of the service.
Text string, up to 256 characters
Criticality
The impact severity of the alarm relative to other current alarms. A higher Criticality value contributes to a higher impact severity value for alarms in OneClick.
10 = Low
15 = Medium Low
20 = Medium
25 = Medium High
30 = High
AttrToWatch
The attribute monitored on the service resource models.
The AttrToWatch value should be consistent with the MonitorPolicy_ID. For example, if you specify AttrToWatch=“Condition”, you should specify a MonitorPolicy_ID for a Condition Policy (1-5).
Condition
RM_Condition(service health)
Contact_Status
Port_Status
LatestErrorStatus (Response Time)
MonitorPolicy_ID
The ID of a specific monitor policy as defined on the GlobalConfig model type. The ID should be consistent with the AttrToWatch value.
1 - 21 (CA Spectrum default)
1000 -
n
(User-defined)
Generate_Service_Alarms
Determines whether the SM_Service model generates alarms upon a change in service health.
True or False
Special_Cause_List
The alarm cause codes to include in an alarm type exemption list for a service.
Text string in the form of comma separated alarm causes or ranges separated with a hyphen ( - )
Cause_List_Control
The integer that defines which alarm types affect or do not affect a service.
0=Unused (Ignore Cause)
1=Inclusive (Caused By)
2=Exclusive (Not Caused By)
 
Monitor Resource Monitor Attributes (SM_AttrMonitor)
When creating service management models with Modeling Gateway, the XML code must provide values for the monitor resource monitor attributes (SM_AttrMonitor) listed in the following table.
Attribute
Description
Possible Values
containment_relation
The set of supported relations from which associations can be created.
SlmMonitors
SlmWatchesContainer
name
The model name of the resource monitor.
Text string, up to 256 characters
AttrToWatch
The attribute monitored by the resource monitor.
The AttrToWatch value should be consistent with the MonitorPolicy_ID. For example, if you specify AttrToWatch=“Condition”, you should specify a MonitorPolicy_ID for a Condition Policy (1-5).
Note:
See Policy ID Mappings for more information.
Condition
RM_Condition (service health)
Contact_Status
Port_Status
LatestErrorStatus (Response Time)
MonitorPolicy_ID
The ID of a specific monitor policy as defined on the GlobalConfig model type. It should be consistent with AttrToWatch value.
Note:
See Policy ID Mappings for more information.
1 - 21 (CA Spectrum default)
1000 -
n
(User-defined)
Special_Cause_List
The alarm cause codes to include in an alarm type exemption list for a resource monitor.
Text string in the form of comma separated alarm causes or ranges separated with a hyphen ( - )
Cause_List_Control
The integer that defines which alarm types affect or do not affect a resource monitor.
0=Unused (Ignore Cause)
1=Inclusive (Caused By)
2=Exclusive (Not Caused By)
 
Customer Group Attributes (SM_CustomerGroup)
When creating service management models with Modeling Gateway, the XML code must provide values for the customer group attributes (SM_CustomerGroup) listed in the following table.
Attribute
Description
Possible Values
containment_relation
The set of supported relations from which associations can be created.
Groups_Customers
name
The model name of the customer group.
Text string, up to 256 characters
 
 
Customer Attributes (SM_Customer)
When creating service management models with Modeling Gateway, the XML code must provide values for the customer attributes (SM_Customer) listed in the following table.
Attribute
Description
Possible Values
containment_relation
The set of supported relations from which associations can be created.
SlmUses
name
The model name of the customer.
Text string, up to 256 characters
CustomerField4
Address Line 1
Text string, up to 256 characters
CustomerField5
Address Line 2
Text string, up to 256 characters
CustomerField6
City, State, Postal Code
Text string, up to 256 characters
CustomerField7
Country
Text string, up to 256 characters
CustomerID
Any identification number.
Alpha-numeric string
Criticality
The impact severity of the alarm relative to other current alarms. A higher Criticality value contributes to a higher impact severity value for alarms in OneClick.
10 = Low
15 = Medium Low
20 = Medium
25 = Medium High
30 = High
Contact_Name
The person associated with the customer model.
Text string, up to 256 characters
Contact_Title
The contact person title.
Text string, up to 256 characters
Email_Address
The contact person email address.
Text string, up to 256 characters
Phone_Number
The contact person phone number.
Text string, up to 256 characters
Mobile_Phone_Number
The contact person mobile phone number.
Text string, up to 256 characters
Secondary_Contact_Name
The alternate contact person name.
Text string, up to 256 characters
Secondary_Contact_Title
The alternate contact person title.
Text string, up to 256 characters
Secondary_Phone_Number
The alternate contact person phone number.
Text string, up to 256 characters
Secondary_Mobile_Phone_Number
The alternate contact person mobile phone number.
Text string, up to 256 characters
Secondary_Email_Address
The alternate contact person email address.
Text string, up to 256 characters
 
 
SLA Attributes (SM_SLA)
When creating service management models with Modeling Gateway, the XML code must provide values for the SLA attributes (SM_SLA) listed in the following table.
Attribute
Description
Possible Values
containment_relation
The set of supported relations from which associations can be created.
SlaPeriod
SlmHasGuarantee
SlmGuarantees
name
The model name of the SLA.
Text string, up to 256 characters
SLA_Control
Specifies whether the SLA is active during the current SLA period or becomes active at the onset of the next period.
0 (inactive until next period) or
1 (active)
SLA_ExpirationDate
The UNIX timestamp, measured as the number of seconds from January 1, 1970.
For example, the value 1514696400 - Dec 31, 2017
SLA_Notes
Any text notes about the SLA.
Text string, up to 256 characters
SLA_Description
Any text description of the SLA.
Text string, up to 256 characters
 
Guarantee Attributes (SM_Guarantee)
When creating service management models with Modeling Gateway, the XML code must provide values for the guarantee attributes (SM_Guarantee) listed in the following table.
Attribute
Description
Possible Values
containment_relation
The set of supported relations from which associations can be created.
SlmIsMeasuredBy
name
The model name of the guarantee.
Text string, up to 256 characters
GuaranteeControl
Specifies whether the guarantee is active or inactive during the current period.
0 (inactive) or 1 (active)
GuaranteeType
Specifies whether the guarantee monitors service availability or performance (response time).
0 (availability) or
1 (performance)
ServiceHealthType
The type of service health time that is accumulated by the guarantee. An availability guarantee can accumulate both down and degraded time. A performance guarantee accumulates only degraded time.
1 (Down) or
2 (Degraded)
WarningThreshold
The number of seconds of outage time allowed per period before a warning alarm is issued.
0 -
n
WarningThresholdPercent
The percentage of outage time allowed before a warning alarm is issued.
0 - 100%
ViolationThreshold
The number of seconds of outage time allowed per period before a violation occurs.
0 -
n
ViolationThresholdPercent
The percentage of uptime per period below which a violation occurs.
0 - 100%
GuaranteeNotes
Any text notes about the guarantee.
Text string, up to 256 characters
GuaranteeDescription
A text description of the guarantee.
Text string, up to 256 characters
MOT_Threshold
Maximum outage time in seconds
0 -
n
MTBF_Threshold
Mean time between faults in seconds
0 -
n
MTTR_Threshold
Mean time to repair in seconds
0 -
n
 
 
Schedule Attributes (Schedule)
When creating service management models with Modeling Gateway, the XML code must provide values for the schedule attributes (Schedule) listed in the following table.
Attribute
Description
Possible Values
name
The model name of the schedule.
Note:
 CA Spectrum renames the schedule name that you provide.
Text string, up to 256 characters
SCHED_Recurrence
Specifies when the schedule is implemented.
1 = Always (24 x 7)
2 = Daily
3 = Weekly
4 = Monthly
5 = Yearly
SCHED_Start_Hour
The hour the schedule starts.
0 - 23
SCHED_Start_Minute
The minute the schedule starts.
0 - 59
SCHED_Start_DoW
The day of the week the schedule starts
0 - 6
SCHED_Start_DoM
The day of the month the schedule starts.
1 - 31
SCHED_Start_Month
The month of the year the schedule starts.
0 (Jan.) - 11 (Dec.)
SCHED_Start_Year
The year the schedule starts. Entering 0 starts the schedule in the current year.
0
SCHED_Start_MoY
The month of the year the schedule starts. Entering 0 starts the schedule in the current month.
0
SCHED_Description
The description of the schedule.
Text string, up to 256 characters
SCHED_Duration
The duration the schedule is in effect in seconds.
0 -
n
SCHED_Recurrence_Multiplier
The number of times the schedule is implemented.
1 -
n
SCHED_Daily_Repeat_Limit
The number of consecutive days to repeat a daily schedule at the start of each recurrence period. Applicable to Weekly, Monthly, or Yearly recurrence only.
0 -
n