Rosetta knows two CMS integration options: unidirectional and bi-directional. The bidirectional integration requires a Rosetta flag to be set in the CMS system. Via the flag, all Rosetta-relevant records from the CMS can be gathered and the metadata pool within Rosetta updated in bulk on a regular basis. However, institutions may be using a CMS for enrichment which belongs to a different / external institution, making the addition of a Rosetta-flag within the CMS system impossible.
This is where the unidirectional enrichment comes to play. The CMS is queried via SRU integration and records are pulled into Rosetta. The pre-requisite is that a CMS section is present within the ie.xml, containing a system name and identifier to automatically query the CMS. This works well exactly once - duirng the first enrichment of the IE from within Rosetta. While all required information to re-query the CMS is present within Rosetta, any re-enrichment attempts via Task Chains such as "Re-assign CMS" or via manual "remove" / "link" will not requery the CMS system but always pull the information from the rosetta-side shared metadata directoy containing the initial harvest. Not only is this behavior counter-intuitive, it also prohibits the update of CMS data for those institutions who do not have control over the source CMS they are enriching from.
Ex Libris has provided a script via which the re-enrichment of these records is possible. The script takes a list of CMS identifiers as an input parameter and returns newly harvested CMS records into the shared metadata folder. However, running the script requires shell access to the application servers and can therefore only be done by system administrators.
It seems that all the basic functionatily for re-enrichment is there, it's just not available in the UI. The users who typically conduct re-enrichment of CMS data, however, do not work via the shell, they work in the UI and expect the functionality to be included there.

Our idea proposed here is to make the re-enrichment mechamism avaiable via the script actionable via the UI. We urgently require this functionalilty as the experience of the past years has shown that CMS records DO change and that these changes are monitored by Rosetta staff users such as participating institutions in a consortia, who do not have sufficient rights to run shell scripts for updates.

ExLibris' current mode of releasing new Rosetta versions is to announce a rough time slot ("April this year") for that new version/minor-release/servicepack/hotfix, release it and deliver a list of changes along with the new release. Up until the actual release, ExLibris will only give a very general roadmap of the planned changes. While this is an easy approach for ExLibris, it's hard for the customers to prepare for the release. Therefore, I propose for ExLibris to provide pre-release versions of Rosetta in order to enable developers to adapt their software (i.e. Submission Applications) to new features, changed API behaviour etc. These beta releases could also be used to gather customer feedback on the changes and improve features before the final release, just like it has been a best practice throughout the whole industry for many years now.

If, for any reason, the suggested developer preview releases are not feasible, I suggest that ExLibris at least releases their interface documentation for new APIs in order to enable developers to begin with their work prior to the actual release. API interfaces have to be specified very early in the design process, so they should be available early on. Developers could mock answers and write their routines before the release, and would only have to do some final tests when the actual working API becomes available.

From my point of view, both ExLibris and the community of customers would benefit from this approach.

In my opinion, the following prerequisites need to be fulfilled to implement this idea and reap the full benefits:
- smaller & more frequent patches, massively simplified/automated install process to enable fast on-site implementation
- rollback over multiple versions including DB schema (In test/dev/staging environments, the Rosetta install script could even take care of backing up the Oracle database using SSH and rman.)
- detailed change information: What new changes does the beta version contain? Which changes are in alpha/beta/release-candidate status? This includes online documentation of in-development features.
- detailed compatibility information (Which version can be installed on top of which other version? Which 3rd party tool versions are needed? Etc.)
- means of communicating development feedback that is separate from the "usual" support cases, so operational content doesn't get mixed up with development issue handling

submitted on behalf of Michele Lindlar

Sometimes it's neccessary to update our cms metadata. if a librarian changes a record in the external cms-system, we want to update the record in rosetta too, but there's no task that works accordingly. we'd be really happy if there would be a task chain or a process that re-harvest existing cms-records.

We currently integrate two catalogue systems via SRU in Rosetta: Aleph and Pica. Both systems are integrated uni-directoinal, as in a Rosetta flag is not available in either cataloguing system. As we are integrating the union catalogues which are held by third parties, we are not at liberty of including any Rosetta-specific fields in the catalogue.

The initial CMS enrichment works without a problem. However, at times it becomes necessary to update the CMS information stored in Rosetta. This can be the case when either the catalogue was updated or when we have detected an error in our mapping.

While two tasks are available which suggest a working update - namely, "Re-Assign CMS" and "CMS Metadata Record Update" - these tasks will not re-harvest from the source CMS included in the SRU integration but will instead always pull from the physical MID copy already stored in the /metadata storage of Rosetta.
Actual re-harvesting is only possible by first manually deleting the MID record in the file storage and then re-harvesting.

ExL has provided us with a script which can be run across the file system. The script requires a list of CMS Ids first and then deletes the records from the storage. The script needs to be run by the administrator from the shell.

We do not consider the script solution sufficient. Instead, we require a functionality of re-enriching with updating CMS records from the integrated CMS system from within Rosetta.

After experiencing some problems with Rosetta's Format Library update mechanism (see SC 00423700 "error while updating Format Library [Rosetta 5.1.0.2]", handled by Paul), we got thinking about Rosetta updates in general. Currently, all updates are downloaded through an unencrypted connection. This includes:
- Rosetta updates (major, minor, service packs, hotfixes) and their checksum files (!)
- Oracle updates and their checksum files
- PDS updates (presumably)
- Format Library updates
Due to this, there's no way to verify authenticity of ExLibris' servers and the integrity of the update packages/the checksums. All information that are downloaded from ExLibris' servers must be seen as tainted and cannot be trusted, because the transmission is unguarded. Even though ExLibris provides checksums for some (all?) of the updates provided, verifying that information against the calculated fixity from the update packages will not provide any additional security, as both the patches and the checksums could be tampered with in a man-in-the-middle attack. This contradicts current best practices in IT security and is considered a risk for the integrity of the repository software and data. Also, if I understand the comment from SC 00423700 correctly, the current FTP password for Format Library updates is hardcoded into Rosetta when it really shouldn't be.

A possible update scenario for major/minor/servicepack updates could look as follows: on Rosetta installation, customers provide ExLibris with a PublicKey specific to that Rosetta installation. To reduce administrative overhead, several/all servers of the same multi server environment could share the same key. That key is added to the ExLibris update servers' list of authorized keys, thus allowing the customers' servers to connect. During the update, the "util sp" command queries the user for the key passphrase and connects to ExLibris' update servers via SFTP to download the patch packets and fixity information. The fixity information is then compared against the calculated fixity of the patches downloaded previously.

A possible update scenario for hotfixes could look as follows: users manually connect to the update server from the Rosetta server CLI using the SSH key. The user then downloads and validates the patch packets and fixity information. Alternatively, the update procedure is unified with the process used for all other updates (btw, is there any technical requirements this hasn't already happened?) and the procedure described above is used.

Updates for PDS and Oracle could be distributed in a way similar to the one described in the hotfixes paragraph.

We've noticed that the first step on improving update security is already done by providing Format Library updates via SFTP (set General Parameter "usesftp" to "true"). However, this is foiled by Rosetta checking for FL updates via plain unencrypted FTP on every reload of the "Home => Preservation => Manage Format Library Version" page. Apparently, that step fails if "usesftp" is set to "true" in Rosetta 5.1.x.

Please keep in mind that publishing and enforcing (!) a policy against short keylengths/weak crypto algorithms/weak kex algorithms is highly recommended when using SFTP/SCP.

Increasingly libraries and consortia are using counter / sushi to measure usage of digital and electronic resources across disparate parts of their holdings.

If holdings being held in Rosetta are to be valued by the broader institutions funding and maintaining those resources, we need to be able to report usage using the counter and sushi protocols (which ExLibris has already demonstrated knowledge of in their support in ALMA and 265 services).

Key features would be basic counter and sushi reporting; use of IP ranges and user groups already defined in Rosetta for reporting; and grouping or content by already defined sets and/or collections for reporting.

we are using the Rosetta-Aleph-Integration in both directions:
1. creating the CMS-record in Rosetta and
2. setting the Rosetta-flag in Aleph as well as updating the Aleph record with the URN created in Rosetta.
In the past there was only one target field for the URN and the assignCMS task with updateURNTask worked without problems.

Due to changes in the cataloging rules - we are using now the international RDA-rules - we have to deal now with different target fields in Aleph for the URN depending on the type of material: e-only e-books, digital reproductions of printed books, online versions of printed books, etc.

The target field is configurable in the Rosetta-Aleph-Sync, but this is not sufficient with the new situation. We want to be able to configure profiles for the updateURNTask depending on the material type: to specify the target MARC-field, to populate subfields with fixed information depending on the material type and with the URN.

(It is not possible at the moment to update the URN in a subfield of an already existing field, a new field is created (case 00510676)).

Astrid Schoger on behalf of the Bavarian State Library

hen running a Publishing Sync Job and looking at the assciated 'View' we get the following information

Mon Jan 07 09:06:40 AEST 2019 INFO sync all configurations for IE publishing
Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614
Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 18981613
Mon Jan 07 09:06:41 AEST 2019 INFO Handling new IEs
Mon Jan 07 09:06:41 AEST 2019 INFO Handling Removed IEs
Mon Jan 07 09:06:41 AEST 2019 INFO Handling updated IEs
Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 18981613
Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for configurationId: 18981614
Mon Jan 07 09:06:41 AEST 2019 INFO sync the configurationId: 20975335
Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975337
Mon Jan 07 09:06:41 AEST 2019 INFO Skipping Profile: 20975337 because it is inactive.
Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 20975337
Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975338
Mon Jan 07 09:06:41 AEST 2019 INFO Skipping Profile: 20975338 because it is inactive.
Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 20975338
Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975389
Mon Jan 07 09:06:41 AEST 2019 INFO Handling new IEs

This is Ok but the additional information 'name/label' would be helpful

For example in the above -

Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614

the informatin would be better dispayed as follows

Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614 (Handle Publishing)

where 'Handle Publishing' relates to the 'Data Management: Publishing Configuration | Details | General Details | Name'

Another example

Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975337

the infomation would be better displayed as

Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975337 (Rosetta2Alma)

where Rosetta2Alma is the filed located in 'Data Management: Publishing Configuration | Details | Profile Details | Name'