On This Page:

Invalid User Name
Interface
RealTime data updates
ServiceManager Server Error
ServiceManager fails to initialise - File Not Found or file permission errors
Selected Instance Misbehaves
Multi-Selection Control is no longer available or appears different on the LogOn page.
Break Names displayed incorrectly in Shift Override Dialog
Local Knowledge Page has empty drop down list

Usually, problems are first seen by the users of the system. These can often be diagnosed and solved by asking simple follow-up questions or doing basic analysis of log files. The following sections describe the most common issues, the questions to ask, and where to look for answers.

Invalid User Name

In order to allow a client to run ServiceManager, the system verifies that the user has permission to do so. ServiceOptimizer also validates the connection made by the client interfaces to the API. A user is passed through as part of the SOAP call. This user must be a valid ServiceOptimizer user. There are several questions that can be asked when a user reports this problem:

Has the user previously been able to use the system?
Are they entering the username in the correct case?

Generally, the problem can be solved by simply adding the user to ServiceOptimizer using ServiceManager. However, it is worth noting that if ServiceOptimizer has not been restarted for several days this problem can also be seen, as new users do not become 'active' without a restart. ServiceOptimizer should be restarted regularly.

Note: It is possible to set up the ServiceOptimizer username to be case sensitive (controlled by an Database sp083_system_parameters called glob_CI_validation_of_user_id) and therefore it is important that, when the user logs on, they use the same case with which their name was set up.

Updating Users

Updating of user details and creation of new users must always be done using the ServiceManager interface.

Whilst using SQL queries to check data in the database is OK, changes to the data must not, in general, be done in this way as there are several tables affected and it would be easy to get something wrong/miss something.

For ServiceManager there is a second level of validation for the user_id. They must be both a general ServiceOptimizer user and have permissions for ServiceManager. At the database level they must have the ‘enabled’ flag set in the database table Database sp085_users and have valid entries in the Database sp800_user_roles, Database sp803_auth_actual_parameters and Database sp088_user_units. This can be (and should be) verified through the ServiceManager user screens.

Interface

All systems that interface with ServiceOptimizer will use the standard APIs. The information that is passed through to ServiceOptimizer can be seen in the APIAgent log file.

Below examples assume that the SOAP trace is not switched on, as this is the default for a long-running system (as in BAU)

The following sections describe each of the commonly used interfaces and the details that are seen in the log file for each connection to the interface. At the correct level of tracing each interface will display the information that is passed through to ServiceOptimizer and the response that ServiceOptimizer gives back. In all cases it is important to get as much information as possible from the user about what action they were trying to perform, what time the problem occurred and what data they were sending (eg postcode/zipcode of job, job reference, engineer details, date).

Each API call can be identified in the APIAgent log file by a key word. This keyword may then be used in a search for all occurrences of that interface call. Because of the volumes of each call that can occur in a day it may be worth redirecting the search results to a file for further diagnosis. The following is the list of key words for the main interfaces

Keyword	Interfaces
Offer	OfferAppt	For each API Call the API call will appear at least twice in the log file. The first indicates the call incoming from the interface, the subsequent is the API Agent redirecting it to the relevant FRU process. The details for these two lines will be identical and should follow on from each other. The line where the information comes in will be identified by the word ‘APIAgent’ and the ‘<:’. The redirection to 1 or more FRUs will be shown by the FRU reference and then ‘>:’. The fields that follow the key word match the fields for the API in the same order as defined in the SERVICEPower API Specification. The other useful information about the API call is the date time stamp which is at the beginning of the line. If you want to know the results of the API call then you will need to look in the API Agent log file at the lines following and you should be able to see `+<Number>/n` The number will match the SERVICEPower API return code as described in the SERVICEPower API Functional Specification.
Book	BookAppt
Bookjob	BookJob
Cancel	Cancel
Job Status	ChangeJobStatus
Dispatch	DispatchInitEx, DispatchRequest, DispatchResult

RealTime data updates

