Basic rules and restrictions for BPM in CURSOR-CRM
CURSOR-CRM is a software that contains a BPMN-based process machine
The not yet fully completed BPMN scope of functions of the Activiti process engine is accessed, which was expanded to include CURSOR-CRM-specific functions. The BPMN scope used was restricted to those functions required to automate workflows in CURSOR-CRM. It is one of the tools used for mapping, automating and optimizing processes in CURSOR-CRM.
CURSOR-BPM - the control center for BPM administrators
The administration and management of the BPMN processes used in CURSOR-CRM is possible only via a rich client. Modeling, instance administration and run time monitoring of processes can only be done here. The run time environment also allows a parallel execution and running of the processes in a rich client and a web client. Switching between clients for the work to be done in the various process phases is easy. User tasks within the scope of a process run cannot be edited via app.
It is important to know that the viability of a process cannot be checked fully or guaranteed at the time of deployment. It is the responsibility of the process architect to ensure viability by way of tests in the test system.
Interaction and process logic comply with the JavaEE 3-layer architecture
Process engineering complies with the following principle: User interaction occurs on the client, data processing and calculation on the application server, and data maintenance occurs in the database. The process workflow controlled by the process engine occurs on the application server. CRM data and process data are saved individually in separate tables on the database and can be synchronized via process configurations.
Each read/write operation occurs in a transaction controlled by the application server. A transaction starts, when control is passed to the application server (start, continuation of a process) and ends, when the user regains control or the process ends. The transaction is interrupted by every BPMN wait status (user task, time-controlled event or incoming intermediate event). The application server limits transaction time to five minutes. For mass data task, the execution must be divided up into several transactions (see also timer intermediate event or asynchronous process call).
The limit of 10,000 datasets for read operations in larger data volumes can be increased only via a server configuration. This setting will also require higher resource consumption and relevantly adjusted storage settings in the application server and client.
Mapping process logic in Groovy
The process script language is Groovy. Groovy is a powerful script language which extends the Java standard by various programming constructs. Some of these should not be used, because they negatively impact the resource consumption of the Java runtime environment and performance or may contradict the rules of the Java Enterprise Edition:
closure: Methods should not be used as variables. A script repository is provided for that purpose.
generated classes: Groovy allows the creation and compilation of classes and objects at run time. This can cause problems in the runtime environment as there is no cache and no clean-up mechanism.
Direct database access: java allows direct database connections to be established. This is, however, not permitted according to Java EE rules and can result in database deadlocks.
Customer-specific third-party libraries: CURSOR-CRM allows the accessing of third-party libraries and their integration in BPM processes. CURSOR accepts no liability for these functions and their effects.
Recommendations for Groovy
In order to maintain readability in scripts, we recommend using the Java syntax, because Groovy allows various syntax extensions, which third parties may not directly understand. This will make work easier in later reworks by colleagues or customers.
Process mask design for web client use
Web client masks are generated in the GUI builder in XML format.
The names must comply with the following regular expression to prevent errors in the Web Client:
[A-Za-z][A-Za-z0-9_.]* (Starts with an ASCII character (no umlauts), followed by any number of ASCII characters, numbers or underscore or full stop (no spaces)).
Any warnings in the mask design are noted in the log file (WebMaskBuilder.log) in conjunction with the web mask as a .xhtml file. The files are located in the temp registry of the CRM client.
The following elements and properties are not yet supported on the web client:
Panel: "Show border" and "Fill background"
Button: "Context menu"
Mask report: "Show toolbar" and "Show border"
Web component: "Navigation allowed"
Radio buttons
Supported databases
The process engine Activiti only supports Oracle and MSSQL. CURSOR-BPM is therefore only enabled for these two DBMS and will not function with any other DBMS, specifically not DB2 (AS400) and Informix.
Maximum script size
Groovy and Java do not allow unlimited script lengths. The size limit for individual methods is set to 65535 bytes. This problem becomes apparent if a Groovy script is not sub divided into individual methods. A Java class is generated and compiled for running a Groovy script. If no methods are used in a script, then the script is packaged into a larger method in the generated class. Should that amount to more than 1000 lines, then errors can easily occur:
MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large!Long codes should therefore be sub divided into several methods to ensure transparency and maintainability.