Skip to main content
The Oracle connector allows you to integrate Oracle into your data flow by pushing or pulling data from Oracle.

Key Capabilities

  • Full-featured database connectivity with platform-specific optimizations
  • Standard database operations (Select, Lookup, Upsert) with transaction support
  • Advanced connection pooling and performance tuning capabilities
  • Support for stored procedures, functions, and complex query operations
Follow the steps below to connect Arc to Oracle.

Prerequisites

Before using an Oracle connector, you must already have a live Oracle database server and a clear network path to that server from Arc. You must also install and configure the dependencies that Oracle requires. Follow the directions below for your version of Arc.

.NET Edition

The .NET edition requires the Oracle Data Provider for .NET-managed driver (ODP.NET), which Oracle distributes through NuGet. ODP.NET is not self-contained: it depends on 11 assemblies, and those assemblies were compiled against different versions of one another. You therefore need to install all 12 files and add binding redirects so that .NET resolves them consistently. Install the exact versions listed below. They are the set that Oracle.ManagedDataAccess 23.26.301 resolves and that CData tests as a unit. Mixing in other versions requires changing the binding redirects to match. In the steps that follow, [InstallationDirectory] refers to the Arc installation directory (by default, C:\Program Files\CData\CData Arc).
Oracle.ManagedDataAccess 23.26.301 targets .NET Framework 4.7.2. Confirm that the Arc server has .NET Framework 4.7.2 or later before you begin.

Step 1: Download the Packages

Use the NuGet CLI to download Oracle.ManagedDataAccess and everything it depends on in one step.
  1. Download the NuGet CLI from Microsoft and save it to an empty working directory, such as C:\Temp\OracleProvider.
  2. Open a command prompt in that directory and run the following command. Replace C:\Temp\OracleProvider with the directory where you saved nuget.exe.
    This downloads Oracle.ManagedDataAccess and its transitive dependencies from the official NuGet feed into a packages subfolder, with one folder per package.
    Run nuget.exe by its full path. Calling it by name alone runs whichever copy appears first on your PATH, which might be an older release. This command requires NuGet CLI 4.4 or later. Earlier releases report Unknown option: '-Framework' or Unknown option: '-DependencyVersion', and releases before 4.1 cannot connect to nuget.org, reporting Could not create SSL/TLS secure channel followed by a misleading message that the package version cannot be found.
The command resolves the 12 packages below. Take one assembly from each, using the path shown in the File in the package column, and confirm that the versions match.
PackageVersionFile in the packageAssembly version
Oracle.ManagedDataAccess23.26.301lib\net472\Oracle.ManagedDataAccess.dll4.122.23.1
Microsoft.Bcl.AsyncInterfaces8.0.0lib\net462\Microsoft.Bcl.AsyncInterfaces.dll8.0.0.0
System.Buffers4.6.1lib\net462\System.Buffers.dll4.0.5.0
System.Collections.Immutable10.0.3lib\net462\System.Collections.Immutable.dll10.0.0.3
System.Diagnostics.DiagnosticSource6.0.2lib\net461\System.Diagnostics.DiagnosticSource.dll6.0.0.2
System.Formats.Asn18.0.1lib\net462\System.Formats.Asn1.dll8.0.0.1
System.Memory4.6.3lib\net462\System.Memory.dll4.0.5.0
System.Numerics.Vectors4.6.1lib\net462\System.Numerics.Vectors.dll4.1.6.0
System.Runtime.CompilerServices.Unsafe6.1.2lib\net462\System.Runtime.CompilerServices.Unsafe.dll6.0.3.0
System.Text.Encodings.Web8.0.0lib\net462\System.Text.Encodings.Web.dll8.0.0.0
System.Text.Json8.0.5lib\net462\System.Text.Json.dll8.0.0.5
System.Threading.Tasks.Extensions4.6.0lib\net462\System.Threading.Tasks.Extensions.dll4.2.1.0
Notice that the package version and the assembly version differ. For example, the System.Memory 4.6.3 package contains assembly version 4.0.5.0. The assembly version is what the binding redirects in Step 4 refer to.
Oracle.ManagedDataAccessDTC.dll is not required. Oracle needs it only for distributed transactions on .NET Framework 4.5.1 and earlier, the 23.x package does not ship it, and Arc does not use distributed transactions.
If you authenticate through MIT Kerberos, also take bin\x64\Oracle.ManagedDataAccessIOP.dll from the Oracle.ManagedDataAccess package and copy it alongside the others in Step 3. The package supplies only the 64-bit version of this assembly. It is not needed for username and password authentication.
For an Arc server without internet access, run the command above on a machine that does have access and copy the resulting packages folder to the Arc server. If you cannot run nuget.exe at all, download each package individually from its page on nuget.org instead: a .nupkg file is a zip archive, so rename it to .zip and extract it.

Step 2: Stop Arc and Back Up

  1. Stop Arc via the Windows service or the CData Arc desktop application.
  2. Back up [InstallationDirectory]\www\bin and [InstallationDirectory]\www\Web.config. Step 3 overwrites files that Arc ships, and Step 4 edits the configuration that Arc starts from.

