Spawning a Subprocess

The spawn process is a sub-process that is started ad-hoc in the scope of an active process instance in runtime environment by users. These sub-processes cannot be specified at the time of workflow design. So a spawned sub-process behaves asynchronously with respect to execution at the time of:

Abort
Recovery
Process Hierarchy

It is possible to spawn all processes from all active models that are startable and you are authorized to start, including the most recent version of the same model.

Common Usage Pattern
Business Case
Data Copy/Mapping Semantics - Pass by Value vs Pass by Reference
Behavior of Subprocesses in Process Instance Hierarchy

Common Usage Pattern

Stardust Process Portal is used to control and automate workflows in organizations. Previously, workflows have to be described as structured process models, where the sequence of steps and possible alternative paths are modeled. Also, the workflow is controlled according to these models at system runtime for a possible large number of business cases following the same model structure. In short, organizations have to follow the structured workflows.

However, for some organizations it is not feasible due to complexity of workflow and dependence on the provided data and documents. To model all necessary steps, possible execution paths and involved organizations; it is required to define and change these for a concrete business case during work on the same.

Stardust helps you to specify, manage and monitor ad-hoc work in addition to structured business process execution. It allows teams to work on business cases collaboratively without having a predefined structure for this work. It helps to improve:

Operational efficiency
Auditing capabilities

The following organization scenario explains how Stardust can help you create ad-hoc process instances. Thus, supports unstructured workflow.

The SunBabel Corporation has recently implemented a Scan client to scan documents into Stardust Process Portal and start process instances. The Scanning implementation is generally regarded as a success but two issues have arisen that SunBabel has requested be addressed with new features in Stardust Portal.

Business Case

This business case describes common usage pattern for the process instances that are spawned during the workflow processing. The spawning of a root process instance creates another sub-process of the same root process. The single document is available to all the spawned process instances.

Goal

This use case explains how the spawning of the process can streamline the operation.

Business Scenario 1

With approximately 5% of scans, the scan operator selects the incorrect process in the Scan UI and the document enters the workflow in the wrong process definition. When these errors are discovered these process instances are aborted and the documents are rescanned into the correct process definitions. This can be time-consuming and has resulted in multiple fines when the processing SLA's were missed. SunBabel has requested enhancements to allow operators working in the Stardust Portal to move these Process Instances (PIs) directly to the correct process definitions. Also, any data associated with the documents should be moved to the new process instances.

Business Scenario 2

SunBabel often receives work that contains multiple requests for a single client. Due to Auditing requirements, these documents must be scanned into Stardust as a single document and any additional process instances needed to work the client's requests should be started in the portal and referenced to this single document. SunBabel has requested enhancements that would allow operators in Stardust to spawn a process instance for each of these requests and have each process instance reference the original document. Additionally, these tasks should have a linkage so that business units can track these requests as a single entity.

Example Usage

Create process definitions called Loans, Brokerage, HELOC and IRA
Scan a document into the Loans Process Definition using Stardust Scan application.
Log into Stardust Portal and locate the Loans process instance created in step 1.
Activate an Activity in the newly created Process Instance.
Click the Spawn Process icon to launch the Spawn Process dialog.
Use Spawn Process functionality to start a Brokerage and HELOC, process.
Review the newly started processes and confirm that the document/document data is linked to the source Loans process instance.
Review the process history of each newly started process and confirm that they are shown as sub-processes of the root process instance.

For detail instructions, please refer to the tutorial Spawning Sub-processes of the Developers Handbook.

Data Copy/Mapping Semantics for Spawned Subprocesses

Spawned subprocesses inherit the data of their root process by copy using the usual semantic for copy all data. Similarly, processes that are aborted and started from the root process instance copy the data using the following data copy semantics. Note that target for the copied data can also be other models or model versions.

Data	Synchronous/Asynchronous Subprocess	Spawned Subprocess And Peer Process
Primitive Data	Passed by value	Passed by value
Serializable Data	Passed by value	Passed by value
Structured Data	Passed by value	Passed by value
XML Document	Passed by value	Passed by value
Hibernate Data	Passed by reference	Passed by reference
Entity Bean	Passed by reference	Passed by reference
Document	Passed by reference	Passed by reference, except for the Extract Pages functionality. In the latter case new documents are created.
Document List	Shallow copy means the list get copied and content passed by reference	Shallow copy means the list get copied and content passed by reference
Folder	Passed by reference	Passed by reference
Folder List	Shallow copy means the list get copied and content passed by reference	Shallow copy means the list get copied and content passed by reference
Notes	Passed by value	Passed by value
Process Attachment	Refer Document List	Refer Document List

Data Mapping Heuristics for Spawned Subprocesses and Peer Processes

Data mapping heuristics is only applied to document data and document list. Consider Po is the originating process instance while Ps is spawned one. The following data mapping heuristic apply for spawned subprocesses and peer processes.

Data	Mapping Heuristic
Document	All data values of Po are passed to Ps regardless of whether Ps uses this data. In addition, the following copy heuristics apply to the document data values Po has, but the Process Definition of Ps does not use and the data of Ps that hasn't been initialized yet via the prior step (passing all data from Po to Ps): The same-type-rule - If Po uses a document data d1 with document type t1 and Po has exactly one document data with type t1 and if Ps has exactly one document data d2 with the same document type t1 then the document (including meta data) will be passed from d1 to d2. The one-document-rule - If Po has exactly one document data d1 with type t1 and Ps uses exactly one document data d2 with type t1 (t1 and t2 might be the same types or not)}} then this document data (excluding meta data) will be passed from d1 to d2. else the document data (including meta data) will be passed as process attachment(s) from Po to Ps (unless Ps does not support process attachments).
Document List	Same as Document

Data

Mapping Heuristic

Document

All data values of Po are passed to Ps regardless of whether Ps uses this data. In addition, the following copy heuristics apply to the document data values Po has, but the Process Definition of Ps does not use and the data of Ps that hasn't been initialized yet via the prior step (passing all data from Po to Ps):

The same-type-rule - If Po uses a document data d1 with document type t1 and Po has exactly one document data with type t1 and if Ps has exactly one document data d2 with the same document type t1 then the document (including meta data) will be passed from d1 to d2.
The one-document-rule - If Po has exactly one document data d1 with type t1 and Ps uses exactly one document data d2 with type t1 (t1 and t2 might be the same types or not)}} then this document data (excluding meta data) will be passed from d1 to d2.
else the document data (including meta data) will be passed as process attachment(s) from Po to Ps (unless Ps does not support process attachments).

Document List

Same as Document

Currently, Stardust Portal does not support viewing of Document List, Folder and Folder List.

Department Scoping for Spawn Subprocess

In case the data associated with root process contains department information, it gets copied to the spawned process as it is. Thus, the department scope of a spawned process inherits the department scope of the root process.

Behavior of Subprocesses in Process Instance Hierarchy

	Is Subprocess Of Root Process Instance	Subprocess Instance Must Be Completed To Complete Root Process Instance	Abort Of Root Process Instance Results In Abort Of Subprocess Instance	Abort Of Subprocess Instance Results In Abort Of Root Process Instance	Interrupted Subprocess: Recovery Of Root Process Instance Recovers Subprocess
Synchronous Subprocess	Supported	Supported	Supported (If it hasn't been terminated yet)	Supported (configurable - the user can decide whether to abort root process instance)	Supported
Asynchronous Subprocess	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported (since asynchronous 'subprocesses' are not real subprocesses)
Spawned Subprocess	Supported	Supported	Supported (If it hasn't been terminated yet)	Supported (configurable - the user can decide whether to abort root process instance	Supported