System Interface Workshop Notes - October 12-13, 2011

Owned by Phyllis G Smith (Unlicensed)
Last updated: Sept 08, 2022 by Chad Millen - NOAA Federal
29 min read

Workshop Agenda: /wiki/spaces/AR/pages/8817155

Presenters:

Gail Smith – ADFG eLandings Program Coordinator
Paul Caldwell – eLandings Analyst Programmer Supervisor
Ammon Bailey – eLandings Analyst Programmer
Amar Das Khalsa – eLandings Analyst Programmer
John Wilcock – eLandings Consultant
Chris Keller – Wostmann and Associates, eLandings Consultant
Jennifer Mondragon – NMFS Program Manager
Larry Talley – NMFS Analyst Programmer

October 12, 2011


Review eLandings, PTI and tLandings Applications
Introductions and opening comments – Gail Smith
The eLandings development team believes processors will be better served if they pull data from eLandings versus importing data into eLandings from a third party application. The eLandings applications have extensive data validation and business rules that are modified as a result of ongoing actions by the Alaska Board of Fish (BOF), International Pacific Halibut Commission (IPHC) and the North Pacific Fisheries Management Council (NPFMC).
The focus of the workshop will be data extraction and import into a third party business application, but other import/export or full import into eLandings data interface systems are allowable, but not supported.  The Department specifically supports the Public Web Services interface, as documented within the eLandings WIKI - System Interface.

Review of February 2010 XML workshop and Data Extraction versa Data Import – Paul Caldwell
Paul reviewed the System Interface Guidelines, which document a framework for third party developer's support expectations.
Paul provided a brief description of the Processor Tender Interface application (PTI) for tLandings data import. He stated that processors that agree to use tLandings are expected to then import that data into eLandings. The data can also be imported into their own business application, as well. He briefly reviewed the eLandings' online resource, defining XML objects and access to system information.
Gail: Described available user support for eLandings end users, as well as developers, and what assistance we can provide, with emphasis on first accessing existing System Interface documentation and other eLandings system resources located at: https://elandings.alaska.gov/confluence/dashboard.action

System Interface Approaches
Gail provided greater detail on approaches to interfacing with the eLandings system.
Processors with integrated scale weight capture for Pollock create landing reports within their business application and do a manual import into the eLandings System. This approach does not disrupt their NMFS approved method of AFA Pollock weight capture. Few tickets are generated during the season, the landings are few species and the business rules are not complex. The American Fisheries Act (AFA) landing reports are not IFQ/IPQ fisheries.
All other landing reports for this seafood company are reported within the eLandings System and the data is extracted into their business operations system.
Processors can develop their own front-end reporting applications and then import the data into the eLandings system. This approach is not recommended for IFQ/IPQ fisheries as immediate validation of all quota permits is a requirement of the program, validation procedures are complex, and the number of landing reports on any day of the season are not great.
As all landings reports and fish tickets are uniquely numbered and this unique numbering is used within the eLandings system as report identifiers, great care must be exercised to maintain eLandings compatible numbering procedures.
The eLandings system industry applications, eLandings web, seaLandings, tLandings are modified on an as needed basis following actions by our governing bodies – BOF, IPHC and NPFMC. Developing front-end data entry application means that the third party developer will always be modifying the application based upon the needs of the resource management agencies.
The audience was reminded that the current NMFS regulations state that all federally permitted processing facilities must use the eLandings system or an approved application for reporting.
Gail summarized the Import and Export capabilities of the eLandings System. The focus of the workshop is a System Interface that extracts the data from the eLandings System, manually or via Web Services.
Non-web service data extraction tools are available within the eLandings web application. The data extract tool is designed for small to mid-sized processors, as the number of records that can be extracted with any request is limited to one thousand.
The Data Extract tool is available from the eLandings web application, Reports Menu.
The eLandings data extract tool allows the end user to access their authorized operation Landing Report or Production Report records in an XML, CSV or Excel output format. The tool also has the ability to create templates to extract reports in a standardized output of your design.
Documentation on the Data Extract Tool and the Database Field Descriptions are located at: https://elandings.alaska.gov/confluence/display/ifdoc/How+to+Extract+Multiple+Landings+or+Production+Reports+from+eLandings+using+the+Report+Extract+Tool
https://elandings.alaska.gov/confluence/display/ifdoc/Report+Extract+Spreadsheet+Columns
End users were reminded that the XML data extract is the most current and up-to-date version of the database field columns as it is updated whenever a change to the schema occurs. These updates do not occur as frequently in the Excel and CVS format output.
Ammon described the columns available in template download. Most database columns made available for export based upon those that are deemed most likely to be of use by industry. A description of each data field is available at: https://elandings.alaska.gov/confluence/display/ifdoc/Report+Extract+Spreadsheet+Columns
Gail displayed the XML output availability. Randy Swain (NPS) and Ammon point out that a simple copy and paste of the XML from the browser could introduce additional data elements, specifically dashes, which corrupts the XML.

