What is a ServiceOptimizer instance?

Processes

The ServiceOptimizer instance consists of a number of separate processes, all of which work together in conjunction with a central database. There are also a number of scripts and utilities provided that may be used, in conjunction with the O/S facilities, to manage the starting, stopping and general maintenance of the system.

A ServiceOptimizer instance may be run either on a single server, or on multiple servers (distributed). In either case, the database may run on (one of) the same server(s) as the instance, or a separate server.

Where the database instance is run on a separate server from any of the servers running ServiceOptimizer, there is no requirement that the database server be running the same operating system as the operating system running on the ServiceOptimizer server(s). Where ServiceOptimizer is distributed, the machines running ServiceOptimizer components should all be running the same Operating System.

The actual configuration of the system, in terms of which processes run, and on which server, is configured in the database - see Setting Up a new Instance. This section also includes an example set up for clarification purposes.

A non-distributed ServiceOptimizer instance consists of API Agent, Gantt Router and FRU processes with a System Monitor process which acts as a controller and coordinator for these processes. All these processes run on the same host computer.

In a distributed ServiceOptimizer instance, the API Agent, Gantt Router and FRU processes are grouped in nodes. Each node in a ServiceOptimizer instance runs on a different computer. Each node has one System Monitor process running on it. One System Monitor process is designated in the database as being the Master System Monitor and is in overall control of the ServiceOptimizer instance. Other System Monitor processes then become Slave System Monitors which carry out actions on behalf of the Master System Monitor. The Master System Monitor and Slave System Monitor are the same executable ( spsysmon(.exe)) and are run with the same command line.

The allocation of ServiceOptimizer components to nodes is (again) configured in the database. This determines the distribution of processes within the ServiceOptimizer instance and cannot be changed at runtime. Further information on distributed ServiceOptimizer instances can be found in Setting Up a new Instance

A data management application, ServiceManager, may be configured to run against the database/instance. Using this, one can set up many of the requirements for system configuration - thereby setting values in the database that are subsequently used when the instance is started. It is, however, necessary to set up some configuration manually, using SQL, prior to starting the instance. It will therefore be necessary for the DBA to work with the business users of the system to determine how this configuration needs to be done.

As mentioned above, the single server process, the master spsysmon, starts up the system. All remaining server processes are started via this process, using data configured in the database. These processes also have auto-restart facilities such that, should they fail, no manual intervention is required to a large degree.

Despite this, there are day to day administration activities required, which are covered in more detail in Business as Usual. There will also be occasions when the system fails, or errors occur that need to be followed up on. Admin ServiceOptimizer Handling Errors and Support Issues covers more detail on how to diagnose and report such issues.

Travel Matrices

A single running instance of ServiceOptimizer may use a single travel matrix or multiple travel matrices (one for each FRU). If a single travel matrix is to be used it is identified via the travel_matrix parameter in sp083_system_parameters. Multiple travel matrices are identified by having one entry for each FRU in sp213_scheduler_parameters of the parameter travel_matrix.

Travel matrices can be located anywhere on the network although, in practice, performance considerations means it’s much more efficient for them to be located locally on the same host as the FRU Processes that are using the travel matrix. Typically, in a distributed ServiceOptimizer instance, it is advantageous for all nodes to be configured identically (in terms of software and hardware on the machine). In this case each node can be loaded with all the travel matrices, even though not all (or indeed any) of them might be used on any given host.

Some further background is given in Admin ServiceOptimizer System Configuration Travel Time Estimates. The processes for managing and upgrading Travel Matrices are documented elsewhere.

About this Guide

This guide takes you through the life cycle of a ServiceOptimizer Instance, from Setting Up a new Instance through Business as Usual to Handling Errors and Support Issues. Each of these sections references the Further Detail sections and, if you are a practiced administrator of the instance, you may find the index of detailed items in Admin ServiceOptimizer Further Detail easier to use to navigate yourself to the information you require. However, it is wise to comeback to the basics every now and again. Setting Up a new Instance may also be used when you are upgrading your system, to ensure the upgrade is fit for purpose.

If there are any issues, or omissions, within the guide, please use Admin ServicePower Support to let us know.

Browser not supported