On-premises installation of Axiell Collections
An on-premises installation of Axiell Collections requires three components to be installed separately and in the following order on a Windows server:
- A database - Microsoft SQL Server or SQL Express with SQL Server Management Studio
Installing the SQL database on the server is typically the responsibility of the customer. Axiell can provide advice and assistance as required.
- The Collections Model Application
This is the collections management heart of Axiell Collections. Different models of the Collections application are available for different types of collection:
and for combinations of collection types:
The XPlus variant is designed for organizations with all three types of collection:
Typically, an organization deploys a single Collections application with a single database.Single vs Multi-tenancy, and multiple environments
There are, broadly, two types of Collections installation:
- A single instance of the Collections application is installed and accessed by staff. This is the most common type of installation.
- In some large organizations comprising multiple institutions, each institution has its own Collections application (typically the same one, XPlus for example) with space allocated in a shared database. We call this a multi-tenancy installation.
Some large organizations comprising multiple institutions may require each institution to use its own instance of the Collections application with each institution restricted to its own data in a shared database.
Consider the ACME Museum Group, which comprises ten separate museums. A single database is used by the entire group, and each museum is only permitted access to its own object data, with Head Office having access to all object data.
In this case:
- A single Axiell Collections installation is set-up on the web server, accessible to all museums in the group.
- Within this single Axiell Collections installation on the web server, each museum has a folder that contains an instance of the same Collections application, XPlus for example.
- The organization as a whole shares a SQL Server database and each museum in the Group is only permitted to access its own data. This is achieved by assigning each museum a database record number range for any database tables that will hold their data:
- The structure of a table in the database is specified in a
.inffile in the
\datadirectory: the structure of the Thesaurus table, for example, is called
- By default, each
.infspecifies a single dataset A record number range in a database table used to group similar types of records. A database table will always have one dataset (with the full range of record numbers), but there may be one or more sub-divisions within this record number range. It is possible to work with (e.g. search) a sub-divided dataset or the full dataset (each sub-division simultaneously). Each dataset is considered a data source in its own right. with a lower and upper record number limit. It is possible to specify multiple datasets in a
.inffile however, one for each institution for instance, each with a specific record number range.
In this example, the folder for each museum includes a
\datadirectory and a copy of the
If the Thesaurus table should be available to all museums, we would not specify record number ranges for each museum in
thesau.infand all records in the Thesaurus table would be accessible to every museum in the group. On the other hand, if each museum should only have access to its own object data, a record number range would be specified for each museum in both
extern.infand a copy of these
.inffiles would be copied to the
\datadirectory for each museum.
- The structure of a table in the database is specified in a
See What is a
.inffile? for more details.
In this example, access to records by Head Office could be handled through access rights (giving Head Office access to each museum application, or perhaps there could be an additional XPlus application for Head Office with
.inffiles specifying the entire record number range).
While most organizations deploy a single Collections application that is accessed by staff, any organization can have more than one Axiell Collections environment: Test, Training, Development and Production for example.
Axiell Collections is deployed in each environment and (usually) has a separate SQL Server database and perhaps different access rights.
See 5. Deploy the Axiell Collections package for details
Multiple environments AND Multi-tenancy
As we've seen:
- Each environment has its own SQL database.
- Each institution in a multi-tenancy implementation has its own Collections application and
.inffiles specifying record number ranges in any database tables where access to records should be restricted to each institution.
So, for an organization with ten museums in a multi-tenancy installation with more than one environment, Development and Production for example:
- The Axiell Collections software is deployed in a Development environment.
- In a Development folder on the Windows server the Collections application is installed for each museum in its own sub folder.
settings.xmlfile in the Development environment references the 10 Collections applications in the 10 sub folders of the Development environment. This is explained here.
Note: In a multi-tenancy installation, users are assigned to groups, and each group is authorized to access a particular Collections application when its users log in.
- This is replicated in the Production environment but with a different SQL Server database referenced in each
Thus each environment has its own Axiell Collections installation, which will appear similar to this in IIS (Internet Information Services):
In this example, when users log into the ACME Development environment, the
settings.xmlfile in that environment is configured to point each user to a specific Collections application.
Alongside the Collections application we install the Axiell Designer utility where much of the administration of Axiell Collections is performed.
Note: When upgrading Adlib for Windows to Axiell Collections, the database will already be installed and the existing Adlib application is the Collections application (although it may be necessary to update the Adlib application to make it Axiell Collections ready). In this case it is only necessary to install the Axiell Collections software.
- The Axiell Collections software
The Axiell Collections software is deployed in IIS (Internet Information Services) as the Axiell Collections web service; it includes configuration files that point to the Collections application and database. Broadly speaking, the Axiell Collections software is the user interface to the collections data. It is the tools and functionality used to manage collections data.
Why separate the Axiell Collections Model application and Axiell Collections software?
Separation of the Collections application from the Axiell Collections core software ensures that each component can be updated and upgraded independently:
- New versions of the Axiell Collections software are made available fairly regularly and the update is straightforward and is typically performed by the customer.
- Updating the Collections application is less frequent, more complex and typically performed by Axiell staff.