How things work when you're hosted with Symplectic

This article aims to answer some of the most frequently asked questions about how things work when you are hosted with Symplectic. It is intended to complement the Service Level Agreement (SLA).

TABLE OF CONTENTS

Version numbers, upgrades and patches

Each release of Symplectic Elements corresponds to a version (consisting of three numbers), and a patch of that version (consisting of a single additional number). For example: The release 6.18.0.4248 of Symplectic Elements made on 12 Sep 2024 was at that time the latest patch of version 6.18.0 of Symplectic Elements. At a later date, a newer patch for that version was released: 6.18.0.4298.

Symplectic's development and release process is designed to provide feature stability for a given version of Symplectic Elements. The purpose of a patch is to reduce the risks and maximise the security and reliability of the system from your perspective. For example, we do not add, remove or significantly change features in patch releases - we only apply bug fixes and security fixes.

In our Elements Upgrade Packs forum you will find an article per version of Symplectic Elements. We recommend that you follow the article corresponding to the version you are on to get notified when a new patch is available for this particular version. The decision to patch or not should be based on the impact the issues fixed in a patch are having on your system. If you are not impacted, you can choose not to request the patch.

The Symplectic Elements 'system' account

The Symplectic Elements “system” account is for the use of the client, and is not intended for use by Symplectic team members beyond the early stages of your product implementation project. This is an important point of security. The "system" account is the seed account used during product implementation to create the first few individuals' accounts. Once this has been done, the credentials to the account are provided to the client, and not kept by Symplectic. The account can later be used by the client in a "break-glass" situation, to regain access should all other accounts have been disabled by an error in the client's HR feed, for example. Otherwise, it is not ordinarily used.

Should you forget the password, then on request, Symplectic can reset it and provide you with the new value. We will not store a copy of the password ourselves, meaning that you, the client, are the only party with ongoing knowledge of it.

Who can request changes to your environment?

Only the named individuals (your "Environment Authority") have the right to request changes (such as upgrades and patches) to be applied to your environment(s). We will not action such requests from other individuals.

Maintenance windows

As described in the SLA, your environment has a regular weekly 2-hour maintenance window. This window is necessary for the proper maintenance of security, availability and disaster recovery procedures. You should expect some down time of the Elements application during this window, while we apply the server maintenance tasks.

For clients in the Americas (non-Eastern time zone) - Mondays 08.00-10.00 (UK time)
For clients in the Americas (Eastern) - Tuesdays 08.00-10.00 (UK time)
For clients in EMEA - Wednesdays 06.00-08.00 (UK time)
For clients in APAC - Thursdays 15.00-17.00 (UK time)

Note: Maintenance windows are never used to deliver changes that you request to your environment, such as upgrades.

Weekly database maintenance

In addition to the scheduled server maintenance windows, we perform weekly database maintenance to ensure the optimal long-term performance of the Elements databases. This automated process runs every Sunday morning at 4:00 AM (server local time).

This maintenance is a standard database administration practice that includes:

Recalculation of statistics: Ensuring the database engine uses the most efficient query plans.
Index optimization: Rebuilding or reorganizing table indices to repair fragmentation and speed up data retrieval.

The duration of this job is highly variable, depending on the size of the database and the amount of data change during the week. While it typically completes in a matter of minutes, it can occasionally take up to an hour or more.

Impact and Recommendations

During the database maintenance period, the Elements application will remain functional. However, any concurrent jobs that perform intensive data updates may experience deadlocks or timeouts if they clash with the optimization routine.

To minimize the chance of these conflicts, we strongly recommend the following:

Avoid scheduling jobs that cause intensive data changes (such as HR feeds and API data feeds) at or shortly after 4:00 AM on Sundays.
If your regular data feeds cannot be moved, please contact us. We will happily work with you to adjust the scheduled database maintenance time to avoid any conflicts.

Requesting upgrades

We release new versions of Symplectic Elements around every 8 weeks. The features included in a particular version are described in the relevant Release Notes.

Your SLA explains that the cost of 3 upgrades per instance per year are included in your support package. Additional upgrades can still be requested, but fall under chargeable support. Each upgrade of a hosted instance must be requested and scheduled with Symplectic at least two weeks prior to the intended upgrade date. The upgrade will be made to the latest patch of the selected version.