Step 3: Copy the Assemblies

Copy the 12 assemblies from Step 1 into [InstallationDirectory]\www\bin, replacing any files that already exist.
Arc ships four of these assemblies for the Apache Kafka connector: System.Buffers, System.Memory, System.Numerics.Vectors, and System.Runtime.CompilerServices.Unsafe. In Arc 26.4 and later, the shipped files are already the versions listed in Step 1, so replacing them changes nothing. In Arc 26.3 and earlier, the shipped files are older than ODP.NET requires and must be replaced. The Kafka connector keeps working in both cases, because the binding redirects in Step 4 route its older references to the new files.

Step 4: Update Web.config

Open [InstallationDirectory]\www\Web.config in a text or code editor. This is an XML-formatted file. Make the three changes below.
  1. Register the configuration section handler. <configSections> must be the first child of <configuration>. If the element does not exist, add it directly after the opening <configuration> tag:
  2. Add the binding redirects. Navigate to the element <configuration>/<runtime>/<assemblyBinding>, which already contains a <probing> element. Leave <probing> in place and add the following after it, inside the same <assemblyBinding> element:
    Keep exactly one <dependentAssembly> element per assembly name. If an entry for one of these assemblies already exists, from an earlier attempt or another connector, replace it instead of adding a second one.
  3. Register the provider. Navigate to the element <configuration>/<system.data>/<DbProviderFactories>. At the bottom of this element, add the following text:
  4. Save Web.config and close it.

Step 5: Restart Arc and Verify

Start Arc, add an Oracle connector to a flow, and confirm the following two things in order:
  1. Test Connection succeeds.
  2. You can select a table in the connector configuration.
Test Connection alone does not confirm that the installation is correct. .NET Framework resolves assembly references the first time they are used, and the code paths that need the binding redirects do not run until Arc reads table metadata. An installation that is missing redirects passes Test Connection, then fails when you select a table. Always complete both checks.
If Arc also uses the Apache Kafka connector, test an existing Kafka connection as well, because Step 3 replaced four assemblies that Kafka shares.

Upgrading Arc

Upgrading Arc overwrites [InstallationDirectory]\www\bin but preserves Web.config. If an upgrade or reinstall restores older copies of the four shared assemblies, the binding redirects point at versions that are no longer present and both the Oracle and Kafka connectors can fail. Repeat Step 3 after every upgrade, then confirm that the assembly versions in [InstallationDirectory]\www\bin still match the values listed in Step 1. Upgrading to Arc 26.4 or later installs the same versions the redirects expect, so no action is needed on that path.

Troubleshooting

The Oracle connector does not appear in the connector list: One or more of the 12 assemblies is missing from [InstallationDirectory]\www\bin. Arc hides the connector when it cannot load the ODP.NET provider factory, without reporting an error. Confirm that all 12 files are present and restart Arc. Selecting a table fails with Could not load file or assembly ... 0x80131040: A binding redirect is missing or points at the wrong version. The message names the assembly and the version that was requested. Confirm that the version of that assembly in [InstallationDirectory]\www\bin matches the assembly version listed for it in Step 1, and that the newVersion of its binding redirect uses that same value. If they do not match, correct the redirect so that newVersion is the installed assembly version and oldVersion is 0.0.0.0-<installed version>. Then restart Arc, because Web.config changes only take effect on startup.

Java Edition

  1. Download the Oracle JDBC .jar file from the Oracle website.
    • If you are using the Arc embedded Jetty server, select the latest release of ojdbc11.jar.
    • If you are using another hosting option, select the latest release of either ojdbc11.jar or ojdbc8.jar, depending on the version of JDK your hosting server uses.
  2. Move the file to the appropriate location:
    • If you are using the embedded Jetty server, move the file to the lib folder in the Arc installation directory ([InstallationDirectory]/lib). If this folder does not exist, create it.
    • If you are using another server, move the file to the lib folder for the server. If this folder does not exist, create it.

Establish a Connection

To allow Arc to use data from Oracle, you must first establish a connection to Oracle. There are two ways to establish this connection:
  • Add a Oracle connector to your flow. Then, in the settings pane, click Create next to the Connection drop-down list.
  • Open the Arc Settings page, then open the Connections tab. Click Add, select Oracle, and click Next.
  • The login process is only required the first time the connection is created.
  • Connections to Oracle can be re-used across multiple Oracle connectors.

Enter Connection Settings

After opening a new connection dialogue, follow these steps:
  1. Provide the requested information:
    • Name — the static name of the connection. Set this as desired.
    • Type — this is always set to Oracle.
    • Connection Type — the connection type (SID or Service Name) to use.
    • User — the username to use for logging in.
    • Password — the password for the user entered above.
    • Server — the address of the Oracle server you want to connect to.
    • Port — the port to use when connecting to the server.
    • SID/Service — the SID or Service (depending on Connection Type chosen) to use when connecting.
    • Other — other authentication information if needed.
  2. If needed, click Advanced to open the drop-down menu of advanced connection settings. These should not be needed in most cases.
  3. Click Test Connection to ensure that Arc can connect to Oracle with the provided information. If an error occurs, check all fields and try again.
  4. Click Add Connection to finalize the connection.
  5. In the Connection drop-down list of the connector configuration pane, select the newly-created connection.
  6. Click Save Changes.

