Subprocess Data Fields and Unmapped Formal Parameters

Subprocess data fields and unmapped formal parameters are moved up to the calling process after refactoring. In order to preserve the original semantics of the subprocess, any data fields or unmapped formal parameters in the subprocess that also exist in the calling-process are renamed (each new instance of the same named data is suffixed with a sequence number). Any references to the renamed subprocess data are updated when the subprocess activities and flows are moved up to the calling process.

Note: Package-level data fields are not included in this behavior unless the subprocess is in a different package to the calling process.

For example: A subprocess has a data field called CustomerField which its activities use internally. The calling process also has a field called CustomerField which it uses internally.

When the subprocess is in-lined, the subprocess CustomerField is copied into the calling-process as CustomerField2. All references to CustomerField in subprocess activities and flows are replaced with references to CustomerField2.

Multiple Calls to a Sub-Process

This rule also applies when several subprocesses are called from a single process. If the subprocesses have the same data fields names, then each invocation will cause separate, sequence-numbered instances of data fields in the calling process when they are made inline.

For example: There are two calls to the same inline subprocess from a single calling process. The subprocess has a field called CustomerField.

The copy of subprocess activities and flows ‘moved up’ in place of one call subprocess activity will operate on CustomerField and the other will operate on CustomerField2.

Field Name Conflicts

This rule also applies when inline subprocesses are nested, and have conflicting field names.

For example: The calling-process (MainProcess) calls an inline subprocess (SubProcess) which in turn calls a nested inline subprocess (SubSubProcess).

Each process has a field called CustomerField.

  • SubSubProcess is in-lined into SubProcess so that its instance of CustomerField becomes CustomerField2 in SubProcess.
  • SubProcess now has 2 fields, CustomerField and CustomerField2. When this is in-lined into MainProcess CustomerField in SubProcess is dealt with first (alphabetically) and is therefore renamed as CustomerField2 in MainProcess.
  • Now when the SubProcess field CustomerField2 is subsequently copied into MainProcess, a CustomerField2 already exists so it is renamed as CustomerField3.