Autoticketing Solution Accelerator

On This Page

	Executive Summary
	Introduction
	Autoticketing Overview
	Processes and Activities
	Appendices

Executive Summary

In the increasingly important and complex world of information technology (IT) operations, it is essential to implement a robust and reliable systems management infrastructure based on proven methods. Service Monitoring enables data center managers to increase operational efficiency and to achieve a higher state of availability for mission-critical applications and management of Microsoft® Windows® services. Increased levels of performance can be achieved on Windows platforms through the implementation of Service Monitoring, which incorporates best-practice guidance in planning, building, designing, and deploying Microsoft Operations Manager (MOM) 2005 to monitor Windows applications and services.

Automated ticket generation—or autoticketing—enables the fully automated posting of a request (or ticket) into the Trouble Ticketing (TT) system used in incident management. Because it requires no user or manual interaction, autoticketing results in improved operational efficiency through:

Top of page

Introduction

Document Purpose

This guide contains information about autoticketing for organizations that have deployed (or are considering deploying) MOM 2005 in a data center or other type of enterprise computing environment. It discusses the steps inherent to preparing for and implementing autoticketing. In addition, it provides sample scripts for the MOM Connector Framework (MCF) and Siebel Enterprise Application Integration (EAI)/HTTP transport.  

It is not the intention of this document to provide a fully implemented autoticketing capability because doing so would be assuming that a universally applicable solution for autoticketing is possible, which is not the case. Autoticketing requires a thorough study of the internal IT organization’s applications, workflows, and business rules. Then the data, logic, and specific configurations must be applied based on that information. This guide describes many of these considerations in order to implement a successful autoticketing solution.

Background

Autoticketing is a practice that is aligned with the Service Monitoring and Control (SMC) service management function (SMF). The SMC SMF is one of the 21 SMFs (shown in Figure 1) defined and described in the Microsoft Operations Framework (MOF) Process Model. Every SMF within MOF benefits from some aspect of SMC because these functions are inherent to ongoing process improvement. This is especially true in the Operating Quadrant of the MOF Process Model, where the SMFs are closely interrelated.

Figure 1. MOF Process Model and related SMFs

Appendix B: Key Performance Indicators contains a statistic that should be reviewed to understand the performance of SMC as well as to identify opportunities for improvement.

Intended Audience

The guide is intended for IT professionals in data centers and in large and enterprise organizations. In particular, MOM administrators, help-desk personnel, and others involved in service monitoring and control and in service continuity management should find this guide helpful. It assumes that the reader is familiar with the intent, background, and fundamental concepts of MOF, MOM, and other Microsoft technologies discussed. (Links to further information are contained in Appendix A: Resources.) An overview of MOF and its companion, Microsoft Solutions Framework (MSF), is available at http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

Terminology

This guide uses terminology that is current for MOM 2005. Table 1 lists the changes in terminology between MOM 2000 Service Pack 1 (SP1) and MOM 2005.

Table 1. Terminology Changes Between MOM 2000 SP1 and MOM 2005

Feedback

Please direct questions and feedback about this guide to msmfeed@microsoft.com.

Top of page

Autoticketing Overview

Goals and Objectives

This chapter identifies some of the reasons for implementing autoticketing. In addition, it supplies details about the key phases, scope, high-level requirements, and challenges as they pertain to autoticketing, and provides a look at its architecture.

The primary goals of autoticketing are to increase operational efficiency, reduce the costs of IT operations, increase the effectiveness of service monitoring and control, and use key information from other IT operations applications.

The successful implementation of autoticketing achieves the following objectives:

Key Phases

In order to effectively create autoticketing, the alert-tuning process must be in place to optimize the alert volume. Guidance on alert tuning is contained in Optimizing MOM 2005 Alert Volume, which is one of the five solutions for Service Monitoring. Once the alert-tuning process is in place, autoticketing can be established through a process involving three key phases:

These phases are discussed in Chapter 4, “Processes and Activities.”

Scope

This document addresses the ticketing of alerts from MOM 2005.  

High-Level Requirements

The successful implementation of autoticketing requires:

Key Challenges

In theory, the concept of autoticketing sounds simple: Receive an alert, decompose it, create a ticket, and supply the data. In reality, there are many more considerations. The three key challenges to successful autoticketing are as follows (ranked from highest to lowest complexity):

