Job profiles are used to control flow of execution in Data Import for records; MARC or EDIFACT or otherwise. Job Profiles can comprise of 4 main objects:
Job Profile: Merely a header object that stores the name and type of profile
Match Profile: Used for determining if a record matches a criteria(s). There are two possible outcomes that will direct the flow of execution: MATCH and NON_MATCH
Action Profile: Used to perform actions like Create, Update & Modify on different types of objects
Mapping Profile: Used to determine how to convert a source record into the desired FOLIO object.
In a Job Profile hierarchy, only one Job Profile should exist. A Job Profile can be linked to one or many Match and Action Profiles. A Match Profile can be linked to other Match Profiles or Action Profiles. Action Profiles can only be linked to one Mapping Profile. Job Profile hierarchy will usually terminate at Mapping Profiles.
The dynamic nature of Job Profile hierarchies means there are many permutations that can occur in the wild, dependent on workflows of libraries. This brings a challenge with testing “all” flows with Data Import. A representative set of Job Profiles is needed to test most flows. One approach would be to recreate job profiles from production systems including their reference data. This is very labor intensive, reference data conflicts have to be resolved and the finished job profiles are not portable.
Instead of maintaining a repository of actual job profiles and their reference data, one approach is to have a repository of “shapes” of job profiles. It is possible to two distinct job profiles from two different libraries in different instances of FOLIO that result in different outcomes but the job profiles have the same structure; the same “shape”. Duplicating both job profiles would yield double effort but extra testing insight is not gained past the first job profile. Maintaining a distilled repository of job profiles brings the following benefits:
Minimal number of job profiles that can be tested in totality while still having decent testing surface area.
Reduced testing duration due to minimal number of job profiles.
No dependency on any library’s reference data. Existing reference data in a FOLIO tenant could be used.
Job profile hierarchies can be represented as graphs. When represented as graphs, Job profiles shapes/structure can be compared(isomorphism) and traversed with industry standard algorithms. Below is a sample job profile and its equivalent graph.
Below is a list of feature possible for a CLI/Library that will form the basis of a comprehensive testing strategy for Data Import.