Testing the Elements Synchroniser

This article describes a possible workflow for testing your Elements system's synchroniser and preparing it for use in a live environment. This involves:

• Checking that you are receiving expected results from the data sources you have access to; and

• Modifying search settings to ensure you are receiving an acceptable amount of publications for your researchers.

1. Ensure access has been arranged with the data sources. See Data Sources Configuration for details.

2. Ensure that the relevant sources are enabled. See Manage Data Sources for instructions.

3. Ensure you have a good understanding of the synchronisation process.

4. Add one user to the sync queue for all relevant sources to check that the sources are responding correctly.

Select one or more users (select users that are likely to return records from all sources) and test that all sources that can be searched by adding them to the sync queue. Do not modify search settings at this point as your aim here is to test that sources are being accessed and returning results!

You will be able to check the user’s search history on the landing page, the system presents logs and search errors in the System Logs. More detailed logs for each data source are present on the application server under [Main Elements Directory]/Sync.Synchronise/logs.

If you are unable to identify the problem please speak with your Symplectic implementation manager.

Once completed successfully, do not accept any pending publications and select “Reset [user name]’s pending publications” to clear out the user’s relationships to the data.

If at any point of the process, you accidentally accept a publication, you can clear its relationship to the user by declining it on the Accepted page of “My Publications” and select “Reset [user name]’s declined publications."

Note: Crossref works differently from other sources in that it searches by object and not by user. This means that it will search against the existing publications of the system and will add a Crossref record if it finds a match. It is a background process and needs existing publications in the system to search. It may require some time to run and may not immediately return results.

Now that you have confirmed that you are able to retrieve records from external sources you are ready to begin configuring search settings. Search settings can be modified on three levels:

1. System-wide level search settings in the Publication module settings.

2. Primary group level search settings in the primary group’s relevant configuration settings.

3. User level search settings in each individual’s search settings page, accessible from their landing page.

A combination of the three can be employed, but this at the discretion of the institution. The more “in-depth” curation of search settings that is done, the higher accuracy in the search results, but the more time is required to achieve.

Before deciding on how to approach this, it is imperative that Elements Module Admin is understood, including Overriding module settings. In particular concentrating on Publication module settings and the discussion on default search terms.

To stress on some of the points raised in the above guides, it is important to understand the difference in the search settings applied on level 1 and 2 against those put in level 3.

The search settings set in 1 and 2, control the search settings for any new users entered into the system, that is, users that are imported for the first time after the settings are set. In order to apply any changes to existing users, you will need to ‘Reset search terms’ under System admin > General settings > Global settings (in 5.x: System Admin > Setup > Global Settings). You can reset the search terms of existing user groups or the whole organisation to match those based on the current settings for new users.

Warning! Beware of including ‘Users with modified search terms’ in the reset as this will overwrite any manual changes made on an individual user level that is, on level 3.

For this reason we only recommend making edits to individuals’ search settings after their defaults have been set.

In the following, we will focus on modifying search settings on level (b) that is, on a primary group level.

Details on how to build this are provided in Managing User Groups

It is not imperative that you have figured out your entire group structure as the following steps can be iterated at a later date.

Select at least two users from each primary group, one with a “common” name and another with an “uncommon” name. This spread will allow you to see how changes made on a primary group will affect both ends of the spectrum.

This manual group can be set at a sub-Organisation level and can sit alongside the main Elements group structure, to ensure it doesn’t interfere with further development of the group structure. Remember that users can be a member of more than one manual or auto group. The manual group can be deleted at a later date.

This will enable them to impersonate all users within the group and modify group’s search settings. This step is not required but may help, if you are considering delegating curation activities to other member of staff.

This will ensure that only this group is searched.

This may take some time to run depending on data sources.

This can be done by impersonating each user. Also a quick view of the number of pending publications for each member can be accessed in the System Administrator dashboard or a report produced in the Reporting tab

Click “Reset [user name]’s pending publications” to clear out the user’s relationships to the data. This will ensure that your previous results are not mixed in with newer results.

This can be done on each primary group’s group settings page in System admin > Users & Groups > Group management > Manage groups. Examples here can include applying address term(s) which could be: an institution name, a school or faculty name (i.e. the level in your institution you primary group is representing), or any other fields that may appear in the publications produced from that primary group.

Note: Presently, the address field is only applied to user’s search settings that are deemed “common” as compared to the 2010 US census. Note, this process is imperfect as it does not handle Asian or Middle Eastern names (i.e. names not common in the US in 2010). 

Through the global settings page, to ensure changes made in step 9 are applied.

Work from looser search settings to tighter ones as required. Note that academics tend to be more forgiving of having to accept a handful of false positives, than having to key in publications not returned.

This is in order to apply the settings agreed upon to all users with the correct primary groups.

Note: This is one possible approach at this point, more options are possible. You may wish to release it as it is, expand the pilot group or start doing individual level search settings modifications.

Please consult the following FAQs on common user-centric search problems:

• Why is the database search failing or missing publications?

• Symplectic Elements Trouble-shooting Guide for Search Settings