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.
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.
In the following steps, five summary pages need to be implemented in order to have a complete image of a process run definition screen, with the image below illustrates the run definition summary page. The main summary page includes the other four, starting from the first, which is shown in the process runs drill-own. This drill-down also includes another two summary pages for the successful and failed entries accordingly and lastly one summary page for the previous versions, as we can see.
In this case, a UI class have to implement as well, extending the CRMUIProcessRunDefinitionBean. Also, module id and process id, must be defined in the UI as they declared in the module.xml file. To implement the basic functionality, we will need to create the following methods: createButton, loadForm, editButton, saveButton, submitButton, deleteButton and amendButton.
Later on, data entry page must be implemented by giving the ability to the user create, view, modify, delete or apply other operations on a process run record. Below, we can see the detail page of the process run definition and specifically the process runs tab, showing the successful whilst failed runs.
In addition, an XMLUtilBean need to be implemented, in order to save action inputs, criteria and schedule settings in the xml. Also this, messageRunDefinitionXMLUtilBean extends ProcessRunDefinitionXMLUtilBean.
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 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.