SugarCRM Troubleshooting: SOAP API Login Problems

One of the oddest technical issues that I have run into dates back a couple of years. In short, attempts to login to the SugarCRM SOAP API failed, but only if the connecting client was a .NET application. That is to say, a PHP script attempting to do the same worked flawlessly.

There was an obvious disconnect there, as the SOAP API should fail for all clients, not just .NET clients. The eventual solution left me puzzled, as it too did not seem to make much sense. As a result, a true solution to the problem seemed to evade me.

By chance, a very similar problem recently found its way to my desk. However, this time around, additional conditions within the environment provided other clues not readily obvious the first time I encountered the problem. 

Not unlike the previous scenario, attempting to execute the login() method of the SOAP API via PHP succeed, i.e. it returned a valid session, but doing the same via .NET failed, returning a SOAP error. 

With the new clues in hand, a definitive solution and explanation finally emerged.

As it turns out, the commonality between the two systems is that both were using self signed SSL certificates. Were we to attempt to access said SugarCRM instance via our browser, it would give us a warning similar to the following image:

The image will vary depending on the browser you use, but the message it is trying to communicate to us is the same: the SSL certificate for the site cannot be trusted.

While our browser permits us to continue on by means of a click, .NET does not. Herein is the root cause of the login() problem for the SugarCRM SOAP API.

To solve the problem, one of two solutions must be applied:

1. Replace the self signed certificate with one validated by a Certificate Authority

or

2. Add the self signed certificate to the list of trusted certificates on the system where the .NET code attempting to connect to SugarCRM is being executed.

SugarCRM Troubleshooting: Those Pesky 500 Errors

Many of us have at some point come across the dreaded Internal Server Error 500 message while routinely visiting random web sites. 

For web site visitors, it can be a frustrating experience, especially if the error is occurring on a page one needs to access to obtain important information. For system administrators, this error is even more frustrating as there is no universal solution to the problem.

Given that SugarCRM is also a web based system, it should be no surprise that it is possible to experience similar errors while using it. Before we get into some of the potential sources of this error, let us take a moment to discuss some items you can quickly cross off your list as potential sources:

1. The web browser. When an error 500 is encountered, it will manifest itself in the same manner on all browsers, whether it be Firefox, Chrome, Internet Explorer, etc. This is because it is a server side problem, thus there is no need to test different browsers.

2. The operating system. As described in the previous point, it is a server side problem. As a result, changes in either the browser or operating system at the end user side will not help alleviate the problem.

Now, let us explore some potential causes for this error. 

SugarCRM: Imports Revisited

A few days ago I found myself in a conversation touching on a subject that made me realize there was a need to expand on a related post of mine from some time back.

The topic at hand related to importing data, which, as I discuss in that prior post, avoiding problems requires that some attention be given to the source data. Continuing this discussion, there are additional points worth mentioning about different data types.

More specifically, below are some parameters to keep in mind as you prepare your data for import:

Recipient SugarCRM Field Data Type	Source Data Format
DateTime	2012-10-23 09:30:00
Date	2012-10-23
MultiSelect	^Value^ ^Value1^,^Value2^,^Value3^ Value must match the Item Name entry defined in the associated drop down list, including case.
DropDown	Value must match the Item Name entry defined in the associated drop down list, including case.
Checkbox	1 = Checked, 0 = Unchecked
Radio	1 = Selected, 0 = Unselected

I hope that helps save you some time at import time!

SugarCRM: Lets Go Fishing

Those of you that read my previous article describing the process for dynamically hiding subpanels may have been left wondering something about the instructions. Reading the article we find that the specific bit of code that hides the subpanel reads as follows:

unset($layout_defs['Accounts']['subpanel_setup']['opportunities']);

In the above, the subpanel for Opportunities data on the Accounts module is being suppressed. But how does one come about knowing the name of the array to manipulate? Further to this, where did the value of 'opportunities' come from? What are the rules for the other panels?

Fortunately, the answers to those questions are all found in one file: subpaneldefs.php

