# Connection Profiles

A single Workato on-prem agent (OPA) can connect to multiple on-prem applications. A connection profile uniquely identifies each application and contains configuration information required to connect.

# Basics

What's a connection profile?
What types of systems can I connect to?
How do I apply a new configuration?

# What's a connection profile?

A connection profile is a file that uniquely identifies and contains information for an on-prem application. Profiles are stored in a configuration file located at <INSTALL_HOME>/conf/config.yml.

A typical config file looks something like this:

database:
  profile1:   # Connection names can't contain 
    ...       # spaces or special characters
  profile2:   # But may contain underscores (_) and hyphens (-)
    ...

files:
  profile3:
    ...
  profile4:
    ...

jms:
  profile5:
    ...

ldap:
  profile6:
    ...

server:
  classpath:
    ...
  staging:
    ...

# What types of systems can I connect to?

A config.yml file can contain profiles for the following system types:

Databases
On-prem file systems
SAP
Java messaging service
Apache Kafka
Active Directory
HTTP profile
NTLM
Command-line scripts
Extensions
Server

You can also configure proxy servers for OPAs installed on a server with limited internet connectivity.

# How do I apply a new configuration?

By default, your OPA must be restarted whenever a change is made to config.yml. Refer to the Running your on-prem agent guide for more info.

To allow the on-prem agent apply the changes automatically, add the following to the top of your config.yml file to use the autoReload option

config:
  autoReload: true

When enabled, changes made to config.yml will be picked up by autoReload. You won't need to manually restart the OPA.

AUTORELOAD AND SERVER PROFILES

autoReload doesn't apply to changes made to server profiles. To apply these changes, manually start and stop the OPA.

# Database Profiles

Database connection profiles provide the information your OPA uses to connect to a database. Connection profiles are located in the database section of config.yml.

OPA supports connections to multiple databases. Add a section under the database key for each database you want to connect to. For example:

database:
  your-connection-name:         # Specify the connection name, ex: sales-database
    adapter: sqlserver
    host: localhost
    port: 1433
    database: sales
    username: sales_analyst
    password: secretPassword456

In this section, we'll cover:

Profile properties
Supported database types
Example profile configurations

# Profile Properties

Database connection profiles can contain the following properties:

Name Type Description

adapter optional The type of database the profile is for. For example, if the profile is for a PostgreSQL database, this value would be postgresql.

Must be one of the databases supported by OPA. Refer to the configuration example for more info.

url optional The JDBC connection URL for the database. For example, jdbc:postgresql://sales.database:5432/sales connects to a PostgreSQL database.

Note: A url or host value must be provided to fully configure the connection profile.

Refer to the configuration example for more info.

host optional The host address of the database. For example, localhost.

Note: A url or host value must be provided to fully configure the connection profile.

port optional The port of the database. If using the default port for a database type, this property may be omitted.

For example, PostgreSQL databases use port 5432 by default. If your PostgreSQL uses this port, you don't need to add a port property to the connection profile.

Default ports are listed in the Supported databases section.

database optional The name of the database. For example: sales

Note: This property may be omitted if the url property is provided.

username required The username of a database user that will be used to connect to the database.

password required The password of the database user (username). This value can be a secret from an external secrets manager. Refer to the configuration example for more info.

driverClass required Required only for JDBC connections. The fully-qualified name of the JDBC driver class for the given database. The driver class must be available on the agent's classpath property.

pooled

optional

Options for configuring database connection pooling which reduces lag between reconnection attempts. Contains the following properties:

Name	Type	Description
minSize	optional	Minimum connection pool size. Default is 1.
maxSize	optional	Maximum connection pool size. Default is 10.
idleTimeout	optional	Idle time after which the connection will be recycled, in milliseconds.
maxLifetime	optional	Maximum life time of a connection, in milliseconds.
timeout	optional	Maximum duration for which a client awaits for a connection from the pool, in milliseconds.

ssl

optional

Options for configuring SSL connections. SSL is supported for the following databases:

MySQL - version 5.7 and higher
PostgreSQL - version 11.x and higher

Contains the following properties:

Name	Type	Description
cert	required	The file path to the SSL certificate.
trustAll	optional	If `true`, forces the client to trust any certificate chain. Self-signed server certificates are supported. Defaults to `false`.
verifyHost	optional	If `true`, the name stored in the server certificate will be matched against the domain name. Defaults to `false`.

# Supported Databases

The following table contains information about the databases OPA currently supports, including:

Database name: The name of the database
Adapter: The adapter value for the database. This value is used to specify the type of database OPA is connecting to.
Default port: The default port for the database
Notes: Notes about configuring the database

Database name	Adapter	Default port	Notes
Amazon Redshift	redshift	5439
JDBC-compatible databases	jdbc		Requires the following: `url` and `driverClass` properties in the connection profile A configured `server` profile Refer to the JDBC example for more info.
Microsoft SQL Server	sqlserver	1433
MySQL	mysql	3306	By default driver streams result sets row-by-row. To change buffer size use defaultFetchSize property.
Oracle	oracle	1521	If using Oracle Service, the `url` property is required. If using a SID, either the `adapter` or `url` properties may be used. Refer to the Oracle example for more info.
PostgreSQL	postgresql	5432

# Example Configurations

Click the blocks to display the example.

Using the adapter property

The following example uses the adapter property to connect to Microsoft SQL Server and Amazon Redshift databases:

database:
  sales:
    adapter: sqlserver
    host: localhost
    port: 1433
    database: sales
    username: sales_analyst
    password: secretPassword123
  operations:
    adapter: redshift
    host: localhost
    port: 5439
    database: customers
    username: cs_analyst
    password: secretPassword789

Using the url property

The following example uses the url property to connect to a PostgreSQL database.

database:
  sales:
    url: jdbc:postgresql://sales.database:5432/sales
    username: sales_analyst
    password: secretPassword123
    ApplicationName: workato

Using a secret for the password property

The following example uses a secret from an external secrets manager to provide the database password. Refer to the Secrets Manager for more info.

database:
  sales_database:
    adapter: sqlserver
    host: localhost
    port: 1433
    database: test
    username: sales_user
    password: { secret: 'sales-db-password-password' }

Connecting to Oracle databases

You can connect to either a SID or Service when connecting to Oracle databases.

If using a SID, you can use either the adapter or url property.

If using a Service, the url property must be provided:

database:
  erp:
    url: jdbc:oracle:thin:@localhost:1521/PROD
    username: admin
    password: SecretPassword456

Connecting to JDBC-compatible databases

Connections to JDBC-compatible databases require the following:

url and driverClass properties in the connection profile
A configured server profile

database:
  tpc:
    url: jdbc:presto://warehouse.intra:8889/tpch
    driverClass: com.facebook.presto.jdbc.PrestoDriver
    adapter: jdbc
    username: my_user

server:
  classpath: jdbc

Connecting to a specific SQL Server instance

The following example shows how to define a JDBC url for a specific SQL Server instance when there are multiple instances on the same server.

Note: You only need to provide the instance name if you don't know the port number.

database:
  sales:
    adapter: sqlserver
    url: jdbc:sqlserver://[Server/Host]\[Instance]
    username: user
    password: Secret123

Enabling SSL

The following example configures SSL for a PostgreSQL database.

Note: Currently, SSL connections are supported for MySQL (5.7+) and PostgreSQL (11+) databases.

database:
  sales:
    adapter: postgresql
    host: localhost
    port: 5432
    database: sales
    username: sales_analyst
    password: secretPassword123
    ssl:
      cert: /path/client_ca.crt
      trustAll: false
      verifyHost: true

# On-prem Files Profile

Working with on-prem files requires you to define a file system profile in the files section. You need to specify the base folder for file access as it will be used for resolving relative paths. A folder named HR in the C:\Documents\ directory will be configured like this:

files:
  hrfiles:
    base: "C:\\Documents\\HR"

In another example, if you wish to provide access to the employees folder in the Desktop directory, the configuration will have a file path that looks something like this:

files:
  hrfiles:
    base: "/Users/me/Desktop/employees"

# SAP Profile

For a SAP connection profile, you must define the server and sap section together.

In the Server profile, the lib_ext is the directory where you put the SAP JCo connector libraries. If this directory is not already created, create this directory under the root directory of the OPA and put the SAP JCo connector libraries there. The lib_ext folder should contain sap-connector-impl-X.X.jar. Learn more about the Server profile.

There are two connection types that the SAP connector supports - Direct connections or Message Server connections.

SAP default ports

Our SAP connector uses these ports by default:

Via SAP Message Server : 36xx (where xx is SAP system number)
W/o SAP Message Server, e.g. direct call to SAP : 48xx (with SNC) and 33xx (w/o SNC)

Furthermore for HTTP(s) inbound communication (for example for consuming REST OData services, SOAP WebServices etc. provisioned from SAP) ports are per default 8000 (HTTP) and 44300 (HTTPs). If this ports have been setup on SAP in custom way, port numbers can be figured out in SAP by

