Metadata Synchronization with Alma

Alma-Rosetta Integration

From Rosetta Version 5.0, Rosetta-ILS integration no longer depends on SRU support on the ILS side (and additional API support on the ILS side for automatically updating a Rosetta inventory flag). With Alma, full metadata synchronization is available, allowing users to update IE-level descriptive metadata with changes done in Alma. This enables the library to fully preserve their descriptive metadata while leveraging Alma’s advanced metadata editing capabilities, providing a unified resource management experience – and with no development on the library’s side. Files remain in Rosetta, and the Rosetta delivery infrastructure, including access rights validation, is responsible for serving up the files to both Alma staff and patrons. This document describes the full synchronization workflow of importing your Rosetta IEs to Alma, enriching their metadata, and updating Rosetta with the changes.


  • Access to Rosetta and Alma user interfaces is restricted by user roles and privileges. Refer to the product documentation to make sure your user is assigned the appropriate roles.
  • Managing digital objects in Alma requires a full Alma subscription.
  • For the purposes of this post it is assumed that all metadata changes will be performed in Alma.
  • Both Rosetta and Alma have built-in mechanisms to compare records and ignore updates if records harvested and existing records are the same.

Step 1 – Publishing your Rosetta IEs

Reference: Rosetta Staff Guide, “Publishing“; Developers Network, Rosetta OAI-PMH Integration

Exposing your Rosetta IEs to Alma is accomplished by OAI-PMH publishing, using a standard Rosetta publishing workflow. If your IEs already have corresponding bib records in Alma, be sure to include the relevant match field using the publishing profile. By default, Alma expects DC (either qualified or unqualified – see below), so you need to make sure the publishing profile is configured accordingly. Rosetta comes out of the box with xsl configuration files that can be used for this purpose.

Step 2 – Defining Rosetta as a remote repository in Alma

Reference: Integrating Remote Digital Asset Management Systems 

If this is the first time you are connecting Alma to your Rosetta instance, you must first configure Rosetta as a remote repository. Alma already includes two basic configurations for a Rosetta repository – “Rosetta OAI DC format” and “Rosetta OAI Qualified DC format.” Chose the one that matches your Rosetta publishing profile settings. You will need to modify this configuration to include specific information about your Rosetta instance. First, change the OAI-PMH baseURL to use your Rosetta hostname (specifically, the delivery load balancer hostname) and Rosetta’s oaiprovider endpoint. This should look something like: After modifying the baseURL use the “Connect and Edit” test button. If your baseURL is correctly configured, a Metadata Prefix drop-down field will appear (if not, you will get an error message).

The Transformer Rules tab allows you to map record information to your Alma representations. Be sure to keep the default mapping to OriginalRecordIdentifier and LinkingParameter1. The first will serve as a match point for any future representation-level updates, and the second, which holds the IE PID, needs to be added to your delivery templates in the Delivery tab:

The OAI-PMH record identifier is also mapped to the bib record 035 field. It will be used to match the corresponding Rosetta and Alma records and should not be modified.

Step 3 – MD Import

Reference: Configuring New Import Profiles

Once Rosetta is set up as a remote repository, a new Digital Import Metadata profile needs to be added. This will be used to harvest the metadata from Rosetta and create bibliographic records with remote digital inventory. Schedule the profile to periodically check for new or updated records (according to your Rosetta publishing scheduling).

Use the test button to confirm your records will be read properly. Note the 035 field.

In the third tab, be sure to select “Import” upon no match.

Run the import and, when compete, select History -> Imported Records to see results.

Your import into Alma is now complete. You can view the object from the Staff Search result’s ViewIt tab, or use the ‘Representations’ link to view/edit your digital inventory.

Step 4 – Editing your metadata

Reference: Opening the Metadata Editor

From the search results, click ‘Edit’ to open the Metadata Editor and enrich your record.

At this point, you have two options:

  1. Rosetta will continue to hold a skeleton metadata record, and that the enriched metadata is relevant for Alma and discovery only (bearing in mind that Rosetta’s viewer will display the metadata stored in Rosetta). In this case your work is done.
  2. You want to sync Rosetta with changes performed in Alma. In this case, proceed to the next step.

Step 5 – Alma Publishing

Reference: Publishing and Inventory Enrichment

Note: If this is the first time you are publishing Alma records using OAI-PMH, you may need to set up an OAI Integration Profile. Be sure to confirm Rosetta’s IP is within the IP range that is permitted to access Alma’s OAI-PMH server. It is recommended that your PC’s IP also be given access. See here for  further details.

If you plan to update Rosetta with your metadata changes, you need to set up an Alma General Publishing configuration.
Format should be DC. Add digital inventory enrichment (remote), and set Repeatable field = dc:identifier (default). This will add three dc:identifier fields:

  1. The OAI-PMH identifier
  2. The MMS_ID (formatted as alma_{MMS_ID}
  3. The link to delivery

As we will see, it is the first that Rosetta will use to match and update its record.

After running your publishing job, confirm your data is published:

<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH xsi:schemaLocation="" xmlns="" xmlns:xsi="">
<request verb="ListRecords" metadataPrefix="oai_dc" set="vangogh"></request>
   <metadata xmlns:xsi="">
    <oai_dc:dc xmlns:dc="" xmlns:xsi="" xmlns:oai_dc="" xsi:schemaLocation="">
     <dc:title>Sunset at Montmajour</dc:title>
     <dc:creator>Vincent Willem van Gogh</dc:creator>
     <dc:description>Sunset at Montmajour is a landscape in oils...</dc:description>

Note the first dc:identifier field contains the full oai identifier.

Step 6 – Setting up a Rosetta Update Metadata Job

Reference: Rosetta Staff Guide, “Metadata Update Job“; Developers Network, Rosetta Metadata Update Job

The Update Metadata Job consumes the Alma records that will be harvested by Rosetta (see next step), but it also serves as an output parameter for your harvesting job. Give your job an appropriate name (e.g. “Metadata Updates from Alma”) and specify an NFS path where you want your metadata update files to be temporarily stored (the directory must be created in advance). Keep the “ignore differences in field sequence” field checked for Rosetta to ignore changes in the field order.

Step 7 – Setting up a Rosetta OAI-PMH Harvesting Job

Reference: Rosetta Staff Guide, “OAI-PMH Harvester“, Developers Network, Rosetta OAI-PMH Integration

Finally, set up an OAI-PMH harvesting job to harvest Alma’s data. Give your job an appropriate name (“Updates from Alma”) and specify your Update Metadata job as your target. Use xsl transformation if you want to manipulate your data (e.g. you do not want to update/store all metadata fields in Rosetta), or leave blank to overwrite your IE DC metadata with Alma’s record. For matching, select Rosetta Origin, leave the qualifier empty, and in the ‘Contains String’ add the Rosetta oai repositoryIdentifier as it appears in the dc:identifier field (i.e. the value between the two colons). In the Metadata Update Job field, select the job you created in the previous step.

During the harvest, Rosetta will attempt to match each record with a dc:identifier containing with the IE PID. Upon finding a match, Rosetta will create an XML updateMD package for the IE and place it in the folder defined in the metadata update job configuration. The file name will contain the harvester job name and the IE PID for convenience purposes; the update itself will be based on the IE PID in the file itself. After the update metadata job is run, the file will be moved to the ‘done’ subfolder if the update was successful, or to the ‘error’ subfolder if unsuccessful.