This file can be found in <sugar_root>/modules/<module>/metadata. For our referenced example, suppressing the Opportunities subpanel on Accounts records, the corresponding subpaneldefs.php file that contains our answers is located in <sugar_root>/modules/Accounts/metadata.

Said file will contain a listing of all the defined subpanels for the Accounts module, along with various parameters that are used to display them. To manipulate the elements, create a layoutdefs.ext.php file, as with suppressing the subpanel, focusing on the specific elements of the array that you wish to change.

Don't forget to run a Quick Rebuild and Repair to apply any changes you wish to introduce via layoutdefs.ext.php.

VB.NET Code Snippet: Pardot Login

Sometimes it is hard to appreciate the degree to which the development world has changed over the last ten years or so, especially when one is surrounded by it on a daily basis.

Anyway, I was recently reminded of it while working on a project involving Pardot, the popular online marketing service provider. In past years, finding .NET based code snippets -- or examples -- demonstrating the process of interacting with the application programming interface (API) for such a service would have been relatively easy. The development world, however, has long moved past that and .NET is no longer considered the dominant player it once was. As a result, snippets of the type I referenced earlier have tended to become a bit more scarce.

But there are still a number of .NET users like myself out there, and here is a code snippet I wanted to share which I think others might find helpful. This VB.NET snippet demonstrates the manner in which we can login to the Pardot API. 

Dim sResults As String

'Email address used to login to Pardot         
Dim sPardotEmail As String = "my_email@mymail.com"
'Corresponding password for login 
Dim sPardotPwd As String = "my_pardot_password" 
        
'Obtained from user settings page in Pardot -- user specific
Dim sPardotUserKey As String = "pardot user key" 

Dim sURL As String = "https://pi.pardot.com/api/login/version/3"
Dim sMsg As String = "email=" & sPardotEmail & "&password=" & sPardotPwd & "&user_key=" & sPardotUserKey
Dim wrRequest As System.Net.WebRequest = System.Net.WebRequest.Create(sURL)

Dim byteArray As Byte() = Encoding.UTF8.GetBytes(sMsg)

wrRequest.Method = "POST"
wrRequest.ContentType = "application/x-www-form-urlencoded"
wrRequest.ContentLength = byteArray.Length

'Post it to Pardot!
Dim dataStream As System.IO.Stream = wrRequest.GetRequestStream()
dataStream.Write(byteArray, 0, byteArray.Length)
dataStream.Close()

'Get the response from Pardot
Dim wrResponse As System.Net.WebResponse = wrRequest.GetResponse()
dataStream = wrResponse.GetResponseStream()
Dim dataReader As New System.IO.StreamReader(dataStream)

'Response is an XML document containing the Pardot API key
sResults = dataReader.ReadToEnd() 

dataReader.Close()
dataStream.Close()
wrResponse.Close()

Your first step when integrating with Pardot should always be to login, as that process provides the Pardot API key that in turn is used in subsequent API calls.

If you have some useful tips for Pardot API integration and .NET, please share in the comments. Thanks in advance.

SugarCRM Customization: Utilizing Custom JavaScript

SugarCRM, being a web application, naturally prompts some users to ask whether it is possible to apply customizations to the system which in turn mimic behavior they may have seen on a random web site in the course of their general web browsing. A good example would be formatting numbers entered into the phone number fields in SugarCRM, similar to the manner in which many web sites handle that type of data on a contact form.

By default, SugarCRM does not format the value one enters into any of the phone fields. For example, if one enters the value of 310.555.1212 into the Office Phone field on a contact record, it remains as such. But some users would prefer the number to be formatted, such as (310) 555-1212, or other pattern. This need gave rise to the phone formatter module that I released some years ago and made available via SugarForge.org. More importantly, it highlights the manner in which a little JavaScript code embedded within SugarCRM can be used to enrich the user experience. 

A number of other enhancements can be applied by means of custom JavaScript code, but we must first understand the manner in which it should be embedded.