Data Sufficiency

The key value that a monitoring system can provide to a ticketing system lies in the description of problems—that is, in identifying the potential root cause of the failure condition. However, there might be more data that the ticket recipient needs before the ticket is actionable. When there is not enough of this information, the following conditions may occur:

Data sufficiency is a challenge because MOM serves a different functional role than a TT system. MOM is focused on infrastructure monitoring, performance collection, and response. The TT system is focused on record keeping of a ticket or service request (SR), managing workflows, coordinating activities, and reporting. It is understandable that these two IT operations products require different (unique) variables and datasets. In addition, other applications might hold the necessary data; however, they too are likely to have their own data formats and conventions.

Data-Transfer Enablement

MOM 2005 now provides a way to expose alert data through MCF, which is a Web service–based framework for connecting MOM and any third-party management platform.Most commercial TT packages also provide a means to programmatically import and extract data. Standards involved include XML, Component Object Model (COM), EAI/HTTP transport model, Microsoft .NET, and other Web application services.

Enabling the data-transfer capability is a challenge primarily because:

Data-Transfer Management

Managing the data-transfer capability is a challenge primarily because:

Autoticket Architecture

Autoticket architecture refers to the component layers that make up autoticketing and the autoticketing workflow process.

Component Layers

As Figure 2 shows, autoticketing has three main layers.  

•	Application layer. Contains MOM, the TT application, and configuration management applications.
•	Event integration layer. Enables communication between the applications.
•	Business logic layer. Contains the rules for manipulating and resolving data elements between applications and handling failure conditions in the autoticket workflow. Figure 2. Main components of autoticketing

Application Layer

The application layer provides the source and target data used for autoticketing. Through this layer, users are able to interface with the following functionality:

Event Integration Layer

The event integration layer is an abstraction of all communications between the applications. This layer includes the collection of alerts, the updating of state, and the insertion into the TT system.

Business Logic Layer

The business logic layer provides the core intelligence for autoticketing. The functions of this layer can be characterized as follows:

Autoticketing Workflow

When MOM is used as the SMC tool, it provides monitoring capabilities for the health conditions of servers and network devices. In the most common scenario, alerts are created by rules that reside in the MOM agent on each managed node. Based on the triggering of a rule, the different attributes of the alert are raised, such as alert name and resolution state. These alerts are often intended to give proactive notice on potentially harmful situations.

Operators who use the MOM 2005 Operator console are able to view the alerts and, when necessary, can manually create a trouble ticket. In this example, problem management and its resources in the Operating Quadrant roles receive the ticket and work toward issue resolution, while continuously tracking progress and information in the ticket.

In many cases, no human discretion is needed to determine whether the alert requires a ticket to be generated. These alerts should be automatically ticketed. The rule that creates the alert should be configured to prepopulate the alert’s resolution state to “AutoTicket.”

Subsequent sections provide functional and technical guidance on the the autoticketing workflow as shown in Figure 3.

Figure 3. Autoticketing workflow
See full-sized image

The workflow shown in Figure 3 consists of the following actions:

The following chapter discusses the processes and activities necessary for creating autoticketing.

Top of page

Processes and Activities

This chapter illustrates what processes must be completed to prepare the environment for autoticketing—namely, assessing MOM 2005 and the Trouble Ticketing (TT) environment, and developing the communications, filtering logic, and business logic behind autoticketing. Next, it defines the activities behind implementing autoticketing and conducting run-time monitoring. In other words, the sections are organized according to user processes and activities—based on the sequence of what the user must do to create autoticketing—followed by the steps that MOM takes once it is implemented (as just depicted in the seven steps of the autoticketing workflow).

When implementing MOM autoticketing, organizations should adhere to the Microsoft Solutions Framework (MSF) life cycle and project-focused guidance. MSF provides a flexible and scalable framework for planning, building, and deploying business-driven solutions. More specifically, the MSF Process Model—with its Envisioning, Planning, Developing, Stabilizing, and Deploying Phases—should be applied to the implementation process.

Autoticketing also requires close coordination with other SMC activities. These activities include the six core processes that an IT organization follows to fully adopt SMC. These processes, as they relate to the MOM environment, are shown in Figure 4. The figure also shows how these SMC activities directly relate to the activities involved in implementing autoticketing.

