Welcome to the XML SOAP Web Services documentation

Communication - Most of the functionality provided by Forsta Plus web services are based on complex data types used as parameters and return values. These complex data types are defined server side as complex class models. When the server is sending these data types to the client the objects are serialized into XML and transmitted across the web. The client receiving the XML can either manipulate the XML directly or deserialize it into proxy objects if the envirronment supports it. Visual Studio .NET has support for creating proxy objects on the client side and is used in the examples in this documentation.

Collections - Only limited datatypes are supported by the web services. This has an impact when using complex datatypes in parameters and returnvalues. All types of collections are simple static arrays when transported as XML between the client and server. Static arrays are not very easy to manipulate and thus it can be an advantage to include standard functions for conversion between static arrays and dynamic arrays (for instance ArrayList and Hashtable) as part of the client envirronment.

Functionality - When an object is serialized only the data is included. Even though an object has functions and helpful constructors on the server side this functionality is not reflected or implemented in the client proxy object. In this documentation help classes are used as wrapper classes for the deserialized objects and support useful constructors. Besides default values of the objects serverside are not reflected automatically in the auto generated proxy objects. Thus it is highly recommended to use the utility classes whenever a new instance of an object is to be created. The utility classes both support useful constructors and make sure that the default values of the classes are used. Please note that the utility classes in this documentation are updated compared to previous versions of this documentation. See below for changes introduced in Forsta Plus 8.0 Server Release webservices.

Changed Names - Some property names have been altered by the webservice due to their nature. Examples are LanguageString, AnswerText and GridAnswerText. Although one property in all these classes is called 'Text' all you will see in the intellisense on the client is 'Value'. 'Value' is the right property to use when using web service. Other properties sometimes are changed from a useful name to Item, Item1, Item2…​ See documentation of the specific objects for further information.

Web service context - Note that each web service (Reporting,SurveyData,SurveyDeployer,…​) has its own context. Same members of different web services cannot be directly interchanged. In particular the webservices 'Reporting' and 'SurveyData' have a lot of members in common. It is for instance not possible to mix the classes [reportingwebservice].QueryForm and [Surveydatawebservice].QueryForm even though the class QueryForm that they both are based on is the same on the server.

Log On - In order to call any functionality in the API the user has to log on by use of the LogOn web service. The user gets a key that is used every time a function is called. The functions in the web services use access control based on the account used when logging on to the web services.

Performance - It is important that the web services are used with caution for performance reasons. The basic rule is that the user should never retrieve more information than needed. In addition a few of the functions provided should be handeled with particular caution (read more in the documentation of each function)