Lets dissect some of the files that make up the phone formatter module to get a clearer understanding of the process one can follow to apply custom JavaScript in an upgrade-safe manner.

If you have not already done so, download the phone formatter module from SugarForge.org. We will not be installing the module, just examining some files. Thus, simply download the most current version of the module and do not concern yourself with the version of SugarCRM you are using. 

Logic Hooks: Odds and Ends

On occasion I run into a logic hook use case that ultimately exposes a limitation of the framework, or generates peculiar challenges during its implementation. Lets review some of these items in hopes they may help you avoid frustration and save you some time.

before_save vs. after_save

It is not uncommon to stumble upon references to either of these terms as one reads about logic hooks. They refer to the timing of the execution of your logic hook code. A before_save hook triggers your code before the record a SugarCRM user is interacting with is physically written to the database, and an after_save hook triggers it after the data has been written to the database. 

While those conditions are easy to understand, the same cannot be said for the technical subtleties each carry. It is important to understand these subtleties because some may require one to change from using before_save instead of after_save or vice-versa. More importantly, being aware of these subtleties helps us reduce the amount of time that would otherwise be wasted on troubleshooting the problems the subtleties bring about.

SugarCRM Video Tutorial: Installing on TMDHosting

One of the more common problems that I notice among would be users of SugarCRM relates to difficulties installing the application. Ironically, some of the confusion surrounding the process is a result of a strength in SugarCRM -- its openness, not necessarily complexity in the process itself.

By openness, I am referring to its ability to be installed on just about every imaginable server environment. To give you a sampling, SugarCRM can be used in conjuction with Windows, Linux, FreeBSD, OS X, Solaris; on dedicated servers, shared hosting accounts, virtual machines (e.g. VMWare, VirtualBox), Virtual Private Servers (VPS), and on and on.

The great thing about this flexibility is that it allows us to make our own infrastructure choices, rather than having them imposed on us. But this is a dual edged sword, as it impossible for the folks at SugarCRM to provide detailed installation instructions for every imaginable server environment.

However, if you happen to be using a shared hosting account from TMDHosting.com, you are in luck. I have prepared a video that will walk you through the process of installing SugarCRM Community Edition on a TMDHosting shared account.

In the tutorial, we will assume SugarCRM is to be installed such that it can be accessed via a URL/address similar to the following: http://your_domain.com/dev/sugarce645. 

You will likely want to change that to something friendlier, such as http://sugarcrm.your_domain.com/ after you complete the install. That change can be made via the Subdomains tool provided on your TMDHosting account, but the video will not walk you through that process.

For more generic installation instructions, visit at http://developer.sugarcrm.com, but do keep in mind that given the number of potential server environments that can be used, it is unrealistic to expect detailed instructions for each one. Regardless, the information provided should be of assistance.

SugarCRM: MS-SQL Performance

SugarCRM and Microsoft SQL Server. It is one of those subjects that seems to be surrounded by a lot of mystery -- and misinformation. 

As I mention in my book, Implementing SugarCRM 5.x, there is nothing inherently wrong with using Microsoft SQL Server (MS-SQL) in conjunction with SugarCRM. There are certainly unique issues to be mindful of, but that is not any different than any other software. 

Because the vast majority of the SugarCRM user community utilizes MySQL, instead of MS-SQL, these unique issues tend to have a mysterious aura about them, leading some to believe they cannot be overcome. I would argue most of that perception is the result of lack of exposure to the platform and to some extent, the rivalry between open and closed source software. In my experience, while solutions to some of the issues can be difficult or tedious to implement, there are fixes for the vast majority of the common problems.

Perhaps one of the trickier issues to address in such environments is the issue of performance, or lack thereof. It is worth noting that performance is a tricky subject regardless of which CRM solution we are discussing, so do not take my comment as a knock on SugarCRM. That being said, there is one specific issue that comes up on a regular basis and has a significant impact on performance.

Before we get into the details of the matter, it is important to note that many SugarCRM installations will never encounter the problem. The reason for this requires us to review some SugarCRM development history. 

SugarCRM 101: Named vs. Concurrent Users