Your preferred version upgrade process may include the testing of the new version of Symplectic Elements on a non-production instance before requesting an upgrade of your production instance to the same version. If a new patch of the version has been released by Symplectic between the two upgrades, it will be applied to the production instance. This may leave your production and non-production instances on different patches of the same version. If it is important to you to align your system patch levels, you can of course schedule a "catch-up" patch for your non-production instance(s).

This is the general process for both upgrades and patches:

1. [You] Create a ticket on this support site, requesting an upgrade to a particular instance.

Please name the instance and version you would like to be upgraded (e.g. Upgrade PROD/TEST/DEV Symplectic Elements to vA.B.C).

2. [We] Respond with a suggested date and time

We schedule this in our Hosting calendar.

3. [We] Update you that the upgrade has been completed

On the day of the upgrade, we will apply the latest patch of the selected version to your instance. We will inform you when the upgrade/patch has completed successfully.

4. [You] Test the upgrade

Depending on the amount of data in your system, it may take a while for the application's background processes to rebuild the Symplectic Elements index and Reporting Database. Once this is complete, we recommend that you undertake appropriate testing to verify that the upgrade was successful.

5. [You] Adjust your customisations where required to work with the new version

Please see the following articles for more information:

For example, please make sure that any custom reports/dashboards are available for you to test in your non-production environment so that any issues are highlighted in advance of your production instance being upgraded.

Requesting patches

We release new patches every other week, containing fixes to relevant versions of Symplectic Elements and/or Discovery. As we are not in a position to know the full details of your institution's use of Symplectic Elements / Discovery, we require you to review the patch content and to make a decision on whether you would like to apply the patch.

Should you decide to patch, the request process is the same as for upgrades (above).

Note: In situations relating to critical security fixes, we reserve the right to patch your instance without scheduling it with you.

Data transfer between instances ("refreshes")

You may on occasion want to "refresh" the data in your non-production instance with the data in your production instance.

To request a refresh, the request process is similar to upgrades (above).

A refresh of a non-production system changes everything that is configurable in Symplectic Elements (front-end) to match the production system, apart from the following:

Authentication settings
Scheduled Jobs
HR Email settings
Database Log truncation settings
Global settings
Repository settings
Branding
Custom reports

Note: If you subscribe to Awards Management, please keep this in mind when refreshing a non-production instance:

All console manual configuration is lost.
All test data is lost.
All forms / document templates / email templates, only in non-production, will be lost.
No documents are copied over on a database refresh so all PDFs in non-production will be lost.
- Links to these documents will no longer work.
- Applications/Reviews/Progress Reports etc will not available, but some of these can be regenerated.
- Forms that have 1 or more attachments included in the PDF, cannot be regenerated and will cause a regeneration error.
User accounts, only in non-production, will be lost.

Note: Any non-production data source that brings data into the system should be refreshed at the same time as Symplectic Elements. An example of this is an RT2 Repository.

Access to the API

Before you start any work with the API, please raise a support ticket for us to create an API Endpoint (include the public IP address/range of the API consumer if known). Once that is completed, any other changes are led by you (but may require assistance to complete). We ask you to do the following:

1. Create an API Account (System Admin) in Symplectic Elements. These are the credentials and permissions for the new API consumer

2. Create an API Configuration (System Admin) in Symplectic Elements. This whitelists the public IP address/range for the new API consumer

3. Restart the API service on the Scheduled Jobs (System Admin) page

4. Create another support ticket to request the new or additional public IP address/range for the new API consumer (if not provided with the "create an API Endpoint" ticket)

Steps 1 through 4 should be repeated for any new API consumers you add.

Notes

We recommend using a single secure endpoint per compatibility level (Repository Tools 1.1, Standard 5.5) as it is not an issue having multiple systems use the same one.
Firewall access to the API endpoints is required and the IP address needs to be owned or controlled by your institution, not your home ISP assigned IP address. This address will be white-listed in our firewall, so that only connections originating from this address will be allowed. If required, you can provide multiple IP addresses, or an IP range
When working remote, your institution might provide you with a VPN connection. In order to have the API traffic from your local machine routed via the VPN IP, the VPN configuration must route all traffic or if split-traffic is configured, your profile/configuration should also have the Elements server IPs added to the traffic routed by the VPN server.

Access to the Reporting Database

Access to the Reporting database - Read-only permissions (default option)

To gain access to the Reporting database with read-only permissions, please raise a support ticket and provide the following details:

Your full name and email address
The IP address you will connect from. The IP address needs to be owned or controlled by your institution and not be your home ISP-assigned IP address. We will whitelist the provided IP address in our firewall so that only connections originating from this address will be allowed. If required, you can provide multiple IP addresses or an IP range.
The name of the Symplectic Elements instance you require access to (e.g PROD, TEST)

Notes

When working remotely, use your institution's VPN. In order to have MSSQL traffic from your local machine routed via the VPN connection, the VPN configuration must route all traffic. Or, if split-traffic is configured, your profile/configuration should also have the Symplectic Elements server IPs added to the traffic routed by the VPN server.
If your institution has outbound traffic filtering (known also as egress traffic filtering), you will need to work with your institution's IT team to open the firewall on your end. We can provide the Symplectic Elements server IPv4 address, or you can determine it by yourself as per the following example:

your Symplectic Elements instance is hosted at example.institution.domain.tld
visit nslookup.io and search for example.institution.domain.tld
the result returned will include 2 CNAME records in the format similar to institution.elements.symplectic.org and server/insitution.elements.symplectic.org and a single A record that will contain the public IPv4 of the server (similar to 12.34.56.78)

Symplectic will provide you with a username and password. To connect to the database you will need:

An MSSQL-compatible client
The following connection details:
- Login credentials: provided in https://pastebin.dimensions.ai/
- URL: Symplectic FQDNs before custom domains are in place; custom domains thereafter
- Port: 1433

Access to the Reporting database and SSRS - permissions to create ‘custom views’, New stored procedures and Ability to create and register reports

To get a read-write access to the Reporting Database, please raise a support ticket as above and provide the following additional details:

Request the ability to create and maintain Supported structural customisations and Custom SSRS reports.

To connect to the SSRS server's web interface (for creating and deploying custom SSRS reports), please go to your Symplectic Elements instance's URL and type reports after the forward slash (e.g. www.elements-test.com/reports) and enter the credentials provided by Symplectic.

Availability monitoring

We use two separate approaches to monitor the availability of your Symplectic Elements and Discovery instances:

UptimeRobot checks every 10 minutes and alerts us immediately if a URL can't be reached.
Zabbix checks every 3 minutes and will trigger an alert when it has failed to reach a URL 3 times in a row.

SSL certificate expiry and renewals

We make use of the Let's Encrypt Certificate Authority for managing SSL certificates and their renewal.

Let's Encrypt offers various automated challenges for certificate provisioning to streamline the process. These challenges are employed by Let's Encrypt servers to verify that the requesting party has control over the domain for which a certificate is sought. "Control" in this context doesn't imply ownership, but rather the ability to demonstrate a legitimate connection to the domain.

Symplectic utilizes the HTTP-01 challenge method. Here's how it works:

Our ACME client, located on our server, initiates a challenge request to the Let's Encrypt certificate server.
Simultaneously, it sets up a temporary web server.
The client then establishes a connection to the domain specified in the challenge, using a predefined URL (http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>), which is served by the temporary web server. This connection is crucial for validating the challenge.
If the server successfully validates the challenge, it proceeds to issue the certificate to the client, who, in turn, stores it and shuts down the temporary web server.

For HTTP-01 challenges to succeed, the entity that truly owns the domain must ensure that the Fully Qualified Domain Name (FQDN) resolves to our server. This is achieved by setting up a CNAME record directing to our symplectic.org FQDN associated with the server.

Symplectic's hosting framework seamlessly manages SSL certificate tasks, including provisioning, monitoring, and renewal. These SSL certificates have a 90-day validity, and renewal takes place after 60 days. In the event of a renewal failure, there is a 30-day grace period for troubleshooting and reissuing. All these operations are expertly handled by Symplectic's dedicated team.

CAA DNS records for LetsEncrypt on custom client specific URLs

When dealing with custom, client-specific URLs (like client-a.yourdomain.com), it's important to understand how Certification Authority Authorization (CAA) records interact with subdomains. Since we utilize Let's Encrypt for automated SSL certificate provisioning and renewal, we require a CAA record on your domain. This record must explicitly authorize Let's Encrypt to issue certificates for your specific subdomains. By default, a CAA record set on your root domain (e.g., yourdomain.com) is inherited by all client URLs. If you have no CAA record, any CA is permitted; however, if you have an existing record listing a different CA, you must add an authorizing entry (issue "letsencrypt.org") either to the root domain or specifically for the subdomains we host. Without this authorization, our automated system will be blocked from configuring the necessary SSL certificates.

