...
The purpose of this document is to enumerate steps that should occur that will allow import & export job profiles between FOLIO tenants. Most changes will occur in mod-data-import-converter-storage(mod-data-import-cs).
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
Fields in a mapping profile can be constructed via the FOLIO UI. Some level of validation exists in the FOLIO UI but much less on Data Import APIs. The FOLIO settings UI is responsible for enumerating valid values that a field can contain. This list of "accepted value" is saved into mod-data-import-converter-storage as is. Incorrect accepted values can be saved in mod-data-import-cs. mod-data-import-cs needs to be augmented to apply validation steps similar to the FOLIO UI. mod-data-import-cs should make calls to retrieve pertinent reference data from other FOLIO modules as needed. As it stands, critical business logic lives only in the FOLIO UI when it should be present in the FOLIO module.
A representation of a mapping field should exist in mod-data-import-cs. This representation should also have a link to its origin; some URL most likelyFOLIO domain areas like Inventory, Orders, Invoices. With the mapping field origin present, this will allow mod-data-import-cs to be able to do the same validation that the FOLIO UI performs.
...
Profile validation should start occurring on mod-data-import-cs. Upon creation or update of a job profile, validation should occur with data sourced from the mapping field origin. Good error messages should be returned to allow easier troubleshooting. Adding this to mod-data-import-cs will make it independent from the FOLIO UI.
mod-data-import-cs will validate every Match, Action, Mapping & Job profile that is persisted within. mod-data-import-cs will be aware of the origin of a profile, e.g. action profile for "create instance", belongs to inventory. Inventory will validate the profile and send a response back to mod-data-import-cs. Some preliminary validations should occur at mod-data-import-cs. Here is a sequence diagram of the example
mod-inventory can be replaced with other FOLIO domain areas for validation of components of a Job Profile. mod-data-import-cs will determine the destination of a Profile object.
The endpoint should be similar to /inventory/data-import-profiles/validate. The endpoint will accept an array of Profiles and return an array of results detailed a valid Profile or error messages signaling reason why a profile is not valid. Order of the results could match the corresponding input OR profile identifiers from the input is referenced in the validation results.. This means that mod-data-import-cs will delegate validation to corresponding modules that own a FOLIO domain. New endpoints will be implemented in those modules that will accept profiles for validation.
3. Profile Transformation
Having mapping field origins defined and validation occurring in mod-data-import-cs, it will set the stage to allow imports of job profiles from other tenants. Transformations would occur to convert by comparing incoming reference data with existing reference data. This will usually be by name or code. If no match can be found then an error is returned. Job profiles returned by mod-data-import-cs API should be accepted as input for the transformation without any modification.
...
During transformation, mod-data-import-cs will convert incoming reference data identifiers/values into reference data identifiers/values that currently exists in the tenant. If a suitable value cannot be found, details errors will be returned to the API client. Errors should include valid values that the system will accept. Every detail will be validated before errors are returned, the process should not fail on the first exception.
...