Primo Concepts, Components, and Relationships

Primo Configuration Levels

For on-premises customers Primo’s configuration data can be managed at different levels to allow institutions in multi-tenant environments to work more independently of each other. The configuration data in Primo’s Back Office is split into the following levels of configuration:

Out of the Box (OTB) – Configuration data (such as normalization rules and view templates) that is supplied by Ex Libris and managed by Ex Libris Support.
Installation – Configuration data that belongs to the whole installation (such as a consortium) and can be shared by all institutions in the installation, but must be configured by installation-level staff users.

The following data must be configured at the installation level:
- Search engine processes
- General configuration
- Some code and mapping tables (For details, see sections Code Table Configuration Restrictions and Mapping Table Configuration Restrictions.)
- Tools – Create X-ref, Import/Delete PNX Extensions, Export User Generated Data, and PNX Extensions Loader.
Institution – Configuration data that belongs to a specific institution and can be configured by installation-level and institution-level staff users.

The following data must be configured at the institution level:
- Data sources
- Pipes
- Scopes
- Restricted delivery and search scopes
- Some mapping tables

The above configuration levels are indicated by the Owner field that appears for each relevant configuration element in the Back Office. For more information, see The Owner Field.

Search engine configurations (not processes) can be configured at the installation or institution level.

The Owner Field

Each configuration element in the Back Office contains an Owner field that is used to separate institution-specific data from shared and common data.

Installation-level staff users will need to select an owner from a drop-down list that includes all of the institutions and the installation name if the data element allows it to be configured at the installation level. For more information on the installation name, refer to The Installation Name.

Owner Field Drop-Down List (Data Sources Example)

For institution-level staff users, their institution will always be pre-selected.

Preselected Owner Field (Data Sources Example)

The Installation Name

A name is given to all Primo installations. For consortia with multiple institutions, this can be defined as the name of the consortium. For installations with a single institution, this can be defined as the name of the institution with Installation added as a suffix. For example, if the institution name is Central College, the installation name would be Central College Installation.

By default, the installation name is set to Installation unless you specify a different name in the Installation Name parameter on the Primo Home > Advanced Configuration > General Configuration > Installation subsystem page.

Default Installation Name

Institutions

The Primo institution is a main element of the Primo system and many aspects in the system can be linked to an institution. All users and resources belong to a specific institution. Resources can also belong to a specific library within an institution. A single Primo site may have multiple delivery systems and Primo must know to which delivery system each user belongs.

The following is defined for each institution:

IP Addresses – Every institution has a defined set of IP ranges. Specifying the range of the IP addresses of the institution enables the system to assign a default institution to users who have not signed in to the system.
Base URLs – For each institution you must define base URLs. This information is used to access the institution's appropriate delivery system, including MetaLib, SFX, digital repository, and ILS (such as Aleph).
Libraries – The Primo library is mainly used to manage the system's physical resources. Although all resources belong to an institution, not all resources belong to a library within an institution.

A multi-institution site may want to define a "central" institution to represent the consortium level. The "central" institution can be used in the following cases:

To create a cross-institutional or "central" view. Every view must be linked to a default institution, which could be one of the member institutions or a "central" institution.
There is a data source that belongs to some or all of the institutions. Data sources must belong to an institution.

It should be emphasized that a "central" institution has no special functionality and is just like a regular institution.

How are Users Linked to an Institution?

In the Primo Front End, users always belong to an institution. The assignment of the institution is based on the user’s credentials. If the user is not signed-in, the assignment is either based on the user's IP address or the default institution of the view (which is configured in the Views Wizard). If the user is off campus and not signed-in, the institution will always be the default institution of the view.

Staff Users

Primo allows you to provide different levels of access to the Back Office interface by assigning specific roles to staff users. The following roles are valid:

Superadmin – For on-premises customers this role provides users with access to all views and functions in the Back Office user interface. This role can only be assigned at the installation level.
Admin – This role provides users with access to most menus and functions, but it does not provide access to the Configure User Groups and PDS Configuration wizards (on-premises customers only).
Data Administrator – This role provides users with access to the Pipe Monitoring page, Pipe Configuration wizards, and pages that are related to pipes, such as scheduling pipes, importing/exporting PNX extensions, and creating the PNX X-Reference table (on-premises customers only).
Pipe Operator – This role provides users with access that is similar to the Data Administrator role, but these users cannot configure pipes, data sources, and scope values.
Normalization Rules Editor – This role is particularly concerned with creating and maintaining normalization rules and mapping tables.
Staff User – This role provides users with access to tags and reviews management (on-premises customers only), monitoring, and reporting.
View Manager – This role provides users with access to the Views wizard and other pages that are related to creating and managing views.
Reporting – This role provides users with access to the following pages:
- Scheduled Reports and Dashboards page (Primo Home > Schedule Primo Analytics) – Allows users to manage scheduled report and dashboard jobs.
- Primo Analytics interface (Primo Home > Primo Analytics) – Provides access to the Primo Analytics interface, which allows you to create jobs and dashboards and run reports.
- Primo Reports page (Primo Home > Primo Reports) – Provides access to the deprecated Primo Reports page, which is used to view BIRT reports.
Operational – This role provides users with access to the Monitor Primo Status, Primo Analytics, Schedule Primo Analytics, Schedule Tasks, Primo Viewer, and Tags and Reviews Management.
Total Care User – This role provides users with access to the following pages:
- Primo Utilities (Primo Home > Primo Utilities) – Provides access to the File Uploader Utility and UI Customization Package Manager pages only.
- Scheduled Reports and Dashboards page (Primo Home > Schedule Primo Analytics) – Allows users to manage scheduled report and dashboard jobs.
- Primo Analytics interface (Primo Home > Primo Analytics) – Provides access to the Primo Analytics interface, which allows you to create jobs and dashboards and run reports.
- Primo Reports page (Primo Home > Primo Reports) – Provides access to the deprecated Primo Reports page, which is used to view BIRT reports.
Utility user – This role provides users with access to the following pages:
- Primo Utilities (Primo Home > Primo Utilities) – Provides access to the File Uploader Utility and UI Customization Package Manager pages only.
- Scheduled Reports and Dashboards page (Primo Home > Schedule Primo Analytics) – Allows users to manage scheduled report and dashboard jobs.

For on-premises customers staff users may be given installation-level or institution-level permissions.

Publishing Pipes

The pipe is the set of steps that the source records go through before being turned into the PNX record. Every pipe includes the following steps: harvesting, normalization and enrichment, loading into the Primo database, dedup and FRBRization. Before configuring your system's pipes, you must configure the data sources, normalization rules, and enrichment sets to be used with your pipe.

Data sources – You must first identify and configure your institution's existing and planned data sources that will be harvested by Primo, to ensure a successful implementation of the system. There are three types of data sources:
- Data sources from an Ex Libris product, such as Aleph, Voyager, DigiTool, MetaLib, or SFX.
- Data sources that are not from an Ex Libris product, but are based on a standard format such as MARC21 and Dublin Core.
- Data sources that are not from Ex Libris products and are not in any standard format.
Normalization rules – Normalization rules are sets of rules that convert source records to the Primo Normalized XML record - the PNX. Generally every data format requires its own set of Normalization rules. These Normalization rules can be shared by multiple publishing pipes.

Primo has normalization rule templates for standard formats and specific systems. In most cases, it is necessary to localize the templates to a certain extent. The normalization rules that generally require localization are listed in PNX Mandatory Fields in the Normalization Rules section of the Pipes Configuration wizard. You can create your own normalization rules by copying the most suitable rule set and then localizing it.
Enrichment sets – An Enrichment set is a group of routines that enrich the source records based on external data or additional programs. Primo has a number of default enrichment sets for standard formats and/or systems which can be used when a publishing pipe is defined. It is also possible to define new sets.

Delivery Functionality and Configuration

Delivery of resources is one of Primo's two basic functions, alongside discovery of resources. In terms of delivery, Primo offers the following:

Availability status – The availability status appears in the Search Results page of the Front End interface and indicates to the user the availability of the resource.

