Menu
Home
About Us
News
Products
Contact Us
Resources
Login

GEMS Overview
Installed Base
Event / Call Logging
Event Updating
Open Event Monitor
Escalation Module
Technical Aspects

Global Event Management System - (GEMS)

Microbit is the developer of GEMS, which is an application used for managing processes that are status and event driven.

Following is just a small list of environments where GEMS could be used:

Call logging
Any process requiring SLA management
On-site / Bring-In maintenance
Asset management
Device and network monitoring using SNMP
Log monitoring

CS Holdings case study...


Overview

GEMS - Global Event Management Systemฎ

Built on more than 17 years practical service management experience, GEMS is one of the first and leading solutions developed for managing an information technology services environment.. The system was developed with the specific integrities of the information technology services environment in mind and not as a general retail package.

1. Historic overview

1989 - 1993

• Initial development
• Used to manage a small IT section
• DOS based
• Shared database concept
• Programming language used is mainly C with many of assembler routines

1993 - 1995

• Development of TechniCall as a broader and more comprehensive service management application
• Developed for exclusive use by Technicare (Pty) Ltd. and its customers
• Switched to client server design using IPX protocol
• Server module developed to run on Windows NT 3.51
• Clients still DOS based

1995 - 1999

• Switched to using the TCP/IP protocol
• Added Repair Centre module
• Major changes were incorporated for customers that wanted visibility and access to their service activities in real time.
• The client was converted from a DOS based application into a Windows based application.
• Security and a higher level of access control in the client and server applications were added which allowed for unsupervised usage at customer locations.
• A replication module was also added enabling functionality that allow for data to be replicated onto a SQL Server. The primary reason was so that the reporting functionality could be moved to SQL servers for flexibility and customer freedom.
• The application was re-branded as TEMS (Technical Event Management System)

1999 - 2005

This period marked the consolidation of existing and new applications and modules into one integrated application branded as GEMS (Global event management System)
• CS It Solutions a division of CS Holdings procured GEMS on an exclusive use basis (it was a strategic decision and seen as a competitive advantage)
• Customers of CS IT Solutions were also allowed to use the system.
• GEMS played a big part in ensuring streamlined business processes and the real time management thereof..
• The majority of modules added during this period were interfaces to enable GEMS to integrate with customer systems.
• Other minor changes were also made such as to enable GEMS to be compliant with Cisco Gold Partner requirements etc.

2. Modules

• GEMS Server

The GEMS Server is the point of integration for most of the modules. It manages the built-in database with which most of the modules interacts. It is not merely a DBMS, but it is in reality an application server with an internal database.

• GEMS Client

This forms the key module that enables user interaction with GEMS. The key functions provided are:
◊ Call / Event management
(Logging, updating. Routing, closing etc.)
◊ Installed Base management
◊ Visibility / monitoring
GEMS provide access control at a granular level and it's thus possible to limit users in almost every major aspect of above.

• SQL Replication module

This replicates data from the GEMS Server to a SQL based DBMS. This design allows for:
• immediate on-line and real-time data backup
• by moving ad-hoc queries and reporting to run of the backup DBMS key frontline operations will not be affected by long running queries.

• Status e-mail escalations

E-Mails can be triggered according to various criteria configurable via templates. It can be sent instantaneous or configured to be sent after a specified delay. As an example it can be setup to sent a mail to two customer engineers (CE) when a new matching call is logged, then again to the CE’s and the supervisor after 60 minutes of no activity took place, following no further activity after 2 hours a mail is send to the parties involved and the customer manager etc.

• SLA e-mail escalations

This module function in a similar fashion as with status e-mail escalations with the major difference being that activities are triggered by SLA calculations and not by status changes or status time measurements.

• Search word e-mails

This allows for general e-mails to be sent according to word or regular expression based matches found in events as they are logged or updated. Although very simplistic this can be an extremely powerful tool used to monitor events.

• Knowledge Base

Parts of this module can function completely independent of the key GEMS components. Separated it consists of the server which includes a DBMS, a windows client for performing administration, querying and other editorial functions. The data can also be replicated to more than one GEMS Knowledge Base server or via ODBC to another DBMS should it become necessary to balance the load between servers.
It is a simplistic process to develop custom web or other types of front ends should the need arise.

• SMTP Interface

This functionality allows for standardized e-mails linking two or more systems. Calls can be logged, updated and information can be mailed using this interface. Mails can be received directly through the built in SMTP server or they can be intermittently retrieved using the POP3 protocol.
The parser ? developed for extracting information from received mails is extremely efficient and error resilient.
Experience has shown that using some of the biggest groupware and mail server products can quickly become a bottleneck and interface killer.
Being a completely in-house developed SMTP server and client, this provides a robust mail infrastructure which is a must when measured using customer systems.

• FTP interface

This interface allows for interfacing using text based files.. It can perform the same functions as the SMTP interface and also allows for simple directory transfers (file copying) instead of FTP based transfers.

• SNMP Interface

An interface for allowing SNMP enabled devices to automatically log calls / events on GEMS. For example when a customer's WAN links go down a call can automatically be logged on GEMS. The call could also be populated with predetermined detail in order to try and eliminate user intervention.

