Importing contacts
Contents
Resources Used
- http://www.sugarcrm.com/wiki/index.php?title=SOAP_Intro_and_Practical_Examples
- http://freephile.com/crm/index.php?module=Home&action=TrainingPortal
- http://freephile.com/crm/soap.php
- http://www.sugarcrm.com/wiki/index.php?title=SOAP_in_PHP
- http://dietrich.ganx4.com/nusoap/
First I downloaded the source
- I went to the SugarCRM homepage, and clicked the top navbar link to "Sugar Open Source"
- I skipped the "Wizard" and went right to the "Download Page" because I know what I'm doing and also have a pre-existing setup of Linux, Apache MySQL and PHP - so I only want the app
- I downloaded SugarCE-5.0.0e.zip (production release)
- I visited the recommended "Installation" instructions page at http://www.sugarforge.org/content/installation/
- Then I installed it according to the instructions, however I immediately ran into trouble because the instructions did say to chmod 766 all files that needed to be writable by the web_user.
- This command renders the directories non-executable which manifests in include errors because the web user (www-data) can not see into those directories (to find includes).
# find directories in the ./crm path and change the mode on them so that all users can execute (see into) the directory
find ./crm/ -type d |xargs chmod a+x
resolved the include errors
The instructions also fail to mention that the application wants to create a .htaccess file (which doesn't exist in the distribution and would not necessarily be writable to the web user. As a failsafe, the information is printed to the screen in the installer. However it doesn't properly display (lacking newline characters) which would make the content suitable for copy and paste into the file. I found the source which generates the .htaccess content, and used that. An alternative is to simply touch and chmod a .htaccess file prior to running the installer.
Ideas on How to do the import
My self-imposed goal was to capture all of the data provided -- assuming the owner of the data collected it for a reason and that they wouldn't be too happy with a loss of data in a migration to a new application.
Existing Work
My first instinct was to find info about somebody doing this before (e.g. APIs, Documentation, forum questions, Wikis)
I searched the wiki for importing or APIs and quickly found the SOAP Intro and Practical Examples, so I figured I was onto a fast track. However, the soap example worked with a frontend form (which wasn't explained much) leading me to investigate more into what was required by the soap service. When I found the form in "examples", it did not work as an application entry point (because even though it defined ('sugarEntry', true); there was also an IF that pre-empted that definition) because other code was being loaded before the form. I did not immediately see this cause for the example failure, so I put the example form outside the application directory and successfully used the form to insert a single lead This is illustrated at http://www.sugarcrm.com/wiki/index.php?title=Creating_a_lead_capture_form_for_your_website Seeing that the example worked, but did not capture all the details provided in the data exercise, I knew I should look at the existing functionality of modules dealing with Import (dataMaps), the database abstraction layer (SugarBeans and VarDefs) or the database directly to get a clearer picture of what I needed to label everything.
Use the Source Luke
My second instinct was to look at the source. Answers are always found in the source, with the caveat that it can be confusing and/or time-consuming to find those answers.
Looking at the full application import routines and the four-step forms for importing leads, it was obvious that there was a lot of machinery that I didn't need or want to get involved with to simply import records. For instance, I would not want to (re-)write the form and UI handling when I simply needed to insert records into a database. This made me reconsider using the SOAP example to do the job. In essence, it would only need to read the exercise data and create full records for the 50 provided leads.
From looking at the source code of the import routines, I noticed that the modules/Import/config.php file defined various types of data formats, and that the "Salesforce" one matched the needs I had for mapping source data to our application contacts.
# temp.php to show a concise view of the variables defined in the config script
define('sugarEntry', true);
include ('./modules/Import/config.php');
print "Defined variables: <br />\n<pre>"; print_r (get_defined_vars()); print "\n</pre>\n";
# end temp.php
# partial output:
[salesforce_contacts_field_map] => Array
(
[Salutation] => salutation
[Description] => description
[First Name] => first_name
[Last Name] => last_name
[Title] => title
[Department] => department
[Birthdate] => birthdate
[Lead Source] => lead_source
[Assistant] => assistant
[Asst. Phone] => assistant_phone
[Contact ID] => id
[Mailing Street] => primary_address_street
[Mailing Address Line1] => primary_address_street_2
[Mailing Address Line2] => primary_address_street_3
[Mailing Address Line3] => primary_address_street_4
[Mailing City] => primary_address_city
[Mailing State] => primary_address_state
[Mailing Zip/Postal Code] => primary_address_postalcode
[Mailing Country] => primary_address_country
[Other Street] => alt_address_street
[Other Address Line 1] => alt_address_street_2
[Other Address Line 2] => alt_address_street_3
[Other Address Line 3] => alt_address_street_4
[Other City] => alt_address_city
[Other State] => alt_address_state
[Other Zip/Postal Code] => alt_address_postalcode
[Other Country] => alt_address_country
[Phone] => phone_work
[Mobile] => phone_mobile
[Home Phone] => phone_home
[Other Phone] => phone_other
[Fax] => phone_fax
[Email] => email1
[Email Opt Out] => email_opt_out
[Do Not Call] => do_not_call
[Account Name] => account_name
[Account ID] => account_id
)
[salesforce_accounts_field_map] => Array
(
[Account Name] => name
[Annual Revenue] => annual_revenue
[Type] => account_type
[Ticker Symbol] => ticker_symbol
[Rating] => rating
[Industry] => industry
[SIC Code] => sic_code
[Ownership] => ownership
[Employees] => employees
[Description] => description
[Account ID] => id
[Billing Street] => billing_address_street
[Billing Address Line1] => billing_address_street_2
[Billing Address Line2] => billing_address_street_3
[Billing City] => billing_address_city
[Billing State] => billing_address_state
[Billing Zip/Postal Code] => billing_address_postalcode
[Billing Country] => billing_address_country
[Shipping Street] => shipping_address_street
[Shipping Address Line1] => shipping_address_street_2
[Shipping Address Line2] => shipping_address_street_3
[Shipping City] => shipping_address_city
[Shipping State] => shipping_address_state
[Shipping Zip/Postal Code] => shipping_address_postalcode
[Shipping Country] => shipping_address_country
[Phone] => phone_office
[Fax] => phone_fax
[Website] => website
)
Soap examples seem to have changed with the addition of a version number, so you must be careful about what example you use, and generally rely on the source to be the definitive source ;-)
Some Issues discovered
"Import Step 2: Upload Export File" is a confusing title on the second step of the "Import Contacts" wizard. It could read "Import Step 2: Specify Data File to load"
Typographical bug: I saw that the term "custom_delimeted" is used in a self-contained way in
./modules/Import/language/en_us.lang.php ./modules/Import/ImportStep1.html ./modules/Import/ImportStep2.php
This term is used elsewhere spelled correctly, and thus could potentially lead to a bug down the line.
The source is formatted differently, or practically not at all in some cases, due to various editors using different space and tab settings, even across different Operating Systems which leads to different line endings. PHPBeautifier used in a commit hook would solve this in the repo. Coding standards and configuration files like vim modelines would solve this on the developer desktop.