The availability indicator displays the availability status for the following types of items:
- Physical – the availability text indicates whether the item is in the library.
- Online – the availability text indicates whether access to the resource is restricted. Restrictions can be defined by creating restricted delivery scopes.
- Remote (MetaLib) and Central Discovery Index – the availability status indicates whether full text is available for the item.
Front End Availability Text

For physical items, Primo uses three basic statuses:
- Available – Indicates that at least one copy is available.
- Unavailable – Indicates that no copies are available.
- Check_holdings – Indicates that the status is unknown and users will need to check detailed holdings by either linking to the ILS or fetching the data if your ILS supports OPAC via Primo. This status is generally used for journals and other multi-volume titles, because Primo does not know which volume the user wants.
The availability status is stored in the PNX record and can be updated in real time using RTA (Real-Time Availability). For more details about RTA, see the Primo Interoperability Guide.

The system displays an availability status per Primo location in the Locations tab. For more information on how to create Primo locations, refer to the Primo Technical Guide.

In addition to the availability per location, Primo displays a calculated availability status in the brief results list. This status is considered calculated because a single PNX (Primo normalized XML record) may include multiple locations. Deduped records will usually include multiple locations. The availability status that Primo displays in the brief results accounts for the status of all the locations in the record.

The calculated availability status can be determined in different ways. This is especially relevant in multi-institution sites where deduped records can belong to different institutions.

The system default is to display availability in relation to the default institution of the view, or if a specific library is searched, the library. It is also possible to display an availability status that takes the availability of all the institutions into account. This is determined by the basic setup that is defined during the initial setup period. If you are a multi-institution site and are not setup in this way, consult with Ex Libris Support. For more information, refer to Calculated Availability Status.

By default, the system displays a single location within the calculated availability status for physical items (delivery category = Physical Item or Microform). For example:
- Available in Green Library Main stacks DD987.F2
- Checked out - Green Library Main stacks DD987.F2
The system will attempt to display the most relevant location based on the calculated availability status. The location is added to the Calculated Availability Text code table using a placeholder. If the placeholder is removed, the location will not display. For more details, refer to Calculated Availability Text in Code Tables.
GetIt! links – There are two GetIt! links. The first GetIt! link offers the optimal delivery option based on the resource type and availability. The second GetIt! link offers additional services that may be relevant to the item.

The following aspects of the delivery functionality can be configured via code and mapping tables in the Primo Back Office:

Calculated and fixed availability status texts.
GetIt! links (which defines Primo delivery options), GetIt! tabs, and GetIt! text.

The configuration of availability status texts and GetIt! links is explained in the following sections:

Delivery Category
The "Virtual" Delivery Category
Calculated Availability Status
Data Source

Delivery Category

The delivery category divides resources in groups that may behave differently during their delivery. The categories that are currently used are described in the following table:

Delivery Categories
Delivery Category	Description
Physical items	All types of physical items, including books, CDs, and tapes, with the exception of microforms.
Microform	Includes any form of microform. In the default delivery configurations, microforms behave as physical items. Microforms are added as a separate category in order to assign them lower priority when records are merged during the Dedup and FRBR processes.
SFX resource	Includes all resources in the SFX KnowledgeBase.
Online resources	Includes digital and electronic resources.
Remote search resources	These are records located via MetaLib or Central Discovery Index. For Alma-Primo environments, see Configuring Primo Delivery of Alma Data and Services.
MetaLib resources	Resources loaded from the MetaLib knowledgebase.
Alma-P	Used for physical items from Alma. For more information, see Configuring Primo Delivery of Alma Data and Services.
Alma-E	Used for electronic items from Alma. For more information, see Configuring Primo Delivery of Alma Data and Services.
Alma-D	Used for digital items from Alma. For more information, see Configuring Primo Delivery of Alma Data and Services.
Alma-C	Used for collections from Alma. For more information, see Configuring Primo Delivery of Alma Data and Services.

The "Virtual" Delivery Category

A record that is available online may also have physical items. In this case, Primo assigns a "virtual" delivery category of Physical Item so that the record will have two GetIt 1 links: one for the Online delivery category and a second for the Physical delivery category. In addition, Primo indicates whether there are physical items in the availability status.

Calculated Availability Status

The availability status is used to indicate different types of availability options for the different groups of delivery categories.

