Laser/ERM integration is a collection of features aimed at allowing a LASER site to synchronize their subscriptions (Content Lists) and licenses with the FOLIO ERM Agreements and Licenses apps. The integration works via a new backed module : mod-remote-sync (https://github.com/folio-org/mod-remote-sync) and related UI: ui-remote-sync (https://github.com/folio-org/ui-remote-sync). Taken together, remote-sync is general purpose scriptable ETL tool for FOLIO into which arbitrary configurations can be loaded and used to keep FOLIO in sync with a remote data source. Whilst remote-sync itself is intended to be general and reusable, the configuration for LASER is solution specific and can be found here (https://raw.githubusercontent.com/k-int/folio-sync-tools/main/laser/laser_registry.json).
...
On the left side, the record source is listed. Boxes in this column represent the actual raw records which will be / have been collected from a remote source. Remote sync runs on a cron schedule which is invoked every 60 minutes. If a previous extract job has not yet completed, the task is skipped. This means remote-sync will try to synchronize with a remote source once per hour. Because some sources (LASER) do not provide a good cursor mechanism the only way to tell if a record has changed is to download the content and compare the current version with the previous one. That is exactly the process which takes place in this box for LASER. The main aim of the first column is to take a datasource with heterogeneous cursor semantics and turn it into a record stream which can be enumerated. The boxes on the left hand side correspond to the "source" record types in the registry.
...
- https://github.com/k-int/folio-sync-tools/blob/main/laser/ProcessLaserLicense.groovy and
- https://github.com/k-int/folio-sync-tools/blob/main/laser/ProcessLaserSubscription.groovy
- But both procedures need to be interpreted in terms of the config found in https://github.com/k-int/folio-sync-tools/blob/main/laser/laser_registry.json
LASER LICENSE Procedures
License Import Procedure - Control
...
- for each property in the incoming LASER license
- Look up the property in the mapping configuration
- If Found
- Look at the TYPE defined in the mapping configuration
- Text:
- join all the LASER notes together and add them to the custprop note field
- Add the value of the custom property as a TEXT field
- If there is NO-Value set the value to "No-Value"
- Date
- Join all the notes as for text
- Store the value in the value field
- Refdata
- Join notes
- Look up the value in the mappings config
- If a mapped value is found, set the value
- If not, ignore the value.
- Text:
- Look at the TYPE defined in the mapping configuration
- If Not Found
- Ignore
- If Found
- Look up the property in the mapping configuration
LASER Subscription procedures
For each incoming subscription
- If the sync titles setting is yes
- Generate the FOLIO Package import JSON for the subscription
- upsert (Insert or update) the package definition and remember the package details (UUID)
- upsert (Insert or update) the subscription
upsertPackage procedure
upsertSubscription procedure
we should set up a (semi-technical) documentation document in google, where you can explain the different workflows in that data is processed in the app. Things like the queue (that I learned about only today ), things like "when does something fail", things like "when do we need to retrigger after a change to a mapping" and so on. You will have it somewhere, surely.
And then, I think, we should get to the point to say that "this is it", every other expected behaviuor will be future features for a future development phase. And only real bugs, where the app doesn't behave as the document describes, will be things to work on in this project.