Go to the ICM Monitor ( SMICM ) transaction.
Choose Goto Services to display the services configured in ICM and correlated ports.

If these ports differ from our defaults, please contact Workato support.

SNC CONNECTION

Refer to SNC encryption for more information on Secure Network Communication setup.

# SAP - Direct Connection

Below is the example of Direct connection type. Use this connection type if SAP system is directly exposed as an application server.

server:
  classpath:
    - lib_ext

sap:
  # Direct connection to an ABAP application server
  sap_profile_1: # This is on-prem agent connection profile name
    network_connection:
      gateway_host: "xx.xx.xx.xx"
      system_number: "00"
      program_id: "WORKATO"  # Only needed if you are using IDocs. This can be omitted for connections that only use RFCs.
      metadata_refresh_interval: "10"
    user_logon:
      client: "800"
      language: "EN"
      user: "USERN"
      password: "PASSW"

Parameter (JCO Connection Property)	Description	Click to expand image
gateway_host (jco.client.ashost)	Can be either DNS name or IP address. If present, this describes a direct connection to SAP host. Can be in the format `xx.xx.xx.xx`. This is the IP Address of the SAP application server to which you are directly connecting. This can be seen on the SAP Logon Pad which is used to login to your on-premise SAP Application server.
system_number (jco.client.sysnr)	Two-digit SAP system number. It identifies the logical port on which the application server is listening for incoming requests. Commonly found from the TCP Port 33XX where XX is the system_number
program_id (jco.server.progid)	OPTIONAL. Only needed when IDOCs are used in recipes. This matches the program ID given to the RFC destination linked to Workato in Tcode SM59. This defaults to `WORKATO` if not supplied.
client (jco.client.client)	The actual client number which is used for connecting to Workato. Use the same client you log into with your SAP Logon Pad. It's always a three-digit integer.
language (jco.client.lang)	OPTIONAL. Represents the logon language. If the property is not provided, the user's or system's default language is used. Valid values are two-character ISO language codes or one-character SAP language codes.
user (jco.client.user)	SAP user provisioned for Workato. Using background user and disabling dialog properties are recommended.
password (jco.client.passwd)	SAP user password.
metadata_refresh_interval (N/A)	OPTIONAL. Configure this parameter to customize the interval that Workato refreshes the list of IDocs available in Workato. The default value is `1440` minutes (24 hours).

# SAP - Message Server Connection

Below is the example of messageserver connection type. Use this connection type when SAP system is behind message server gateway.

server:
  classpath:
    - lib_ext

sap:
  # Message Server connection to an ABAP application server
  sap_profile_2: # This is on-prem agent connection profile name
    network_connection:
      message_server_host: "10.30.xx.xx"
      logon_group: "PUBLIC"
      system_id: "DEV"
      program_id: "WORKATO" # Only needed if you are using IDocs. This can be omitted for connections that only use RFCs.
      metadata_refresh_interval: "10"
    user_logon:
      client: "800"
      language: "EN"
      user: "USERN"
      password: "PASSW"

Parameter (JCO Connection Property)	Description	Click to expand image
message_server_host (jco.client.mshost)	Message Server host in the format of `xx.xx.xx.xx`. This is the IP Address of the Message Server you are connecting.
logon_group (jco.client.group)	Optional. Logical group name of the application servers. Can be found in SAP Tcode `SMLG`
system_id	The system ID of the system the message server belongs to. See SAP Note 52959 in case of connection error.
program_id (jco.server.progid)	OPTIONAL. Only needed when IDOCs are used in recipes. This matches the program ID given to the RFC destination linked to Workato in Tcode SM59. This defaults to `WORKATO` if not supplied.
client (jco.client.client)	The actual client number which is used for connecting to Workato. Use the same client you log into with your SAP Logon Pad. It's always a three-digit integer.
language (jco.client.lang)	OPTIONAL. Represents the logon language. If the property is not provided, the user's or system's default language is used. Valid values are two-character ISO language codes or one-character SAP language codes.
user (jco.client.user)	SAP user provisioned for Workato. Using background user and disabling dialog properties are recommended.
password (jco.client.passwd)	SAP user password.
metadata_refresh_interval (N/A)	OPTIONAL. Configure this parameter to customize the interval that Workato refreshes the list of IDocs available in Workato. The default value is `1440` minutes (24 hours).

# JMS Profile

JMS connection profiles must be defined in the jms section. A JMS provider is specified by provider property of a connection profile. The following JMS providers are supported by the on-prem agent:

Messaging service	provider
Amazon Simple Queue Service	`amazon-sqs` or `sqs`
Apache ActiveMQ	`activemq`
Azure Service Bus	`custom`

# Amazon SQS

You need the following configuration properties when connecting to Amazon SQS:

jms:
  MyAmazonProfile:
    provider: amazon-sqs
    region: <Your Amazon API region, eg 'us-east-2'>
    accessKey: <Your Amazon API access key>
    secretKey: <Your Amazon API secret>

Note that you need to make sure your SQS queue is created before sending messages.

# Apache ActiveMQ

For connecting to a running ActiveMQ broker you only need to specify the broker URL:

jms:
  MyActiveMQProfile:
    provider: activemq
    url: tcp://localhost:61616

ActiveMQ broker cannot be embedded into the agent. Using any vm:// broker connections is not supported.

# Azure Service Bus

Azure Service Bus uses custom JMS provider. You will need the following configuration properties when connecting to Azure Service Bus:

jms:
  azureServiceBus:
    provider: custom
    class: org.apache.qpid.jms.JmsConnectionFactory
    remoteURI: amqps://<host-name>.servicebus.windows.net
    username: <policy-name>
    password: "<primary-key>"

Download jar files from here (opens new window) and extract it inside the lib_ext folder.

Add the classpath inside the config.yml file. Learn more about the classpath property.

server:
 classpath: lib_ext

# Apache Kafka Profile

Kafka connection profiles must be defined in the kafka section. You need the following configuration properties when connecting to Kafka:

kafka:
  MyKafkaProfile:
    ... connection properties ...

You can provide any Kafka producer (opens new window) or consumer (opens new window) configuration properties, for example, bootstrap.servers or batch_size.

However, some properties are overridden by the on-prem agent and cannot be configured. You will get a warning when trying to redefine a protected property. Some examples of these protected properties:

Property name	Comment
key.serializer	Only `StringSerializer` is supported by agent
value.serializer	Only `StringSerializer` is supported by agent
key.deserializer	Only `StringSerializer` is supported by agent
value.deserializer	Only `StringSerializer` is supported by agent
auto.offset.reset	Defined by recipes
enable.auto.commit	Defined internally

Workato Agent also supports the following (non-Kafka) configuration properties:

Property name	Description
timeout	General operation timeout, milliseconds.
url	Comma-separated list of server URLs where protocol is either `kafka` or `kafka+ssl`.
ssl.truststore	Allows inlining of PEM-encoded truststore for secure connection to Kafka
ssl.keystore.key	Allows inlining of private key for secure connection to Kafka
ssl.keystore.cert	Allows inlining of client certificate for secure connection to Kafka

ssl.* options above can be used when connecting to Kafka using SSL/TLS and allows you to keep PEM-encoded certificates and private keys inside the config.yml file. Any YAML-compatible multiline syntax could be used, for instance:

kafka:
  MyKafkaProfile:
    ssl.truststore:
    |
      -----BEGIN CERTIFICATE-----
      502mPNNAYkY4a7Zu84DLCXLFurEa4BhLBqLkzC6WdTrBN9z6Rp/svTIl6VgjSTP6
      .....
      -----END CERTIFICATE-----

Note that password-protected private keys cannot be inlined.

# Active Directory Profile

Active Directory connection profiles must be defined in the ldap section. Example profile:

ldap:
  active_directory_main:
    url:
      - ldap://acme1.ldap.com:389
      - ldaps://acme2.ldap.com:636
    username: Administrator
    password: foobar
    base: dc=acme,dc=com
    ssl:
      cert: /path/to/PEM-encoded-certificate-or-trusted-CA
      trustAll: true

Property name		Description
url required		The URL of the LDAP server to use. The URL should be in the format `ldap://myserver.example.com:389`. For SSL access, use the LDAPS protocol. The URL format is in the same format `ldaps://myserver.example.com:636`. If fail-over functionality is desired, you can provide more than one URL.
username required		The username (principal) to use when authenticating with the LDAP server. This will usually be the distinguished name of an admin user. For example, `cn=Administrator` or simply `Administrator`.
password required		The password (credentials) to use when authenticating with the LDAP server
base optional		The base DN for all requests. When this attribute has been configured, all Distinguished names supplied to and received from LDAP operations will be relative to this LDAP path. This can significantly simplify working against a large LDAP tree. However there are several occasions when you will need to have access to the base path. For more information on this, please refer to Obtaining a reference to the base LDAP path.
ssl optional	cert	Path to the PEM encoded certificate or a trusted CA.
	pem	Full content of a PEM encoded certificate.
	key	Private key for mutual SSL setup. Required if `pem` is provided.
	trustAll	Set to `true` to enable self-signed certificates.