For physical items and microforms, there are fixed statuses (which display in the Locations tab) and calculated availability statuses (which display in the Brief Results list). Refer to the following table for descriptions of the availability statuses.

Physical Item Delivery Status
Availability Status	Description
Fixed:
Available	The item is available.
Unavailable	The item is unavailable.
Check_holdings	Primo does not have enough information and detailed library holdings must be checked. This status is typically used for journals and other multi-volume records for which Primo does not include a complete listing of the institution's holdings.
Calculated (see the Calculated Availability Text code table for more details):
Available in main institution	There is an available item in the institution of the view. default.delivery.code.available_in_maininstitution
Unavailable in main institution - more	The item is not available in the institution of the view, but it belongs to additional institutions. default.delivery.code.unavailable_in_maininstitution_more
Unavailable in main institution - no more	The item is not available in the institution of the view and does not belong to additional institutions. default.delivery.code.unavailable_in_maininstitution_nomore In order to display a different label in the Front End, Primo distinguishes between this status and the Unavailable in the main institution - more status.
Check holdings in the main institution	The institution of the view has the item, but because Primo does not have enough information, the user must check the detailed holdings in the ILS. default.delivery.code.check_holdings_in_maininstitution
Does not exist in the main institution	The institution of the view does not have a copy of the item. default.delivery.code.does_not_exist_in_maininstitution
Available in institution	The item is available in the institution being searched. This status is only used if the user searches a specific institution and INSTITUTION_AVAILBILITY is set to Y (system default) on the General Configuration (Delivery) page. default.delivery.code.available_in_institution
Unavailable in institution	The item is not available in the institution being searched. This status is only used if the user searches a specific institution and INSTITUTION_AVAILBILITY is set to Y (system default) on the General Configuration (Delivery) page. default.delivery.code.unavailable_in_institution
Check holdings in institution	The institution being searched has the item, but because Primo does not have enough information, the user must check the detailed holdings in the ILS. This status is only used if the user searches a specific institution and INSTITUTION_AVAILBILITY is set to Y (system default) on the General Configuration (Delivery) page. default.delivery.code.check_holdings_in_institution
Available in library	The item is available in the library being searched. This status is only used if the user searches a specific library and LIBRARY_AVAILBILITY is set to Y (system default) on the General Configuration (Delivery) page. default.delivery.code.available_in_library
Unavailable in library	The item is not available in the library being searched. This status is only used if the user searches a specific library and LIBRARY_AVAILBILITY is set to Y (system default) on the General Configuration (Delivery) page. default.delivery.code.unavailable_in_library
Check holdings in library	The library being searched has the item, but because Primo does not have enough information, the user must check the detailed holdings in the ILS. This status is only used if the user searches a specific library and LIBRARY_AVAILBILITY is set to Y (system default) on the General Configuration (Delivery) page. default.delivery.code.check_holdings_in_library
Available in my Institution	There is an available item in the user's institution. default.delivery.code.available_in_my_institution
Available in other Institution	The user's institution has the item, but it is unavailable. However, the item is available in another institution. default.delivery.code.available_in_other_institution
Unavailable in all Institutions	The item is not available in any institutions. default.delivery.code.unavailable_in_all_institutions
Check holdings	The user's institution has the item, but Primo does not have enough information and detailed holdings in the ILS must be checked. default.delivery.code.check_holdings
Does not exist in my Institution	The user's institution does not have the item and: Check holdings – other institutions have the item, but there is not enough information and detailed holdings in the ILS must be checked. default.delivery.code.does_not_exist_in_my_institution_check_holdings Available in other institutions – the item is available in another institution. default.delivery.code.does_not_exist_in_my_institution_available Unavailable in all institutions – the item is not available in any other institution. default.delivery.code.does_not_exist_in_my_institution_unavailable

For online resources, SFX journals, and MetaLib resources, Primo calculates the availability status by matching the user with the restricted delivery scopes that are defined for the record. The restrictions and delivery configuration settings are defined in Restrictions and Delivery Configuration Wizard. Refer to the following table for descriptions of the calculated availability statuses.

