Every decade or so, there is a dramatic shift in how people use computers. We’ve seen mainframes cede to personal computers which enable web applications which, in turn, have given rise to RIAs and mobile apps. We are on the cusp of the next revolution.

With all the buzz around cloud computing it is difficult to get at what really matters. Will the Software – with all the bugs and deployment/management headaches – disappear? Will everyone shelve the notion of “deployment“ as an outdated concept from the 20th century? On the contrary, the rush to the Cloud is a dramatic validation that Software is more alive than ever; what has changed is the way we deploy it.

In the last decade we had two options: either deployment was easy but all systems were locked with no customer access (SaaS) or deployment was difficult but the systems were accessible to the customer (local systems).

At Sugar we believe that the decision about deployment- or the lack of thereof- belongs to the customer. We’ve always felt that our customers know how to run their business, and it is part of our job to accommodate. Here at Sugar, we recognize that every customer is unique with unique requirements. We are here to help our customers reach their goals, not to tell them how to run their business.

Cloud technologies are exactly what the doctor ordered to empower our customers. Suddenly the availability of low-cost computing resources has flipped the customer’s deployment decision on its head. An application that is written for the Cloud is truly capable of running anywhere- sometimes even across multiple clouds. Such applications offer the customer an option involving minimal deployment with full access to the customer’s data as if it were deployed locally. These applications are using the Cloud as their operating system. Distributed file systems, memory management, resource rebalancing, asynchronous notification mechanisms can be easily implemented and/or consumed using cloud APIs.

Next week I’ll dig in to the different cloud offerings and how to best utilize them in your applications.

Digg recently dug into why users are using IE6. Their results are quite interesting.

Of course, this only represents users thar are going to digg with IE6, but their results do tell us “IT departments prevent users from using a modern browser.”  Why are IT departments doing this?  Laziness?

Consider this:

IE6 just had two new vulnerabilities confirmed by MS in the last six weeks… even after 8 years of development.

YouTube announced it is dropping IE6 support … will the market dictate the end of life for IE6?

Sugar is NOT going to drop IE6 support in 5.5, but we’re going to introduce an IE6 only theme.  So grab your chaise lounge, sit back, and tell us how you feel.

I’ve been thinking a lot lately on how you (the developer community) and SugarCRM can work closer together.  We’ve come up with a few ideas that we’re working on here at Sugar.

For starters, I want to revamp SugarForge.  There are some features that I want and they do not currently exist.  My inspiration has come from sites I have been using lately – GitHub, BitBucket, and LaunchPad. I have also been playing with Trac a lot.  What all of these have in common is excellent source control and wikis. I also particularly like the project management & issue tracking available from Trac.

I don’t think its possible (or even wise) to replace SugarForge with any of the above mentioned developer collaboration services.  However, I do think we have some options.  These are the few that I have identified:

• Redmine
• gForge
• Trac (does not do multiple projects)

Is there any software collaboration suites that you think would be perfect for SugarForge 2.0?  Right now I’m leaning towards gForge because it’s PHP and SugarForge is already gForge based.  It looks like they’ve done some major updates since we initially started SugarForge.

If you have any other ideas that will help SugarCRM collaborate with you better PLEASE let me know. You can often find me hanging out in the IRC #sugarcrm channel (nick: roder).  That’s irc.freenode.net in channel #sugarcrm.

No doubt one of the biggest takeaways from SugarCon is how the focus we’ve placed on the Sugar platform over the last several 5.x releases has resulted in a highly flexible platform that is very easy for developers to extend in many different ways.  Throughout the SugarCon case studies, product feature demonstrations and technical “how-to” discussions, the message was that our developer community, partners and customers are all taking advantage of Sugar’s platform to build new plug-ins and extensions, to add new features and to customize Sugar to fit their business processes and goals.

I attended the SugarCON session on “Five Game-Changing Extensions”, presented by SugarCRM’s Reem Bazzari, and witnessed several eye-catching and popular extensions in action.  Among these are the following extensions are currently available on SugarExchange and SugarForge.