If this occurs, the end user should perform a "Save As" and select the .xml format. This is primarily a limitation on the way browsers render Carriage Return and Line Feed combinations.
eLandings Resources – Brief review – Amar Das Khalas
Amar Das provided a brief review of the eLandings WIKI including:

  • eLandings System Overview
  • User's guide for eLandings
  • Glossary
  • Training Materials
  • System Interface Guide
  • Documentation of XML format of all valid eLandings codes.


He strongly recommended that developers review this documentation carefully.
Lastly, Amar Das displayed our version history of schema and system updates documentation.
Paul pointed out that some of the schema version history is not complete because of the huge number of changes made over the summer.
(Following the workshop, the eLandings Development Team determined that they would keep current only the last year of schema version and system update change documentation.)
He also provided a review of our procedures for system announcements and schema change notification. Registered users associated with an established eLandings operation can be notified of schema changes via email. Participants that are third party developers requested another method to be informed of schema changes, because they are not registered users.
(The eLandings Development Team are actively addressing providing additional and timelier notification of schema changes as registered users.)
Amar Das provided a brief review of the Public Web Services documentation, but noted that this will be next day topic.

A notification discussion followed and Amar Das noted that our email list is for eLandings users associated with an elandings operation, not necessarily 3rd party developers. Update notifications are sent out usually the day before implementation. We recognize that these notifications are not available to TPD (third party developers) that are not working closely with processors.
(This issue is being addressed by the eLandings Development Team to allow TPD access to eLandings change notifications. Need to change how email lists are managed, such as modify to an online subscription system.)
Amar Das and Paul again noted that schema change notification is part of this process, as well as web services change notifications.
Recordkeeping and Reporting Requirements – Gail
Understanding how the eLandings System operates and the imbedded business rules, requires an understanding of the recordkeeping and reporting requirements for all three management agencies – IPHC, ADFG and NMFS. Gail reviewed the on-line documentation for reporting requirements.
Training Scenarios – Gail
Gail reviewed the on-line training scenarios available for large variety of fisheries currently using eLandings. She noted that training scenarios will assist developers in a greater understanding of the eLandings system, reporting sequence, validation and business rules, and allocation calculations.
Gail mentioned that the ADFG maintains a confidential dataset of commercial landings from 1966 to present. She reviewed all three agencies on-line Reporting Requirements and noted that each agency has a set of rules pertains to fisheries where their jurisdiction exists. The jurisdiction is related to state/federal waters, specific target fisheries, such as halibut and if the species is state or federal managed. These jurisdiction trigger when a Landing Report or Production Report is required. She specifically reviewed the location of documentation for groundfish and IFQ reporting requirements. Reporting requirements and required data elements are the result of the public management council/board/commission process, and there is often a disconnect in timing of decisions changing requirements and notification to programmers and developers of the changes. These rules and changes drive database/application business rules.
Randy (NPS) pointed out that the word "expectation" is used, but wants to know where the line exists between expectations and requirements. He used, as an example, developing his own program to upload to eLandings instead of PTI.
Gail pointed out that regulations state that fish tickets must be submitted within a specified time period – that is a requirement as we must have timely reporting. The eLandings Team and ADFG expect industry that are using tLandings for electronic reporting on-board tenders to use PTI to upload this landing report data into eLandings because the PTI performs additional data validation and because ADFG wants the data in an electronic format. We do not want processors to use tLandings and then only submit the printed PDF copies of the electronically generated fish tickets to the Department.
The ADFG does not require eLandings or tLandings, but do believe that there are significant benefits to it for processors. The ADFG Commissioner and the Director of Commercial Fisheries have stated that eLandings is the desired direction of the ADFG for reporting of commercial catch. Eric (Coastal Villages) commented that they have used tLandings for two years with minimal issues. They extract the data from eLandings into their accounting systems and can pay Bethel based fishers from their Anchorage office within four days.
She also added that the workshop is designed to provide information on what is required, by regulation and what is expected by the program managers.
eLandings System Overview – Gail
The system has five visible components.

  • eLandings - web-based access for seafood processors
  • Agency Interface - locally installed access for fisheries agency personnel
  • seaLandings - locally installed program which provides email-based access for clients with no web access (typically for catcher/processor factory ships which report at sea)
  • tLandings - locally installed program for salmon, shellfish and groundfish tenders with no web access
  • eLogbook – interfaces with eLandings and seaLandings and allows electronic capture of logbooks for federal fisheries


All Landing and Production Reports, eLogbook data, and Operations/User Accounts are stored in the eLandings Repository Database. End Users gain access to the eLandings System when an Operation account and associated user accounts are established. All operations require unique identifiers – a State of Alaska Fisheries Business License (Processor Code) and/or a Federal Processor Permit.
Unique applications have been developed for specific fisheries (such as IFQ), specific data collection (such as eLogbook), or lack of internet connectivity (such as seaLandings and tLandings).

