User Reported Problems
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
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 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 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 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 Configuring Instance Selection and determine the appropriate strategy.
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
.