Core concepts and execution lifecycle
Separate the definition of work from a particular execution. In iJob 1.0.0, saving a task publishes a version; workflows use Save and publish. Neither action starts execution.
From configuration to results
Resources & parameters
Connections · Input contractsSupply access and input definitions. A task may need no external resource.
Task definition & version
Configure plugin → Save & publishSaving a task publishes its definition; it does not run the task.
Workflow & publication
Dependencies · Gateways · Child jobsPublication fixes the referenced task and child-job versions.
A trigger records its source, time and inputs. Enabling a schedule permits future triggers; accepting a trigger does not mean execution has started.
Tasks reference resources when needed; a task may require no external resource. Publishing a workflow fixes its task and subjob version references. A trigger records its source, time and inputs. Execution also depends on scheduling, concurrency, routing, resources and instance state.
How the concepts relate
| Concept | Meaning in iJob | Example |
|---|---|---|
| Resource | Connection and access configuration used by tasks | Business PostgreSQL, SSH host, HTTP service |
| Task | One plugin configured for an execution action | Query orders, call an API, run a script |
| Job / workflow | Tasks and subjobs connected by dependencies and gateways | Extract orders → check data → process results |
| Subjob | A published workflow referenced by another workflow | Reusable validation flow |
| Version | Published definition snapshot; history is read-only | A parent still references an older task |
| Publish | Produce an executable or referenceable definition version | Save a task; save and publish a workflow |
| Enabled | An object-specific switch controlling applicable operations | An enabled schedule can create future triggers |
| Trigger | An execution request with source, time and inputs | Manual execution or a scheduled time |
| Instance | Identity and state of a particular execution | Root instance and child/node instances |
| Run | The process of progressing toward a terminal state | Inspect topology, stop or retry |
| Parameter template | Input names, types, constraints and defaults | Required batchDate and integer limit |
| Variable | An input, system context value or node output | limit, instance ID or upstream rows |
Account roles ADMIN/OPERATOR/VIEWER differ from runtime roles API/SCHEDULER/WORKER/MAINTENANCE. See permissions and deployment roles.
What each action or state establishes
| Action or state | What it establishes | What still needs checking |
|---|---|---|
| Task saved | A new definition version was published | It did not start automatically |
| Workflow published | The publication transaction fixed current child versions | Preflight checks do not lock those versions |
| Object enabled | Its relevant switch is on | Due time, routing and other conditions |
| Trigger accepted | The execution request was received | Instance creation and actual execution |
| Instance SUCCESS | Plugin/workflow completion rules were satisfied | Target data and business conditions |
| Stop or timeout | The platform handled control or deadline conditions | Remote processes and external effects |
A version-reference example
- Save task A to publish a version.
- Add A to workflow B and publish B.
- Update and save A to publish a newer version.
- B's older version keeps its original reference to A.
- Validate and publish B again to adopt the new task version, then inspect its references.
Product version 1.0.0, definition versions, the Local JAR protocol and database migration numbers are separate identifiers.
Two event paths
- Event binding: a matching event produces a new execution request.
- Event or approval wait: an existing instance waits and continues when a matching event or authorized decision arrives. Waiting is not itself failure.
Approval requires the relevant permission, allowed operator and processable state. Stop, timeout and retry do not automatically undo completed external writes.
Next steps
Run your first task · Parameters and variables · Glossary · Subjobs and versions