OpCon RPA Task job
Behavior-level reference for building and diagnosing OpCon RPA Task jobs.
The OpCon RPA Task job starts one task on a single OpCon RPA agent, waits for it to finish, and reports the agent's verdict as the job's outcome. The agent's own logs become the job output.
An OpCon RPA agent is a robotic-process-automation host that exposes an HTTPS REST API. Continuum reaches it through a relay, the same as a legacy LSAM machine — but it is not an LSAM, and the differences matter when you register one:
| Legacy LSAM machine | OpCon RPA agent | |
|---|---|---|
| Platform label | WINDOWS, UNIX, IBM_i, SQL | OpCon RPA |
| Reached over | The LSAM wire protocol | The agent's HTTPS REST API |
| Default port | 3100 (LSAM Port) | 7047 (HTTPS Port) |
| JORS Port | Optional, for job output retrieval | Not offered — there is no JORS listener |
| Credential on the agent record | — | An API Token, which must be a GUID |
| File-transfer (FT) role panel | Offered when editing | Not offered — an RPA agent is never an end of a SMAFT transfer |
An RPA task is the automation the RPA agent holds — a robot script, a browser macro, or a document scan. It is not a Continuum job type. One job type, OpCon RPA Task, runs any of them; which one it runs is the Task field.
Before you can build one
Three things have to be in place.
- A relay that supports OpCon RPA. The relay reports whether it can serve RPA agents, and Continuum refuses to register one under a relay that does not. The register dialog says This relay must be upgraded to run OpCon RPA agents. — see Relays.
- A registered OpCon RPA agent. Agents → Legacy Agents & Groups, pick the relay, then add an agent with Platform set to OpCon RPA. See Registering the agent.
- Tasks configured on the agent. Continuum does not create RPA tasks. It reads the list the agent already holds, so the task you want must already exist in the agent's own configuration.
Registering the agent
The agent form changes when Platform is OpCon RPA:
| Field | Detail |
|---|---|
| Host | IP address or fully qualified domain name of the OpCon RPA agent. Host only — a pasted URL, a path, or a stray space is refused with Enter the host name or IP address only — no scheme, path or spaces. Set the port below. |
| HTTPS Port | Default 7047. Switching Platform swaps the port default, but only while the field still holds one of the platform defaults — a port you typed is never overwritten. |
| API Token | The GUID API token configured on the OpCon RPA agent. Optional on create, but without one the agent reports DOWN and no job can run on it. A value that is not a GUID once trimmed is refused with API token must be a GUID. |
| Max Concurrent Jobs | As for any legacy agent. |
The API token is write-only. It is stored encrypted, it is never shown again, and no read ever returns it — the agent record reports only whether a token is stored.
On an edit you have three choices:
- Leave it blank to keep the stored token.
- Type a new GUID to replace it.
- Clear token to remove the stored token entirely. The dialog then says The stored token will be removed when you save. Typing a value cancels a pending clear — a typed token always wins.
An RPA agent with no stored token reports DOWN, because the relay has nothing to authenticate with. Clear the token only when you are about to enter a new one, or when you are retiring the agent.
There is no Reset API token action for an RPA agent. Continuum cannot mint a token for it: the token is configured on the agent itself, and Continuum only stores a copy.
A token you replace is in use within one relay check-in — the relay re-reads its agents as soon as the change is recorded, and the previous token's session is dropped with it.
Which machine runs the job
The machine is picked in Agent Assignment, as it is for a Windows or UNIX LSAM job. Only OpCon RPA agents are offered, because the job type requires that platform.
The picked machine also decides what the Task and Version pickers contain: each list is read from that agent, so choosing the machine is the first thing to do. Change the machine and both lists change with it.
Configuration reference
The job type takes three fields. It takes no connection of any kind — no batch user, no credential. The account the task runs as is the agent's own business.
Sub-type
| Value | What it runs |
|---|---|
| Robot | A desktop robot |
| Web Macro | A browser macro |
| Scan Document | A document scan (OCR) |
Sub-type is required, and it scopes the Task list — the agent is asked only for tasks of the chosen kind. Change the Sub-type and the Task field clears, because a task id from one kind is not valid in another.
Task
Required. The RPA task to run, identified by its task id.
The list is read live from the agent once both the machine and the Sub-type are set. Each entry shows the task's name, and what the job stores is its task id. If the agent reports a task with no name, its id is shown instead.
Version
Optional. The task version to run: a whole number, or left empty.
Every version of an RPA task has its own task id on the agent, so the version is resolved at the moment the job starts, not when you save it.
| What you set | What runs |
|---|---|
| Empty, or Use latest | The task's highest version, resolved when the job starts |
A whole number — 2, 03 | That version. Leading zeros are dropped, so 03 runs version 3 |
| Anything else | The job fails before anything runs, with RPA task version '…' is not a number or 'Use latest' |
The list shows Use latest first, then the versions the agent reports. Use latest is the field's placeholder, so an empty Version and an explicit Use latest mean the same thing.
Use latest is resolved per run, not per save. A job left on Use latest picks up a new version the moment someone publishes one on the agent — which is usually what you want, and occasionally a surprise. Pin a number when the workflow depends on a specific version's behavior.
When a lookup fails
Both the Task and Version lists come from the agent through the relay. When that call cannot be made, the field falls back to free text and tells you why, followed by You can still type a value.
| Message | What it means |
|---|---|
| The relay serving this agent must be upgraded before it can look up RPA tasks. | The relay does not support OpCon RPA |
| The token sentence | The agent rejected the stored API token |
| The selected machine is not an OpCon RPA agent. | The picked machine is of another platform |
| The timeout sentence | The relay is offline, or the agent did not answer |
Typing a value by hand is legitimate — the field stores a task id, and you can paste one from the agent's own configuration. The lookup is a convenience, not a gate.
What happens when the job runs
- The relay exchanges the agent's API token for a short-lived session with the agent.
- It resolves the version — either the number you set or, for Use latest, the highest the agent reports — into that version's own task id.
- It starts the task, carrying the job's and workflow's instance properties.
- It polls the agent every 5 seconds until the task reaches a terminal status.
- It fetches the agent's logs, renders them as the job's output, and reports the outcome.
Outcomes
The agent reports a process status, and that status alone decides the job's outcome.
| Status the agent reports | Job outcome |
|---|---|
| Created, Scheduled | Still pending — polling continues |
| Running, Paused | Still running — polling continues |
| Completed | Success, exit code 0 |
| Skipped, Failed, Aborted | Failure, exit code -1 |
| Anything else | Failure — never "keep waiting" |
A failed run's termination description names the status: RPA process Failed, RPA process Aborted, or, for a value Continuum does not recognise, RPA process status 9.
This job type has no exit-criteria setting. The status is the verdict; there are no conditions to translate. That puts it with IBM i (AS/400) Batch Job and SMAFT File Transfer rather than with the OpCon MFT Transfer job.
Instance properties the job carries
Every start sends the agent two sets of properties, so a task can read values from the run that started it:
- the job's instance properties, and
- the workflow instance's properties.
Two rules govern what actually arrives.
Values are sent exactly as stored. They are not resolved first, so a property whose value contains property-token syntax reaches the agent as that literal text rather than as a substituted value. This is deliberate.
Encrypted properties are withheld. A property name flagged encrypted anywhere in the job's list
is dropped, and the match is case-insensitive — so flagging Secret also withholds a plain
SECRET and secret. Nothing encrypted is sent to the agent.
If the job's and workflow's properties exceed 64 KiB serialised together, the job ends INITIALIZATION_ERROR with RPA instance properties exceed 64 KiB and nothing runs on the agent. It is not retried — the size will not change on its own. Trim the properties, or move the bulk of the data somewhere the task can read directly.
What the Output tab shows
The job output is rendered once, when the run finishes, from the logs the agent holds. It opens with a header naming the task, the version, the task id, the process, the status, and the start and end times as the agent reported them. Then one section per log item, in the agent's own order.
Shown in full:
- StandardOutput and StandardError
- VariableValue — a value the task set
- TextFile
- TaskProcessStats — pretty-printed when it is readable JSON
Listed but not shown:
- Image, Gif, Video and DownloadedFile — named, with their encoded size, because they are binary
- Cookies — named only. Their value is never shown, because it may carry session secrets
A run whose logs hold nothing shows (no output). A very long output is truncated, and ends with
... (truncated) when it is.
If the logs cannot be fetched after the run finishes, the run is still reported — the job's outcome is never lost to a failed log fetch — and the output holds the reason instead.
Killing a running job
Killing the job asks the agent to abort the process. What happens depends on how far the run had got:
| When you kill it | What happens |
|---|---|
| Before the task was started | Nothing is started on the agent. The job fails with RPA job killed before the RPA process was started |
| While the start is in flight | The abort is sent as soon as the start returns, so no robot is left running |
| While the task is running | The abort is sent. If the agent cannot be reached, it is retried on the next poll |
| After the agent no longer knows the process | The job fails with RPA process not found |
A relay restart resumes the run, not the task
RPA runs survive a relay restart. The relay stores what it needs about each in-flight run and picks it up again when it comes back, and a verdict it had already reached is reported as it was — it is never re-derived by polling again, so a finished run cannot be flipped to a failure by a process the agent has since forgotten.
Two cases cannot be picked up, because the relay went down at the one moment the outcome was genuinely unknown:
| Message | What it means |
|---|---|
| Relay restarted before the RPA process id was known; the process may still be running on the RPA Agent | The start had been sent but its answer had not arrived. Check the agent before rerunning — a robot may be running |
| Relay restarted before the RPA process was started; nothing was run on the RPA Agent | The start had not gone out. Nothing ran; rerun freely |
Unlike the OpCon MFT Transfer job, there is no resume-the-previous-run behavior here. Restarting an RPA job starts a new process on the agent, every time.
Agent health
An RPA agent's UP or DOWN status is checked on its own, about every 10 seconds, by asking the agent for its version and its status. Both have to answer for the agent to be UP, and the version the agent reports is the version Continuum shows for it.
It is DOWN when the agent cannot be reached, when it rejects the stored token, or when no token is stored at all — in that last case Continuum does not even try to call it.
The agent's health is deliberately not tied to whether its own robot clients are connected. An RPA agent with no robot attached still reports UP, because the agent itself is answering. A task that needs a robot that is not there fails as a run, which is where you want to see it.
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| Registering the agent fails with This relay must be upgraded to run OpCon RPA agents. | The relay serving it does not support OpCon RPA | Upgrade the relay — see Relays |
| The agent shows DOWN immediately after registration | No API token is stored, or the stored one is wrong | Edit the agent and enter the GUID token configured on the agent itself |
| The Task list is empty | No machine or no Sub-type is set yet, or the agent holds no tasks of that kind | Set Agent Assignment and Sub-type first, then check the agent's own task list |
| The Task list is empty for one Sub-type but not another | The agent holds no tasks of that kind | Expected — the list is scoped by Sub-type |
| The job fails with RPA task '…' not found | The saved task id no longer exists on the agent | Reselect the task; a task deleted on the agent is not removed from saved jobs |
| The job fails with RPA task '…' has no version … | The pinned version was removed from the agent | Pin a version that still exists, or switch to Use latest |
| The job ran a different version than last time | Version is empty or Use latest, and a higher version was published | Expected — pin a number if the run must not move |
| The job fails with RPA instance properties exceed 64 KiB and nothing ran | The job's and workflow's properties are too large together | Trim them — see Instance properties the job carries |
| The task did not see a property value you set | The property is encrypted, so it was withheld | Expected. Give the task the value through the agent's own configuration instead |
| A property value arrived as literal token text | Carried properties are sent as stored, never resolved | Expected — resolve the value into a plain property first |
| The job output names an image or a video but does not show it | Binary log items are listed, not inlined | Expected — retrieve it from the agent |
| Adding a job to the pool fails with the relay serving agent pool … has not reported RPA support | The pool's relay does not support OpCon RPA | Upgrade that relay, or place the job on a pool whose relay does |
Contact support when
- The agent is UP and its token is accepted, but every task fails with an agent-side status the job output does not explain.
- A run reports Relay restarted before the RPA process id was known and the agent shows no matching process, so you cannot tell whether the task ran.
Related topics
- Relays — the relay that reaches the agent, and the capability it has to report
- Agents and pools — registering and grouping an OpCon RPA agent
- Job type catalog — every job type available today
- OpCon MFT Transfer job — the other REST-reached legacy agent
- How connectors work — the connector model behind this page