It is not uncommon to engage in conversations related to the manner in which SugarCRM licenses function. The topic usually surfaces while attempting to determine the specific license count one must purchase for a commercial implementation of SugarCRM, such as Professional, Corporate or Enterprise Edition. 

A proper user count ensures one is not paying for too many licenses, nor purchasing too few. But determining the proper user count is sometimes a bit tricky, given the various ways in which licenses function from vendor to vendor, or in the case of SugarCRM from one edition of the application to another.

Fortunately, there is nothing complicated about the subject and is easily explained with some simple real world usage examples, which is what we will be examining in this article.

First off, if you are intending on using SugarCRM Community Edition, there is no need to worry about user licenses. Community Edition can be used in conjunction with as many users as your hardware resources will permit. However, if you are considering a commercial edition of SugarCRM, including Professional, Corporate or Enterprise, you do need to take user licenses into consideration.

SugarCRM: SOAP API Gotcha

Technical issues have a funny way of resurfacing sometimes. For example, a number of months ago I came across a problem relating to the SOAP API and Users module and more recently I come across another oddity involving both elements. This time around, however, it seems the problem is broader in scope, applicable to all modules. 

For those of you that work with the SOAP API on a regular basis, take note that there is an issue with the get_entry_list() method. If you are unfamiliar with this method, it is used to retrieve a list of records from a given module such as a list of all contacts whose last name is "Smith." 

In addition to filtering the data retrieved, the method also permits one to control the number of records retrieved. This is helpful because it allows us to limit the amount of bandwidth and calls used to interact with SugarCRM. 

Going back to our example, we could use it to retrieve 20, 50 or 100+ records with one call, by simply specifying any of those numbers as a parameter to the method. This is also where we can run into trouble. As it turns out, there is an issue with the interpretation of this number. In short, if one attempts to retrieve a greater number of records than what exists in the target module, the method fails and none of the records are returned. 

In most cases, it is unlikely one would run into this problem, but if one is working with a module that typically does not contain a large number of records, the chances increase. The Users module exposed it to me because I was attempting to get a list of all users defined for a given instance. Because it is not a large implementation, retrieving 50 records in one call seemed feasible. But the process continually failed, leading me to the realization that the Users module only had approximately 30 records. 

Once I updated my code to retrieve an equal number of records as what existed in the module, all was fine.

SugarCRM Troubleshooting: Error Deploying Custom Module - Part II

Some months ago I wrote an article discussing a potential solution to an odd problem relating to the deployment of custom modules from within the Module Builder tool. While helpful, there are other situations which may also lead one to the same error.

Recently, the same error appeared on a system when one attempted to deploy a custom module, despite not having any other modules deployed. Attempting to Export the module also failed, with an error indicating that the zlib PHP extensions were not available on the system. This error was critical in resolving the matter at hand.

The zlib extensions are used to compress and decompress zip archive files, i.e. create and open zip archives. As noted in my previous article regarding this topic, the deploy process in Module Builder relies on module packages in order to complete its work. Said packages are zip files. If the system is unable to create the zip archive during the deploy process, as in this case, the deploy process will fail with the error message of:

"An error has occured during deploy process, you package may not have installed correctly."

In summary, if the advice in my prior article does not help resolve your problem, verify that the zlib extensions are installed, as this may also be the source of the problem.

Adding zlib to your PHP installation will vary by system and may require you to recompile. You should consult the PHP documentation for further information on adding/installing zlib support.

SugarCRM Customization: Dynamic Subpanels

Suppose we are working on a SugarCRM instance for an organization that uses the Accounts module to store records representing either customers or suppliers. The distinction is made by selecting the appropriate value on the Account Type field of an Account record. 

Opportunities, or sales, are only relevant to customers, as suppliers would not be purchasing from the organization. Our task is to simplify the DetailView screen as much as possible by removing unnecessary components. 

Eliminating components from the view has the net effect of making it easier for users to quickly locate data they find most valuable, along with simplifying navigation. With this goal in mind, we conclude one helpful customization would be to only display the Opportunities subpanel on records that are of type Customer. 

