Intermediate events

Definition

Intermediate events are wait states in the process, which are not waiting for user interaction, but for CRM system events.

Incoming email

If the system is waiting for an email import, then the mail must comply with specific criteria to continue the process. The criteria are:

Identifier pattern of the subject: The structure of the identifier, consisting of fixed text and number sequences of a defined length that must be contained in the subject.
Process identifier: Select a variable that contains the process identifier at runtime. The identifier must be contained in the subject of the email to continue this process, e.g. a ticket number or a contract number.
Sender address (optional): The email address of the sender. If no variable is specified here, then the sender address will not be checked during import.
Recipient address (optional): The email address of the recipient. If no variable is specified here, then the recipient address will not be checked during import.

You can add fixed text and number sequences for the identifier pattern of the subject via the relevant button. For the identifier TICKET004711, the text TICKET and a 6-digit number (NUMBER6) must be added to the pattern.

If an email was uniquely assigned to a process during the email import, then the process continues and the imported activity is handed over as the variable container (see also start event email import). If multiple processes are uniquely identified for the email, then these will be continued in sequence.

Upon process continuation, the following variables are available, just like for the start event email import:

eventName: ActivityImportEvent
container: The activity dataset generated from the mail import
NewMail: true for a new dataset, false for an update.
Sender: The email address of the sender.
Recipients: A list of recipient email addresses.

Timer intermediate event

You can store a relative time specification for the configuration of the timer intermediate event.

A date variable can be selected instead of a relative time definition. The date variable contains the date variable as a character chain in ISO 6801 format: yyyy-MM-dd'T'HH:mm:ss. This format is generated via the script method DateUtils.convertISO(Date date) from a date value.

CODE

Date date = DateUtils.parseDate("08.10.2014T13:45","dd.MM.yyyy'T'HH:mm") //DateUtils.NOW + 1
String dateISO = DateUtils.convertISO(date)
ProcessUtils.setVariable("date", dateISO)

Event-based gateway

Waiting for the email import under consideration of the configured parameters may result in the process not being continued for a long time. In that case you must ensure that the process can continue via an alternative gateway and re-issue the request for the mail again. Insert a timer intermediate event into the model to run in parallel to the email event.

The process shown here waits a maximum of 5 days for the mail import and will then continue the process automatically. Any incoming mail after that time frame will no longer be assigned to that process.

The system currently considers calendar times as time data, which means there is no separate handling for work times, weekends or public holidays.

Warning

Should an error occur in subsequent actions in connection with the timer intermediate event, the process workflow will attempt the process execution 2 more times. This is a fixed default setting of the Activiti repository.

Attached intermediate event

The timer intermediate event can be attached to user tasks or sub processes for time escalation via drag and drop.

You can attach exactly one event. You can set via the option Cancel activity, whether the activity should then be canceled or whether it should occur in parallel to the user task.

The non-interrupting state of this option is depicted with dotted lines in the model.

Message intermediate out event

Actions can be executed on the client without user interaction via the message intermediate out event. These actions will only be executed if the current process user is logged in at the client.

Three action types are currently provided:

Reload: Reloads a dataset (only the main range) in the client if the dataset is open there.
Open: Opens a dataset in a new level, e.g. for a manual rework of a quote creation.
Activity synchronization: The entity has a fixed "Activities" configuration.
The activity defined via the primary key will then be reconciled on client-side using Outlook, provided it requires reconciliation. This reconciliation is needed for the Windows client.
Execute script: Executes a mask script in the client.

The entity name must be selected from the data model for each of the first two action types, as well as a variable that contains the primary key of the dataset.

Action type "Execute script"

A mask type can be saved in the client for the action type Execute script. The script will be executed on the client without user interaction.

For your convenience, detailed documentation about auto completion is provided in the script editor (shortcut UNKNOWN ATTACHMENT+UNKNOWN ATTACHMENT).

Web service

A process can do more than just call up a web service or start via a web service. The incoming mail event now also allows the process to be continued via web services.

The call-up script calls an external web service to e.g. execute an external calculation. The calculation can only be completed after some time, which means that the result will not be available in the web service reply.

Web service call

GROOVY

Map parameters = new HashMap();
parameters.put("parameter", true);
parameters.put("processInstanceID", ProcessUtils.getInstanceID());
IWebServiceResult result = WebServiceUtils.callWebService("EXT_SERVICE", null, parameters, "Aufruf"); // Das Ergebnis liegt hier noch nicht vor

The current instance ID is handed over to the external program via a parameter. The external program can use this instance ID to forward the result to the process via a separate web service call to trigger process continuation.

Theoretically, it is conceivable to call one's own system via the web service and to continue one's own processes via it. However, this approach is not a good process design and may cause runtime errors during execution at the network environment change.

The type Web service and the required input parameters are defined in the incoming message event. The process cannot be continued if one of these parameters is missing in the call. Another option is to return variables for the process in the form of output parameters as part of the web service event.

The web service call for the external program will now have to transfer the process instance ID and the two input parameters needed for our example to the CRM system to allow the process to continue. The call method resumeProcess can be called in parallel to startProcess via the URL http://[HOST]:[PORT]/soap/ProcessWebService?wsdl. The XML schema describes the call structure.

SoapUI call - resumeProcess

XML

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://web.process.cursor.de/" xmlns:var="http://variable.process.common.jevi.cursor.de/">
   <soapenv:Header/>
   <soapenv:Body>
      <web:resumeProcess>
         <var:processWebExecutionParameter>
            <ExecutionId>bfd47211-60dc-11e4-9a27-c86000771447</ExecutionId>
            <Locale>de</Locale>
            <Parameter>
               <item><Name>WebParam1</Name><Value><DoubleValue>100000</DoubleValue></Value></item>
               <item><Name>WebParam2</Name><Value><StringValue>RG12345</StringValue></Value></item>               
            </Parameter>
         </var:processWebExecutionParameter>
      </web:resumeProcess>
   </soapenv:Body>
</soapenv:Envelope>

The process will now continue normally and the subsequent steps are executed with the forwarded parameters.

Web service processing

GROOVY

String WebParam3 = Erstelle Rechnung für " + WebParam2 + " mit Wert : " + WebParam1
ProcessUtils.setVariable("WebParam3", WebParam3)
ScriptUtils.info(WebParam3)
//Ausgabe => Erstelle Rechnung für RG123456 mit Wert : 100000

The call result looks as follows:

Soap result

XML

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <ns3:resumeProcessResponse xmlns:ns3="http://web.process.cursor.de/" xmlns:ns2="http://variable.process.common.jevi.cursor.de/">
         <ns2:processWebResult>
            <InstanceId>bfeeb0f4-60dc-11e4-9a27-c86000771447</InstanceId>
            <Status>ENDED</Status>
            <ResultParameter>
               <item><Name>WebParam2</Name><Value><StringValue><[CDATA[RG12345]]></StringValue></Value></item>
               <item><Name>WebParam3</Name><Value><StringValue><[CDATA[Erstelle Rechnung für RG123456 mit Wert : 100000]]></StringValue></Value></item>
            </ResultParameter>
         </ns2:processWebResult>
      </ns3:resumeProcessResponse>
   </soap:Body>
</soap:Envelope>

Should a call parameter be missing or the execution ID invalid, then the web service caller will receive an SOAP error message.

CODE

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:Server</faultcode><faultstring>
de.cursor.jevi.common.process.ProcessException:
Could not resume 'bfd47211-60dc-11e4-9a27-c86000771447'.
Expects one webservice wait state entity.
      </faultstring></soap:Fault>
   </soap:Body>
</soap:Envelope>