Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
The following roadmap was developed based on discussions with stakeholders.
The outstanding tickets will be finalized shortly and put to the voting (Prioritization in the ERM SIG).
The respective release of a feature will be agreed upon with the development team on a case-by-case basis, which is why no decision can be made at this time. We are a small team and need to make agile decisions.
Improve handling of COUNTER API Exceptions (See ongoing discussion)
Backend (Harvester): Behavior depending on error code.
UI: Improvements to the overview of Counter reports within the UDP, if necessary. For example: new icons.
Improvements to error overviews:
UI + Backend: Extended error messages in the harvester logs
Backend: Additional field for error code in Counter reports. Currently, the error code can only be filtered out using a kind of LIKE command. Other things can also be stored as errors, not just counter API errors. The field would thus contain the code or “Other,” as in the provider's data record.
See also the agenda item Extend information from Counter exceptions which was mentioned in Slack by Bernd.
If you want: InApp report to see all Counter reports that have errors. FYI: API calls for errors are already possible. Leipzig has an API query and an SQL report that displays all errors.
@Stefan Dombekwill create subpages explaining how to create these queries.
Features to solve errors
UI: Repeat failed server requests manually.
UI: Delete failed reports
Features that prevent incorrect harvesting configurations
UI: Provider list with data from counter registry
UI: Integrated status check of the provider's Counter API.
During the harvesting configuration:
Checking credentials
Which report types are available
After the harvesting configuration: If the credentials are no longer valid after a certain period of time and this causes an error, no further reports should be requested. Instead, a different error message should be displayed in eUsage.
Not only via AWS, but general connection to S3 object cloud storage (data sovereignty).
Feedback from backend developer: It would work for the non-Counter reports. For the Counter reports, you would have to modify the backend a lot.
Extend information from Counter exceptions
Use case: The UI only shows the Exception.Code and and Exception.Message. The exception often includes additional information in the Exception.Data element, for example for code 3032 the information which period is still available, for 3031 the months not yet processed, or for code 1020 how many requests are permitted. There are 9 exceptions listed in Appendix D of the CoP where the server should provide additional information in the data element.
DevTeam Leipzig: For various reasons, it makes sense to add another field for errors in the JSON of a report. At the moment, the only way to filter out the contents of the errors is to use a kind of LIKE command, because the “failedReason” field contains all error messages across multiple releases, including HTTP error messages. This means that the backend will be redesigned so that it extracts the error message and stores it in the new additional field accordingly. This allows API queries to be made more targeted and the UI to use the data more effectively.
Examples
{"Code":2000,"Severity":"Error","Message":"Requestor Not Authorized to Access Service","Help_URL":"","Data":"Incorrect API key."}
{"Code":1011,"Severity":"Warning","Message":"Report queued for processing","Help_URL":"https:\/\/connect.liblynx.com\/sushi\/r5\/help\/1011"}
{"Code":2020,"Severity":"Error","Message":"APIKey Invalid","Data":"Incorrect API key."}
Report not valid: [{"Code":3030,"Severity":null,"Message":"No Usage Available for Requested Dates","Data":"Requested data between 2022-11-01 and 2022-11-30"}]
Harvester - Improving the processing of CoP error codes
In the next meetings we would like to discuss how eUsage should react to the individual exception codes.
The handling of the exception will be changed. The harvester should stop and make no further attempts. Instead, an error message is displayed in the Detail View. This can also be filtered to search for it.
Feel free to add points to the list
Workshopping
There will be a new agenda item in the next meetings. If anyone has errors in the system or problems, these can be presented at the meeting. We can look at these together.