• Log monitor

An interface for monitoring logged files or event databases allowing call logging to GEMS according to specified rules. In this way the GEMS server can be seen as fulfilling a similar function than a syslog daemon ? with the addition of many advanced features.
It can also be setup to accept data from any device capable of sending data to a syslog server.

• HTML monitor

This module is similar to the log monitor with the exception that web pages can be monitored.
Another advantage of this module is the ability to log or update events from page detail in cases where the customer does not want to allow interface connectivity..

• DB monitor

This module provides access to a customer's DBMS via ODBC in order to transfer event detail back and forth.

• GSM module

The GSM module interface to a cellular modem or phone in order to send and receive SMS messages. It can be used in conjunction with other modules in order to facilitate SMS notifications of new calls or updates, etc.
It can also be used for logging, updating and closing of calls by sending SMS messages to it to the GSM module, or it could simply be used to enquire about call details.

• GEMS Timecast module

This module consists of both a server and client module with both installable as services on Windows NT based computers. It is used to ensure that client times are synchronized with the server. It functions similar to the Windows Time service functionality with the exception that the server uses multicast packets to broadcast it's time, which the clients then adjust to.

3. Technology

● Platform

• GEMS Server
◊ Windows NT Server based service or GUI application
◊ Multi Threaded
• GEMS Client
◊ Windows based GUI application
◊ Multi Threaded
• Status and SLA email escalation modules
◊ Windows based service or GUI application
◊ Multi Threaded
• SQL replication module
◊ Windows based service or GUI application
◊ Multi Threaded
◊ ODBC connection to DBMS
◊ DBMS must support Stored Procedures
• Other modules
◊ Windows based service or console applications
◊ Multi Threaded

● Design

◊ Networking
For most of the modules the underlying protocol used is TCP/IP. In most cases data is compressed before being put on the wire, which has a significant improvement over relying purely on routers etc. with built-in compression, this is especially true in WAN environments.

◊ SQL Replication module
● Separate process
● can run from any computer
● Use ODBC, thus not limiting to a single SQL DBMS vendor.
● can perform calculations for custom fields required on the SQL DBMS.

◊ E-mail escalation modules
● Built-in mail user agent
● can have 676 levels
(Each level represents a status matching specified criteria for which a bunch of steps would be performed. The levels are executed in order as they match the criteria specified.)
● 676 steps per level
(Each step representing a recipient to be mailed according to criteria specified for that recipient. Each step also can have its own message text, i.e. each recipient can receive a unique message.)

◊ Interface modules
● FTP
● can perform FTP get, put, local file retrieval and local file drop operations
● Sole purpose is to move files around, transferring over unstable environments doesn't influence other processes
● a separate process takes responsibility of acting on file contents.
● SMTP
● Mail interface modules have robust and fast built-in servers implementing the SMTP protocol
● also supports the POP3 protocol for retrievals from other mail stores like Microsoft Exchange etc.
● can process multiple connections at the same time
● Messages can be stored in mail directories or in a database
● the number of modules running per computer is only limited by practical limits such as available memory, disk space etc.
● SNMP
● It is a separate process and can thus be implemented anywhere on the network
● alert triggering is based on full text search criteria
● MIB / OID information doesn't have to be available
● HTML
● it is a separate process and can be implemented anywhere on the network or on a web server itself
● Allows for full text search regular expressions based triggering
● Log monitor
● It is a separate process and can be implemented anywhere on the network
● Allows for full text search regular expressions based triggering

◊ Reporting
● Standard reports are available
● running of separate SQL based DBMS ?
● Any report writer than can query the SQL DBMS can be used for creating reports
● Custom pre-calculated fields can be added for specific reports.

● Database

◊ Built-in - primary function is information storage
◊ SQL DBMS - used for live backup storage, reporting etc.

● Security

The primary focus for security in GEMS is the accessibility of data and functions provided via the client. In short what this means is that users of the GEMS client can be locked down based on their role in the organization, or in the case of multiple customers, locked down just to the level of information or functionality required per customer.

4. Advantages
◊ Customers

● GEMS can in most cases be easily changed to accommodate customer' requirements .

◊ Business

● In today's business environment it is necessary to continually seek to enhance and improve business processes to increase service delivery to the customer. GEMS your chances of these reword

● GEMS is aligned using a factual pattern that repeats itself over and over. This means that simplicity and ease of implementation form the basis of the technology used.

● Experience has shown that by being the hub with various customers interfacing, it is ideal not to be reliant on a standard retail package. All customer regiments are different and as the customers embrace the use of the system these requirements change insisting quick system changes in a structured manner..

● GEMS flexibility caters for most requirements in the service / Event management environment which includes management of:
Availability Facilities
Capacity Planning Incidents
Change Control Networks
Configuration Projects
Customer Care Security
and more…

◊ Cost

● By using GEMS costs will be managed down. This is not always visible e.g. GEMS was developed with bandwidth efficiencies in mind. WAN costs can quickly grow to a significant cost if a non optimized system is used.

◊ Stability

● Being developed in C not only makes the front and back end functionality fast, but also provide stable code which is not always possible if applications is used that was developed using high level languages based on multiple layers of components and libraries from third parties.

◊ Performance

● Most of the modules can run on separate servers and not necessarily from the same database or the same GEMS server. This design creates numerous advantages in a high volume environment that are rarely seen at this cost.
● Most interface and monitoring modules can be built with their entire trigger and monitor criteria built into the remote process, This allows for enormous bandwidth savings when monitoring remote devices over a WAN.

◊ Flexibility

● Very few retail systems allow you to practice Service Performance Management (SPM) to a level closely matching the customer's environment, GEMS achieves this in various ways such as ?.

● With most functionality developed in-house and not depending on third parties for development and components, GEMS provide the flexibility necessary to manage customer events according to their requirements and not according to system capabilities or limitations.

◊ Platform independence

● Migration to future platforms is easy due to the development language, minimal dependence on third parties and by following official and industry standards with regard to protocols implemented and software bindings utilized.

● CAPACITY

Number of status sets that can be active

If ease of reading underlying IDs are required the practical limit is 676, otherwise it's 64,516

Number of statuses per set

Limited to the number of unique descriptions that can fit into a 20 byte field

Installed Base items (Serial Numbers)

4,294,967,296

Bill Of Material (BOM) items

4,294,967,296

Unique call numbers
6,760,000 per year if using a 6 character call number. This is configurable to virtually unlimited though it should ideally be pre- determined to avoid different call number formats and be as small as possible for customer convenience.

Service Level Agreement (SLA) measurement types
Response Time
Downtime
Next Business Day (NBD)
Turn Around Time (TAT)
All assignable per Serial Number (SN) with the maximum daily clock period determined by a Service Schedule also assignable per SN

Service Level Agreement (SLA) measurements.
999999 minutes per SLA type, amounting to close to 2 years of counting when the clock is running 24/7, with a work day of 8 hours it's almost 6 years.

Status effects possible on the SLA clocks (Separately assignable for Response and Downtime and per status)

Start clock
Stop clock
Start clock, cannot be stopped again
Stop clock, overriding above state
Stop clock, cannot be started again
Start clock, overriding above state
Reset already measured time to zero
Start clock, overriding any previous state
Stop clock, overriding any previous state
Carry over previous clock state

Other status functions possible
Log call
Close call
Close call, but keep open for administration purposes, i.e. close repair part of call
Cancel call
Log and Close call
Log a linked call
Automatically log a new call pre-determined by user defined template

Repeat call counter

Measurable within a minimum of 1 day and a maximum of 999 day period

Completely logged status changes per call
1000 - Every status change can copy all call details into a new sub event / record which is a copy of the previous record updated with the changes or additions. These provide for a complete and easily end user viewable call history and since only the last sub event is updatable after every new record added, it also provides for a reliable audit trail.

E-mail interface source data size stored for easy visibility

5KB of data with relevance (strange / unreadable characters removed)


◊ Case Study: CS Holdings

● Peak GEMS usage statistics:
• 25 000+ record inserts / updates per day
• 6 interfaces running concurrent (who?)
▪ 2 e-mail based (SMTP)
Linking a remote HEAT system
Linking a remote Remedy ARS system
(Both having multiple mail formats with updates going both ways)
▪ 1 FTP / HTTP combination
▪ 3 FTP based using the following designs:
Monitor remote FTP / fetch / drop local
Monitor local folder / fetch / action
Drop into remote via FTP
• Max interface e-mails received per day: 2 800+
• Max open calls reached: 11 000+
• GEMS built-in database size reached (active data): 12+ GB
• Installed Base unique serial numbers: 1.2 million
• BOM: 550 000+

● Uptime
• During the period in use at CS Holdings only two crashes were experienced, one due to a disk failure (Windows NT 4.0 SP 1) and one due to a problematic Windows Service Pack supplied by Microsoft (Windows NT 4.0 SP 4)

◊ Implementation

Implementation is mostly dependent on specific requirements, though a limited 'quick and dirty' installation can be accomplished within one day.

◊ Business continuity

In order to allow for zero business risk the following safe guards are suggested:
• Source code ownership under certain circumstances
• Source code escrow with business accesability based rules
 

◊ Training

Sugested training:
• Super user training
If the customer requires, designated people can be trained / made more familiar with how GEMS works and the technical aspects related to GEMS and all of it's modules

• General client usage
This is training mostly directed towards the general front-end usage of the GEMS client and can almost be seen as a typical Office application course. In most cases this is not necessary where users are already familiar with Windows

• Business usage
This is training that would go hand in hand with the customer's own customer managers or people responsible for service and support and would in most cases be held in functional groups covering customer or support specific scenarios.

Most of the training can actually only be done once identification and setup of business processes are completed or well underway.

GEMS
Open Event Monitor
GEMS Open Event Monitor
Per serial number help
GEMS Modules
Modules
GEMS Modules
more...

www.cpdanywhere.co.za - Continuing Professional Development (CPD) activities online>