Architecture

Overview

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

...

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) 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’).

...