IPC Event

Parent: The process planning the child process

Child: The process being planned by a parent process

Plan / Planning: The process of instantiating an existing process by using administrative tools or the IPC wizard

Recursive call: The parent process is called as the child

Asynchronous: The parent process instantiates the child, passes data to the child, and proceeds with the next activity

Synchronous: The parent process instantiates the child, passes data to the child and then waits for the child to return data

Calling

Calling a child process requires you to choose the child process as well as the manner in which the child process is called (Synchronous/Asynchronous).

The Child Process

The child process is planned by the parent process in the context of an activity during the execution of the parent process. When the child process is planned, one of two events takes place depending on how it's planned. The parent process will wait for the child process to complete its execution (Synchronous), or the child process executes without any further interaction with the parent process, and the parent process moves on to the next event or activity (Asynchronous).

Folio

The folio is an optional piece of data that is added to the process call which ties the parent and child processes together. This is for information purposes only and has no bearing on the actual execution of the process itself.

The Call Method

The call method impacts when and how data is transferred between the parent and child processes. The synchronous method is used to wait for the child process to complete, and typically pass data back to the parent process. If return data is not required (data can be information or a Boolean indicator) the asynchronous method can be used.

Recursive Process Calls

It is OK to call the parent process as the child process. However, this creates a recursive call of the same event. The danger when doing this is that the child process may go into an infinite loop of calling itself. This can result in many processes being instantiated. This impacts on the available system resources and may lead up to the physical machine experiencing performance issues to the point of not responding.

You must, therefore, consider why the need for a parent process to be called as a child is required and if it's necessary. Logic should be introduced into the workflow leading up to the IPC call to ensure that the logic path is not recursively calling the same parent process as a child.

The data direction is in reference to the parent process. Data between the parent and child processes is passed in, out or bi-directionally between the parent and child processes, and always at the level of the process (vs. the activity or event).

Field	How it functions
Receive data from child process	Data is sent from the mapped field in the child process to the parent process
Send data to child process	Data is sent from the mapped field in the parent process to the child process
Send data to child process and receive data back upon completion	Data is sent from the mapped field in the parent process to the child process. Data is received back from the child process when the child process is complete. Applies to a synchronous IPC configuration where the parent process waits for the child process to complete.

You may have scenarios where the parent process handles one aspect of the process approval while a child process is called when LOB (line of business) updated needs to take place. Not all LOB systems use the same authentication as the parent process and may require the credentials to make the call. In this case the IPC event as well as cached credentials must be set using the User Settings page in K2 Workspace. However, care must be taken when configuring the process call and the Authentication Mode selected as this impacts on which credentials are used.

Managing Authentication Errors

During the life span of the process, there might be authentication errors. This does not always mean a fatal system failure or error but, provided the security is setup correctly, correcting the authentication error may be as simple as caching new credentials against the security label for the LOB system.

The authentication errors show up in the K2 Server error log / error profile.

Security Methods and Authentication

There are a number of authentication methods available. Since an IPC call may initiate a process to which the originator does not have rights, the authentication method must be chosen that suits a successful completion of the process call.

The authentication methods provided:

• Integrated Windows
• Basic (password sent in clear text)
• Impersonate Originator

The method chosen determines what credentials will be passed. The Integrated Windows method passes the credentials of the K2 service account to the child process for authentication purposes. The Basic method passes a connection string containing the user name and password from the parent process to the child process for authentication purposes. The Impersonate Originator method passes the user credentials of the user that started the parent process to the child process for authentication purposes.

Single Sign On

Single Sign On (SSO) may be necessary if the child process requires a secondary set of credentials to be passed to a LOB system. This requires that a user's credentials are cached against the appropriate label.

If credentials for the backend system have not been cached, the child orparent process may go into error or not complete successfully depending on the call mode (sync or async) selected.

Process Call Considerations and Credentials Cache

Shown below is the selection for calling a process either synchronously or asynchronously. Regardless of the method chosen, the child process is ultimately owned by the K2 server and the K2 service account. Therefore, if the child process accesses a LOB resource and that resource requires a cached credentials, the K2 server service account must be cached against that security label and, in addition, any user credentials that may be cached as well.

Avoiding errors for LOB systems when calling the child process

There are two instances where an authentication error can take place, where the child or parent and child processes may go into error or not complete.

