You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Status
DECIDED
Stakeholders
OutcomeDetermine the results taken by errors and warnings as it relates to EDSM and UI
Due date

 

Owner

Background

Currently, there are about 111 validation codes that were turned into warnings or turned off completely during the implementation of EDSM 2.0.  The program and ISG are currently in the process of reviewing these codes and determining if they should be turned back on as errors or remain as warnings.  When submitting data via EDSM (batch), the system applies business rules logic to ensure that the data meets specific parameters set by the program.  Since there are error validation codes currently turned off, EDSM allows for data (that do not meet the set parameters) to be loaded to the system (normally these would be rejected and not allowed to load).  However, the data is not visible via the UI since it does not meet the business rules logic even though the data was processed and loaded into the database tables.  This causes issues since the EDIs do not have visibility into the data that have been sent via batch files.   


Decision

The following decisions were made in regards to how the system will process and display errors and warnings via the UI.  

Validation Type

Data Visibility

Notes

Level of Effort (LOE) to Make Visible

Warning

Portal UI

EQRS ingests data that triggers a warning, and the data is visible through the Portal UI. It may also be accompanied by a warning message.

No additional effort is required to make the data visible.

Error

Client System(s)

EQRS does not accept or process data that triggers an error. The condition that triggers the error must be resolved and the corrected data must be resubmitted for it to appear in the Portal UI.

N/A - EQRS does not ingest data that triggers an error. 

Error Converted to Warning or Removed

Unknown

Once an error is backed down to a warning or removed, EQRS ingests the data; however, it may still violate other business rules, causing unexpected behavior, such as system errors, suppression of data in the UI, and triggering of unexpected alerts in the UI.


We need to make sure we revisit this and prioritize it accordingly.

The effort to make data from the converted errors display consistently in the UI is significant. It involves:

  • Identifying and tracing all of the business rules that are impacted
  • Redesigning the impacted business rules to handle the data appropriately
  • Testing that the changes have the desired result
  • Regression testing the impacted functionality in EQRS to confirm that all impacted functionality still behaves as expected
  • No labels