On This Page:

Start/Stop Mechanisms
Database Instance
User Access
Environment Resources
Configuring your System
Setting up for BAU

Related Pages:

Having installed and tested ServiceOptimizer (see the ServiceOptimizer Install Guide) you are now ready to set up your Instance for day to day running.

It is recommended that you read through the whole of the following section before following up on any of the individual set up processes required.

The following must be considered:

Start/Stop Mechanisms

How should the instance be started and stopped?

Presumably some form of automation would be ideal for a production system, but test and development systems may be required to be manually started/stopped to give more immediate control. A number of Admin ServiceOptimizer Further Detail Scripts and Utilities are provided with the installation to help to automate these processes.

Also, whenever the instance is upgraded to a newer version of code the entire instance must be shut down.

The instance cannot start without a running database instance, so ensure any Start/Stop automation takes this into account.

Database Instance

Is the database business ready?

In general, for a brand new Instance, the ServicePower consultancy team will have provided an initialized database for use within your business. There may need to be additional Admin ServiceOptimizer System Configuration within the database before the instance is fully configured - this can be done in one of 2 ways:

Manual updates via SQL (see Admin ServiceOptimizer Further Detail Loading Bulk Data)
Updates through the ServiceManager application.

Either way, these updates will need to be made in conjunction with the business.

When a new version of the product is released, there may be further changes required in order to configure new functionality. Any such requirements will be mentioned in the Changes from Previous Issues section of this Guide.

All client Users of the Instance need to be set up in the Database. See User Access for further detail on this.

There must be connectivity available to the database server for all components and appropriate Environment Variables set up.

All ServiceOptimizer processes require the database connection details to be supplied on the command line, in one of the following forms:

   [ <dbUser>/<dbPassword>[@<dbHost>]                                 ] |

   [ORACLE:<dbHost>:<dbUser>:<dbPassword>                             ] |

   [MSSQL:<dbServer>[\<dbInstance>]:<dbName>:[<dbUser>]:[<dbPassword>]]

The first and second variants are Oracle only; the third is MS SQL Server only.
If there is no password configured in the SP database then the dbPassword is also used to authenticate the database password supplied by an SP client (such as ServiceManager or ServiceGANTT).
Default Oracle dbHost is environment specific (specified for example by LOCAL or TWO_TASK environment variables).
The MS SQL Server dbInstance is only required if you are connecting to a named instance.
If MS SQL Server dbUser is not specified, the connection to MS SQL Server will be made as the trusted user (i.e. the operating system user). dbPassword is then not used to authenticate the ServiceScheduling connection to the database.

User Access

Are your users set up to have appropriate access to the Instance?

All access to ServiceOptimizer, via client applications, or via APIs, is subject to authentication and permission control. This is discussed in detail in Admin ServiceOptimizer Further Detail Access Control. It is important to remember that this control may need to be different for different types of Instance, such as Production-v-Development, so where database instances are being shared it may be necessary to ensure the database tables supporting this process are appropriately managed.

Environment Resources

Does you server have enough resources to run this Instance?

Admin ServiceOptimizer Further Detail Resources discusses the various environmental resources required by a running ServiceOptimizer Instance. It is important to reassess these requirements regularly and specifically when:

A new version of the product is installed
The business makes a change in business usage of the Instance

The resource requirements may differ between the Production Instance and the Test/Development Instances, but it should be noted that the resource requirements heavily affect the performance of the Instance.

Warning

Ensure there is a System test of a Production equivalent environment, from a resource perspective, prior to putting a new installation into production.

Configuring your System

What are the processes I would expect to see in my running system and how do I configure them?

ServiceOptimizer consists of a number of Admin ServiceOptimizer Further Detail Core Processes. As seen, in Start/Stop Mechanisms above, in the main the system is driven by just the single process spsysmon, however the database needs to be configured for how these other processes are to be run; this is covered in the Admin ServiceOptimizer System Configuration documentation.

Setting up for Business As Usual (BAU)

When should regular restarts occur? How should this be managed?

Once everything is set up and you are ready to start the system for BAU, you need to give some thought as to how the system is to be managed on an on going basis. It is the case that each component of the system must be restarted on a regular basis, and the fru components particularly must be restarted daily. Planned restart of Components covers the reasons why this is necessary, and how it can be achieved.

Browser not supported