Figure 4. Six core processes as they relate to the MOM environment
See full-sized image

Again, you should be familiar with the MOF Service Monitoring and Control SMF (which describes these six core processes) and with the guidance related to it. Further information is available at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfsmc.mspx.

Assess MOM and Ticketing Environment

In this initial phase, pertinent information is collected and organized. Specific mappings and data identification might need to be performed in order to prepare for the implementation.

Define Taxonomy

It is important to organize a taxonomy for autoticket values. This taxonomy helps to identify all the key pieces of information necessary and also serves to clarify duplicates, attribute overloading, and misuse.

Tables 2 and 3 are examples of generic attributes for alerts and trouble tickets, respectively. These are shown for illustration purposes only; they are by no means comprehensive or authoritative.

Table 2. Generic Alert Attributes

Table 3. Generic Trouble Ticketing Attributes

Identify Authoritative Source

Once the taxonomy has been created, identify the authoritative source for the information. This source holds the most accurate and updated copy of that attribute. Table 4 lists generic alert attributes, MOM alert attributes, and the authoritative source.

Table 4. Alert Attributes and the Authoritative Source

Map Attributes

Once the taxonomy and authoritative source have been identified, a full mapping can be created. Table 5 illustrates a sample of map attributes.

Table 5. Map Attributes

Develop Alert-Filtering and Business Logic

The next process in assessing MOM and the ticketing environment is developing alert-filtering logic and business logic (of which alert-filtering logic is a subset). Business logic is necessary to resolve data issues as well as to provide algorithms to the autoticketing workflow. Business logic physically can reside either in the connector itself or within a standalone service.

Alert-Filtering Logic

Alert-filtering logic contains all the business rules that determine which alerts should be processed in autoticketing. The filtering logic is enforced through the use of a state table, which determines the action that should be taken on the alert based on the following criteria:

The business logic for numbers 1-3 is maintained in a state table. Number 4 is enforced through backend code only and will not be data-driven like numbers 1-3.

The state table contains all possible combinations to the answers of questions 1-3 and also contains the appropriate action that should be taken as a result of each possible alert state. When the MOM Connector Framework (MCF) returns data as part of an update, pre-established business logic has to be applied to determine which changes to a particular attribute or state warrant an autoticket generation or change. For example, in MOM 2005, MCF now exposes the ProblemState attribute. This attribute is part of the State Monitoring capability and reveals whether the alert is no longer a problem (whether it has been corrected at the source). Alert-filtering business logic can evaluate this change and choose to process it into the workflow for reflection onto the ticket.

Table 6 shows what values are possible within the state table and explains what these values mean.

Table 6. Valid Values Within the State Table

Business Logic

Business-logic rules are used in taxonomy resolution to help resolve data items. Perhaps the best way to describe this is through sample scenarios.

Scenario 1: Ticket Date

MOM stores the alert date using the datetime SQL type. When exposed using MCF, the format can be very different from what is used in the TT system. A Siebel service request (SR) uses a date and time format of “05/14/04 04:22:05 PM” whereas other TT systems use the format “16:22:05 Friday May 14, 2004”.  

Business logic provides a Transform capability and resolves the formatting prior to insertion into the TT system.

Scenario 2: Priority Weighting

In MOM, an alert has seven default severity levels defined, as shown in Table 7.

Table 7. MOM Default Severity Levels

A Trouble Ticketing system such as Siebel Call Center© has six default severity levels defined, as shown in Table 8.

Table 8. Siebel Call Center Default Severity Levels

Immediately, the data challenge of Transform becomes apparent. How do the severity values of MOM resolve to the severity values that should be used for the ticket? The levels are almost inverted, and there is an additional level from MOM. The business logic has to resolve this relationship using a customized inverse relationship and rules regarding the lower severity (by description) values.

Assume, at this point, that a ticket is created containing the appropriate severity value.

The problem arises when the ticket recipient needs to rank which ticket to address first (in order to sequence or schedule repair activities.) The ticket recipient is unable to do this because the ticket is incomplete. Although the severity has been identified, the severity and priority are unknown. Therefore, the ticket recipient will need to investigate and obtain the necessary priority information in the CMDB, which is typically composed of systems including inventory and asset management.   