Online Resource Delivery Statuses
Calculated Availability Status	Description
Not restricted	The item can be accessed by the user.
Restricted access	The user cannot access the item.
May be restricted	Primo cannot calculate whether the user's access is restricted or not.

For remote source resources, such as records retrieved via Central Discovery Index or MetaLib, the availability status indicates whether there is full text or not for the item. The availability of full text is checked via SFX. Refer to the following table for descriptions of the availability statuses.

Remote Source Delivery Statuses
Availability Status	Description
Fulltext	The item's full text is available.
No full text	The item does not have full text.
Full text unknown	Primo does not know whether or not there is full text for the item. This status is used when it is not possible to check via SFX.
Citation available	The item does not have full text, but it does have a citation.

Data Source

By default, all the data sources share the same configuration. You can configure GetIt! links and text for tabs per data source. For example, for a specific data source you can define a different GetIt! link than the link specified for the rest of the records with the same delivery category and availability status. To do this, you must add a configuration for a specific data source. For instructions on adding a configuration for a specific data source, see Editing Data Sources.

Scopes

The term “scope” is used for various entities in Primo. The following table summarizes the various entities, their purpose, and how they are configured in Primo.

Summary of Scopes
Entity	Description	Back Office Configuration
Scope values	Scope values are used to tag local PNX records as belonging to a specific group of records. There are three types of scope values: Search Restricted Search Restricted Delivery	Scope values are defined on the Scopes Values Configuration page (Primo Home> Ongoing Configuration Wizards > Pipe Configuration Wizard > Scopes Values Configuration). You can configure each scope to be one or more of the following types of scopes: search, restricted search, and restricted delivery. During the normalization process, PNX records are tagged as belonging to a specific scope by adding the scope value to dedicated fields. The search scope and restricted search scope are then copied to the generic search/scope field in the PNX. The rules are included with the out-of-the-box normalization templates.
Search scope values	Used to group records for use in searches.	On the Scopes Values Configuration page (Primo Home > Ongoing Configuration Wizards > Pipe Configuration Wizard > Scopes Values Configuration), define the scope values that are used for searches. Note that every Primo institution is added automatically as a search scope value. Add the search scope value to the search/searchscope field in the PNX using the normalization rules. In the View Wizard (Primo Home > Ongoing Configuration Wizards > Views Wizard), add the search scope value to a search scope.
Restricted Search Scope	Used to group records that should be restricted in terms of search. Only users that match specified criteria are permitted to search for these records. For more information, see Restricted Search Scopes.	On the Scopes Values Configuration page (Primo Home > Ongoing Configuration Wizards > Pipe Configuration Wizard > Scopes Values Configuration), define the scope values that are used for restricted searches. Add the scope value to the search/ressearscope field in the PNX via the normalization rules. On the Define Restrictions for Search Scopes page (Primo Home > Ongoing Configuration Wizards > Restrictions and Delivery Configuration Wizard > Define Restrictions for Search Scopes), define the users who are allowed to discover the restricted search scope records.
Restricted Delivery Scopes	Used to group e-resource records that are restricted in terms of delivery. Restricted Delivery scopes can be used in combination with the following delivery categories: Online Resource MetaLib Resource SFX Resource Alma-E Alma-D Users that do not have access to the e-Resource will get one of the following availability statuses: Restricted access Maybe Restricted	On the Scopes Values Configuration page (Primo Home > Ongoing Configuration Wizards > Pipe Configuration Wizard > Scopes Values Configuration), define the scope value in the list of scopes values as being used for restricted delivery. Add the scope value to the delivery/resdelscope field in the PNX using the normalization rules. On the Define Restrictions for Delivery Scopes page (Primo Home > Ongoing Configuration Wizards > Restrictions and Delivery Configuration Wizard > Define Restrictions for Delivery Scopes), define the users who are allowed to discover the restricted search scope records.
Search Scopes	Search scopes define the groups of records from which end users can search in the Front End UI. Search scopes may include any of the following sources: PNX records from the local Primo database – represented by search scope values Central Discovery Index MetaLib quick-sets Other search engines accessed via a Deep Search adaptor	Search Scopes are defined in the Views Wizard (Primo Home > Ongoing Configuration Wizards > Views Wizard) and can include one or more local search scope values, a single MetaLib quick-set, and one or more Deep Search adaptors including Central Discovery Index.

