This document describes how a process run definition is working. In general, processing runs are used to keep logs of a process run request execution. Processing Run Definition can be applied once or on a recurring basis, based on the scheduling settings as defined on the definition. All the runs that were performed based on each definition can be viewed within the definition. The following example construct a process run mechanism that sends messages using threats.
In order to implement a process run definition, the first thing to do create a new module in metadata. This new module has a module id and a new feature with its own process id and a method that will be explained later. The next step is to create a Java class smsMessageRunDefintion which extends viewObject class. It is includes a processRunDefinition and a schedulerTask objects which are necessary for a process run definition. Then, some action inputs should be defined to specify certain fields that describe a process run (broadcastPeriod, broadcastInterval etc.) whilst some criteria if are available.
...
On the last step, the CRMProcessRunBean mentioned in the module.xml as additional process need to be implemented whilst the method executeMessageProcess which executes the process runs via threats mechanism like in Implement a multithreaded processMultithreaded Process section. Firstly, process run method saves the action inputs. Then each process run request processed from a thread and if procedure works correctly, the next process run prepares to been processed and the current one saved as completed. On the other hand, if something goes wrong, the current process run is saved as failed and moves to process the next request. This procedure continues until all the process run requests pass from the multi-threading mechanism. As a result, all the successful and failed process runs are illustrated in the summary page image above.
...