In some cases it might be nice to provide a single application/service that supports multiple version of the InfoSystems webservices. In order to do that information about the version of the service is needed, the following describes what the version service is.
When hosting a shared service, sometimes a need arises to target multiple instance of the InfoSystems webservices. These services might not be the same version, and as such some features are possibly inaccessible in older version, or a behavior has changed.
Another common question during upgrade and debugging is
What version is this service?.
The IVersionService will help with those scenarios (and possibly others) by providing information about the current product version and the database version.
There are commonly two interesting version markers that you as an application developer might need to consider.
The DatabaseVersion which describes the current schema version of the database.
It usually also describes the "major" version of the installation, and changes here might indicate breaking API changes.
The ProductVersion specifies the marketing/product version including the patch version number for the web service installation.
In addition there are currently two extra version markers, one indicates the particular build version, another indicates the greatest client version that was ever connected to the database instance. These are likely never interessting in an integration scenario, but they are including for completeness.
For you convenience the version service is provided both as an HTTP resource using GET, and as an ordinary SOAP resource. Refer to the list of default endpoints Default Service Endpoints for the SOAP URL.
Getting version information using the HTTP method is straightforward. Just issue a GET request to the url http://installationroot/Version/GetVersion and you will get a result with the version information in it.
Normally the output content type should be auto-detected based on the request. However if you find yourself getting an XML response instead of JSON, or Vice Versa, then you can define the HTTP Accept header.