Select an Action

After establishing a connection to Oracle, you must choose the action that the Oracle connector will perform. The table below outlines each action and where it belongs in an Arc flow.

Advanced Tab

Many of the settings on the Advanced tab are dynamically loaded from the data source you are working with, so they are not covered in this documentation. You can find detailed information for your data source on the Online Help Files page of the CData website. The options described below are available for all data sources.

Advanced Settings

Advanced settings are common settings for connectors that rely on arbitrary database drivers (for example, Database, CData, and API connectors) in order to make connections to various data sources.

Miscellaneous

Miscellaneous settings are for specific use cases.

Automation Tab

Automation Settings

Settings related to the automatic processing of files by the connector.

Performance

Settings related to the allocation of resources to the connector.

Alerts Tab

Settings related to configuring alerts. Before you can execute Service Level Agreements (SLAs), you need to set up email alerts for notifications. By default, Arc uses the global settings on the Alerts tab. To use other settings for this connector, toggle Override global setting on. By default, error alerts are enabled, which means that emails are sent whenever there is an error. To turn them off, uncheck the Enable checkbox. Enter a Subject (mandatory), then optionally enter a comma-separated list of Recipient emails.

SLAs Tab

Settings related to configuring Service Level Agreements (SLAs). SLAs enable you to configure the volume you expect connectors in your flow to send or receive, and to set the time frame in which you expect that volume to be met. Arc sends emails to warn the user when an SLA is not met, and marks the SLA as At Risk, which means that if the SLA is not met soon, it will be marked as Violated. This gives the user an opportunity to step in and determine the reasons the SLA is not being met, and to take appropriate actions. If the SLA is still not met at the end of the at-risk time period, the SLA is marked as violated, and the user is notified again. To define an SLA, toggle Expected Volume on, then click the Settings tab. Empty SLA configuration
  • If your connector has separate send and receive actions, use the radio buttons to specify which direction the SLA pertains to.
  • In the Expect at least portion of the window:
    • Set the minimum number of transactions you expect to be processed (the volume)
    • Use the Every fields to specify the time frame
    • Indicate when the SLA should go into effect. If you choose Starting on, complete the date and time fields.
    • Check the boxes for the days of the week that you want the SLA to be in effect. Use the dropdown to choose Everyday if necessary.
  • In the Set status to ‘At Risk’ portion of the window, specify when the SLA should be marked as at risk.
    • By default, notifications are not sent until an SLA is in violation. To change that, check Send an ‘At Risk’ notification.
The following example shows an SLA configured for a connector that expects to receive 1000 files every day Monday-Friday. An at-risk notification is sent 1 hour before the end of the time period if the 1000 files have not been received. SLA Configuration Example
You can turn off SLA alerts if necessary. This can be useful during maintenance windows. Click Settings on the navbar, then navigate to Alerts > General Alerts. Click the tablet and pencil icon to edit, and uncheck the SLA Alerts setting.

Macros

Using macros in file naming strategies can enhance organizational efficiency and contextual understanding of data. By incorporating macros into filenames, you can dynamically include relevant information such as identifiers, timestamps, and header information, providing valuable context to each file. This helps ensure that filenames reflect details important to your organization. Arc supports these macros, which all use the following syntax: %Macro%.

Examples

Some macros, such as %Ext% and %ShortDate%, do not require an argument, but others do. All macros that take an argument use the following syntax: %Macro:argument% Here are some examples of the macros that take an argument:
  • %Header:headername%: Where headername is the name of a header on a message.
  • %Header:mycustomheader% resolves to the value of the mycustomheader header set on the input message.
  • %Header:ponum% resolves to the value of the ponum header set on the input message.
  • %RegexFilename:pattern%: Where pattern is a regex pattern. For example, %RegexFilename:^([\w][A-Za-z]+)% matches and resolves to the first word in the filename and is case insensitive (test_file.xml resolves to test).
  • %Vault:vaultitem%: Where vaultitem is the name of an item in the vault. For example, %Vault:companyname% resolves to the value of the companyname item stored in the vault.
  • %DateFormat:format%: Where format is an accepted date format (see Sample Date Formats for details). For example, %DateFormat:yyyy-MM-dd-HH-mm-ss-fff% resolves to the date and timestamp on the file.
You can also create more sophisticated macros, as shown in the following examples:
  • Combining multiple macros in one filename: %DateFormat:yyyy-MM-dd-HH-mm-ss-fff%%EXT%
  • Including text outside of the macro: MyFile_%DateFormat:yyyy-MM-dd-HH-mm-ss-fff%
  • Including text within the macro: %DateFormat:'DateProcessed-'yyyy-MM-dd_'TimeProcessed-'HH-mm-ss%