How connectors work
Behavior-level overview of the connector model.
A connector is what lets OpCon Continuum do a specific kind of work — run a command, wait for a file, move a file between machines, call into a legacy system. Each connector contributes one or more job types. When a Builder adds a job to a workflow, they choose a job type; that choice determines what the job does and what settings it needs.
This is the surface customers care about most: connectors are how OpCon Continuum integrates with the systems a bank or credit union already runs.
The four ways a connector runs
How a connector runs determines what (if anything) has to be set up before a customer can use it.
| How it runs | What it means | Setup needed | Examples |
|---|---|---|---|
| Built-in | Ships with the Universal Agent | None | Run Command, Run Script, Wait for File |
| Downloadable | Runs on the Universal Agent as a separate connector the agent has to obtain | The plugin enabled for your organization. No downloadable connector runs in this build — see below | SQL Database Executor |
| Platform-internal | Runs inside the platform — no agent involved | None | Null Job, Workflow Container |
| Legacy (relay) | Runs on an existing on-prem machine through the relay | A relay and reachable machines | UNIX/Linux LSAM, Windows LSAM, IBM i LSAM, SQL LSAM, SMAFT File Transfer, OpCon MFT |
SQL Database Executor jobs do not run in this build. The platform sends them to the agent without the connector's download location, so the agent cannot obtain the connector and every such job fails with External plugin sql-executor requires pluginDownloadUrl and pluginChecksum.
Connections
Some connectors need a saved connection — the endpoint and credentials for an external system or the account a job runs as. A legacy UNIX job, for example, takes a batch user connection for the account it runs on the machine as. Built-in utility connectors (Run Command, Run Script, Wait for File) need no connection because they act on the agent itself.
Credentials in a connection are delivered to the connector securely at run time and are not exposed in the job definition. (Connection setup and security is an Administrator topic.)
Where a job type can run
A job type can require a specific operating system or agent type. The platform only dispatches a job to an agent that matches — for example, an SSIS package job targets Windows agents, and a UNIX LSAM command targets UNIX LSAM agents. If no matching agent is available, the job can't be assigned.
Before a job runs
When a Builder configures a job, its settings are validated against the connector's parameter definition before any work is sent to an agent. A job with missing or invalid settings is rejected up front rather than failing on the agent. Each connector also runs in isolation on the agent, so one connector's failure doesn't affect others.
The connector catalog
Fourteen connectors provide 58 job types today. Each connector declares a category, which is how the Plugins administration page groups and filters them.
| Connector | Category | Job type(s) | How it runs | Needs a connection? | Runs on |
|---|---|---|---|---|---|
| Run Command | Script | Run Command | Built-in | No | Universal Agent (Windows/Linux/macOS) |
| Run Script | Script | Run Script (PowerShell, Bash, Python, Shell) | Built-in | No | Universal Agent (Windows/Linux/macOS) |
| Wait for File | Utility | Wait for File | Built-in | No | Universal Agent (Windows/Linux/macOS) — see Wait for File job |
| SQL Database Executor | Database | MS SQL Script, MS SQL Job, MS SQL DTExec (SSIS), MySQL Script, Oracle Script, Other DB Script (ODBC) | Downloadable | Yes — a database connection (SQL Server, MySQL, Oracle, or ODBC) | Universal Agent; OS varies by job type |
| Null Job | Internal | Null Job | Platform-internal | No | No agent — completes immediately |
| Workflow Container | Internal | Workflow Container | Platform-internal | No | No agent — runs another workflow as a step |
| UNIX/Linux LSAM | Integration | UNIX Command, UNIX - File Arrival, UNIX - Embedded Script, and seven UNIX - Episys types (Run JobFile, Answer Prompts, Compare ACH Totals, three Find types, FTP all Reports in List) | Legacy (relay) | Yes — a UNIX Batch User connection, the account the job runs as; four Episys types also take an Episys credential connection | Legacy UNIX/Linux LSAM agent |
| Windows LSAM | Integration | Windows Command, Windows - WS_FTP Pro, Windows - Command: File Copy / Move / Rename / Delete, Windows - Corelation, Windows - Fiserv DNA, Windows - Fiserv DNA (File Loader), Windows - File Arrival, Windows - Embedded Script, Windows - Web Services | Legacy (relay) | Optional — a Windows Batch User connection; blank runs the job as the agent's service account | Legacy Windows LSAM agent |
| IBM i LSAM | Integration | IBM i (AS/400) Batch Job — enablement in progress | Legacy (relay) | Optional — an IBM i Batch User connection; blank uses the job description's default user | Legacy IBM i LSAM agent |
| SQL LSAM | Integration | MS SQL Script | Legacy (relay) | Optional — a SQL Batch User connection; blank runs the job as the agent's service account | Legacy SQL LSAM agent |
| SMAFT File Transfer | File Transfer | SMAFT File Transfer | Legacy (relay) | Up to two Batch User connections, one per end, matching each machine's platform | Legacy Windows or UNIX LSAM agent — see SMAFT File Transfer job |
| OpCon MFT | File Transfer | OpCon MFT Transfer | Legacy (relay) | Optional — an OpCon MFT Compression Password connection, used only when the transfer compresses or decompresses | OpCon MFT agent — see OpCon MFT Transfer job |
| OpCon RPA | Integration | OpCon RPA Task | Legacy (relay) | No — none of any kind | OpCon RPA agent — see OpCon RPA Task job |
| EASE (Episys As A Service) | Integration | Twenty EASE - types (RSJ, RSJMULTI, RSJEDIT, MONITOR, PROMPT, PROMPTSEQ, TRANSLATE2COMMAS, RESET, SEQ, SEQ-SEND, five letter-file and report types, FILEPERMS, RUN-FTP-OUT, and three BUNDLE types that are not supported yet) | Legacy (relay) | No — none of any kind | EASE agent — see EASE jobs |
For the full per-job-type breakdown — internal names, connection types, and OS requirements — see the Job type catalog.
- Null Job is a workhorse for workflow design, not a no-op to dismiss: it's used to aggregate dependencies, hang events off a single point, and build a workflow on hold.
- Workflow Container embeds one workflow inside another — when troubleshooting a workflow, remember a job may itself be an entire child workflow.
- Legacy LSAM job types only work through a configured relay; "no agent available" for any of them usually points at the relay or LSAM connectivity, not the Universal Agent.
- Windows LSAM carries more than one job type. Besides Windows Command it provides a WS_FTP Pro file transfer, four file operations (copy, move, rename, delete), a Corelation batch job, and two Fiserv DNA jobs (an SQT job and a File Loader) — all with command lines the relay builds for you from form fields, so there's no command-line field to fill in. File Arrival is the exception: it waits for a file to turn up on the machine using the LSAM's own file watcher, so there is no connector to install and no command line at all.
- IBM i LSAM was the newest legacy connector until the SMAFT one, and its enablement is still in progress. It also has no exit-criteria setting, because IBM i exposes no exit code for the relay to translate.
- SMAFT File Transfer is the one connector that spans platforms — a single job can move a file between a Windows and a UNIX machine — and the one whose machine you don't pick. You name both machines, and Start Transfer On decides which of the two runs the job. It also has no exit-criteria setting: the file-transfer agent's own verdict is the job's outcome.
- OpCon MFT is reached through a relay but is not an LSAM. It is a separate kind of agent with its own HTTPS API, so it has no JORS port and no file-transfer endpoint, and it cannot be either end of a SMAFT transfer. Its transfer job names one agent and moves files between two endpoints configured on it, and the endpoint and PGP key lists you pick from are read live from the agent rather than held in Continuum.
- OpCon RPA is the second connector reached over REST rather than the LSAM wire. Like OpCon MFT it rides a relay without being an LSAM, so it has no JORS port and no file-transfer endpoint, and the relay has to report that it can serve RPA agents before one can be registered under it. Its job type takes no connection at all and has no exit-criteria setting — the process status the RPA agent reports is the job's verdict.
- EASE is the third connector reached over REST rather than the LSAM wire, and the first that runs its jobs somewhere you do not administer. An EASE job adds a pre-built job to today's instance of your schedule on Jack Henry's EASE OpCon and waits for it; the remote status is the verdict, so there is no exit-criteria setting, and there is no connection to pick because the credentials live on the agent. Three of its twenty job types are in the catalog and fail at start — they add a container job to a local OpCon schedule, which Continuum has no equivalent for yet.
- Two connectors move files, and they solve different problems. SMAFT File Transfer moves a file between two legacy LSAM machines; OpCon MFT moves files between two endpoints on one MFT agent, with optional compression, PGP encryption and renaming along the way. Neither substitutes for the other.
- Two connectors provide a job type named MS SQL Script, and only one runs today. The SQL LSAM one runs the script on an existing SQL LSAM machine through the relay, using a batch user. The SQL Database Executor one, for a Universal Agent over a saved database connection, does not run in this build. The job type catalog names the plugin beside each.
Related topics