The eLandings team has provided web pages to export and import landing and production reports. We encourage third-party developers to use these methods while learning how to work with eLandings XML data structures. It may also serve as a temporary backup strategy if or when third-party applications become out of date with their eLandings XML schema definition. Although not recommended, third-party developers may choose to build applications that revolve sole around these web pages without making use of the public web services. This approach attempts to shifts work from the third-party developer to the user of the application and to eLandings developers. Such solutions may be cheaper to implement in the short term but more costly to maintain over time. It is predicted that end users will be less satisfied with third-party applications built on this philosophy.
If third-party developers opt for this approach they can expect the following:
Inability to create all desired features requested by the user group
It is expected that third-party developers who opt to build their solution solely around eLandings web pages, will be unable to create all the desired features requested by their user group.
The choice to build third-party solutions solely around eLandings web pages results in shifting work responsibility from the third-party programming staff to the eLandings programming staff. Third-party developers are in effect saying "I want eLandings developers to build and maintain the interfaces by which my users will import and export eLandings data." Predictably, third-party developers who make this choice sacrifice control of those interfaces and the timeline for the implementation of changes to those interfaces.
Inability to handle a large number of reports efficiently
Requiring the users to do more work than a comparable system built using the public web services