Gail provided a brief review of the tLandings application and the relationship of eLandings and the PTI to tLandings.
The workshop participants discussed eLandings operations and authorized users associated with multiple operations. Gail pointed out that a user can be authorized in one operation and added to many additional operations. A good example is a data manager located in Seattle that is given access to several processors landing and production reports throughout Alaska. User accounts are always associated with an operation and only the owner of the data, the primary administrator, can add new users.
An attendee wanted to know why they could not delete a Landing Report. Gail noted that submitted reports are sometimes voided, but never deleted. The deletion of a submitted landing report requires intervention by the eLandings Team. The report(s) are voided with an explanation of the reason for the action*.*
Current and planned tLandings and PTI modifications – Amar Das
Amar Das: Issues with tLandings application in 2011, and updates implemented:
Inseason:

  1. Lockups from two reasons, main one being a memory leak. Fixing that memory leak fixed almost all reported lockups. The other minor lockup issue was fixed as well.
  2. For Mixed Salmon, difficulty pulling up Landing Reports to apply species percentages due to restriction on Port. Changed mixed salmon percentage tool so that Port is no longer a required element which needed to match operation port to apply update.
  3. Total Tare weight calculated incorrectly on and was fixed.
  4. Expanded the allowable temp ranges and modified from errors to warnings.
  5. Added drive name (actually, Volume name) to Processor Tender Interface (PTI) drive selection dialog, Thumb Drives and provides label, such as "Kingston".
  6. Catch Manager Excel Report output added to PTI, added elements.
  7. Removed popup dialog for Number of Fish, simply highlight cell in red.

PostSeason:

  1. Address PTI download time, low bandwidth issue. Reduced size of download, and optimized TWS installer.
  2. TWS installer failure to configure Thumb Drives provides cleaner messages with more validation. Forced app start in background to verify install.
  3. PTI users no longer required to be administrative user.
  4. Confirmation popup on TWS app close if unsaved Landing Report is open.
  5. Prevent multiple instances of TWS (addressed Landing Report numbering conflicts).
  6. PTI uninstaller added. Simplified uninstall for the few problems.
  7. Added CFEC permit and vessel interim values to code menus.

Scheduled Modifications for 2012 Salmon Season:

  1. Incremental updates to vessel lists. Vessel lists now stored and managed in eLandings, with new tools/controls added to applications. Much work already done, but may not be final version.
  2. Add over-limit functionality expanded to account for multiple sizes/grades.
  3. Run Diagnostics on startup (both PTI and TWS) to improve valid operation.
  4. Provide standardize weekly catch reports on eLandings web app to be provided to ADFG area management staff.
  5. Mixed Salmon pct update will no longer require every field to be entered
    • Port code for the registered operation not necessarily matching the real port was brought up as an issue (port is the largest issues, (e.g. Inform user when port does not match, allow edit)).
  6. Easier management of tender operation users in eLandings – add to tender accounts, enable, disable, remove.
  7. Additional Species Summary report within the Tender Workstation by gear type.
  8. Additional Landing Characteristic check box, Brailers Met Criteria, within the Tender Workstation.

Question from attendee: What is our expectation regarding number of Thumb Drives used by a tender for an opener? Explanation of general concept of 1 thumb drive/trip, configured with specified number of Landing Report/Fish Ticket numbers, returned for upload at trip end. Gail provided clarification to the group on the flexibility with the number of Landing Report/Fish Ticket numbers that can be assigned to a thumb drive and the dynamic assignment of multiple batch numbers to fish tickets generated with a specific opener. Amar Das also provided a review of the tLandings Developers efforts to optimize and shortening the bandwidth (time) required to configure thumb drives.
Amar Das also provided a clarification of differences between Tender Workstation (tLandings), the Processor Tender Interface application, and eLandings web application.

  • eLandings Web Application is an internet link to the eLandings database and provides access to operation accounts and user accounts, as well as all electronically submitted reports. All tLandings reports are uploaded into the eLandings Web Application and accessed by the shoreside processor via eLandings.
  • Processor Tender Interface is an application that allows the processing staff to configure thumb drives that are unique to a specific processing facility and to a specific tender.
  • Tender Workstation (tLandings) is the application stored on the thumb drive and used to create landing reports on board the tender.

