Technical framework conditions

Significance of process changes in the customizing transport

The following changes in BPM processes are considered by the customizing transport:

The documentation about the customizing transport contains all the details.

Rights concept

The the data read/write rights of users from CURSOR-CRM are generally applied to CURSOR-BPM.

The following therefore applies for the process tasks listed below:

• Process start: The process is started with the rights of the user, who triggered the relevant process. Should a process be triggered due to e.g. a data change in the entity, then the rights of the user, who effected the changes will be applied.

• User task: A user task is executed with the CRM rights of the relevant user.

• Script tasks: A script task is executed after process start with the same rights used for starting the process. Later on in the process, script tasks will be executed with the same rights used for the previous user task.

• Email import: Similar to the previous general descriptions, the email import contains the rights of the user importing the emails or those of the BCC importer installed for that purpose.

• XML import: The XML import occurs with the rights as per web service authentication.

This rights concept applies also for the execution of searches within the process.

The system differentiates between set rights and field rights when saving data. The process will run into an error if the relevant rights for saving a dataset are not provided. The process administrator can then either assign the process to another employee with the necessary rights by re delegating the instance, or he can assign the required rights to the original employee. The employee can then call up the task a gain from the task list and continue the process.

Only those fields for which rights are available will be saved if rights are missing for some fields.

Information about insufficient user rights
Where a user has insufficient rights on set level within the scope of a BPM user task, then the system will display a relevant message for the following tasks and can consult his BPM administrator:

• myCRM and mask script start of processes

• Saving, creation, deletion of datasets

• Process continuation

The user task contains an error status and can be released for further processing by the BPM administrator by changing the rights of the current user or by delegating to another user.

Data maintenance between the BPM process and CRM

Important to know:

• No data can be modified in the CRM database in and by user tasks.

Default behavior

Conflict case in data maintenance due to default behavior

Optional behavior as of version 2015 to prevent conflict cases

BPM processes that use data from CRM have their own data maintenance during process execution. Should one instance take very long to complete, because e.g. the processing of user tasks is delayed due to rest times, a danger of data not matching between the running process and the CRM may exist if data was changed in CRM after the process has started. Previously, any more up to date data in CRM was simply overwritten by processes. The system now checks whether the data differs between the process and CRM.
Technically, the update date in CRM is used to check whether the data for the data container to be saved differs from the data currently saved at the time of reading.
If there is a deviation, the user of the relevant user action receives the usual dialog in CRM for processing the data conflict with which the field values are reused as specified by the user.

Synchronous and asynchronous data execution

Processes can be run synchronously and asynchronously.

Synchronous means that no other tasks and actions can be carried out in the CRM client while the process (or a partial process) is running and that the system will wait until the process or sub process is completed. A parallel execution of multiple client tasks is only possible in asynchronous mode. Client tasks are not the same as user or system tasks in a process. This parallelization is currently not yet available in CURSOR-BPM.

Synchronous script tasks are triggered by a start in the foreground (e.g. via mask scripts, in the myCRM section or as a response to data-specific events live saving, etc.). Asynchronous process starts occur via a background call-up (e.g. via web service or timer). The following important detail should be noted: Web service starts are synchronous from the viewpoint of the web service caller.

The execution modes differ additionally in their behavior as follows:

In a synchronous execution, all data changes will only be written to the database at the process or partial process end time (e.g. wait states, timer or user task, but not sub processes). This procedure ensures data consistency and data safety. No partial changes will be written, in case a process encounters an error during execution or is otherwise interrupted or canceled.

That also means that multiple searches in a common data space (e.g. a group of activities) within one process will always access the data space that was valid at the time of the process or search start. Changes to the data quantity effected by the process will not influence the encountered data range of synchronously following searches executed at instance run time. Other changes, e.g. from CRM, can nevertheless influence the data quantity at the time of instance run time. If the process is to use previously modified data, work must continue in the generated or changed workspaces.

In contrast to synchronous execution, all changes are written to the database immediately in an asynchronous run. That is because data cannot be buffered during the process or will require some primitive data types (e.g. integer) and objects to function correctly (see process variables that support only these data types). Searches conducted by the process instance during process run time can therefore work with the same data range and will always include the latest changes from upstream process steps or code executions.

A process that is actually synchronous, can be executed asynchronously by switching a timer intermediate event in front of the part of the process, where an asynchronous execution should be initiated.

This is recommended only if process safety is a given in a productive environment and if all possible error sources can be excluded, because partial changes in the data range will not be reversed in case of a process abort.

In an asynchronous process run, data integrity is key: the relevant process section must be designed in such a way that possible process interruptions (e.g. a server crash) will produce as little data for clean-up as possible.

Hint

Summarize all data changes at the end of this process section in to-do blocks.

Example: Collect the data in variables and only write them at the end of the database