LoopParallel Job
This job type runs a loop in which all subjobs are executed in parallel. It can be used for groups of independent jobs and load to separate cubes / cube slices.
Running a job
To run the job, select Run from the toolbar, indicated in the screenshot below. The job executes using the variable values currently saved in the component.
To run the job with different values without changing what's saved in the component, select Run with options from the dropdown next to Run. This opens a dialog listing the component's variables. Update any variable value as needed, then use the reset icon next to a field, or select Reset all, to restore its saved value. Select Run in the dialog to execute the job using those values; they apply only to that run. If the job has no variables, the dialog states that no variables are used; select Close and run the component normally instead.
To run the job with different values without changing what's saved in the component, select the arrow next to Run and choose Run with options. This opens a dialog listing the component's variables, where you can change values for this run only; the saved values are not affected.
Fail on status
If the job executes several loads or sub-jobs, the selected option defines the behavior in case of a warning or an error message in one of the loads or sub-jobs. The options are described below.
| none | All subsequent loads or sub-jobs are executed even if errors or warnings occur. The job terminates with "Completed with warnings" or "Completed with errors" or "Completed successfully". |
| error | In case of an error message, the job terminates without executing subsequent loads or sub-jobs and the job terminates with status "Failed". In case of warnings subsequent loads or sub-jobs are executed and the job terminates with "Completed with warnings". |
| warning | In case of a warning or an error message, the job terminates without executing subsequent loads or sub-jobs and the job terminates with status "Failed". |
| inherit | If the job is executed directly (without parent job) it uses failOnStatus "error". Otherwise if the job is used as a sub-job it inherits the failOnStatus of its parent job (see corresponding descriptions of these failOnStatus options above). |
Example
variables: level1
Loop source: level1 receiving Jan | Feb | Mar
Execution: Load OneMonth
In the LoopParallel job, the load OneMonth will be executed 3 times simultaneously:
- with variable level1="Jan"
- with variable level1="Feb"
- with variable level1="Mar"
Limits of parallelism are globally configured:
| Parameter | Description of parameter value | Default value | Type |
|---|---|---|---|
| maxParallelWritelExecutions | Maximum number of parallel root executions without counting the dependent subjobs / loads of a parallel running execution. Write executions are those that may change data in the target system, such as starting a load or a job. | 5 | integer |
| maxParallelReadExecutions1 | Maximum number of parallel running Integrator executions. Read executions normally only read data from source systems and don't change data in target systems. Examples: data preview, function preview, tests, drillthrough, metadata, column output. | 7 | integer |
| maxParallelSubExecutions | Maximum number of parallel sub-executions inside of a parallel execution | 5 | integer |
Notes
-
In the case that there is already another running parallel execution at the beginning of a new parallel execution, the new one will only have one parallel sub-execution, i.e., no effective parallelism happens inside the execution. Therefore, as the best practice, at any given moment, run only one execution of a LoopParallel job or a Parallel job with multiple parallel sub-executions. For this "interior parallelization" the limit of maxParallelSubExecutions (default: 5) applies.
-
Other parallel jobs that do not have parallel sub-executions can be efficiently executed simultaneously. For this "exterior parallelization" the limit maxParallelWriteExecutions (default: 5) applies.
Updated September 24, 2026