Specifically, the ticket recipient will need to manually obtain the information shown in Table 9.

Table 9. Information That the Ticket Recipient Must Obtain

To improve future autoticketing, multisourcing should be employed to collect this data from the CMDB applications.

However, having the data is not enough to use it in an automated way. The Siebel SR only has one Priority field. How do the four data points converge into one? This is where priority weighting is used.

The IT organization establishes a formula that the business units agree upon in order to normalize the data set. It has been agreed that a weighted average of all priorities should be used to compute a final value.

The formula is as follows:

((LOB Priority * SLA Weight for LOB) + (LOS Priority * SLA Weight for LOS) + Rule Priority)/3

The severity values were transformed, the multisourced priority data receives business rules for weighting, and the final value is mapped to the appropriate Siebel SR field. Future autoticket cycles will now have more complete information.

Scenario 3: Ticket Queue

An enterprise typically has multiple ticket-recipient targets. For example, there may be a separate team at each key data center to handle failures at those locations. Using mapping-relationships and workflow-results business logic, data from configuration management can be used to populate TT attributes in order to designate a particular ticket queue.

Implement Autoticketing

After assessing MOM and the ticketing environment, the second phase of establishing autoticketing begins, namely, the actual development and implementation of the communications and workflow activities performed during autoticketing. This section gives detailed guidance on the activities within the second phase.

Extend MOM Resolution States

The autoticket design described throughout this guide is dependent on an upstream process that identifies the alerts to be autoticketed. The result of this process is that all alerts that should be autoticketed arrive in the MOM top-tier database with a predetermined resolution state, such as 5 = AutoTicket.

MOM 2005 implementations undergoing preparation for autoticketing should extend the resolution state definitions to include those shown in Table 10.

Table 10. Extending Resolution State Definitions

*- Locked

Develop MCF Connector

As stated previously, the MOM Connector Framework (MCF) is a Web service–based framework for connecting MOM and any third-party management platform. It enables full bidirectional alert forwarding and synchronization, including alert clear-downs between management tools. These capabilities provide increased management benefits to both medium and large enterprises.

MCF is a class library used to connect an external system to the MOM database. External systems can only access MCF through product connectors, which are the system interfaces with MOM through which data and objects can be accessed. This guide uses autoticketing as one example of a product-connector function.

Note   This guide provides an idea of what can be done with an MCF product connector. However, detailed information on how to develop a product connector is beyond the scope of this document. That information is contained in the MOM 2005 documentation.

Retrieve Alerts from MOM

The first step in the autoticketing workflow is to retrieve alerts from MOM. The GetData method is an MCF Web service method used for retrieving these alerts. It uses the registration ID associated with the specific product connector (such as the product connector for AutoTicket) as a parameter when requesting alerts with the resolution state of AutoTicket. The GetData method is called at regular time intervals (approximately every 30 seconds).

Although the interval timing for the GetData method is configurable, it is assumed that the autoticketing system will not make GetData method calls more frequently than what the TT system can handle. (For example, it can be set for an interval of every 20 seconds.) In addition, it is assumed that autoticketing will not request too many alerts with each GetData method call. (For example, the request size can be limited to a maximum of 20 alerts.)

If any method call to MCF fails, the service-requestor service should pause. Table 11 gives the workflow rules, dependencies, and error conditions associated with GetData.

Table 11. The GetData Method

Retrieving alert data from MOM using the GetData method returns various attributes. The complete list of attributes is contained in the MOM 2005 documentation.

Apply Filtering

The second workflow activity is to apply the filtering-logic rules developed earlier. Further information is contained in “Develop Alert-Filtering and Business Logic,” earlier in this document.

Update State to “Pending”

When an alert is returned through MCF as part of a GetData result set, the MOM application automatically updates the OnePoint.Alert.ResolutionState to “New.” This resolution state sends a confusing message to users of the MOM Operator console, so the third step in the autoticketing workflow is to change the Alert.ResolutionState to “Pending.”

Table 12 identifies the workflow rules, dependencies, and error conditions associated with UpdateAlerts.

Table 12. The UpdateAlerts Method

Apply Business Logic

After updating the MOM state to “Pending,” the fourth workflow activity is to apply the business logic that was developed earlier. Further information is contained in “Develop Alert-Filtering and Business Logic,” earlier in this document.

