http://cfmedia.clicflic.com/web/misc/api/HRAvatar_IMO_API_current.pdf
This guide will show you what the embedding parameters are, the interface for the required javascript functions, and the format of the result XML that has all the test-takers clicks.
An XSD for the result XML is at:
Additionally, the IMO API document provides an explanation of all the elements and attributes in the result XML as well as how the response data is formats for different types of item formats - ie multiple choice, radio buttons, sliders, text boxes, etc.
The contents of the methods for the webpage to be used for reporting status, receiving and storing result XML, etc. are left to your developers. However, since we've built our own testing system we've had to implement these methods ourselves.
Here are a few lessons learned:
1. Pay attention to the eventid verification feature in the IMO API, the title of the section is: Having an IMO Verify an embedded eventid with a third-party server. This is a security feature to prevent unauthorized use of the test.
2. Also in the integration guide is a section entitled: Capturing Error and Other Messages from the IMO. Implementing this can assist with troubleshooting down the road.
3. When an IMO loads it always asks for any existing result xml. We use a javascript method that then asks the server for the result xml using a synchronous XMLHttpRequest. Also, even though the response to the request is an XML document, we treat it as a text string within the javascript. We have found it's better to have the page request the XML from the server every time it's needed rather than embedding it in the dynamic page when you serve the page. This removes any chance of the IMO reloading result XML that is not the most current.
4. When the IMO calls a method with a revised result XML document, we send it back to the server using an asynchronous XMLHttpRequest. We use the onreadystatechange event to monitor the success of posting and if there's a problem, we tell the test taker that their data is not being recorded.
5. The result XML contains a sub-element called event which has an attribute called pctcomplete. This is a number 0-100 that represents the percent complete. When storing result XML on the server during a test, we parse the XML to obtain this value and if the current percent complete is higher than the one in the most recently received result XML, we don't record it. Percent complete cannot go down. This could happen if a person opened the same test in multiple windows and then switched windows.
6. To prevent the session from expiring while a test is loaded we use a javascript setTimeout() method and XMLHttpRequest to keep the session alive if needed.