Contact Capture is a nifty tool for very easily capturing and importing lead and contact information from any file into Sugar.  Klipfolio for SugarCRM provides quick and convenient access to relevant information within Sugar within dashboards on the desktop.  SalesView by InsideView is business search application that brings insight gained from subscription-based and user-generated sources, such as Hoover’s, D&B, Reuters, Zoominfo, Jigsaw and LinkedIn, into an easy-to-use panel directly within the DetailView of Sugar records. Mobile Edge for SugarCRM allows sales representatives to access and update pipelines and contacts anytime and anywhere within seconds right on their Blackberry smartphones.

I also attended the session on “Five Extensions Yet to be Built That Users Would Love”, presented by Clint Oram, SugarCRM Co-Founder and VP of Product Management.  During his talk, Clint brought to attention the following categories that come up time and time again for highly-anticipated features and extensions that promise to have an impact on user productivity and adoption of Sugar.

1) Web Content Management

Integrations with:

* Blog software: Wordpress
* Forums software: vBulletin
* Wiki software: MediaWiki

2) Finance Systems

Integrations with:

* Magento
* Mas 90
* SQL-Ledger

3) Telephony

4) Productivity Tools

Enhancements to:

* Sugar Calendar
* Sugar Feeds

Integrations with:

* Apple Mail and iCal
* Entourage

Address book and alerts

5) Connectors to Web Meeting applications

Got what it takes to build these extensions?  Or got any other great ideas?  Share them with us.

With the upcoming Web Services improvements, new Themes framework and other platform enhancements that will be included in Sugar 5.5, there’s no excuse to not get out there and start building!

A key feature in the up-coming 5.2 release for Sugar Professional and Sugar Enterprise will enable Sugar administrators to delegate more granular module control to end users. In previous versions, users needed to be marked as an “Administrator” to gain access to the Administration area of the application.  This exposed ALL administration functionality to that user.

In 5.2, users can be marked as being administrators for particular modules giving them access to only relevant administration functionality.  This can be done by giving users a role with its “Access Type” set to “Developer” or “Admin & Developer“.  Both settings will ensure that users with that role will have access to Administration areas for that module.  The “Admin & Developer” setting additionally grants the user visibility into all the records for that module (by-passing any team security that may be in place).

What exactly does a MA see?

• Upon login, a module administrator will see an “Admin” link at the top of the application (previously only available to System Administrators).  This will give them access to the Administration area of the application.
• MAs of all studio-enabled modules will have access to Studio in the Administration area.  In Studio, MAs will be able to modify only those modules for which they are either “Developer” or “Admin & Developer”.
• Workflow tools will be exposed and MAs can define workflows for the pertinent modules.
• Any other module specific tools in the Administration area will be exposed (e.g. A “Developer” for the Products module will see the Products related tools, etc.).

Enabling MA functionality for your custom modules
Custom modules can take advantage of this feature quite easily.  Any new Administration tools should be added to the following file:

custom/modules/Administration/Ext/Administration/administration.ext.php

in the following format:

<?php
$admin_option_defs=array();
$admin_option_defs['Administration']['MyModulesLink']=
array($imagePathForLink,$labelForLink,$descriptiveLabelForLink,$URLforLink);
$admin_group_header[]= array($labelForTheNewGroup,'',false,$admin_option_defs, $descriptiveLabel);
?>

In this example, the link will ONLY be available to System Administrators. To enable access for MAs, you’d specify the module name as follows:

$myModuleName = $customPkgName.'_'.$moduleName;
$admin_option_defs[$myModuleName]['MyModulesLink']=...

OOB examples of this construct are located at

/modules/Administration/index.php

API Change Affecting all Editions

While this new feature is available only in Sugar Professional and Sugar Enterprise, the code for defining sections in the Admin screen has changed in 5.2 for all editions of Sugar including the Community Edition.  The $admin_option_defs[] array is now a two-dimensional array as described above where in previous releases it was a one-dimensional array.  The two-dimensional array now defines both the module section and the entry key for a given Admin screen entry instead of just the entry key.

Developers who built customizations around the Admin screen will need to modify their code appropriately.

While PHP accelerators deliver better server-side performance and scalability, we can also do other things to speed up the end-user experience. HTTP compression is a common technique for improving performance across the network between the server and the client.  Sugar Labs measured the client-side performance of the SugarCRM application both with and without HTTP compression using Yahoo’s slick YSlow plug-in for Firebug on the FireFox browser. We sampled the SugarCRM application under a couple of different scenarios.

What are the benefits of HTTP Compression?

HTTP compression will compress data that is sent between the server and a user’s browser. In most cases it takes just a few lines to enable it on a Web server, and you can compress HTML, JavaScript and CSS. On average you will see the amount of data transferred between a Web server and a user’s browser decrease in size between 3x to 10x.

Depending on the latency between the server and browser, HTTP compression can have a dramatic effect on the performance of round trips.  The greater the latency, the better the impact.  That means implementing HTTP compression across a LAN connection normally doesn’t help and can often negatively impact performance as the time to compress/un-compress on a LAN outweighs the value of fewer network packets.  HTTP compression works best when there are many network hops between the server and the browser such as when your users connect to their Sugar application over a broadband connection.

A common compression utility used by Web servers and browsers is Gzip.  All browsers that Sugar supports also support accepting data that has been compressed using Gzip.  The Sugar Wiki details how to configure Gzip compression for Apache for the best results with SugarCRM.

Here is a brief sampling of the data collected:

This chart shows the amount of data being transferred the very first time a user views a page with an empty browser cache. Each page was tested independently and the browser cache was cleared between page views. This is a worst case scenario. In a real world scenario, many pages would share common JavaScript and CSS libraries that would be cached between round trips. It does however show the amount of savings per page view once you turn on compression.

Overall the average data size without cache headers and without compression came out to 925 Kb from 58 HTTP requests per page. The 58 requests included loading the page’s HTML and the referenced CSS, JavaScript and images. With compression enabled, the average page size reduces to 270 Kb.  Once the CSS, images, and JavaScript are cached in the browser, the majority of data being passed around is just the actual HTML. The following chart reflects the benefits of compression on the HTML payload.

After the initial page hit for each action, the average page size reduced to 101 Kb per page without compression.  Once you enable compression, that number is reduced to 14 Kb per page, but it still makes 58 HTTP requests to the server. Even though the files are cached by the browser, the browser still makes a call to the server asking if the file has changed. That is why the number of requests per page is still the same. The server will only send back data that has changed, but there is still the overhead of making all those HTTP requests.

If you enable cache headers in your web server, the number of HTTP requests made reduces significantly.  On average, the browser will only make 1 request per page view with cache headers enabled.  You can set the cache for as long as you would like. I would recommend about a week. Note that if your users are connecting over HTTPS, the browser will only cache an object for a given session. As soon as a user logs out, the browser cache will clear by default.  Firefox does allow you to change this browser behavior for HTTPS connections by setting the browser.cache.disk_cache_ssl value to true by typing in “about:config” into your Firefox browser and navigating to this setting.

If you want to calculate the overall amount of data being transferred from the server to the client, the formula would be as follows:

for a single user who views z pages of which k are distinct actions

No Compression:

Total Data Transferred = 925 * k + n * (z – k ) * 101

With Compression :

Total Data Transferred =  270 * k + n * (z -k) * 14

So for 1 user viewing 40 pages of which five pages are distinct actions

No Compression:   925 * 5 + 100 * (40 – 5) * 101 = 8,160 Kb per user

With Compression:  270 * 5+ 100 * (40 – 5) * 14 = 1,840 Kb per user