Create Ticket

The fifth step is to create the ticket. Details for this activity will vary according to the particular TT system being used. Accordingly, specific information cannot be provided here.

Update Attributes in MOM

After the ticket has been created, the sixth step is to update the attributes in the MOM alert to reflect the new state and other new information. This update is accomplished using the UpdateAlerts method. Table 13 identifites the workflow rules, dependencies, and error conditions associated with UpdateAlerts.

Table 13. The UpdateAlerts Method

Call AckData Method for All Alerts Retrieved

After the ticket has been successfully created, and the MOM alert properties have been updated, the seventh and last activity is to set the alert to MCF Acknowledged (not Alert Resolution State). This is perfomed by the AckData method. Table 14 identifies the workflow rules, dependencies, and error conditions associated with AckData.

Table 14. The AckData Method

Develop TT Connector

The specific connector for your TT system should be developed in order to transport data to and from the system. This example illustrates the construction of a connector for Siebel.

Background

The Siebel Web Engine will provide HTTP listening services and invoke a workflow process through a business service method. This workflow process will accept the incoming XML document and pass it through an integration object into the business object to update Siebel data. Use the following Siebel components:

Note the following prerequisites:

•	The Enterprise Application Integration (EAI) component group must be enabled (as in Figure 5).
•	The Thin Client component group does not need to be running. Figure 5. The Siebel Web Engine

Setup Process

The setup process for developing the TT connector involves:

Create the Workflow

To create the workflow

1.	Log onto the Siebel client and navigate to Screens > Siebel Workflow Administration > Workflow Processes > All Processes (as shown in Figure 6).
2.	Create a workflow titled Microsoft Connector (the same name as the business service). Click the Process Properties tab, and add the following variables: • SR message with a type of hierarchy. • <Value> with a type of binary
3.	From the palette of Process Designer, add a start, two business services and an end (as shown in Figure 6).
4.	Edit the first business service and choose EAI XML Converter as the business service and XML Document to Integration Object Hierarchy as the method. Create a new input argument, choose XML Document, set the type to Process Property and choose <Value> as the property name. Create a new output argument and choose SR Message as the property name, with Output Argument as the type and Siebel Message as the output argument.
5.	Edit the second business service and choose EAI Siebel Adapter as the business service with Insert or Update as the method. Create a new input argument and choose Siebel Message as the input argument with Process Property as the type and Account Message as the property name. Add an output argument. Choose <Value>, designate the type to be Literal and add the following to the value: <h1>Update Completed</h1> Figure 6. Creating the workflow

Set Up the Configuration Files

To set up the configuration files

Invoke the Workflow Through a URL

Invoke the workflow through a URL as given in the following example:

Note: Some of the lines in the following code have been displayed on multiple lines for better readability.

http://autoticketdemo.microsoft.com/eai_enu
/start.swe?SWEExtSource=SiebelMOM&SWEExtCmd=Execute
&UserName=SADMIN&Password=SADMIN&SWEExtData=
<?xml version="1.0" encoding="UTF-8"?>
<SiebelMessage MessageId="" MessageType=
"Integration Object" IntObjectName="Sample Service Request">
<ListOfSampleServiceRequest><ServiceRequest>
<SRNumber>SDC-100</SRNumber>
<CustomerRefNumber>4334d03c-323c-4787-8211-01ed033d3c3f
</CustomerRefNumber> <Organization>
Default Organization</Organization>
<Description> 
SIID: 4334d03c-323c-4787-8211-01ed033d3c3f
Description: Low disk space detectedIP: 
172.20.87.30;100.100.100.100User: adminPostToQueue:
1Status: Waiting</Description>
<Abstract>Low disk space detected</Abstract>
<ServiceRequestType>Internal</ServiceRequestType>
<Area>IT</Area><Sub-Area>Hardware Break
/Fix</Sub-Area> <Source>Web</Source>
<ContactCreated>06/09/2003 04:22:05 PM<
/ContactCreated> 
<ContactLastName>Doe</ContactLastName>
<ContactFirstName>John</ContactFirstName>
</ServiceRequest></ListOfSampleServiceRequest
></SiebelMessage>

This will insert a new account called “SDC-100” in the “All Service Requests across Organizations – HelpDesk” view.