Restricted Search Scopes

This section explains what restricted search scopes do and when they should be configured. See Scopes for a more general explanation of the scope entities used in Primo.

It is important to understand how Restricted Search Scopes work because they affect all searches within an environment. If a large number of restricted search scopes are defined, response times can be affected and even cause a crash of the SE. For this reason a limit of 20 restricted search scopes has been defined for the entire environment.

When are Restricted Search Scopes not Needed?

Many library catalogs include records that need to be suppressed from public view for some reason (such as the record is no longer relevant). These are records may have also been suppressed in OPACs and should not be discoverable in Primo as well. Restricted Search Scopes are not intended to handle these kinds of records. Instead, these records should be suppressed as follows in Primo:

The records should be suppressed from the data source and never published into Primo. All of the Ex Libris ILSs and most non-Ex Libris ILSs enable the suppression of groups of records during the publishing stage.
If it is not possible to suppress these records during the publishing stage, another option is to ensure that the records are not added to any of the scopes in the search/searchscope field of the PNX during the normalization stage. If the records do not belong to any scope, they cannot be discovered in Primo.

When are Restricted Search Scopes Needed?

Restricted search scopes can be used to restrict searches within a record or group of records to specific types of users. In other words, the records must be searchable in the Primo but not by everyone. In general, most Ex Libris customers (such as academic libraries) do not need this functionality. In most libraries the records harvested into Primo are open to all (note that delivery to the full text or to a library request may be limited). The need is more common in corporate libraries but there can be exceptions in academic libraries.

Restricted Search Example

Library A harvested the results (which includes a description and link to the full text) from an unpublished physics experiment into Primo that should be discoverable only by users linked to the Physics department.

In order to restrict access, the customer can include these records in their standard institutional search scope and also tag them as having a restricted search scope. Only users belonging to the Physics Faculty (based on user group returned by PDS/Primo Authentication Manager) will be able to discover these records. The following section explains how this works.

How do Restricted Search Scopes Work?

Restricted search scope are tags that are added to PNX records and indexed by the SE. When restricted search scopes are defined within a Primo environment, the SE automatically appends the restricted search scopes to all queries with a Boolean “AND NOT” unless the active user is allowed to discover the restricted scope. Specific user groups can be defined as “allowed” to access the restricted scopes in the Define Restrictions for Search Scopes option, which is explained below.

Because the system does not currently take the owning institution into account for multitenant environments, restricted search scopes defined for institution A are appended to all searches, including those invoked from a view that belongs to another institution.

The following is an example of a debug log in which all Restricted Search scopes defined in the environment were added to the query because a user was not permitted to access any of them:

2015-08-27 07:20:51,145 DEBUG [t-http-bio-1701-exec-677] [c-JaguarSearchEngineImpl] [O -(31261958,161861139,null)] - Users query:((history)) AND NOT scope:(48WAT_ukryty) AND NOT scope:(32EUC_COLLJRC) AND NOT scope:(47STAT_ML_DS) AND NOT scope:(44NHM_CALM_SUPPRESS) AND NOT scope:(47STAT_LMS_DS) AND NOT scope:(351EDP_CISION_RS) AND NOT scope:(39USA_NOT) AND NOT scope:(44CCC_SUPPRESSED) AND NOT scope:("45DDA" ) AND NOT scope:(351EDP_SFX_RS) AND NOT scope:(44SGUL_SUPPRESS) AND NOT scope:(33UBO_ALEPH_TOHIDE) AND NOT scope:(44NHM_ALMA_DEL_RS) AND NOT scope:(39BRG_NOT) AND NOT scope:(351EDP_ALEPH_RS) AND NOT scope:("NOT") AND NOT scope:("NOT_953") AND NOT scope:(47STAT_SFX_DS) AND NOT scope:(MIT_ALEPH_STA) AND (scope:("39UDN"))

Configuring Restricted Search Scopes