Now assuming that each user views a new page every 30 seconds (i.e. a 30 second “think” time) we can calculate the bandwidth needed

40 page views * 30 seconds/page view = 1,200 seconds

bandwidth = Total Data Transferred/ Seconds

8,160 K/1200 s = 6.80 Kbps without compression per user

1,840 K/1200 s = 1.53 Kbps with compression per user

Now to get the bandwidth for n users, we simply multiply by n

so for 100 users it would be

6.8Kbps * 100  = 680 Kbps without compression for 100 users

1.53Kbps * 100 = 153 Kbps with compression for 100 users

Doesn’t the browser automatically cache files without cache headers?

The browser will try to cache files, but it will still send a request to the server for each file that it loads from cache that does not have a cache header associated to it.  This is to check if the browser should update the file or not. So there is still a slight request load on the server for each file.  Cache headers prevent this. So while you will see the browser caching, it is still beneficial to send cache headers down with XML, JavaScript, images, CSS, TXT, and SWF files.

Does compression work with everything?

For the most part compression works well, but I would recommend not using it for SOAP since there are several SOAP clients out there that do not handle Gzip compressed data very well. Also you may want to disable it for downloads since often times you will be downloading data that has already been compressed which won’t see any benefit from being Gziped again.  Also note the discussion above on the value of HTTP compression when the server and the browser are on the same LAN.

This article demonstrates adding an asynchronous call from the cases edit view to simulate returning an SLA computed date.  Everything here is shown except creating the actual logic to determine the date a case should be closed by.   There are several steps that must be completed.

•    Create a custom field to hold the date
•    Create a whole bunch of Javascript to make an Asynch call and handle the result.
•    Create the logic to determine SLA date

This document has step by step instructions.

One of the things I’ve seen popping up on the Sugar forums lately is people looking for suggestions on hiding the left shortcut menu on their views. We do this in a number of places in the application, such as in Studio, Module Builder, in the AJAX Email client, and in step 3 of the Import module.

The most common approach I’ve seen discussed is to remove the contents of the side QuickCreate definitions. This will only remove the content of the menu, but doesn’t hide the actual menu from the view. The easier method is to hide the menu via JavaScript; doing this will allow you to simply default the menu to being hidden ( like we do the the aforementioned modules ) or you can completely remove it from the screen.

To have the menu start off hidden ( and preserve the users preference for having the menu visible or hidden ) add the following JavaScript code to display in the view.

<script type="text/javascript">

<!--

// hide the shortcut menu

if (!Get_Cookie('showLeftCol')) {

Set_Cookie('showLeftCol','true',30,'/','','');

}
var show = Get_Cookie('showLeftCol');

if ( document.getElementById('leftCol').style.display != 'none' ) {

hideLeftCol("leftCol");

closeMenus();

}
Set_Cookie('showLeftCol',show,30,'/','','');

-->

</script>

To not display the menu at all, add the following JavaScript code to the view instead:

<script type="text/javascript">

<!--

document.getElementById('leftCol').style.display = 'none';

document.getElementById('HideHandle').style.display = 'none';

-->

</script>

You can add this to output in the display() method of the view.  To learn how to override views, check out the Sugar Developer Guide.  Be sure to put your new view in the custom/ directory.

We have been running load test after load test in the Sugar Labs to determine the performance of Sugar 5.1 and where to focus on improving performance in the future.  You will see performance benefits in 5.1 with the new logger utility, SugarLogger, that greatly reduces the CPU load and the revamped internal handling of custom fields that both reduces the amount of code as well as database queries. We already have a list of improvements we’ll be making to 5.2 and 6.0 as well.

We just finished analyzing one of our load tests that we felt the community would find interesting. This test was geared towards showing the benefits of operation code (op-code) caching as well as external data caching with SugarCRM. We ran a load test geared towards the sales automation functionality with a PHP accelerator, and then we ran it again the with the accelerator disabled.