The URL is the key for activating the SWE. It has multiple sections:

http://<Web_Server>/eai/start.swe?SWEExtSource=<SourceName>&SWEExtCmd=<Execute>&UserName=
<UserName>&Password=<Password>&SWEExtData=<Some_Data>

Create a New LOV

Type = SR_SOURCE

Display Value = Microsoft Operations Manager 2005

Invoke Service Example

The following script listing combines the background and setup information into a sample trouble-ticket creation.

Note: Some of the lines in the following code have been displayed on multiple lines for better readability.

‘-------------------------------------------------
----------------------------------------------------
-------------------------
' CHANGES TO BE MADE BELOW FOR APPROPRIATE SR NUMBER 
GENERATING
strSIShortID = SDCFindSIShortID( pGuid )
If  strSIShortID = "" Then
  strSIShortID = left( pGuid, 8 )
End If
strSRNum = "SDC-" & strSIShortID
‘--------------------------------------------------
-----------------------------------------------------
-----------------------
' CHANGES TO BE MADE BELOW FOR APPROPRIATE INTEGRATION 
IMPLEMENTATION
strEAIHTTPServer = "CHANGE ME"
strEAIMethod = "SiebelActivator"
strRefNum = pGuid
strDesc = pDetails
strAbstract = pDesc
' NOTE: the following subroutines are coded to be reused
in the following context.  
' They rely on the global variables to be set correctly 
outside before being invoked.
' They may also modify the global variables to be used 
later. 
 Sub SDCOpenTicket
‘---------------------------------------------------
------------------------------------------------------
---------------------
' CHANGES TO BE MADE BELOW FOR APPROPRIATE EAI CONFIG
AND DATA MAPPING
  strEAIURL = "http://" & strEAIHTTPServer & 
"/eai_enu/start.swe?SWEExtSource=" & strEAIMethod& _
            
"&SWEExtCmd=Execute&UserName=SADMIN&Password
=SADMIN&SWEExtData=" & _
            "<?xml version=""1.0"" 
            encoding=""UTF-8""?>"
            & _        
            "<SiebelMessage MessageId="""" 
MessageType=""Integration Object"" IntObjectName=
""Sample Service Request"">" & _
            "<ListOfSampleServiceRequest
            >" & _
            "<ServiceRequest>" & _
            "<SRNumber>" & strSRNum
            & "</SRNumber>" & _
            "<CustomerRefNumber>" &
            strRefNum & "</CustomerRefNumber
            >" & _
            "<Organization>
            Default Organization</Organization
            >" & _
            "<Description>" & 
            pAS_Description & "</Description
            >" & _
            "<Abstract>" & pAS_Title 
            & "</Abstract>" & _
            "<ServiceRequestType>Internal
            </ServiceRequestType>" & _
            "<Area>" & pSR_Area &
            "</Area>" & _
            "<Sub-Area>" & pSR_SubArea 
            & "</Sub-Area>" & _
            "<Source>" & pSR_Source 
            & "</Source>" & _
            "<ContactCreated>
            06/09/2003 04:22:05 PM</ContactCreated
            >" & _
            "<ContactId>1-5YQ1<
            /ContactId>" & _
            "</ServiceRequest>" & _
            "</ListOfSampleServiceRequest>
            " & _
            "</SiebelMessage>"
  LogMessage( strEAIURL & vbcrlf)
  SDCSendHTTPReq "POST", "", strEAIURL
  SDCStoreCTSTicket pGuid, strSRNum , SEARCHKEY_SIEBEL, 
CTSTYPE_SIEBEL, pStatus
End Sub
Sub SDCCloseTicket
' ***********************************************************
****************
' CHANGES TO BE MADE BELOW FOR APPROPRIATE EAI CONFIGURATION 
AND DATA MAPPING
' ***********************************************************
****************
  strEAIURL = "http://" & strEAIHTTPServer & 
"/eai_enu/start.swe?SWEExtSource=" & strEAIMethod & _
            "&SWEExtCmd=Execute&UserName=
SADMIN&Password=SADMIN&SWEExtData=" & _
            "<?xml version=""1.0"" encoding=
            ""UTF-8""?>"  & _
                
            "<SiebelMessage MessageId="""" 
MessageType=""Integration Object"" IntObjectName=
""Sample Service Request"">" & _
            "<ListOfSampleServiceRequest>
