System
| System Requirements | |
|---|---|
| Memory | 8GB minimum |
| Processor Cores | 4 minimum |
| Hard Disk Space | 100GB minimum
|
| Network Interface | GigE |
If deploying in an AWS environment, we recommend using a m5.xlarge EC2 general purpose instance with general purpose SSD (gp2) EBS volume type. Perspectium has tested using the m5.xlarge instance type though any system meeting the system requirements should be able to run the application.
For other cloud platforms, it is recommended to use the equivalent services to the aforementioned AWS services:
| AWS | Microsoft Azure | |
|---|---|---|
| Virtual Machine | m5.xlarge | Standard_D4_v3 (Dv3 and Dsv3-series) or Standard_D4_v4 (Dv4 and Dsv4-series) |
| Storage | general purpose SSD (gp2) | Standard SSD Managed Disks |
Java
Java is required to be installed to run the DataSync Agent. Both 32 and 64 bit versions of Java are supported. The Java version must be Java 8 or higher. It's strongly recommended that you use a server type JVM instead of a client or desktop version. Both Java and OpenJDK are supported including distributions that include OpenJDK and certified compatible to the Java standard such as Amazon Corretto.
The Agent requires Java 11 at a minimum and will not run with versions older than 11.
| DataSync Agent version | Java 7 & earlier | Java 8 | Java 9 | Java 10 | Java 11 | Java 12 | Java 13 | Java 14 | Java 15 | Java 16 | Java 17 | Java 18 | Java 19 | Java 20 | Java 21 | Java 22 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Krypton |  | | | |  | | | | | | | | | | | |
NOTE: These versions of Java have been tested to work with the DataSync Agent. Newer versions may also be able to run the Agent but have not been tested or verified. We typically provide support for the latest version of Java with a major release after the Java version's general release date and when we have completed testing to ensure compatibility.
ServiceNow
The DataSync Agent requires a ServiceNow user in order to access the ServiceNow table schemas you share. This user you specify must be a local user in the ServiceNow instance (i.e. it cannot be a SSO user) that is given at minimum the perspectium role and has permissions to invoke a processor. In the event that the processor cannot be accessed when the DataSync Agent runs, a call to the PSPSchema rest API will be made instead to get the ServiceNow table schema.
You can use ServiceNow's OAuth implementation. See here for further information.
You do not need to upgrade the Agent at the same time as you upgrade the ServiceNow application as the core functionality of syncing data will work. New features however may require both to be upgraded to function properly. Perspectium tests n-2 compatibility with each release e.g. the previous two major releases of the Agent prior to this release has been tested with the latest version of the ServiceNow application.
Supported Databases
| Database | Version |
|---|---|
| Oracle | 11g, 12c Release 1: 12.1 - 12.2 |
| SQL Server (MSSQL) | 2010 - 2019 |
| MySQL | 5.6 - 8.X.X |
| SAP Hana | SPS 12 |
| Amazon Redshift | 4.0-4.1 |
| Amazon Aurora (MySQL compatible) | N/A |
| IBM DB2 | 11 |
| HP Vertica | 8.0 - 9.21 |
| PostgreSQL | 9.6 |
| Snowflake | 2.0 - 3.9 |
| Microsoft Azure SQL | 12.X |
^For Oracle, the Agent requires six open cursors per ServiceNow table to be replicated as it uses prepared statements to ensure the most efficient processing possible. For each operation per table (insert, update, delete, query metadata) we use a prepared statement which is reused whenever the next similar operation needs to be executed against the same table. Each of these prepared statements uses a cursor. If we didn't use an open cursor, every transaction would be very inefficient because the Agent would need to re-establish the client/server connection and query the structure each time.
If deploying an AWS RDS instsnce, we recommend using the m5.xlarge general purpose instance with a bandwidth of 4000 IOPS and 500GB of storage space. To really measure your bandwidth requirements, contact support@perspectium.com as we will work with you to understand how many records you plan to share a day during the initial seeding phase and the daily volume expected after the initial seeding to really know what the bandwidth needed is.
Database User Permissions
For integrating with a database, the following are the required permissions the DataSync Agent must have.
NOTE: It is recommended that the Agent be the only one writing data to this database to avoid conflicts with the Agent accessing tables it did not create and/or do not match the schema definitions as the source (such as ServiceNow).
| Permission | Description |
|---|---|
| Create a new database | After installation has been performed and the DataSync Agent is started, the Agent establishes a connection to the database server using the credentials configured. This task must be completed successfully before the Agent will proceed with subsequent processing. Once the connection has been established, the Agent will attempt to create the configured database. This step requires that the configured user has the proper permissions to create a new database. If this is not the case then an error will occur. As an alternative, the required database can be created by something or someone other than the Agent. When this approach is taken you add the configuration directive <skip_database_creation/> to the configuration and the Agent will not attempt to create the database since this tell the Agent that the database already exists. |
| Create tables within defined databases | Once replicated data is available, the Agent will determine if the table associated with the replicated data exists, and if not, the Agent will create it. This means that the configured user must have the permissions required to create tables within the defined database. |
| Query database and associated tables and update data in existing tables | When you share out data to be consumed by the DataSync Agent, you'll typically specify whether the data is being shared in bulk or dynamically. When the data is shared in bulk and based on how the Agent has been configured, it will typically perform a query in order to determine if the row already exists in the database. The Agent must therefore have permission to query the database and the associated tables. If the Agent determines that the row already exist then it performs an update, otherwise it will insert the row. The Agent must have permission to perform both these actions. |
| Insert data into tables | Once the required table has been created the Agent will perform an insert in order to populate the table with the replicated row. This means that the Agent must have the permissions to perform an insert into the table. |
| Alter table | The Agent wants to ensure that all data is replicated. It's possible that the structure of the source table has changed. For example, an additional column has been added to the table or the size of a column has been increased. The Agent performs the analysis required to make this determination and by default will alter the table in order to align it with the source table. Currently, Perspectium supports adding a column and increasing the size of a text or character type column to the maximum. Additionally, if the database supports it, a text or character type column can be modified to a larger type of text or character column.
The Agent also will not delete a column in a database table if the column is deleted in ServiceNow. It is possible to constrain the Agent from altering tables by including the <skip_alter/> directive within the SQL Subscribers <task> definition. |
| Delete table row | In order to support the deletion of rows from a table, the database user must also have permission to delete a table row |