Friday, August 28, 2009

SugarCRM Scheduler Explained

The SugarCRM scheduler functionality seems to be a source of confusion for some users. Hopefully this article will help add some clarity to its intended use and mechanics. To begin with, lets examine how the process works as a whole. First, a schedule or time table is defined by an admin level user via the Admin Control Panel. Each entry within the schedule includes not only the parameters for when things should run, but also which task should be performed. Some of the possible tasks are:
  • Prune database
  • Send campaign e-mails
  • Check inbound e-mail
However, in order for any of the tasks to occur, one must process the schedule. The processing is performed outside of Sugar and can be invoked on an ad-hoc basis or periodically via an external tool such as cron (Linux) or scheduler (Windows).

Instructions on which command to use to process the schedule are normally found in the scheduler page. Below is an example:

cd C:\xampp\xampp\htdocs\sugarce52 php.exe -f cron.php

Thus, it is necessary to do at least two things in order to get the scheduler to work. So far, so good.

Confusion usually starts to creep in when one realizes that cron and Windows scheduler also have a time table. The time table for both of those indicate the frequency in which the defined task is performed.

For example, one could configure Windows scheduler or cron to execute the command required by SugarCRM every hour, every day of the week.

NOTE: The rate at which the command is executed via cron or Windows scheduler is only indirectly associated with the time table defined by the admin user within SugarCRM.

Below is an example that illustrates the point:

SugarCRM scheduler is configured to send e-mail campaign messages at midnight, every day of the week.

cron is then configured to run the required execution command at 10 PM, every day of the week.
Despite cron executing its part correctly, Sugar will not perform any actions.

The reason: when cron runs the execution command at 10 PM, the process will examine the time table defined in SugarCRM in order to determine whether or not something should happen.  

Because the Sugar defined schedule is configured to perform its task at 12:00 AM, the process ignores it, since it is not midnight at the time it is examined.
To address this situation, one must either adjust the time at which Sugar is scheduled to perform its task. Alternatively, one can choose to reconfigure the cron schedule to run every hour, at midnight or a few minutes thereafter.

The key to understanding this functionality is comprehending that SugarCRM merely creates the time table, but doesn't actually do anything at the specified times. Utilities such as cron or Windows scheduler are responsible for the latter.

Friday, August 21, 2009

SugarCRM Upgrade Problems

Sometimes technical issues seem to come in waves. This past week, the Sugar Forums highlighted that point quite well. Multiple users reported unusual behavior when attempting to perform upgrades to varying versions of SugarCRM.
Some of the challenges that were reported included:
  • Errors such as: Warning: Invalid argument supplied for foreach() in /home/xxxxx/public_html/xxxx/data/SugarBean.php on line 2322
  • Inability to click Browse button to select upgrade files or Browse button missing
  • Errors when clicking Upgrade Wizard link that prevent upgrade wizard from displaying altogether
The common thread between all of these issues is that SugarCRM in part relies on files stored in the /cache/upload directory in order for the feature to work correctly. Temporarily renaming the /cache folder prior to attempting to access the Upgrade Wizard feature appears to correct the problem.
It is strongly advised that one NOT delete the existing /cache directory as an alternate solution. The danger in doing so is that the /cache/upload directory is used to store e-mail attachments, documents and other files related to Sugar. Deleting that directory would in turn cause those files to be lost. DO NOT DELETE the directory.
Once you have successfully upgraded -- assuming the rename trick solves the problem -- the current /cache/upload directory contents will need to be merged with the contents of the /upload directory that resides in the renamed /cache directory.