Web Service Interface enables retreiving material from and importing material to Netvisor. The Web Service Interface resources are divided into upper level categories.
Common for all transactions:
- Dates are in ANSI format
- Country codes are always in ISO-3166 format
- Attachments are always Base64 encoded in XML message
- Empty elements don't need to be given in the XML message. For example in edit request the empty element is interprented as an order to delete the existing value
- Compulsory elements should not be given empty in the XML message
- Elements have to be in the same order as in the DTD
To be able to import Scandinavian characters (Ä, ä, Ö, ö or Å, å) the message has to be endcoded in ISO/IEC 8859-15 but xml declaration does not need to be given. The message should always start with <root>. If the scandinavian characters won work in ISO/IEC 8859-15 encoded format, the encoding can be changed to UTF-8 format.
Make large retreives and imports outside office hours if there is no special need to do these during that time. The frequency for transfers varies from resource and use case. In many cases transfers once a day or month is sufficient. You can speed up the transfers with appropriate limitations using resource parameters.
Enclosed is a description of different entries and their meaning and interpretation in Netvisor's Web Service Interface. The XML structure of different messages is descibed in tables for the part it is possibel and logic. Due to the XML structure, the resource descriptions have references to different parts of the instructions to be able to keep the entity as clear as possible.
The basic structure of resource description is the following:
- Basic data
- The used resource
- GET - generally retreiving data from Netvisor
- POST -generally posting data to Netvisor
- Usually defined in the QueryString, separated from the actual resource with ? and after the parameter there is &
- XML structure when importing data (POST)
- Described is the XML structure and e.g. the amount of different elements and their compulsion
Note that when using self closing tags in POST-messages, Netvisor ignores these completely, including possible attributes. For example, when importing customer details, the element <email/> is ignored, while <email></email> updates that particular value in Netvisor to blank.
Every query is answered with an XML response. The structure of the response matches the query for the most part and the general structure can be seen in the chapter below The response to GET type queries includes resource specific data structure that is described in each resource description. Depending on the POST type query, Netvisor Web Service Interface returns Replies element that can include e.g. InsertedDataIdentifier element with added item's NetvisorID.
Every request is responded with a standard response message. In GET type request the response includes the requested data (<resouce specific element>) and in POST type request the response might include a event spefic response (Replies).
The general sturcture of a response message:
Element: Root (occurs: 1)
Element: Root/ResponseStatus (occurs: 1)
|Status||String||Indicates if there was an error in handling the request||OK||FAILED|
|Status||String||Error type and description||This element only occurs if the status is FAILED. Check Controlling errors|
|TimeStamp||Date||Time stamp of the response||01.01.2018 12:00:00|
The response type is related to the direction of the data transfer:
1. When retreiving data from Netvisor
The retreived data is in its own element in the response message:
Element: Root/ResponseStatus/<resource element>
2. When importing data to Netvisor
The response includes Replies element and in that element there is data in some occasions:
Element: Root/ResponseStatus/Replies (occurs 0-1)
The enclosed elements occur times 0-n.
Did you find it helpful? Yes NoSend feedback