Drupal 'cron' and CiviCRM tasks

Certain things in CiviCRM need to happen on an automated basis. The most straightforward way of acheiving this is via drupal's fake cron process, which is well documented on the drupal site. Our drupal cron configuration is set to run hourly, and is triggered when the timer exceeds that limit AND a page somewhere on the drupal site is accessed.

To create a Drupal cron task, implement a cron hook function in a Drupal module. This should be called {MODULE_NAME}_cron(). To ensure that CiviCRM is correctly initialised, the method should first run the function

civicrm_initialize();

GENVASC 'mark as available' activity

This has been applied to test, but not production.

The code is located in the genvasc_labels module and uses the CiviCRM API. The process is as follows:

1. Select all the cases with a type of 'Genvasc' that have a status of 'Recruited'.
2. Load the activities for these cases.
3. Disregard any case that does not have an activity of type 'Mark available for cohorting' that is due in the past.
4. For the remain tasks carry out the following processing.
5. Update the case status to 'Available for cohorting'.
6. Add a new activity against the case of type 'Status Changed'. The target contact is the case contact, and the source contact is the 'Cron System' user (see below).
7. Update the 'Mark available for cohorting' activity status to be completed.

This change requires the amended Case API that has been submitted to CiviCRM as a patch. The original version of the civicrm/api/v3/Case.php has been renamed to civicrm/api/v3/Case.php.old.

Note regarding Cron System

By default, the activities and entries created by automated jobs in this way are assigned to whichever user triggered the cron job, in a similar way to the user who accesses an API call in a module being assigned to the results of that API call.

However, for an automated process this isn't what we want, because cron jobs will be assigned to whichever user happens to be logged in at the time the job is triggered. Instead, the LCBRU module creates a CiviCRM contact called 'Cron System' (LCBRU Staff sub-type), and all the functions and activities performed by cron tasks should be explicitly assigned to that specific contact ID. This will require the cron job to look up the Cron System in order to obtain the correct contact ID.

CronHelper

In order to assist with some of the common tasks associated with Drupal cron tasks a new CronHelper class has been created.

Functions

1. Initialise CiviCRM
2. Switch the user used for thr cron job from the anonymous user to the Cron System User for the duration of the processing.
3. Ascertain if the cron processing is due to run.

Usage

The following code shows how the cron Helper should used.

 // Implementation of Drupal cron hook
 function module_cron() {

    $helper = new CronHelper('JobName', variable_get('MODULE_CRON_FREQUENCY', CronHelper::FREQUENCY_WEEKLY));

     if (!$helper->is_due()) {
        return;
     }

    $helper->start();
    
    try {

        // Do stuff here
        
    } catch (Exception $ex) {
        throw $ex;
    } finally {
        $helper->end();
    }
    
 }

Things to note are:

• The job name and frequency parameters for the constructor are optional and are only used if the helper is being used to check if the job is due.
• The variable get for the frequency uses a default value from the constants defined in the CronHelper class.
• The start() method should be called before any processing occurs.
• The end() method should *always* be called after processing. Therefore, in the example all processing is placed in a try block with the end() method called from the matching finally block.

Config Usage