Amar Das also provided a review and demonstration of the eLandings application feature to allow for an update of mixed salmon to specific species. His demonstration included the assignment of multiple Tender Batch IDs.
Question from attendee: A participant asked why we do not use eLandings production reporting module for Mixed Salmon Updates. The production reporting module within eLandings is for required federal reporting of groundfish and is not designed to update Mixed Salmon species to individual species. The information needed to update Mixed Salmon comes from the individual processing facility sorting of the delivered catch.
Workshop participants discussed tender split deliveries – sorting and delivery of king salmon to one processing facility and the balance of the catch to a different processing facility. The total catch (kings and other salmon) are recorded on individual fish tickets. Where do the signed copies of the fish tickets and the thumb drives get processed? The eLandings Team had no immediate answer to this question and will need to discuss a workable solution with Alaska Wildlife Troopers and with ADFG area managers.
Participants also discussed the potential of lost data as a result of a thumb drive failure or loss. Gail pointed out the paper back-ups exist – fish tickets, tally sheets, back deck tallies. If the thumb drive is lost or broken, the landing records can be recreated from the fish tickets, or if both are lost, from the back deck tallies. She explained that deck tally, thumb drive, trip log, and printed Fish Tickets in possession of both the tender and the fisherman would have to be lost before the record of the delivery is unrecoverable. Randy (NPS) stated that he feels it is better than the old system, because of this redundancy, and has never had a problem.
The participants then discussed data corrections and updates to landing reports. Gail pointed out that ADFG managers need the best available data and corrections to required data elements, which does not include price, and corrections shall be made in the eLandings system. The mixed salmon update shall also be updated within the eLandings system which will allow the processor to then generate the Weekly Salmon Report within the eLandings web application, as well.
If processors create a third party application for reporting and then import this information into the eLandings System, each modification to any given landing report requires a refresh of the eLandings data.
Following lunch Gail provided a quick review of the tLandings user guide, and tLandings Training Scenarios on our Confluence Wiki. She and Amar Das provided a demonstration of the PTI Catch Manager Report. The Catch Manager Report was created to provide easier data entry of fish ticket information into the Catch Manager software application used by many seafood companies.
eLandings System Business rules and validation – Amar Das
Amar Das covered the multiple validations that occur during data entry, submission, upload and editing. He also provided an explanation of our error message documentation feature.
He demonstrated an attempt to save a landing report with many uncompleted, required data elements and the generation of error messages. Within eLandings the web application does not allow a save and submission of the record to the database if required data elements are missing or do not pass code and business rule validation.
The tLandings (tender workstation) application does allow an initial save of the landing report, but does not allow printing of a fish ticket record that contains errors. Because the tLandings application is not connected to the database via the internet, validation is limited. As an example, the CFEC permit and the ADFG vessel number are not validated until the data is uploaded into eLandings via the PTI.
Amar Das also pointed out that the all eLandings system applications also generate warning messages to assure that the information entered is correct. An example of an error message is a temperature entered as 56 degrees. Upon a save attempt the application will message back: Warning: Temperature 56.0 is high. The application logic will allow the user to save, ignoring the warning. Warning communicate – check your work to ensure valid data.
Amar Das pointed out that eLandings system warning and error messages are contextual and numbered allowing user to reference additional information on the problem. Each message also contains recommended corrective action.
Amar Das provided another example of error messaging using the Mixed Salmon chum percentage update feature of eLandings. He entered a king salmon species code, 410, as one of the species determined to be a portion of the mixed salmon composition. The error message was: King Salmon not allowed with mixed salmon, they must be recorded and counted separately. Randy (NPS) asked if this was a new rule – a regulation or an expectation. Gail responded that it is a requirement of the local area managers that all king salmon throughout the state must be identified, sorted, weighed and counted individually. Randy also asked if the information for these business rules is available. Amar Das responded that the code for validation is spread throughout the application, but the general description of business rules are outlined and available on line: http://elandingstest.alaska.gov/businessRules/index.html
The final area that Amar Das addressed was the business rules and documentation for the Mixed Salmon Update feature. He specifically reviewed the issue of rounding, which default to the nearest whole number. Randy (NPS) asked how a species update can occur if the Mixed Salmon update feature, was limited to chum/sockeye. Gail responded that the Update feature allows for identification of coho, pinks, chums, and sockeye. Randy then asked what happens to the rounding error remainders. Amar Das responded that it is applied to sockeye.
During the tLandings workshop on 10/11, Rosemary (Trident) noted that the Mixed Salmon Update feature in elandings allocates pounds slightly differently than Catch Manager. At that workshop, Gail asked the Parity (Catch Manager) programmers to provide their allocation documentation for this function in Catch Manager for the workshop on 10/12-13.
When asked at this workshop the Parity programmers indicated that the coding was done 20 years ago and they did not appear to have documentation. They are in the process of rewriting Catch Manager and they plan to follow our business rules as documented.
IFQ Rounding - Chris
Via a call-in, Chris described how rounding occurs in the IFQ fisheries. The rounding process is much more complex as areas of harvest, statistical areas, are frequently 2 or more and permits can be stacked. IFQ pounds allocated over several statistical areas and permits cannot exceed the total pounds extracted and the IFQ weight must also be whole pounds. The rounding precision is to four places, on landing report fish tickets, but rounded to whole pounds in IFQ reporting. However, numbers are adjusted to make sure that weights are always equal in all reporting using a tool called Summary Manager. Constraints are applied to make sure that very small amounts never result in negative numbers. Chris provided a brief description of the calculation process, but pointed out that third party developers do not want to attempt to make the same calculations outside of eLandings as it would be difficult to create the identical results. The way to do the calculation if that is what is wanted; in the landing report fish ticket(s) is to enter poundage for each of the statarea line items - for each Landing Report Fish Ticket. Randy (NPS) asked if there is a way to submit the unallocated information to eLandings thru web services and receive the allocations back? Chris stated that it could be done but it would require an additional application feature. Gail mentioned that it might be quite some time before a feature such as this could be addressed. Karl (Sea State) asked, "Are the rounding remainders applied to the largest proportions, or is the algorithm more complicated than that?" Chris responded that the calculations are more complicated as the IFQ amount must be a whole number. He suggested that developers reference the Business Rules documentation, Class Allocation Rule Manager. For additional documentation see: https://elandings.alaska.gov/confluence/display/doc/Rounding+on+Landing+Reports+Explained+and+Illustrated
ADFG Standards and Expectations - Gail
Gail mentioned that the majority of reporting requirements for commercial harvest are located in ADFG regulations, 5 AAC 39.130. When using eLandings applications – eLandings web or tLandings, the fish ticket(s) generated must comply with current regulations – signatures from the seller and the agent for the buyer and submission within seven days to the local office of ADFG.
The Bristol Bay Weekly Salmon Report will be moved to the eLandings web application for the 2012 salmon season. The weekly report time frame is Sunday thru Saturday. ADFG Area Managers expect processors to submit the weekly report by noon on the following Tuesday. Weekly reports must reflect harvest updated from mixed salmon to unique species, based upon production data.
Edward (Peter Pan): requested clarification on the number and routing of signed (and unsigned) copies of Fish Tickets. Gail responded that the tLandings application has the ability to create two copies of the Fish Ticket and the Tally Sheet. Signatures are need on the Fish Tickets only. Additional copies can be printed depending on processor's needs on board the tender or at the shoreside office once the data is uploaded into eLandings. Our ultimate goal is to reduce the number of copies being generated, including moving to signature capture. Paul described the non-plug and play nature of signature pads (i.e. they require proprietary software) and our current lack of development plans in this area.
Gail also reviewed our plans to develop other standardized ADFG catch reports for other fisheries and again reiterated our expectation that correct – best available - data be available to area management biologists. She stated that the bottom line is that any correction to a required field within a processors business application also be updated in eLandings.
Data Flow – tLandings to eLandings to Export – Paul
l
Paul reviewed in detail the data flow from eLandings to the PTI to tLandings back to PTI and eLandings and then export to a third party application. He reiterated that data validation occurs at every step. Paul then discussed a new feature of the eLandings System, the ability to dynamically update the processor's vessel list when the thumb drives are reconfigured. He provided a demonstration of this feature, explaining that the vessel list created at the beginning of the season is appended when a new vessel delivers to the processor. The new vessel information is uploaded and stored in eLandings and captured when the thumb drive is reconfigured.
Gail mentioned that a couple of the third party developers and consultants were planning on uploading the landings data from the thumb drive directly into their business application and then import into eLandings. The question Gail had to the eLandings Developers was if this vessel update feature would work if this approach is used? Paul speculated that the ability to update the vessel list would be effected if the data is imported into eLandings from another application, unless the third party developer were able to carefully duplicate our code, capture those vessel that were newly added with the opener and refresh the vessel list within the eLandings database. All of the new vessels would need to pass validation procedures and if the ADFG number is not valid it would require an update of the third party application database, a new export files and a re-import into eLandings.
The web service feature to refresh the vessel file for the processor is housed within the PTI. The processor would need to upload the landings data from the thumb drive into their third party software application and using the PTI, upload the data into eLandings. This procedure will guarantee that any new delivering vessels are captured.
Randy asked for clarification, the thumb drives on board the vessel would all need to be updated to capture the new vessel information? Paul responded, yes.
Ammon mentioned that corrections to vessel characteristics – vessel name, CFEC permit names, etc. are corrected in the database based upon the validation process. When the thumb drive is reconfigured, the corrected information is loaded. If the third party business application pulls the data from eLandings, the corrected data is available. The paper fish ticket printed on board the tender vessel should be reprinted from the eLandings web application if you wish a corrected copy.
Clarification question from Edward (Peter Pan): The Catch Manager report available within the PTI is all drawn from eLandings, not from the Thumb Drive? Amar Das responded; if the batch of records you are wishing to access are already stored within eLandings (already uploaded) then that is considered source. If the data has yet to be uploaded into eLandings, the data only exists on the thumb drive.
The last issue that was addressed before the break was duplicated landing report and fish ticket numbers. Amar Das mentioned that this problem was the result of opening and logging into more than one instance of the tLandings application. He stated that issue was addressed. Only one instance of the application can be open at any given time. The group discussed the importance of managing Landing Report and Fish Ticket numbers as duplicate numbers would over write earlier versions of a record.
Ammon provided a quick overview of tomorrow's topics. Web services; What's available, and how to use them. In preparation for the 10/13 workshop Ammon asked the following of the 31 participants:
How many of you have worked with eLandings web services? Five raised hands.
How many of you are familiar with web services? About half raised hands.
How many of you have worked with XML? Almost everyone raised hands.
How many of you are familiar with JBOSS, GLASSFISH, Tomcat or other application servers? --Only two people said yes but I know at least 2 others are.
Not all participants responded to these questions.
Future Plans for Standardized Reports – Gail
Gail wanted to clarify that ADFG standardized reports that are under development or are planned to be available for Landing Reports are for fisheries Data housed within eLandings system. Randy (NPS) asked why the processor needs to run these reports when ADFG already has the data. Why can't ADFG run the reports? Gail responded that the summary reports must be reviewed by the processor prior to submission to ADFG to make certain that the landings data is correct and complete, prior to submission.
She noted that the eLandings Team already received feedback that these reports do save processors a significant amount of staff time.
The use of these standardized reports is available for processors that are fully implemented with the tLandings reporting applications. The reports are generated from the eLandings database, which does not contain any conventional paper fish ticket data. Consequently, for salmon, tLandings implementation is important to be able to use these standardized reports next season.
After the development work is completed for the Bristol Bay Weekly Salmon Report, staff will then address reports for groundfish fisheries.
With the full implementation of eLandings for all fisheries, ADFG hopes to address a roll-up of all buying activity consolidated for the Commercial Operators Annual Report.
Production Reports – Jennifer and Larry
Jennifer reviewed the requirements for production reporting for NMFS. She also mentioned that it is very easy and logical that this information be imported into the eLandings System, as it is data that is resident to the processor's business application. Randy (NPS) mentioned that he is currently importing production data from the NPS operation system into the eLanding system. Jennifer added that the at sea production reports from seaLandings are handled in a unique manner, as an email attachment, and cannot be "imported" into eLandings via web services.
Randy (NPS): He was curious about species/pricing/grading documentation, with the weight entered at the species and delivery condition level, and pricing-grading done as multiple row children of species/delivery condition. Larry responded that it was an attempt to meet user needs on line item reporting. One line item for a species and condition combination can result in multiple grade/size and prices variations.
Randy also asked about business rules that can guide the developer to understand species/delivery condition and disposition combinations that are NOT allowable. He specifically wanted to know where this was documented in regulation and in our Java Docs business rules.
Larry responded that the rules for what is NOT allowed are more difficult to determine as the documentation focus is on what is valid and allowable. Randy questioned how current the Java Docs are and Larry responded that they are maintained and accurate.
Gail asked Jennifer to provide information on eLogbook. Jennifer stated that eLogbook replaces paper logbooks and currently only Pollock trawlers are using the application. Other fishing sectors are waiting for the program to maturity and in near future it will be used with other groundfish fisheries. NMFS is moving slowly to make certain no one is overwhelmed with too rapid of an implementation.
Randy (NPS) asked about the NMFS regulation to use eLandings or an "approved" system. He wanted to know how the approval processes works. Specifically he wanted to know for Groundfish IFQ, what is the approval process is to submit xml directly to eLandings? Jennifer responded, indicating that NMFS does not currently have a formal process, but would just need to demonstrate that the third party has produced XML that has been reviewed with our XML code checker, passes validation and is a correct documentation of the landing or production data. Randy states he has been live since January, but has just learned that approval is required. Jennifer stated that if it's been going in, then the xml is correct, and he has de facto approval. Their approval process was not meant to be formal, and they want it to be somewhat flexible. Gail added that the approval process is more of a notification process rather than a formal certification process.
The workshop participants revisited question of how to find documentation for xml schema that explains valid species and disposition code combos.
http://elandingstest.alaska.gov/businessRules/org/psmfc/er/business/ValidationRuleManager.html#validateLineItem%28org.psmfc.er.business.LandingReportMessageCollection,%20org.psmfc.er.business.LandingReportWrapper,%20org.psmfc.er.business.helper.LrLineItemVO,%20int,%20int,%20java.lang.String,%20boolean%29
Larry also briefly discussed additional documentation on the business rules on rounding, located at: https://elandings.alaska.gov/confluence/display/doc/Display+of+Partial+Pounds and https://elandings.alaska.gov/confluence/display/doc/Rounding+on+Landing+Reports+Explained+and+Illustrated.
Jennifer noted that rounding is handled very uniquely for IFQ and IFQ/IPQ fisheries and the complexity associated with IFQ (stacked permits and multiple statistical areas) may make it very difficult to understand and then implement this in a third party system. Developers could spend a great deal of time and effort for few landings. You need to ask yourselves, "Is it worth it?" Jennifer's last comment was that NMFS specifically tries to steer everyone away from trying to replicate IFQ business rules. It is way too complicated, and changes to the business rules occur all the time.
A workshop attendee asked about production reports for the at sea fleet fishing IFQ. Jennifer explained that the production reports for IFQ do go thru additional validations and are equally complex when compared to non-IFQ groundfish or CDQ.
Gail ended the first day of the System Interface workshop with this take home message - IFQ is complicated.

