Process Handling Scenarios

When specifying general settings for a process, you must specify whether there will be one project per job or multiple projects per job for the process.

If you select the One Project per Job option, each project assigned to the process will spawn its own job or more than one job if that project contains multiple input files that are to be handled each in its own job. If the Allow Parallel Jobs option is not selected, then the job(s) from the first project will be processed before the job(s) from the second project, and so on. If allow parallel jobs is selected, however, then one cannot assume that the spawned jobs will run in any particular sequence.

If you select the multiple projects per job option on the General tab, then each job spawned will process the inputs for all the projects in their given order. Often there will be only one such job spawned, but there will be more than one job spawned if any of the projects specifies multiple input files that are to be handled each in its own job.

NOTE: In the case where more than one project specifies multiple input files that are to be handled each in its own job, then the process will generate an error if the multiplicities implied by these multiple projects actually exist, and/or are not compatible with each other. See Scenario 8 further for an example of this.

Below is an analysis of the scenarios that can arise from a process containing two projects, ProjectA and ProjectB. ProjectA has input Class*.prn that expands to ClassJan.prn, ClassFeb.prn, and ClassMar.prn. ProjectB has input Employ*.prn that expands to Employ1.prn and Employ2.prn.

Scenario 1

Spawns 2 jobs:

  1. Job1: ProjectA with inputs ClassJan.prn, ClassFeb.prn, ClassMar.prn

  2. Job2: ProjectB with inputs Employ1.prn, Employ2.prn

Scenario 2

Spawns 1 job:

  1. Job1: ProjectA with inputs ClassJan.prn, ClassFeb.prn, ClassMar.prn AND ProjectB with inputs Employ1.prn, Employ2.prn

Scenario 3

Spawns 3 jobs:

  1. Job1: ProjectA with inputs ClassJan.prn, ClassFeb.prn, ClassMar.prn

  2. Job2: ProjectB with input Employ1.prn

  3. Job3: ProjectB with input Employ2.prn

Scenario 4

Spawns 2 jobs:

  1. Job1: ProjectA with inputs ClassJan.prn, ClassFeb.prn, ClassMar.prn AND ProjectB with input Employ1.prn

  2. Job2: ProjectA with inputs ClassJan.prn, ClassFeb.prn, ClassMar.prn AND ProjectB with input Employ2.prn

Scenario 5

Spawns 4 jobs:

  1. Job1: ProjectA with input ClassJan.prn

  2. Job2: ProjectA with input ClassFeb.prn

  3. Job3: ProjectA with input ClassMar.prn

  4. Job4: ProjectB with inputs Employ1.prn, Employ2.prn

Scenario 6

Spawns 3 jobs:

  1. Job1: ProjectA with input ClassJan.prn AND ProjectB with inputs Employ1.prn, Employ2.prn

  2. Job2: ProjectA with input ClassFeb.prn AND ProjectB with inputs Employ1.prn, Employ2.prn

  3. Job3: ProjectA with input ClassMar.prn AND ProjectB with inputs Employ1.prn, Employ2.prn

Scenario 7

Spawns 5 jobs:

  1. Job1: ProjectA with input ClassJan.prn

  2. Job2: ProjectA with input ClassFeb.prn

  3. Job3: ProjectA with input ClassMar.prn

  4. Job4: ProjectB with input Employ1.prn

  5. Job5: ProjectB with input Employ2.prn

Scenario 8.1

NOTE: Scenario 8.1 is executed if the key "PumpTaskLegacyBehavior" is set to "true" in the config.xml file.

Scenario 8.2

NOTE: Scenario 8.2 is executed if the key "PumpTaskLegacyBehavior" is set to "false" in the config.xml file.

Spawns 3 jobs:

  1. Job1: ProjectA with input ClassFeb.prn AND ProjectB with input Employ1.prn

  2. Job2: ProjectA with input ClassJan.prn AND ProjectB with input Employ2.prn

  3. Job3: ProjectA with input ClassMar.prn