Browse Prior Art Database

Hash Code Filtering of Network Management Event Data

IP.com Disclosure Number: IPCOM000201848D
Publication Date: 2010-Nov-26
Document File: 2 page(s) / 39K

Publishing Venue

The IP.com Prior Art Database

Abstract

This disclosure outlines a method of filtering out redundant information, to reduce the amount of ticket information forwarded by a gateway system from a network management system and to an external ticketing system. Such filtering reduces the cost of resynchronising ticket data, as well as reducing bandwidth needs and ticket system processing requirements.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 01 of 2

Hash Code Filtering of Network Management Event Data

In an automated ticketing environment the network management system can be used to send ticketing requests to a target customer relationship management system(CRM). These ticket requests can take the form of ticket creates or updates and are generated by transforming the network management event data into ticketing requests. For example a server down network event could create a server down CRM ticket.

    A common problem is that sending duplicate updates can cause performance issues on the target CRM system without providing any new information about the problem. This can happen when event information is repeatedly being sent to the network management system. This can cause the customer major issues with handling automated tickets and bring the CRM system to halt due to performance constraints in the CRM. It also adds no value to the customer when the update contains no new information.

It might be possible to use a scripting approach in order to weed out the repeated updates by cross checking a local cache of data sent to the CRM system - however this is cumbersome and not very usable - as it requires increased disk space usage and more maintenance overhead for the customer. Especially when the customer

wants to add a new field to send to the target CRM system

                                        . In a scripting based approach the customer would need to keep a persistent cache of all the columns that are sent to the CRM system. So if we added or removed columns we would need to update the persistent cache schema, as well as updating the logic of the script. These steps are not required if hash filtering is used. Also because a script based approach needs a persistent cache it requires more disk space then the hash filtering method.

    The idea is to maintain the hash result of the last update event data that was sent to the CRM system for a particular event. Any subsequent updates have their hash calculation cross checked with the recorded value - if it is different the update is forwarded to the CRM system by the network management system - otherwise it is discarded.

The advantage is that if a new field is added to the event data that needs to be sent to the CRM sys...