Admin ServiceOptimizer New Instance Set Up
On This Page:
- Start/Stop Mechanisms
- Database Instance
- User Access
- Environment Resources
- Configuring your System
- Setting up for BAU
Related Pages:
- ServiceOptimizer Install Guide
- Admin ServiceOptimizer Further Detail Scripts and Utilities
- Admin ServiceOptimizer Further Detail Loading Bulk Data
- Admin ServiceOptimizer Business as Usual Planned Restart of Components
- Admin ServiceOptimizer Further Detail Core Processes
- Admin ServiceOptimizer Further Detail Resources
- Admin ServiceOptimizer Further Detail Access Control
- Admin ServiceOptimizer Further Detail Environment Variables
- Admin ServiceOptimizer System Configuration
Having installed and tested ServiceOptimizer (see the ServiceOptimizer Install Guide) you are now ready to set up your Instance for day to day running.
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>]]
]
dbPassword
is also used to authenticate the database password supplied by an SP client (such as ServiceManager or ServiceGANTT).dbHost
is environment specific (specified for example by LOCAL
or TWO_TASK
environment variables).dbInstance
is only required if you are connecting to a named instance.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.