Saltar al contenido principal
Servicio de soporte de OCLC

File structure for User Import

  1. Última actualización
  2. Guardar como PDF
Learn about the file structure required for user import in OLIB.

General structure

The User Import process takes as its input a text file containing tagged data which has been exported from another system. The process loads this data into the OLIB database as user records and associated addresses, groups and other data. The data load will match with existing reference data (e.g. locations and user categories which must exist in the system before the dataload). In addition, a certain amount of reference data can be created during the import process. For example, the incoming record can include the user's department for which there is no corresponding department record in OLIB. As long as the appropriate tag is used in the incoming record, the import process will create a new department record in OLIB. This is referred to as extendable data.

The expected input file format is as follows :

  • a tag at the start of the line. This is not case sensitive
  • one or more spaces immediately after the tag
  • the data immediately after the space(s), exactly as it is to be imported
  • A line break (either Unix or Windows style)
  • a single asterisk to terminate a record. This should be on a separate line on its own
  • where a tag refers to extendable reference data, the file can include a ‘+’ immediately after the tag to generate basic reference data entries. Where this is done, the characters to be used for the key and those used for the description should be separated by at least two spaces.

Ejemplo de registro

The following is an example OLSTF file for the user import process:

SEC 6438
SN Smith
FN John Robert
INIT J.R.
BAR 6438
CAT STUDT
TI Mr
PASS secure
MAIL jrsmith@somecompany.com
TELMOB 07654 321 1234
SEX M
TP+ ADULT  Adult
CIRCBAN Y
DELETE COURSE LINKS CASCADE
COURSED+ Computing
DELETE DEPT LINKS
DEPT+ TS  Technical Services
DIST+ Manor Park
LOC BH
OCCUP+ TIM  Technical Implementations Manager
DELETE OBJECTS LINKS CASCADE
OBJECT+ T WWW  http://students.ourcollege.ac.uk/registry/idimages/student-78485.jpg
*
SEC 6438
ATP P
HOUSE Brincliffe House
ST 861, Ecclesall Road
CITY Sheffield
PC S11 7AE
*
SEC 1111
GNAME Staff
OWNSEC 6438
*
SEC 6438
GROUP Staff
*

Notes

  1. By default, all dates should be in the format DD-MON-YYYY.
    • An alternative format can be specified at any point with the "DF" tag
  2. Matching can be made on BARCODE or SECCODE.
    1. To match on barcode, include the MATCH tag at the top of the file, i.e.   
      • MATCH BARCODE
    2. To match on seccode, include the MATCH tag at the top of the file, i.e.
      • MATCH SECCODE
    3. The tag used for matching must be present as the first tag in every record (after any MATCH line) in the file to be imported.
  3. If CAT is not specified in the records to be imported, the default User Category will be used. If the default user category is not specified in Admin Client defaults, the load will fail.
  4. Individual records (between *'s) must contain either user or address or group or rapid data. A combination of different types of data is not allowed.
  5. If you want to link a user to a group during the import process (using the GROUP tag), the group record must be present in the database. Group records can be created as part of the import process, using the GNAME tag set.
  6. Non-extendable reference data which does not already exist will not result in the user record being rejected, but will not be populated in the user record.
    • The Reference Data Mapping options can be used to match incoming data to specific reference data as required
  7. Ensure that the default Location and User Category defaults are set in Admin Client Defaults
  8. Ensure that the Default Address Type field is set in OLIB Defaults
  9. Ensure that either Expiry Date or Expiry Days is defined either in OLIB Defaults or in the relevant User Categories record
  10. The DELETE tag’s CASCADE option can be specified for course, department or object data. With CASCADE specified, the course, department or object will be removed from the database if there are no more Users linked to that record (ie: it is obsolete). In the above example, obsolete courses and objects will be removed and obsolete departments retained.