" & _
            "<ServiceRequest>" & _
            "<SRNumber>" & strSRNum 
            & "</SRNumber>" & _
            "<Organization>Default Organization
            </Organization>" & _
            "<Status>Closed</Status>"
            & _
            "</ServiceRequest>" & _
            "</ListOfSampleServiceRequest>
            " & _
            "</SiebelMessage>"
  LogMessage( strEAIURL & vbcrlf)
  SDCSendHTTPReq "POST", "", strEAIURL
End Sub
Dim pID
pID = SDCFindCTSTicket( pGuid, SEARCHKEY_SIEBEL, 
CTSTYPE_SIEBEL )
‘------------------------------------------------------
---------------------------------------------------------
---------------
' To open new service request
If pPostToQueue = POSTTOQUEUE_OPEN Then
  If pID = "" Then
    LogMessage( vbtab & "... submitting new 
service request #" & strSRNum & " 
into Siebel ..." & vbcrlf )
    SDCOpenTicket
  Else
    LogMessage( vbtab & "... no new submission 
is needed since the SI has already been submitted into 
Siebel as " & pID & " ..." & vbcrlf )
  End If
‘----------------------------------------------------
-------------------------------------------------------
-------------------
' To close the associated service request
ElseIf pPostToQueue = POSTTOQUEUE_CLOSE Then
  If pID = "" Then
    LogMessage( vbtab & "... submitting new ticket
first since the SI has not been submitted into Siebel yet
..." & vbcrlf )
    SDCOpenTicket
  End If
  LogMessage( vbtab & "... closing Siebel service 
request #" & strSRNum & " ..." & vbcrlf )
  SDCCloseTicket
End If
LogMessage( "Script Ends!" & vbcrlf )
]]></SCRIPT>

Develop Error Handling

Table 15 summarizes the error-handling conditions that are part of the autoticketing process.

Table 15. Error-Handling Conditions

If the TT system is down, the autoticketing workflow should consider this a failure event and pause the processing.

Similarly, if behaviors within the TT systems’ interfaces or MOM’s MCF indicate that the TT system is either down or not responding, this should be considered a failure. When this happens, the autoticketing workflow should create a Windows Event and send an automated e-mail message to a configurable alias. In addition, the entire workflow should pause for new requests. The autoticketing system will continue to attempt the failed method every 30-60 seconds until both the TT system and MOM/MCF are online.

Develop Thread Control

Autoticketing volumes should not exceed the capacity of the TT system. This is primarily a limitation based on the amount of time it takes most TT systems to create a ticket (or service request), which can be due to system capability, business-rule complexity and other external limitations. If the ticketing volume exceeds this number and a backlog occurs, it is recommended that the alerts be ticketed at a rate that is congruent to the performance of the workflow, such as one service request per three seconds, until the backlog is gone.

Thread Control Using Configurations

A distinct execution thread for the product connection cycles continuously over the life of the autoticket process. The autoticket thread represents a process to create a ticket and update the status of the alerts.

When writing an MCF or autoticketing system, the process thread should include the following configurable parameters:

Conduct Run-Time Monitoring

The third and final phase in establishing autoticketing is run-time monitoring. Autoticketing has been implemented and now needs to be monitored for its health. When operational, autoticketing is a function of the control process within the Service Monitoring and Control SMF.

The automation is triggered when an alert is received in MOM 2005 that matches specific autoticket criteria.  

At run time, all autoticket components should be checked, and error-handling events should be monitored. Figure 7 illustrates the interface components to this solution.

Figure 7. Interface components of autoticketing
See full-sized image

Top of page

Appendices

Appendix A: Resources

Overview of MOF and links to the SMFs, available at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfsmc.mspx 

Service Monitoring and Control SMF, available athttp://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfsmc.mspx

Appendix B: Key Performance Indicators

The following statistic should be reviewed to understand the performance of autoticketing as well as to identify opportunities for improvement. The value is mapped over predefined timeframes (such as daily, weekly, and monthly).

Actual Ticket Volume: ”AutoTicket” Alert. This is a key statistic that indicates performance of the filtering and business logic. The goal is to achieve a 1:1 ratio between alerts that qualify for autoticketing and those that successfully have a ticket created.

Top of page