This document will illustrate how error codes will be setup in the Data Import(DI) subsystem for FOLIO. Common terms used in this document include

• Domain: Subsystems of FOLIO that can be grouped together to satisfy some functionality. E.g. Inventory, Orders, Invoices etc.
• Domain Owning Module: FOLIO modules that are at epicenter of Domain functionality flows. They are typically not storage modules. 

Introduction

Generic backend error messages are returned to the user upon failures in data import. Data Import should employ error codes and specific error messages for issues that occur frequently. This page contains error messages from the community Data Import Log Error Messages that need to be better. Data Import needs to present better user facing error messages that can assist with troubleshooting.

Design

Each Domain Owning Module; e.g. mod-inventory(Inventory), mod-orders(Orders), will be responsible to accurate depiction of issues that arise during a Data Import job. DI modules like mod-source-record-manager and mod-source-record-storage will produce their own messages and will not be responsible for presenting a user facing error from an exception generated somewhere in the DI pipeline. Domain Owning Modules that generate DI_ERROR events will be responsible for populate the error indicator in a Data Import Event Payload.

Model

Today, the error indicator is populated with a String representing an error that will be presented as is at the Data Import logs in the FOLIO UI. When appropriate an error object is populated instead of a string. The error object will have properties at minimum:

• code: Error code for the user facing error
• message: user facing error message that should include the code. Message should be descriptive enough to aid in issue resolution.
• cause: "ugly" java exceptions as seen today, most likely containing stacktraces

Code Scheme

Error codes will following the following scheme:

{DOMAIN}-XXX

Source Record Manager(SRM)

SRM is responsible for processing DI_ERROR event and translating them to Journal log entries that will find their way to the UI eventually. The error message in the Data Import Event Payload is saved as is into an error column for journal log entries. A new property, system_error , will be added to hold the "ugly" java exceptions while the existing error column will hold the user-friendly message. Using this approach, the user-friendly error will be displayed in the FOLIO UI with minimal code changes to the UI. 

SRM should be backward-compatible with scenarios that cannot generate user-friendly errors. This can be achieved through the following decision tree:

• If a string value is encountered in the error indicator of a Data Import Event Payload, store this value in the error property of the journal record. In this case, the "system_error" property will remain empty.

• If an Error Object is encountered in the error indicator of a Data Import Event Payload, store the message property of the Error Object in the error property of the journal record. Then, store the "cause" property of the Error Object in the system_error property of the journal record.

Error Code Persistence

Error codes and their corresponding messages will be stored in property files inside the Domain Owning Module. If the module is written in Java, these property files should be placed in the Resources folder of the FOLIO module. This arrangement will enable the use of ResourceBundle for obtaining future translations. It will also centralize messages in one location for regular review and minimize code collisions. Example:

000=Internal Error
001=Item not found

000=Erreur interne
001=Élément non trouvé