The eLandings team has provided system provides web pages to that import and 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 servicesThe import function is allows users to enter reports into eLandings without having to duplicate the data entry they have already done on their own business system. The import function expects that users will review the data as entered into eLandings, prior to submitting it. Adjustments to the report data may be made. This is particularly true for reports with IFQ, since eLandings allows the IFQ reports to be generated from the submitted landing report. It is not uncommon for generated IFQ reports to be edited before final submission.
The export function allows users to get reports in XML format, suitable for importing into third party system. Reports can also be exported in CSV or Microsoft Excel format, for users who manage their business with spreadsheets.
Using the eLandings web pages for interfaces to third party system has advantages and disadvantages for third party developers.
Advantages
The interface to eLandings is quicker and easier to build using the web page features. The third party system only had to read a file on user command to acquire eLandings data, and to write a file in the designated format if exporting data to eLandings. Users take the responsibility for transferring the files to and from eLandings.
For an interface where the third party system exports report files for import into eLandings, the need for automated error handling is reduced. The user is already in the loop, for transferring the file to eLandings using the import web page. If the eLandings system returns errors on the import the user receives and deals with them. IFQ report generation can be completely in the hands of the users, utilizing the eLandings web page functions for IFQ reporting. Generating IFQ reports correctly is among the most complex processes for landing reporting.
Disadvantages
The primary disadvantage of using the web page functions as the system interface is that it burdens the user. 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:
...
A system interface built on web page data file functionality will have limited custom features. 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 A system interface build using the web page data file functions may not be appropriate for seafood processors involved with fisheries with a high volume of landings in a short time period. It is expected that third-party developers who opt to build their solution 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.
The eLandings team has a small staff of programmers with limited time and resources. The eLandings project is under active development with a very long list of new systems, enhancements, improvements, refactoring, general maintenance, and bug fixes. The eLandings programming staff time is fully allocated. Due to the large workload and small staff, eLandings programmers may be unable to implement reasonable third-party developer requests in as timely a manner.
Any request made by third-party developers of the eLandings programming staff must be reviewed and prioritized within the existing workload, prior to work being done. As with all eLandings programmer tasks, third-party modification requests for the eLandings web pages, fall into the following categories:
The requested change cannot be done
The requested change would negatively impact other users
The requested change would take a very long time to implement and would have very little positive impact
The requested change would have positively impact but has a lower priority than other higher priority issues.
The requested change would have a large positive impact and can be quickly implemented
The requested change would have the highest positive impact of any potential development task in eLandings
By relying on eLandings programmers to provide the import and export interfaces, third-party developers are choosing to have other people prioritize the third-party requests within a much larger list of unrelated pressing issues that will impact a much larger group of unrelated users. Predictable, the eLandings team will not come to the same conclusions of priority and time allocation that third-party developers might like. For additional information see: <ADD LINK TO "eLandings Team Structure and Request Handling" below>
...
, will be unable to handle a large number of reports efficiently from their third-party solutions. The eLandings Report Extract 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.
A system interface using web page data file functions could operate based on one of two scenarios:
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.
Another disadvantage to a web page based data interface is that enhancement requests will have lower priority and will be slower in being implemented. The eLandings development team has provided the web services for third party interfacing systems. Enhanced functionality will be implemented there first. Requests for enhancement of the web page data file functions will be addressed at a lower priority, particularly if the requested feature is already available through the web services. Also, changes to the data, such as additions of new elements, will be implemented in the XML format first. The CSV file and MS Excel files produced by the report extract web page may not get the new data elements for a considerable period of time.
Scripted Interface to Web Pages
One approach that third party developers who want to interface to the web pages might contemplate is to automate web browser actions through scripting. Tools such as Ruby/Watir allow software to control a web browser automatically, to visit pages and get data. Such scripting techniques are heavily dependent on the page elements within the HTML pages remaining constant. Third-party developers should be aware that eLandings developers may occasionally have to change the HTML pages as corrections and improvements are made. Preserving page elements to provide backward compatibility with scripts will not be a consideration, since the eLandings system provides the web services for automated system interfaces. Third party developers who use a scripted web page approach to their system interface will need to have a mechanism for correcting their scripts in the event that changes to the HTML pages causes problems.