# HTTP Profile

The http configuration section allows configuring agent access to internal HTTPS resources:

http:
  connectTimeout: 5000
  keepAlive: true
  ssl:
    trustAll: false
    verifyHost: true
    cert:
    |
      -----BEGIN CERTIFICATE-----
      MIIF3TCCBMWgAwIBAgIQBlp2+roj8DZRf7VwurC8BjANBgkqhkiG9w0BAQsFADBG
      .....
      -----END CERTIFICATE-----
    key: /path/PEM-encoded-private-key
    pem: /path/PEM-encoded-certificate-or-trusted-CA

By default, OPA uses set of root Certification Authority (CA) certificates from the built-in JRE. The agent may be configured to allow accessing internal HTTPS resources which use self-signed certificates. To enable self-signed certificates, fill ssl.cert property either with path to server certificate or with PEM-encoded certificate value. To trust any server certificate, set ssl.trustAll property to true. Additionally, the agent supports mTLS with ssl.key and ssl.pem properties which should contain client private key and certificate respectively.

Normally a server certificate's Common Name (or Subject Alternate Name) field should match the target hostname. If you want the agent to accept server certificates with non-matching hostname, disable hostname verification by setting ssl.verifyHost property to false (defaults to true).

# NTLM Profile

Certain HTTP resources require NTLM authentication. This can be done using a NTLM connection profile. Here are some example NTLM profiles:

ntlm:
  MyNtlmProfile:
    auth: "username:password@domain/workstation"
    base_url: "http://myntlmhost.com"
    cm_default_max_per_route: 15
    cm_max_total: 100
    verifyHost: true
    trustAll: false

  AnotherNtlmProfile:
    auth: "domain/workstation"
    username: "username"
    password: "password"
    base_url: "http://myntlmhost.com"
    cm_default_max_per_route: 15
    cm_max_total: 100
    verifyHost: true
    trustAll: false

The following profile properties are supported:

Property name	Description
auth	Full NTLM authentication credentials. This can include username, password, domain, and workstation. For OPA version 2.4.7 or later, username and password can be configured separately if they contain special characters like `@` and `/`.
username	Username for NTLM authentication. Only for OPA version 2.4.7 or later
password	Password for NTLM authentication. Only for OPA version 2.4.7 or later
base_url	The base URL for NTLM resources
cm_default_max_per_route	Optional. Sets the number of connections per route/host (must be a positive number, default 5)
cm_max_total	Optional. Sets the maximum number of connections (must be a positive number, default 10)
http_connect_timeout	Optional The timeout in milliseconds used when requesting a connection (must be a positive number, default 10000)
http_connection_request_timeout	Optional The timeout in milliseconds until a connection is established (must be a positive number, default 10000)
http_socket_timeout	Optional The socket timeout in milliseconds, which is the timeout for waiting for data or, put differently, a maximum period inactivity between two consecutive data packets (must be a positive number, default 10000)
verifyHost	Optional. Specifies whether to enable verification of the host name for SSL/TLS connections (default true)
trustAll	Optional. Specifies whether trust all certificates for SSL/TLS connections (default false)

HTTP methods supported for NTLM connections are GET, POST, PUT, PATCH, DELETE and HEAD.

# Command-line Scripts Profile

This profile allows users to run arbitrary scripts or commands on OPA. The script definition in the config file can have parameters.

When you declare an action, you need to specify the values of the parameters.

An example profile on Unix can look like this:

command_line_scripts:
  workday_reports:
    concurrency_limit: 3
    timeout: 30
    scripts:
     copy_file:
       name: Copy file
       command:
         - /bin/cp
         - '{{source_file}}'
         - '{{target_directory}}'
       parameters:
         - { name: source_file }
         - { name: target_directory }           

     append_file_to_another:
       name: Append file to another
       command:
         - bash
         - -c
         - cat {{source_file}} >> {{target_file}}
       parameters:
         # Parameter quoting
         - { name: source_file, quote: '"' }
         # Advanced parameter quoting
         - { name: target_file, quote: { start: '"', end: '"', quote: '"', escape_char: \ } }

     generate_report:
       name: Generate report
       command:
         - python
         - /home/user/script.py
         - --from
         - '{{from_date}}'
         # Conditional fragment
         - { value: --to, if: to_date }
         # Conditional fragment
         - { value: '{{to_date}}', if: to_date }
       parameters:
         - { name: from_date }
         - { name: to_date, schema: { optional: true, control_type: select, pick_list: [01/01/2018, 02/02/2018] } }

