Oracle EPM Automate copyToSftp — Eliminate the Middleman: Direct Cloud-to-SFTP File Transfers!

If you've been running Oracle EPM Cloud automations for any length of time, chances are your file transfer workflow looks something like this: run a data export in EPM Cloud, download the file to an intermediary server using downloadFile, then use a third-party SFTP client (like WinSCP) to upload it to the destination SFTP server. It works — but it's clunky, introduces unnecessary dependencies, and creates security exposure by landing sensitive financial data on a local disk.

What if I told you there's a single command that sends files directly from EPM Cloud to any SFTP server — no local download, no third-party tools, no files touching intermediate servers?

Meet copyToSftp.

In this post, I'll walk through what copyToSftp does, the authentication methods it supports (including the newly introduced SSH key-based auth), the prerequisites, and — most importantly — the real-world lessons I learned while implementing it for a production FCCS-to-Adaptive integration at a client site.

 

The Problem: The Traditional 5-Step Relay

Before copyToSftp, a typical EPM-to-SFTP automation looked like this:

EPM Cloud ──downloadFile──▶ Local Server ──WinSCP──▶ SFTP Server

The full workflow:

1. epmautomate runDataRule — Generate the extract in EPM Cloud
2. epmautomate downloadFile — Download to local server inbox
3. Rename-Item — Rename with timestamp for versioning
4. WinSCP PutFiles() — Upload to destination SFTP
5. Move-Item — Archive locally

Dependencies required:

• WinSCP .NET assembly (WinSCPnet.dll)
• Stored SFTP credentials (sftp_credential.xml via DPAPI)
• Local inbox and Archive directories
• Network connectivity from local server to SFTP

 

 

The Solution: copyToSftp — One Command, Zero Intermediaries

The copyToSftp command copies a file directly from an EPM Cloud environment to an SFTP server. No downloading. No local staging. No third-party libraries.

 

EPM Cloud ──copyToSftp──▶ SFTP Server

 

The new workflow:

1. epmautomate runDataRule — Generate the extract in EPM Cloud
2. epmautomate copyToSftp — Send directly to SFTP ✅

That's it. Two steps.

 

 

 

 

Authentication Methods

As of the April 2026 update, copyToSftp supports three authentication methods:

 

Method 1: Username + Password

The simplest approach — provide SFTP credentials directly.

 

epmautomate copyToSftp sftp://myserver/dir/file.csv myFile.csv username=jDoe password=myPassword

  

Pros	Cons
Simple setup	Password in plain text on command line
No key management	EPM warns about clear-text passwords
Works with most SFTP servers	Less secure for automation

Method 2: Username + Private Key (Unprotected)

SSH key-based authentication without a passphrase — ideal for automated scripts.

epmautomate copyToSftp sftp://myserver/dir/file.csv myFile.csv username=jDoe privateKey=C:\keys\my_key.pem

Pros	Cons
No password transmitted	Key file must be secured on disk
Industry best practice	Unprotected key = risk if server compromised
Automation-friendly	Requires .pem format
No clear-text warning

Method 3: Username + Private Key + Passphrase

The most secure option — the private key itself is encrypted with a passphrase.

epmautomate copyToSftp sftp://myserver/dir/file.csv myFile.csv username=jDoe privateKey=C:\keys\my_key.pem passphrase=myPassPhrase

Pros	Cons
Highest security	Passphrase on command line (use -p param file)
Key + passphrase = two-factor	Slightly more complex setup
Meets compliance requirements

Command Syntax

epmautomate copyToSftp SFTP_SERVER_URL EPM_FILE_NAME

    username=USERNAME

    [password=PASSWORD]

    [privateKey=KEY_FILE]

    [passphrase=PASSPHRASE]

 

Parameter	Description	Required?
SFTP_SERVER_URL	Full SFTP URL including directory and target filename	Yes
EPM_FILE_NAME	Name of the file in EPM Cloud (outbox)	Yes
username	SFTP user account	Yes
password	SFTP password (if not using key auth)	Conditional
privateKey	Full local path to .pem private key file	Conditional
passphrase	Passphrase for encrypted private keys	Optional

 

Supported Cryptographic Algorithms

The SFTP server must support at least one algorithm from each category:

Category	Supported Algorithms
Ciphers	chacha20-poly1305@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm@openssh.com, aes256-gcm@openssh.com, aes128-cbc, aes192-cbc, aes256-cbc
MACs	hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com, hmac-sha1-etm@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1
Key Exchange	curve25519-sha256, ecdh-sha2-nistp256/384/521, diffie-hellman-group14-sha256, diffie-hellman-group16-sha512, and others
Host Key	ecdsa-sha2-nistp256/384/521, ssh-ed25519, rsa-sha2-256/512, ssh-rsa, and certificate variants

---

 

Prerequisites

Before using copyToSftp, ensure the following are in place:

 

1. EPM Automate Installed and Updated

• Latest version of EPM Automate CLI installed on your automation server
• Java Runtime Environment (JRE) configured

 

2. EPM Cloud Login

• Valid Service Administrator credentials
• Encrypted password file (pass.epw) recommended:

epmautomate encrypt YourPassword pass.epw AnyRandomKey

 

3. SFTP Server on Port 22

• copyToSftp supports port 22 only — non-standard ports are not supported

 

4. Private Key in .pem Format (for key-based auth)

• The key must be in PEM format (e.g., -----BEGIN EC PRIVATE KEY-----)
• Supported key types: RSA, ECDSA (nistp256/384/521), Ed25519
• The file must be stored locally on the machine running EPM Automate (not uploaded to EPM Cloud)

 

5. IP Allowlisting (if applicable)

• If the SFTP server has IP allowlisting enabled, add Oracle's outbound IP address for the OCI region hosting your EPM environment

 

6. Public Key on SFTP Server

• The corresponding public key must be added to the authorized_keys file on the SFTP server under the appropriate user account

 

Real-World Implementation: FCCS → Adaptive via SFTP

Here's where theory meets reality. I implemented copyToSftp for a production FCCS-to-Adaptive integration, replacing a WinSCP-based pipeline that had been running for months. Below are the actual findings, errors encountered, and solutions discovered.

 

The Setup

Component	Detail
Source	Oracle FCCS (Test Instance)
Destination	awssftp1.brooksautomation.com
Auth	ECDSA private key (-----BEGIN EC PRIVATE KEY-----)
Username	fccs
Files	DLR_Data_Extract_JE.csv, DLR_Data_Extract_AllEntities.csv

The private key file must reside on the local machine running EPM Automate. The command reads it locally and uses it for the SSH handshake.

 

 

• File Extension Must Be .pem

 

• Do NOT Include password= with Key Auth

When using key-based auth, the password= parameter must be omitted entirely. Including it — even with a dummy value — causes a parsing failure.

 

• PowerShell Mangles key=value Arguments in Scripts

 

Even after placing the .pem file in the correct directory, EPM Automate reported "File does not exist."

 

The Java process running EPM Automate operates under a different security context. The file existed but wasn't readable.

 

The Final Working Command

After all the troubleshooting, here's the exact command that works:

 

epmautomate copyToSftp sftp://awssftp.server.com/DLR_Data_Extract_JE.csv DLR_Data_Extract_JE.csv username=fccs privateKey=C:\Scripts\secure\privatekey-sftp.pem

 

 

Before vs. After Comparison

Metric	Before (downloadFile + WinSCP)	After (copyToSftp)
Steps per file	5	2
Dependencies	WinSCP DLL, credential XML, inbox/archive folders	None — EPM Automate only
Data on local disk	Yes	Never
Auth method	Password (DPAPI encrypted)	SSH key (.pem)
Security exposure	Password + files on intermediary server	Key-only, zero local data
Lines of PowerShell	~80 (SFTP section)	~10
Failure points	Download, rename, connect, upload, archive	Single copyToSftp call

---

 

Pipeline Alternative: No Script Needed

As of the September 2025 update, Oracle also introduced Copy to SFTP and Copy from SFTP as native Pipeline job types in EPM Cloud. This means you can configure the entire extract-and-push flow within the EPM Cloud UI — no PowerShell script required.

This is worth exploring if you want to move the orchestration entirely into EPM Cloud and eliminate the local server dependency altogether.

 

Quick Reference: Troubleshooting Checklist

Error	Cause	Fix
EPMAT-7: File does not exist	Wrong path, wrong extension, or permissions	Use full path, .pem extension, grant read access
EPMAT-7: Invalid or missing parameter: privateKey	Empty privateKey= value or space after =	No space: privateKey=C:\path\key.pem
EPMAT-7: Invalid or missing parameter: password	password= included with key auth	Remove password= entirely
Usage text dumps before error	PowerShell mangling key=value args	Use cmd /c or --% in scripts
EPMAT-7: Session is not authenticated	Not logged in before copyToSftp	Run epmautomate login first
EPMAT-1: File already exists	File from previous upload still in EPM	Run epmautomate deleteFile first
Connection timeout	IP not allowlisted on SFTP server	Add Oracle OCI outbound IP to SFTP allowlist

---

 

Conclusion

copyToSftp is one of those features that fundamentally simplifies your EPM automation architecture. It eliminates intermediary servers, third-party dependencies, and local data exposure — replacing a fragile 5-step relay with a single, secure, auditable command.

Combined with the April 2026 enhancement for SSH key-based authentication, it now meets enterprise compliance requirements for secure file transfers without compromising on automation capability.

 

Whether you're pushing FCCS extracts to Adaptive, sending reconciliation data to FloQast, or transferring reports to any SFTP endpoint — copyToSftp should be your default approach.

 

Key takeaways:

•  Use .pem format for private keys
•  Omit password= when using key auth
•  Use cmd /c in PowerShell scripts to avoid argument parsing issues
•  Grant file read permissions for the Java process
•  Allowlist Oracle's OCI outbound IP on your SFTP server
•  Consider Pipeline job types for fully cloud-native orchestration

Happy days on the Cloud!!!