This page provides an overview of the architecture of the ServiceOptimizer SOAP APIs.

Architecture

Overview

To enable interworking with other systems, ServiceOptimizer provides several groups of SOAP APIs to allow:

Job creation and cancelling through the ServiceOptimizer Appointments Booking Server;
Job updates including status changes, force fixing, priority and call confirm;
an interface into the ServiceOptimizer Appointments Booking Server (ABS), which allows appointments and SLA jobs to be requested, booked, cancelled and updated;
interfaces out of ServiceOptimizer so that other systems can get job details or be notified when any of a particular set of jobs’ attributes has changed;
new employees (aka operatives and crews) to be added, and existing employee’s details to be updated;
standard activities (sickness, holidays etc) to be created and updated;
new skills to be defined;
updates to an employee’s travel status;
the Optimizer to be started and stopped;
an interface out of ServiceOptimizer so that other systems can be notified when jobs have been earmarked (or re-earmarked or unearmarked) by ServiceOptimizer and are ready for dispatch; and
an interface out of ServiceOptimizer so that other systems can be notified of all jobs which are in jeopardy (unresourced, late etc).

All of these interfaces to ServiceOptimizer are implemented in a client library or as a web service that’s linked into client applications or both. The client applications and the ServiceOptimizer server are therefore always in different processes, even when they are running on the same host.

The schematic diagram below shows those parts of ServiceOptimizer which are important for integration, and where user code must be written to make use of them:

The client code connects to the ServiceOptimizer application over a http connection.

Before using any of the functional calls defined in §6 onwards, a single call to LoginRequest (§5.1) may need to be made to connect the client application program to the ServiceOptimizer server. The database username and password for the service are passed as parameters to this call. When it’s no longer needed, the client must close the connection with a call to spQuit (§5.2).

Incoming SOAP Calls

The incoming SOAP calls (see Product Overview and Architecture#Overview) follow a simple request/response pattern. The caller requests a particular action or set of data and the response to it is returned synchronously.

The Dispatch Interface

After initialising the connection to ServiceOptimizer, the client application makes a call to the initialisation function DispInitRequest.

The client program then makes requests to and receives responses back from ServiceOptimizer in a similar manner to how it’s used for the incoming SOAP calls (see §7.2 above), except that dispatching each job takes two function calls to complete: a call to ‘Dispatch Request’ to get the details of the job to be dispatched next, and then a call to ‘Dispatch Result’ to tell ServiceOptimizer whether the dispatch was successful or not. Between these two calls, the client application should process the information that it has been sent so that it then knows whether to return success or not in the subsequent call to ‘Dispatch Result’. From the point of view of the client application, the function DispRequest normally blocks until there is a job ready for dispatch (unless it’s being used in ‘batch mode’).

The SOAP implementation of the dispatch interface is limited to 100 requests. After 100 requests a client will be required to log back in to receive any further dispatch messages.

Browser not supported