How do we accomplish this?

It is actually rather simple. To apply this type of customization, we simply need to create a custom PHP file and execute a Quick Repair and Rebuild of our SugarCRM instance.

What does that custom PHP file look like?

SugarCRM Customization: Email Templates with Attachments

Earlier posts on this blog have described the manner in which one can send email messages via SugarCRM, with one example going as far as demonstrating the manner in which one can use an email template in the process.

In the case of the latter, people often times wonder if it is possible to include attachments with the message. It certainly is possible and that is focus of this post. For the purposes of our example, we will assume that we are altering the above referenced example that uses a template.

Enhancing the code to accommodate attachments is actually quite easy. But before we can apply that modification we must attach the file to the template within SugarCRM.

The process for attaching it is no different than it would be for any other email template. Simply edit the email template and then attach the file. Take note of the ID value corresponding to the email template as we will need it within our code. Before we get to that point, let us take a look at what else happened when the email template was saved.

Navigate to the Notes module and notice that the file you attached to the email template has been added as a note. The entry usually has a Subject line that begins with the text "Email Attachment." This tells us two things: one, an attachment is actually a note entry related to an email template, and two, the actual file that represents the attachment is stored in the cache/upload folder. Both of these tidbits will be important to our process.

Let us begin with our modifications.

SugarCRM Troubleshooting: SMTP Problems and TMDHosting

Some months back I posted an article pertaining to SMTP connectivity problems users of Hostgator accounts may experience, resulting from network security measures applied by default to Hostgator shared hosting accounts.

I recently ran into a very similar problem with TMDHosting. Like with Hostgator, the problem manifested itself within SugarCRM through the inability to send email. Examination of the sugarcrm.log file revealed error messages indicating the connection to the SMTP server timed out.

As it turns out, TMDHosting also closes some ports for outgoing traffic on its shared hosting accounts. In this case in particular, the port in question was number 26. Thus, if you wish to use SugarCRM to connect to a server  that is listening on port 26, you should first contact TMDHosting technical support and request that they open up outgoing traffic on that port for your account.

Logic Hooks: Lead History Transfer

Have you noticed what happens to history information associated with a lead when one converts that lead into a contact within SugarCRM? 

If not, give it a try. Enter a lead record named John Doe, add a Note under its History section. Next, convert the lead into a contact. Now, take a look at the History section on the new contact record for John Doe that was created via the conversion process and compare it to the History section on the lead record. You will notice that the Note entry is nowhere to be found on the contact record and instead, remains associated with the lead record.

This separation allows us to see which interactions were completed when the individual was a lead and which were completed after it was converted into a contact. In turn, it helps us identify processes and techniques that led us to converting it. 

All future activity relating to that individual would be recorded against the contact record, not the lead. However, many users find that the distinction between lead and contact history causes too much confusion.

One problem that is created by this separation of data is that looking at the History section of a contact does not give us a full picture of everything that has occurred over time, as it relates to the individual. One must toggle between the contact and lead record in order to gather that insight. 

How can we address this problem?

One school of thought would bring us to the conclusion that one should not use the Leads module at all and simply enter everyone as a contact. This would solve the History problem, but creates others, such as the inability to track lead conversion rates. 

A second approach would be to carry over the History data from the lead over to the contact record during the conversion. Doing so would solve the problem as all the History would appear on the contact record, but a facility for this does not exist in SugarCRM. Fortunately, it can be easily accomplished via a logic hook.

Let us take a look at the logic hook we would use.

SugarCRM Cookbook: Adding Related Records

Lets jump right into this one and begin by looking at a code snippet:

$rel_name = 'contacts';

$record_id = 'some_id_value';

$bean->load_relationship($rel_name);

$bean->$rel_name->add($record_id);

So what does it do?

Assuming we execute the above code within the scope of a before_save logic hook for Opportunities, the above code would add a linked contact to the opportunity being saved. 