The command-line script profiles are placed in the command_line_scripts section in config.yml. Each profile can contain multiple scripts. The profile configuration properties are as follows:

Property name	Description
scripts	The scripts hash. The value for each key contains the script profile.
concurrency_limit	Optional. Maximum number of concurrently executed scripts. Defaults to 10 when not provided. After reaching the limit, requests are queued.
timeout	Optional. Maximum duration(seconds) for each script execution. Defaults to 90 seconds when not provided.

The hash key is used as an unique identifier for a script profile. The script configuration properties are as follows:

Property name	Description
name	Friendly name for the script that will be displayed in the recipe UI.
command	The command invocation array. The value of each item can use Mustache (opens new window) template variables to substitute the parameter values.
parameters	Optional. The parameter array (defaults to an empty array).

The command invocation element configuration can be just a string, but also can contain these properties:

Property name	Description
value	The command invocation element value.
if	The parameter name. If parameter value is empty, this command invocation element is not taken into account.

The parameter configuration properties are as follows:

Property name	Description
name	The parameter name.
quote	Optional. The rules of parameter quoting (defaults to no rules).
schema	Optional. The parameter schema.

The quote configuration can just be a string or have properties. The properties are as follows:

Property name	Description
start	The opening quote character.
end	The closing quote character.
quote	The quote character in the parameter value to be escaped.
escape_char	The escape character.

If the quote configuration is a string, its value is considered as the value of the start, end and quote properties, and the escape_char property value is set to '\' on Unix and '""' on Windows.

The parameter schema configuration can have properties as follows:

Property name	Description
optional	Optional. The optional flag of the parameter (defaults to false).
label	Optional. Friendly name for the script, that will be displayed in the recipe UI (defaults to the parameter name).
control_type	Optional. Can be 'text' or 'select'. If it's 'select', property 'pick_list' should also be defined. Defaults to 'text'.
pick_list	Optional. Values for selecting the parameter value. This property should be defined if property 'control_type' has value 'select'.

# Extensions Profile

Working with Java extensions requires you to define an extensions profile. You need a server section to define where the jar files are located, and an extensions section to create individual profiles for the Java classes. A Java extension will be configured like this.

server:
  classpath: ext

extensions:
  security:
    controllerClass: com.mycompany.onprem.SecurityExtension
    secret: HA63A3043AMMMM

The server parameter configuration property is as follows:

Property name	Description
classpath	Specifies the location of user-defined class

Each extensions profile configuration properties are as follows:

Property name	Description
controllerClass	A required field to inform the OPA which Java class to map the extension to.
secret	Optional environment property that is used in the Java class. Multiple properties can be added.

Find out how to create a Java extension.

# Server Profile

Server profiles define where OPA assets are located on the on-prem server. Server profiles are located in the server section of config.yml.

server:
  classpath: lib_ext
  staging: staging

In this section, we'll cover:

Profile properties
Example profile configurations

# Profile Properties

Server profiles can contain the following properties:

Name	Type	Description
classpath	required	Defines the directory that contains Java driver or user-defined classes. For example, jar files or driver classes. Note: This must be a pre-existing subdirectory in the OPA installation folder.
staging	required **	Defines a staging folder to temporarily store data during loading to the target system. Note: This must be a pre-existing subdirectory in the OPA installation folder. If left unspecified, the OPA will manage the staging folder internally. A file stored in the staging folder is automatically deleted after OPA finishes loading it to the target system. ** Required for OPA versions 2.10.0 and lower. Optional for versions 2.10.1 and up.

# Example Configurations

Let's look at some example profile configurations using the following directory structure. In this example, the on-prem agent is installed in /opt/workato-agent:

/opt
├── /workato_agent
    ├── /conf
    ├── /bin
    ├── /lib_ext
    ├── /staging

The following example defines a jdbc directory that contains Java driver classes or user-defined classes:

server:
  classpath: lib_ext

Next, we'll demonstrate setting the staging property. This property defines where the OPA temporarily stores files during loading to the target system.

For example, when executing the SQL Server Export query result action, CSV output will be temporary stored in the /staging directory and deleted after the file is loaded:

server:
  classpath: lib_ext
  staging: staging

Last updated: 2/13/2024, 4:59:53 PM