Synchronous Call: In a synchronous call, the parent process waits for the child to complete. If there is an authentication error both the parent and child process would be in an error state. The child process is in error due to the authentication error, and the parent process because it can only continue once the child process returns that data it is expecting.

Asynchronous Call: In an asynchronous call, the parent process passes data to the child process and then moves on to the next activity. If there are any authentication errors, the child process does not complete but the parent continues running. In this case the use of the folio is very useful as it would link the parent process to the child.

The IPC Event wizard enables you to call a child process from a main, or parent, process. Click Next to continue.

Requirements:

• The identity of the child process
• The folio details
• The method used to call the process

Field	Description	Sample Value
Process	The process to be called as a child process.	Click the ellipses to find a process using the Context Browser or click the Browse button to locate a potential child process in the current solution
Folio	A unique name for the instance of the process.	Select a data field that you want to use as a folio reference
Select how to call the process	Synchronous Select this option if you require the child workflow process to be completed before the parent workflow process can continue. Asynchronous Select this option if the child workflow process and the parent workflow process can run simultaneously	Select an option

Selecting an existing process

Clicking the Browse button opens the Select a Process dialog. The dialog displays processes on the local K2 Server. One Child process is selected from the dialog.

The Select a Process dialog lists two type of processes 1) existing processes 2) the parent process. The parent process can be selected as the child process, however this creates a recursive process call.

Requirements:

• The workflow server (multiple servers may be listed)
• Authentication method (select the appropriate method)

Field	Description
Workflow Servers	Specify the server name where the child workflow process is hosted
Authentication Mode	Integrated : This option uses the K2 service account as the user attempting to start the IPC Process. Basic : Use this option to specify a security label, user name, password and domain to call the child process. Note that the password is sent unencrypted. Impersonate Originator: This option uses the credentials of the person who started the main process as the user attempting to start the IPC Process. Note: This option is only available if the IPC process is located on the local K2 server.

This step provides the ability to map any field (process level and activity level) or value (inline functions, Workflow Context fields, etc) from the parent to the child process.

The data configuration information maps the child process fields to the parent fields or values.

Field	Description	Sample Value
Field Name	Data or XML field of the child process	Tick the option if this data field should be mapped to the parent process
Description	The description of the field
Value	The value that should be used to map the parent process with the child process fields	Type a value or drag and drop a value from the Context Browser on the right

Field Mappings

The data field mappings are created between parent and child processes. The mapping is a one to one mapping between two data fields of the same type between the parent and child processes. The Process Send Field Mappings page provides the ability to send data to a child process when it is called.

Data Direction

The data direction is always taken with reference to the parent process. Data between the parent and child processes is passed in, out or bi directionally between the parent and child processes.

Field	How it functions
Receive data from child process	Data is sent from the mapped field in the child process to the parent process
Send data to child process	Data is sent from the mapped field in the parent process to the child process
Send data to child process and receive data back upon completion	Data is sent from the mapped field in the parent process to the child process. Data is received back from the child process when the child process is complete. Applies to a Synchronous IPC configuration where the parent process waits for the child process to complete. The data sent and received are both separate mappings created.

This step provides the ability to map process level fields from the child back to the parent process. This step is not applicable to an asynchronous configuration as the process won't wait for the child process to complete.

The data configuration information maps the child process fields to the parent fields. Activity level data and XML fields can also be mapped.

Field	Description	Sample Value
Field Name	Data field of the parent process	Tick the option if this data field should be mapped to the child process
Description	Specifies the field type	N/A
Value	The value that should be used to map the parent process with the child process fields	Drag and drop a field from the Context Browser on the right

Field Mappings

The data field mappings are created between Parent and Child processes. The mapping is a one to one mapping between two fields of the same type between the Parent and Child processes. The Process Return Field Mappings screen provides the ability to return data from the child process upon completion of the child instance.

Data Direction

The data direction is always taken with reference to the parent process. Data between the parent and child processes is passed in, out or bi directionally between the parent and child processes.

Field	How it functions
Receive data from child process	Data is sent from the mapped field in the child process to the parent process
Send data to child process	Data is sent from the mapped field in the parent process to the child process
Send data to child process and receive data back upon completion	Data is sent from the mapped field in the parent process to the child process. Data is received back from the child process when the child process is complete. Applies to a synchronous IPC configuration where the parent process waits for the child process to complete. The data sent and received are both separate mappings created.