While that example may have limited applications, the snippet of code does not. It can be reused within any custom PHP code you are writing for SugarCRM to link records together, all via the SugarCRM framework.

The advantage of this approach is that it is applicable to any module. In addition, and perhaps more importantly, it is upgrade-safe and eliminates the need for us to know about relationship tables, linking fields or any of the finer details that SugarCRM relies upon to establish relationships between records.

In order to see the power of this little snippet, we need to dissect it line-by-line and expand scope of our example.

MySQL Quick Hit: Drop First Word

Here is a quick tidbit you might find helpful.

Recently I ran into a scenario where a number of records in a table named contacts had an undesired word at the beginning of the value in the last_name column. Here is an example:

Table: Contacts

first_name       last_name

Angel            Zyx Magaña

This complicated the searching of records based on last name because one had to use a wildcard or search for the preceding value in the last_name field, along with the desired value, hence the need to adjust the data. 

To adjust the data, it was necessary to execute an UPDATE query against the table in question. However, it was important to take into consideration the fact that there were some records in the table that did not have the offending value preceding the actual last name. The only real way to differentiate between valid and invalid entries was to assume that any record with more than 1 word in the last_name field required adjustment.

Side note: The caveat with this approach is that valid last name values that use 2 words, such as Mac Donald, would also be affected. However, the number of records meeting that criteria was very low and could easily be corrected manually at a later time.

Based on this strategy, our first step would be to figure out the word count on the field. Unfortunately, MySQL does not provide a function to do this, but a reasonable alternative would be to figure out if there if a space exists in the value of the field. A space in the field would equate to a separation between two or more words. For this, MySQL does provide a function, called LOCATE(). 

Given our main concern was to drop the first word in the field, i.e. anything before the first instance of a space, the LOCATE() function serves our purposes rather well. Next, our query had to instruct MySQL to update the last_name column with the value following the space, whether it was 1 or 4 additional words. Finally, we also had to limit it to records where a space actually existed between words. This latter part is accomplished by the WHERE clause in our final SQL query, demonstrated below:

UPDATE contacts SET last_name = TRIM(SUBSTR(last_name, LOCATE(' ', TRIM(last_name))))

WHERE LOCATE(' ', TRIM(last_name)) > 0

In case you are wondering about the use of the TRIM() function, it is to eliminate any preceding and trailing spaces in the value.

SugarCRM 101: Licensing and Vertical Markets

gnu.org

There are some subtle nuances to non-technical aspects of SugarCRM that have very meaningful implications, but are often not well understood. One such nuance relates to licensing.

Conversations relating to the topic usually resemble the following:

What is the per user cost of a SugarCRM license?

Can one resell a customized version of SugarCRM?

Is it possible to provide SugarCRM hosting services?

One of the first important points to bear in mind regarding these types of questions is that the answer can vary depending on the edition of SugarCRM in question. This is especially true for the question of licensing costs, as Community Edition is completely free, while Professional, Corporate, Enterprise and Ultimate all require payment on a per user, per month basis.

More importantly, many of these conversations tend to only revolve around equating open source to FREE (as in costs, not liberty). As discussed, it is true for Community Edition, but not for the other editions of SugarCRM -- although they too are open source. 

It is also equally important to note that open source is a programming philosophy that incorporates both the idea of making software available at no cost, as well as free to be shared. This latter part has significant ramifications on the answers to questions such as those posed earlier in this post and in turn, business models one might be considering that involve SugarCRM.

Perhaps the most overlooked matter of importance is the issue of whether or not one can customize and then resell SugarCRM. Usually this comes up within the context of the idea of creating a vertical version of SugarCRM. 

Not to get too sidetracked, but vertical refers to a version of a product that is highly tailored to fit the needs of a specific industry, such as real estate, healthcare, automobile dealerships, etc. A default SugarCRM install is said to be horizontal, as it is not specifically designed for any given industry, although its flexibility makes it a more than adequate starting point for many vertical solutions.

SugarCRM Cookbook: Adding Leads via SOAP

bvdservices.com