We use two separate approaches to monitor the expiry date of your SSL certificates, and we will contact you in good time before a certificate has to be renewed.

UptimeRobot checks every 24 hours and alerts us of when there are 30, 15, 7 and 1 day(s) left before expiry
Zabbix checks every 6 hours and will trigger an alert when there are fewer than 30 days left before expiry.

Note: The UptimeRobot check is using a random and non-existent URL, and produces one System Log error everyday. It is a Website 'Bad request: An invalid request was made.' error that is identified to come from UptimeRobot.

How email works when using AWS SES option provided by Symplectic

Symplectic Elements can be configured to send emails in various scenarios. There are 2 options for setting up the email details to be used:

1. Your IT team provides the details and you configure Symplectic Elements to use your institution's email server(s)

2. Symplectic provides the email option using AWS SES. In this specific case the following will apply:

Symplectic will provide the AWS SES details to our Support team and they will configure the Symplectic Elements instance
The AWS SES endpoint will be in the same region as your Symplectic Elements server
The From email address will be in the format of
- notifications@CLIENT-MONIKER.elements.symplectic.org or
- notifications@INSTANCE.CLIENT-MONIKER.elements.symplectic.org
The above AWS SES configuration can be used only on the Symplectic hosted Symplectic Elements instances or the Symplectic hosted Importers

Data feeds

1. If you feed data into the Symplectic Elements API directly from your source system(s), the only change will be:

We will provide you with new API endpoint URLs to connect to
We will need to whitelist your source systems’ External IP addresses on our firewall

2. If you use a data feed application provided by Symplectic, to feed data into Symplectic Elements, we can host the application for you on our FTP server (FTPs or sFTP)

We will give you access to our FTP server, so that you can upload the data files there on a regular basis
We will schedule an automated task to process the files and push the data into the Symplectic Elements API
We will give you access to the Data Feed’s logs
We can enable error/success notifications to be emailed to you, every time the data feeds run.

This approach covers the following Symplectic Elements data categories: Users details, Publication, Grants, Professional Activities, Teaching Activities, and User Profiles.

Secure FTP Access for Clients

We offer FTP server access to our clients, supporting the FTPS (FTP Secure) and SFTP (SSH File Transfer Protocol) protocols for secure data transmission. Authentication is supported via both password-based and key-based methods. To ensure the highest security and compatibility, we will provide the complete connection details and setup instructions after you have selected your preferred secure protocol (FTPS or SFTP) and authentication method. When selecting key-based authentication, you are responsible for providing the public part of the key using a secure method of transmission.

Custom website URL and Custom Researcher URL for Discovery Module

The following support article documents the options for the above URLs. In order to keep the integration between Symplectic Elements and the Discovery Module working smoothly, please coordinate with Symplectic when you want to change to a custom URL, in order to create correct DNS records and alter the configuration in a timely manner. The change can be easily requested by the Environment Authority and the required details are simple:

URL to be used
Confirmation that the IT team of your institution created the required CNAME DNS entry.
(Optional) SSL certificate if there are security constraints mandated by your institution. See the previous sections SSL certificate expiry and renewals and the CAA DNS records for LetsEncrypt on custom client specific URLs

Change freezes

In line with standard industry good practice, Symplectic implements regular change freeze periods where only strictly necessary changes to client environments will be scheduled and performed. These periods are critical as they allow us to focus on housekeeping and furthering the quality of our hosting service.

Change freeze periods:

Two weeks prior to each Symplectic Elements release - please see Symplectic Elements 2025 Release Dates
Two weeks prior to a new year
One week after a new year

Other responsibilities of the Environment Authority

In order to ensure you do not lose track of any Reporting Database access accounts you have asked Symplectic to create on your behalf, we recommend you perform a regular review of those accounts and whether they are still necessary to your use of the system.

Where you decide an account is no longer required, please contact Symplectic to have it removed.

On request, Symplectic will be happy to list the current set of usernames for accounts with access to the Reporting Database.

Should your institution also have access to any of the following interfaces, we recommend a similar process for them:

The SSRS (SQL Server Reporting Services) UI - used for detailed management of report definitions
SSAS (SQL Server Analysis Services) - data access direct to the Symplectic Elements Analytics Database
The shared Symplectic Elements FTP service - possibly used to swap data such as HR feeds and database backups