The Scope Values Configuration page (Primo Home > Ongoing Configuration Wizards > Pipe Configuration Wizard > Scope Values Configuration) allows you to define all three types of scopes: Search, Restricted Search, and Restricted Delivery.

To define a restricted search scope:

On the Scope Values Configuration page, use the Create a new scope value section to create new scope value, making sure that you select the Restricted Search check box.

Scope Values Configuration Page
On the Full Normalization Rule Configuration page (Primo Home > Advanced Configuration Wizards > Full Normalization Rule Configuration), edit your normalization rules set and add a rule (such as the following rule) to the search/ressearchscope field:

Normalization Set Editor
On the Define Restrictions for Search Scopes page (Primo Home > Ongoing Configuration Wizards > Restrictions and Delivery Configuration Wizard > Define Restrictions for Search Scopes), define the user groups that are permitted to access the restricted search scope. Users can be identified by institution, whether they are on or off campus, and user group.

Deep Search Adaptors

Deep Search adaptors are Primo plug-ins that enable you to extend Primo search capabilities beyond Primo local searches and remote searches via MetaLib, using the standard Primo services and view. Out of the box, Primo provides an EBSCO plug-in, which is configured with search scopes in the Views wizard. For more information, see Configuring the EBSCO Plug-In.

In addition, on-premises customers can create their own adapters to extend Primo’s search capabilities. For more information on Deep Search adaptors, refer to the following page in the Ex Libris Developer Network:

https://developers.exlibrisgroup.com/primo/integrations/search/deepsearch

Central Discovery Index

Central Discovery Index (CDI) is a centralized index that encompasses hundreds of millions of records of global or regional significance that are harvested from primary and secondary publishers and aggregators. CDI is maintained by Ex Libris and offered as a service to all Primo customers. For general information about CDI, see An Overview of the Ex Libris Central Discovery Index (CDI).

Views

The view is the Primo Front End user interface, which is the way end-users interact with the Primo system. Your institution can have its own fully customized view with one or more tabs. Tabs enable a site to divide the Primo repository and records from remote resources into resource groups or types. Within a tab, one or more search scopes can be defined based on the values defined in the scope values section of the Pipes wizard.

View Components and Relationships

Mapping Tables

The Back Office uses mapping tables for configuring different aspects of the system. Most of the mapping tables are parameter tables that configure different aspects of the system, except for the normalization mapping table which maps the normalization rule source to its target. The mapping tables are divided into subsystems according to the various sub-modules of the Back Office.

Deployment

The Back Office enables you to configure many different aspects of the system, such as end-user views, search scopes, and mapping tables. These changes are not applied to the Primo Front End until you decide to deploy them. You may deploy them individually as you make configuration changes with the configuration wizards or you may decide to wait and deploy them all at once using the Deploy All page.

The system can process only one deployment at a time. If several users attempt a deployment at the same time, Primo places the requests in a queue.

PNX Extensions

Primo allows you to import enrichment content (such as full text, abstracts, and tables of contents), which are indexed to help users find relevant results. In addition, you can configure Primo to display snippets of this content in your view.

Primo allows you to use the following methods to import (load) enrichment content into the P_PNX_EXTENSION database table:

File splitter plug-ins (such as the XML, HTML, or user-defined file splitters that allow you load extensions) – This method is meant to be used while you are loading source records into Primo. It allows you to load source records and add extensions at the same time, using the IFileSplitter interface. For more information, refer to File Splitters in the Ex Libris Developer Network.
Import PNX Extensions tool – This method is meant to be used after you have already loaded your PNX records, allowing you to associate extensions from third-party sources (such as Brooks & Taylor, LibraryThing, and Syndetics) with the PNX records. For more information, refer to the following sections:
- The Create XREF Tool
- The Import PNX Extensions Tool
PNX Extensions Loader tool – This method allows you to add extensions after you have already loaded your source records into Primo. It is much faster than the Import PNX Extensions tool and utilizes the IFileSplitter interface, which is more intuitive to implement than the PNXExtensionPlugin interface. For more information, refer to the following sections:
- The PNX Extensions Loader Tool
- PNX Extensions Loader Tool in the Ex Libris Developer Network
Each of the above methods has its own advantages and should be used in cases where it best fits the application.