...
Inability to handle a large number of reports efficiently
It is expected that third-party developers who opt to build their solution solely around eLandings web pages, will be unable to handle a large number of reports efficiently from their third-party solutions.
The eLandings Data Export web page has a record export limit of 1000 landing reports. This restriction is to protect eLandings from exceeding the java heap size on the eLandings server for any one user. It is also designed to protect the eLandings database from long running queries. In effect, eLandings is protecting other users from any individual data extract request.
The choice to build third-party solutions solely around eLandings web pages will require the third-party developers to figure out how they will move data from eLandings to their third-party application. This might be manual or programmatic.
Scenario 1
A user logs into eLandings, enters a search query and exports an XML, Excel or CSV file containing one or more landing report or production report. The user logs into the third-party application, browses for the exported file and imports the file into the third-party application.
Scenario 2
A user logs into the third-party application and exports an XML file containing a single landing report or production report. The user logs into eLandings and imports the XML file into eLandings.
Both scenarios are not well suited to handle a large number of reports efficiently. In both cases, the larger the data volume, the more likely users will become frustrated, make mistakes or fail to keep eLandings and third-party in sync.
Third-party applications may relieve some of the manual steps by scripting these steps with automation languages such as Ruby Watir. Such scripting languages allow, programmers to write code to open a browser, go to a URL, enter form data and submit that data, among other tasks.
Be aware that these scripting techniques are fragile and easily disrupted during execution by users doing other activites on their computer. If Watir is used, it is recommended that users be trained not to do other things while the Watir scripts are running.
Be aware that these scripting techniques are heavily dependent on the page elements within the HTML pages being constant. Although rare, eLandings developers occasionally have to change the HTML pages as corrections and improvements are made. Third-party developers will need to have a mechanism for correcting their scripts in the event that such a change to the HTML page causes a problem.
Requiring the users to do more work than a comparable system built using the public web services