Datasource Objects

The Datasource object enables you to create a data source that can connect to an external database. The Datasource object can then be used in multiple areas of Process Director. An example use of the Datasource object is with a Database Connector Custom Task. With a Database Connector Custom Task you must specify a data source either manually (by entering a connection string) or by using a Datasource object which was created once and used throughout Process Director.

Organize Datasources in root folders of the partition, separate from any implementation folders, so that implementers don't have to export Datasources when the implementation is exported from development to production. Exports and Imports are name-based, and relative folder position-based. Consequently, the root folder containing database sources should be mirrored on development and production servers, so that both the names and relative folder positions are exactly the same in both environments. If the mirroring is correct, implementations will be imported/exported between development and production without losing contact with the Datasources.

Datasource Object Configuration #

There are a number of database types that are supported by the Datasource object, which are listed in the Datasource Type dropdown. In addition to supporting the internal Process Director database, the Datasource object also supports a wide variety of other types of data sources :

  • SQL Server
  • Oracle
  • Access
  • Teradata
  • PostgreSQL Npgsql
  • PostgreSQL Devart
  • MySQL
  • SharePoint
  • Twitter
  • Google Sheets
  • Amazon Database
  • Windows File Path
  • Dropbox
  • OneDrive
  • Facebook
  • Salesforce.Com
  • Box (Box.net)
  • MS Dynamics CRM
  • Azure IoT Hub
  • SFTP (SSH File Transfer)
  • Compliance Data Source
  • OAuth

Other Datasource Types

To see more information about different Datasource Types and their configuration, please refer top the following topics:

Datasource Caching

Starting with Process Director v3.76, database caching for Datasource objects is implemented on all SQL Datasource objects, including Datasources for SQL Server, Access Oracle, and PostgreSQL. When caching is enabled on a Datasource, Process Director will retrieve the data from the database one time, then store the returned data in memory until the cache expires. Any time the database call is subsequently made, Process Director will first check the cache to see if the cache is still active, and, if so, will return the data from the cache, rather than attempting to retrieve the data from the database. If the cache is expired, Process Director will perform the database call, and reset the cache timeout.

When you select one of these data types from the Datasource Type dropdown, the Caching parameters will appear on the configuration form.

You can enable caching by checking the Enable Cache check box.

You can manually clear the cache, if necessary, by clicking the Clear Cache button. The Current Cache Entries label always displays the number of items currently in the cache, and clearing the cache should reset the value to "0".

You can optionally set the Cache Timeout (seconds) to the number of seconds that you wish the cache to remain active. If you don't set the Cache Timeout, Process Director will automatically time the cache out in around eight hours. The Cache Timeout that you should configure for the Datasource will, of course, depend on how current you need the data to be.

When caching is configured, all Business Values and database Custom Tasks that use the Datasource will also use its caching configuration, though you'll need to ensure that you are using the latest version of the Custom Tasks. Custom Tasks that were created prior to February, 2016, are not configured to use Datasource caching.

Users of Datasource caching should notice significant performance increases for data-heavy Forms.

Note As a security enhancement to Process Director v5.08 and higher, when exporting a Datasource to XML from the Content List, the Datasource Password will not be exported. You'll need to re-enter the password when the Datasource is imported again. As a best practice, Datasources shouldn't be exported between systems, anyway. They virtually always require reconfiguration on the target machine, and it’s easy to wipe out a working Datasource pointing at production data and replace it with another pointing at test data that you imported from your test system. Even worse, when you go back and refresh your test systems from production, the same thing can happen in reverse, causing you to corrupt your production data with test data.

Note As a security enhancement to Process Director v6.0 and higher, passwords in connection strings and password fields are obfuscated by default, and will not display unless the Eye icon adjacent to the field is clicked, which will show the password in clear text.