A common complaint/comment from users is about updating information in SERVICEManager and it not appearing live in the system. Not all updates in SERVICEManager update the system. Some require a restart to take effect (and therefore will not be available until the next day). Although not exact, the easiest rule of thumb to apply is that if the change is to an operative then it should be real time. Any other data requires a restart. To help users to identify those operations that require a restart, a will appear next to the “Apply” button.

The Problem

In most cases any database incompatibility issues will be ungracefully notified to the user within their browser:

The Reason

ServiceManager fails because of incompatible changes between it and the ServiceScheduling database. In general it is not safe to run the ServiceManager application against a different version of ServiceOptimizer and the database. ServiceManager is notionally bound to a specific server data model that is the ServiceScheduling database schema.

The Resolution

Use the correct ServiceOptimizer and database version.

The Problem

Users with permission to modify users (within User Management) do not see all users. Specifically they do not see so-called "system accounts", such as the user defined as the API agent user, when displaying the list of ServiceScheduling users.

The Reason

System account users are specific to the internals of ServiceScheduling and should be set up once, by ServicePower personnel during installation. Modification of these users can result in unexpected ServiceScheduling behaviour. By default users of this type are not displayed within the User Summary Report.

The Resolution

To view system account users the following key-value pair must be added to the service_manager.properties file, and ServiceManager restarted: include.systemAccounts=true

There are a number of reasons why ServiceManager may fail to initialise, leading to the user seeing this screen. In order to ascertain the specific reason you need to review the ServiceManager console log. The following gives a description of some of the possible evidence and the reason and resolution for each.

The Problem

ServiceManager fails to initialise, possibly after a long time, with errors such as ‘File Not Found’ or file permission errors.

The Reason

As ServiceManager initialises it recursively copies files in its modules directory (where ServicePlanner, ServiceAnalytics or ServiceGantt modules are installed) to areas within the tomcat deployment, but if the directory specified contains files other than ServicePower files, e.g. the C:\ directory is specified, ServiceManager will attempt to copy all files within that directory structure. If any of those are system files, or files the user cannot access, or indeed the tomcat installation files themselves then the copy process will fail and the instance will fail to initialise.

The Resolution

Ensure that the setting within the service_manager.properties file is correct: modules.dir=<path to SP modules installation>

If no modules are installed then the setting may be removed completely from the properties file or may be left unset: modules.dir=

The Problem

Multiple ServiceManager instances have been deployed, apparently correctly, within a single Tomcat instance and the Java environment variable com.servicepower.servicemanager.propertiesFile has been removed. However the ServiceManager instance fails to start. Inspection of the console log shows:

SERVICEManager: setUpPropertiesFile - started
SERVICEManager: setUpPropertiesFile - using plug-in value:\sm_properties\service_manager.properties
SERVICEManager: **
ERROR ** setUpPropertiesFile could not access the file file:\sm_properties\service_manager.properties
java.lang.IllegalStateException: Could not access service_manager.properties file
        at
com.servicepower.servicemanager.ApplicationSetupPlugIn.setUpPropertiesFile(ApplicationSetupPlugIn.java:131)
        at
com.servicepower.servicemanager.ApplicationSetupPlugIn.init(ApplicationSetupPlugIn.java:365)

The Reason

The Java environment variable has been correctly removed however the applicationContext.xml file has not been modified appropriately.

The Resolution

Edit the applicationContext.xml file. To do this the new ServiceManager instance needs to be deployed into its expanded directory structure, by starting Tomcat. Once deployed, Tomcat should be terminated and the file

tomcat\webapps\<service manager instance>\WEB-INF\applicationContext.xml

should be edited to include the correct path to this ServiceManager instances properties directory. Once restarted the console log will display the following:

SERVICEManager: setUpPropertiesFile - started
SERVICEManager: setUpPropertiesFile - using plug-in value:
C:\SERVICEManager\sm_properties\service_manager.properties

The Problem

If ServiceManager has been defined to run in multi-instance selection mode then the instance selection file must be defined correctly. If ServiceManager has any problem processing this file then any attempted logon will fail.

The Reason

A review of the ServiceManager console log will display the fact that one (or more) instance definitions is incorrect:

...
- Failed to create SERVICEManager instance definition: name(SVM
Prod)url(htt://localhost:8080/SERVICEManager)desc(whoops
invalid URL)
...
SERVICEManager: init - ended: unsuccessfully

The Resolution

Review Install Guide 14.1 Configuring Instance Selection, taking care that the configuration files are correctly editted.

The Problem

Two instances of ServiceManager appear to be using the same properties file instead of the two unique files that have been configured.

The Reason

ServiceManager property file location is dictated by one of two settings, either via a Java environment variable, or via a change to an internal ServiceManager file: applicationContext.xml. Of these, the environment variable is the default, and master, setting. Regardless of modifications to the applicationContext.xml, if the Java environment variable (com.servicepower.servicemanager.propertiesFile) is set then it takes precedence and is used.

The Resolution

The start up parameters for the particular Tomcat instance need to be modified. This can be done either

via a direct edit to svmconf.bat to remove the property file reference followed by a re-registering of this Tomcat service OR
tomcat5w.exe may be used to edit the registry settings directly.

The Problem

The multi-instance selection control is displayed on the logon page and the user selects what they believe to be an appropriate instance. However upon entering their username/password combination either of the following unexpected events occurs:

The user logon fails
The browser displays the "page cannot be displayed" page.

The Reason

As described in 14.1 Configuring Instance Selection, the instance selection data needs to be set up correctly. User logon failures are likely to be to do with the instance selected not having the user's account set up correctly. If the browser renders "page cannot be displayed" then the likely cause is that specific instance of ServiceManager is not currently available.

0.1.1.2 The Resolution

Review 14.1 Configuring Instance Selection and:

ensure that the appropriate user accounts are available on each ServiceManager/ServiceOptimizer instance
ensure that the relevant ServiceManager/ServiceOptimizer instances are running.

The Problem

The browser brings up the logon page with the selection control is displayed and chooses a different ServiceManager instance to connect to. Upon completion of that interaction the user logs off and then attempts to logon again via the Logon Link. In doing so the logon page is displayed but the instance selection control is either no longer visible, or contains different instance data.

The Reason

The instance selection control is relatively basic in operation. It relies on the correct set up of both the service_manager.properties file and the instance selection XML file.

Each ServiceManager instance is configured separately to each other instance, so it is possible for each to be configured

to not present the multiple instance control, or
to present it, but with data specific to the instance the browser is connected to.

In the outlined problem, whilst the selection control is visible for the ServiceManager instance the user initially connected to (for example http://production:8080/SERVICEManager), the actual ServiceManager instance (for example http://test-install:8080/SERVICEManager) the user selected has either not been configured to present the control, or has been configured to use a different instance selection XML file.

The Resolution

Review 14.1 Configuring Instance Selection and determine the appropriate strategy.

For most cases, definition of a multiple instance "cluster" should have all ServiceManager instances configured to present the instance selection control and to use the same instance selection XML file.

The Problem

This problem only occurs for user who have started ServiceManager from within ServiceGANTT

When the user, who is using Internet Explorer, starts the Shift override dialog some of the break names are not displayed.

The Reason

Due to incompatibilities between ServiceManager and the latest versions of Internet Explorer intranet (not internet) sites display in the wrong mode, causing some text to be lost.

The Resolution

In IE go to Tools->Compatability View Settings . Make sure ‘Display internet sites in Comptaibility View’ is un-checked

The Problem

When the user selects Update Local Knowledge Defaults or Update Local Knowledge Pattern for a specific day, the dropdown copy control contains no data:

The Reason

This control is a convenience function and expects values to be entered within Database sp276_knowledge_set_names.

0.1.1.2 The Resolution

Insert one or more rows of data into Database sp276_knowledge_set_names. Entries should be of the form [<LK-mnemonic><LK-value>][<LK-mnemonic><LK-value>][<LK-mnemonic><LK-value>][<LK-mnemonic><LK-value>], when LK-mnemonic can be any of the mnemonics VGAP (specified in order) and LK-value is some ascending value of minutes.

For example: V30G60A90P120 and V60P250.

Browser not supported