Reserves and returns one or more landing report id's in the database for your user. Other users will not be given these numbers in their requests as they are reserved for your use. This is provided to help preserve uniqueness of these id's. It is encumbant upon the user application to prevent inappropriate landing report id reuse.
All eLandings landings reports have a landing_report_id associated. Before assigning a landing report number to a new report, eLandings and all third-party users need to verify that the landing_report_id that they assign is not already in use by another report. Otherwise, previous report data will be lost and new report data may be corrupted.
For example:
A landing report is created by userid=Bob and the landing report is assigned landing_report_id = 1000.
A landing report is created by userid=Joe and the landing report is assigned landing_report_id=1000
The header information for the record created by Bob will be replaced by the header information created by Joe. If Bob's report had more permit items than Joe, then Joe's report might contain his line items and Joe's permit items. Bob will be angry at eLandings and at Joe.
To avoid this situation in eLandings situations or in third-party tools, eLandings provides the means to get and reserve a list of landing report id's in such a way than anyone else that asks for an available landing report will not be provided with these reserved id's. As long as everyone honors this rule, we can avoid collisions and data loss.
We cannot prevent users from illegally reusing a landing report id. eLandings allows users to save their changes. It is very hard to determine if a change should be labeled illegal reuse or normal user data changes.
This method returns a list of reserved landing report numbers as a string in XML format as defined by the XSD definition for number_info object in dataelements.xsd. If errors were encountered while retrieving the landing report in the web service, an empty number_info object will be returned containing a list of messages objects as defined by the dataelements.xsd definition for messages elements.
The getLandingReportNumbers() takes several arguments:
- String Userid – i.e "amarx"
- String password – i.e. "A_marx"
- String schemaVersionNumber – i.e. "2.1"
- String numberOfNumbersRequested - i.e. "10"
- String reportType – i.e. "C" or "" – THIS FIELD'S DATA HAS NO EFFECT
If we pass in a numberOfNumbersRequested=10, we are asking for 10 new landing_report_id's from the database that have never been used and will be reserved for our use.
There are several reportTypes available for use:
- "C" = Crab
- "G" = Groundfish
- "B" = Salmon
Note: Currently, elandings web service logic does not use the reportType. Any String value passed in will be accepted and discarded. It will have no effect on how the numbers are retrieved or reserved in the database.
In the web service client we might auto generate a data structure by providing the web service URL. In eLandings we use Java – JAX-WS and generated a structure called ReportManager.
ReportManagement ws;
"
"
String xml = ws. getLandingReportNumbers (userid, password, schemaVersionNumber, numberOfNumbersRequested, reportType);
Or
String xml = ws. getLandingReportNumbers ("amarx", "A_marx", "2.1", "10", "C");
If the web service call was successful you will receive a string containing something like:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <number_info> <schema_version>2.1</schema_version> <landing_report_id>15397997</landing_report_id> <landing_report_id>15397998</landing_report_id> <landing_report_id>15397999</landing_report_id> <landing_report_id>15398000</landing_report_id> <landing_report_id>15398001</landing_report_id> <landing_report_id>15398002</landing_report_id> <landing_report_id>15398003</landing_report_id> <landing_report_id>15398004</landing_report_id> <landing_report_id>15398005</landing_report_id> <landing_report_id>15398006</landing_report_id> </number_info>
In eLandings, this webservice is called when creating a new Landing Report. For example, if you logged into eLandings as amarx and clicked on the "Salmon Landing Report" button
eLandings would call the webservice method and ask for a new Landing Report number to attach to the new landing report. In so doing, eLandings is telling the database not to give this landing report number to anyone else. This preserves the landing report id's uniqueness.
The web page runs the following web service call:
String xml = ws. getLandingReportNumbers ("amarx", "A_marx", "2.1", "1", "B");
The returned XML
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <number_info> <schema_version>2.1</schema_version> <landing_report_id>15404133</landing_report_id> </number_info>
This number will then be assigned to the new landing report number
eLandings will use this number (15404133) when creating the new landing report: