On This Page:

ServiceScheduling 9.3.2.1 has resolved an issue with failing to ensure that un-earmark dispatch notifications are sent (when appropriate) when earmarked jobs are de-allocated or earmarked standard activities are deleted via ServiceOptimizer API calls. ServiceScheduling 9.3.2.0 has resolved an issue with failing to ensure that un-earmark dispatch notifications are sent (when appropriate) when earmarked jobs are de-allocated or earmarked standard activities are deleted via the Gantt.

Users upgrading from previous versions of ServiceScheduling should be aware that, as a result of previously incorrect functionality in these areas, their integration with ServiceScheduling may not handle all possible un-earmark dispatch notification messages. ServicePower recommends that users test their handling of un-earmark dispatch notification messages before upgrading in production.

ServiceScheduling 9.3.2.0 has resolved an issue with the Get Job SOAP API not correctly enforcing the mandatory login information.

Users with systems that integrate to ServiceScheduling using the Get Job SOAP API who are incorrectly calling the API without login information must update their integration before upgrading, to ensure that they are correctly calling the API to specify mandatory login details.

ServiceScheduling 9.3.2.0 has resolved an issue with FRUs crashing when the Request Appointments SOAP API was called with invalid start and end dates for long jobs.

As part of the work necessary to resolve this issue, the functionality of the Request Appointments SOAP API was corrected to meet the original specification of the API - namely, the API ensures that all parts of a split job offer fall within the inclusive date and time range between which appointments were requested.

It is possible that some customers have integrated with the API in a way that depends on the previously incorrect functionality, where only the first part of a split job was guaranteed to be within the inclusive date and time range between which appointments were requested (and so, subsequent parts may have been outside the inclusive date and time range between which appointments were requested).

Users with systems that integrate to ServiceScheduling using the Request Appointments SOAP API who are incorrectly requesting long job appointments by only specifying the inclusive date and time range for which they want the initial part to take place in must update their integration before upgrading, to ensure that they are correctly calling the API to specify the inclusive date and time range in which the entire long job is to be performed.

ServiceScheduling 9.3.2.0 has updated the database driver used for Oracle database connections. As a result, for users running ServiceScheduling against an Oracle 12c database, it is no longer necessary for the Oracle database installation's sqlnet.ora file to contain the SQLNET.ALLOWED_LOGON_VERSION=8 setting.

Users running the Oracle 12c database must remove this setting from their Oracle database's sqlnet.ora file and restart Oracle immediately prior to upgrading to ServiceScheduling 9.3.2.0.

The sqlnet.ora can be found in a directory of the form similar to C:\oracle\product\12.1.0\dbhome_1\network\admin\sqlnet.ora, depending on the Oracle installation directory.