The database was run on a separate server to ensure that it had no impact on the Web server CPU utilization.

What is Operation Code Caching?

When a user requests a PHP page, most PHP Accelerators will compile the PHP code for the requested page into bytecode. It will then save that bytecode in a cache either on the file system or in shared memory that allows the PHP Accelerator to skip the compile step the next time that PHP page is requested. This greatly reduces CPU utilization since a PHP script no longer needs to be compiled on every round trip.

What is External Data Cache?

An External Data Cache is either shared memory or file based storage that many PHP accelerators have that allow for storing data across round trips and sharing data between multiple users. SugarCRM has an API that takes advantage of these and can currently support APC, Zend Platform, and Memcache. This reduces file I/O as well as round trips to the database.

The Results:

We saw that with caching enabled, our test server completed more requests per second and the requests completed faster. Once we disabled caching we saw the average server response time shift from sub .5 second response times to around .75 second response times. You will also note in the graph below how much longer the tail of the chart is without cache. This indicates that there was a noticeable increase in the number of responses that took greater than 1 second response time without the cache enabled.

The biggest factor is the improvement in CPU utilization when you utilize a PHP accelerator. We saw a drop in CPU utilization from around 75% down to around 40% when utilizing both the op-code caching and the external data cache.

Conclusion:

If you are not running SugarCRM with a PHP accelerator, you really should be. You will see dramatic improvements in performance as well as scalability leading to better user productivity and reduced hardware needs. You can check out our wiki page on PHP Accelerators for more information.

How would you like your sugar served? In grains, cubes, in a bowl or in a packet? Yes, this may be a cheesy play on the SugarCRM name but it is the perfect metaphor for the deployment options you have with SugarCRM.

Many of the CRM vendors today have one or maybe two deployment options. With SugarCRM, you can deploy in any of the multiple ways you will see outlined in this article.

First let’s recap on just a few places and platforms that we have seen SugarCRM installed. We have seen it on the Bitnami LAMP/WAMP stack, in the cloud with Amazon EC2, hosted by SugarCRM Inc with Sugar On-Demand, or installed on your local Window, Mac OSX or Linux server.  Of course all of these different server installation options can be accessed with your web browser, mobile device or using the Sugar offline client.

To add to this list, we now have the SugarStick.  I initially created the SugarStick a year ago to show the flexibility of SugarCRM at the first SugarCRM Atlanta Meetup. The SugarStick is a completely self-contained Apache, PHP, MySQL, SugarCRM installation running from a USB drive or “stick”.  No, it’s not a VM image.  No, it doesn’t install the stack software onto your machine.  Read on…

A few issues arise when you start thinking about running a CRM application from a USB stick. The first is how to run Apache, MySQL, and PHP on a USB stick without having anything get installed to the host system. To overcome this, I found CH Software’s MoWeS Portable package.  It is a lightweight and easy-to-configure software package that runs Apache, PHP and MySQL without installing those software packages on your machine.

The next problem is, what if the host system is already running a Web server or DB server? This can be corrected by changing the default ports that the server runs on. In my How to make a SugarStick tutorial you will see a step-by-step guide on how to get this up and running.

To make it even easier, the people at CH Software have added SugarCRM to their package list on their download site. This means that when you download MoWeS portable, you can simply choose to include SugarCRM and it will come preinstalled.

Now that you know what the SugarStick is, you may be wondering what the uses for this would be. The benefit of this would be that it can be used on any Windows system and will not clutter your host with extra services that you might not need all of the time. The best use that I have been able to come up with is for entrepreneurs that are very mobile. The SugarStick enables them to use SugarCRM anywhere, with or without an Internet connection. It also enables them to work from different systems, if needed, by simply plugging in the USB stick to any system they are working on. The last use is as a promotional item. USB sticks are cheap, so brand them, install SugarCRM and give them away for people to play with and use.

To further discuss the SugarStick you can visit the tutorial post in the Sugar Forums: How to make a SugarStick