System Interface Workshop, October 13, 2011


System Interface Introduction - Ammon

  • PTI
  • Agency Desktop
  • eLandings web interface

For all three interfaces, end users need a link to the eLandings server hosting the eLandings database. The eLandings team uses JBoss, an application server, which listens and waits for web service requests. JBoss routes requests to the appropriate web service. Using JBoss for all three interfaces to pass strings of XML through the web services offers flexibility which can extend to variety of interfaces enabled by the web.
Ammon described the three parallel eLandings environments – Test (Development), Training, and Production, and the appropriate use of each. Test is the absolute latest that developers are currently working on, but can be very unstable. Training is used to train users and is the same version as Production. It is stable and can be used by third-party developers to test against. Production is our live environment for end-users and all users have a responsibility to report true and accurate data, so testing against this environment is not an option.
On the eLandings Confluence WIKI, the System Interface Documentation is located at: https://elandings.alaska.gov/confluence/display/ifdoc/Public+Web+Service+Documentation.
Ammon described each public web service call, which is found at: https://elandings.alaska.gov/confluence/display/ifdoc/Public+Facing+Web+Services
Amar Das asked Ammon what timeout constraints exist in the system for end users in low bandwidth situation. Participants requested that this information be available to developers. Session timeout was not available at the workshop (all web connections should timeout after 30 minutes.)
One consideration is that bandwidth is unique to locations and the service that each site has chosen. Also, technology is changing every year.
Ammon begin demonstrating the web service tutorials found at: https://elandings.alaska.gov/confluence/display/ifdoc/Public+Web+Service+Client+Tutorials
This included copying and pasting of code from the tutorial to a new project in NetBeans IDE. He mentioned that the web service calls must include the desired eLandings schema version. All XML Schema documentation is located at: https://elandings.alaska.gov/confluence/display/ifdoc/XML+Schema
eLandings XML descriptions are obtained from schema downloads available from the XML Schemas web pages for each environment:
Test: https://elandingstest.alaska.gov/elandings/ReportManagementService?wsdl
Training: https://elandingst.alaska.gov/elandings/ReportManagementService?wsdl
Production: https://elandings.alaska.gov/elandings/ReportManagementService?wsdl
Ammon saved each XSD (schema) file to be included in the project. He used JAXB (XML binding) on each of the schemas. This created a bunch of new Java objects that correspond to the data elements contained in a landing report XML file generated from tLandings. Now he can marshal Java objects into the XML file and produce the Java objects by unmarshalling an XML file. Taking a string returned from successful web service request, he demonstrated how JAXB can unmarshal the elements in the string to the Java object, which can now be used in the Java application.
He showed the eLandings search tool, which allows the user to search for landing reports based on flexible data criteria. This search tool uses the findUserLandingReports web service method, which returns a landing_report_info XML element. This element can return a list of landing reports with minimal landing report data, based on the search criteria. This list can be iterated over to retrieve single landing reports with the getLandingReport web service method. This methodology will meet user needs while minimizing the impact on the eLandings server.
The example used was to call the webservice to search for landing reports with a certain date range of the date of landing. XML was returned and unmarshalled into java objects. The size of the list of landing reports returned was 193.
Paul noted that the web services approach to data integration provides greater flexibility and also allows greater capability. For example, the Data Extract tool, on eLandings, is limited to a return result of 1000 landing reports; however, the web service approach accommodates unlimited data pulls.
Randy (NPS) noted that the schemas were one file but are now split into many different schema files, with more than one schema referencing the dataelements.xsd it can result in duplicate generated java classes in different packages that create ambiguous reference conflicts under certain tool sets, during development. Ammon pointed out that it is more complicated to deal with more files; however, the original schema file was becoming too large and unwieldy. Also, different eLandings components can use completely different sets of elements. For example, tLandings and PTI does not use many of the elements needed for logbook or production reporting.
Question (Rob – Camelot Computers): how long before submitted data is available to user? Ammon responded that once the web service finishes, the information is immediately available.
Ammon reviewed the process of requesting modifications to the eLandings System. Specifically, the group discussed how long it would take to get a requested change implemented and deployed to Production. Request should be submitted via eLandings@alaska.gov. It is initially reviewed by the Interagency Steering Committee (SC), meeting bi-monthly. The issue may then be reviewed by the IT Steering Committee (ITSC), meeting bi-monthly. If the request is related to an identification of a bug, it is addressed immediately and if critical, it may trigger an immediate deploy. If an enhancement or a new feature, the request is documented in our issue tracking application for review and prioritization. The Program Management Board (PMB) with members from both the SC and ITSC meet every fifth week to prioritize issues. The timeframe, for developers, once the issues are selected to deploy, is usually five to six weeks.
Question: How will third party developers be informed of the status of issues? Gail mentioned that the status of issues submitted by private industry and usually communicated back to the initial submitter, after the prioritization done at a PMB meeting.
Ammon also mentioned that releases are given a release number. If a release has a modification to the schema, then the schema version is incremented. He also noted that the system is built for backward compatibility for the schema versions, but this means that if third party developers are not current, they may not have access to any of the new data elements. Removal of any element from the schemas would also break any out of date third party developer applications. Paul noted that this has never happened and there would have to be an extremely good reason to do this.
Ammon navigated to the eLandings web application code lookup xml files: http://elandingstest.alaska.gov/elandings/XmlCodesLookup
Along with the landing report schema files, you can also download the schema file for eLandings codes. Ammon demonstrated that the species.xml file can be added to a project, marshaled and used to list the codes, handle data validation, and provide additional information about the codes to the user.
Question (Rob - Camelot Computers): are eLandings codes available in an Excel format? Gail mentioned that they are available in that format and will be moved to the eLandings System WIKI.
https://elandings.alaska.gov/confluence/pages/viewpageattachments.action?pageId=25756184&highlight=PORT.XLS#eLandings+Code+Tables
The error code messages are available in both locations in XML and XLS format. These error codes may be returned by eLandings web services. If the third party application integrates these codes into their application, then the user could have immediate access to a description of what the errors mean.
Syncing eLandings data with third party applications - third party applications need to receive updated information from eLandings. Web services allows for great flexibility in how this can be accomplished, depending on user needs. One way to do this is for every time the third party application runs, save a last update timestamp. Then a web service request can pass that date and pull all the landing reports from eLandings based on the last update date that was saved in eLandings. With this method a third party application will data-sync during initialization. Adding a feature within the application to do the same data-sync, so the user can do this process at will without having to restart the application, is advised.
Question (Fawn - Unisea): Are there modifications to the eLandings data by agency staff that make the data housed by the processor different than that housed by the Agency? Gail responded that the Agency Desktop application is used by agency fisheries managers to modify the catch records submitted by industry. The most common modifications are to area(s) fished and effort (shellfish fisheries). The original submission of the landing record and the modification of that record are stored in the eLandings database, but the modifications are not viewable or downloadable by industry. The modifications are based upon confidential sources – logbook, interview, and observer data.
Question (Tom – Adaptent): How do we identify the last user that modified the data? Gail and Ammon point out that nearly every time a user touches and changes the database, it is recorded and time stamped. Gail pointed out that the last user is most frequently an agency staff person – IPHC, NMFS or ADFG. This was illustrated by showing training agency desktop application and displaying the edits that Ammon made during the earlier demos.
The group also discussed landing report 'status' of initial and final submissions.
Status values are:
1 - Not submitted
4 -Initial Report Submitted
8 - Final Report Submitted
16 - Report Deleted (aka. Report Voided)
These different submission states of a landing report allow the processing facility staff to document the landing in stages – initial off-load without grading/sizing and pricing. This provides the processor with the ability to print the fish ticket, obtain the signature of the permit holder and submit to ADFG. After production information is obtained, the processor can then recall the initial fish ticket, add additional information and submit as the final report.
Gail also mentioned that no landing reports are ever deleted. They are "voided", which means they are marked as deleted, in the database, but never removed from the database. Developers need to pay attention to the status of landing reports, especially deleted ("voided") reports.
XML Code Checker – Ammon
Ammon demonstrated xml code check tools on the website. Documentation on the XML code checker with links to the Test, Training and Production XML Check are provided: https://elandings.alaska.gov/confluence/display/ifdoc/XML+Resources+and+Documentation
Currently, the XML Code Checker only checks the validity of the XML code. To fully test the eLandings business rules and to validate fisheries codes, developers should complete test submissions within our training environment.
Ammon reviewed XSD schema files and the available documentation. He requested that program developers review this documentation and contact the eLandings Team if information is neither available nor correct. https://elandings.alaska.gov/confluence/display/ifdoc/eLandings+Applications+and+the+Webservices
Paul: eLandings@alaska.gov is the best way to get hold of team, but notes this is for those things they can help developers/processors with. Gail also notes that they can request modifications this way.
Post workshop activities have included adding public web service client tutorials demonstrated in the workshop. https://elandings.alaska.gov/confluence/display/ifdoc/Public+Web+Service+Client+Tutorials.
Participants also asked for specific detailed documentation on field lengths. The eLandings Development Team has addressed this issue by adding field specific documentation on the XML Schema documentation pages. The additional documentation provides the column definition that is actually used in the eLandings database, as well as links to the code table values for elements specified by code tables and business rules for elements where the allowable values are limited. The documentation pages with the additional information are at the following links.