Back in 1996 when I first got my start in the CRM world, I remember how impressed I was by a new feature about to roll out in an upcoming release of our software. It was something called "web import," which allowed web site visitors to enter information on a standard web form and the submitted data would then appear in the CRM system without any further user intervention. It was the early days of leveraging the web as a lead generation tool and this feature was nothing short of magical.

Nowadays, it is not so magical and is a standard feature in many CRM packages. In SugarCRM, it manifests itself as something aptly named Web-To-Lead. Through this feature, one can create a web form to embed in a company web site, with the necessary behind the scenes magic that allows for the data to automatically enter the SugarCRM system as a lead.

The drawback of this automated approach is that the resulting web form usually requires some fine tuning in order to seamlessly incorporate it into a company web site. For example, colors, fonts and other cosmetic aspects will likely need some adjustment. If you are using a Content Management System (CMS) such as Drupal or Joomla!, other challenges are likely to present themselves in the process. 

But all this means is that one might need to use a different approach to get the job done and sure enough, SugarCRM provides another method for entering data, more specifically, an Application Programming Interface (API). Through it, one can communicate with SugarCRM to read or write data, among various other things. 

There are two built-in APIs for SugarCRM, one is SOAP based and the second uses REST. The finer details of each are beyond the scope of this post, but for our purposes, we will focus on SOAP and the point that both allow us to interact with SugarCRM in a much more controlled manner, using a wide range of programming languages common to the web world. 

Leveraging the API gives us greater control than the auto-generated form by allowing us full control over which fields are to be populated. Further to this, it allows us to access any part of SugarCRM, opening up the possibility of performing additional tasks at the time the lead enters the system, such as scheduling a follow up call, attaching a document or numerous other things. Lastly, it is also makes it possible for us to build the form using whichever method is already in place for creating the web site and simply tie it to the API -- it is automatically seamless.

So, how do we go about creating a lead via SOAP? Lets take a look. 

Database Administration Redux

Some time ago I wrote a post describing an unorthodox method of leveraging the SugarCRM framework to perform database administration duties. It sounds odd, but it is quite helpful for scenarios where one has severely limited access to the server hosting the SugarCRM instance.

While the technique works, its potential dangers make it a bit unattractive. One such danger is that syntax errors in the SQL query to be executed can cause the entire SugarCRM instance to become inaccessible. Coupled with limited access to the server, this danger alone is reason enough to be extra careful. Another high risk danger is the possibility of inadvertently executing the corresponding query more than once, as it would execute every time a specific menu option was selected.

These dangers have encouraged me to look for alternative techniques that would yield similar functionality and at the same time, reduce or eliminate the aforementioned dangers. As it turns out, a minor modification to the previous method accomplishes this goal.

One of the features of the Module Loader install packages is the ability to execute SQL queries when a module is installed. This process occurs automatically, assuming certain guidelines are met, such as including a specifically named file within the package.

The advantage of this approach is that the query only gets executed once, at the time that the module is installed, effectively eliminating the danger of accidentally executing the query again. More importantly, syntax errors and the like do not cause the system to become inaccessible. Such problems simply generate an error and install process is deemed unsuccessful. One is then free to correct the errors without further complications.

What do we need to do to take advantage of this approach?

Thank You!

Its been a few days, but Happy New Year! 

As I get back to writing content for this blog in this new year, I want to make sure to thank everyone for their support of it. 

A big thank you to everyone, all the regular and casual visitors alike. A special thanks to John Mertic (@jmertic), SugarCRM Community Manager, for his continued support of my efforts, regularly syndicating my content and allowing me the opportunity to post on the SugarCRM Developer Blog as a guest.

My motivation for this blog has never been monetary gain, as the satisfaction from helping people is sufficient for my needs. And your comments, emails and continued visits are quite rewarding and am appreciative of all of them. 

Thanks to all of you, visits to this blog have nearly quadrupled on a month-to-month basis since last year. 

I think it is safe to assume its content is of help. That makes me happy. 

Thanks and best wishes for the new year!