Blog Entries tagged sugarcrm
Feeds: RSS | Atom

Access SugarCRM from Python via SOAP

Published: 2007-01-30 22:35 UTC. Tags: software sugarcrm soap

I spent part of the evening writing the embryo of a python module that will hopefully make it easy to access SugarCRM from Python via SOAP.

Right now, it only contains code for adding, updating, getting and deleting Accounts, but that could easily be extended. A bunch of unit tests too. 
Not very useful unless you're a developer. You need the Zolera Soap Infrastructure to get it to work.

Get the code from SVN:

svn co 

See also:

ZSI vs. SugarCRM, 1-0

Published: 2006-09-13 22:20 UTC. Tags: software sugarcrm soap

Yay! I've started to understand how to use the Zolera Soap Infrastructure to communicate with the SOAP interface of SugarCRM. Todays understatement is hereby delivered: It's not the easiest thing in the world. It doesn't help that most of the methods in the SOAP interface of SugarCRM are documented like this:


Well, they do tell which datatypes the expect as well, but not exactly how they should be filled.

Anyway, today I managed to create a meeting and connect it to the current user. Yay! Here's the code:

#!/usr/bin/env python

from sugarsoap_services import *
import md5

import sys

class LoginError(Exception): pass

def login(username, password):
    loc = sugarsoapLocator()

    portType = loc.getsugarsoapPortType()

    request = loginRequest()
    uauth = request.new_user_auth()
    request.User_auth = uauth

    uauth.User_name = username
    uauth.Password =
    uauth.Version = '1.1'

    response = portType.login(request)

    if -1 == response.Return.Id:
        raise LoginError(response.Return.Error)
    return (portType, response.Return.Id)

def add_meeting(portType, sessionid,
                date_start, time_start, name, duration_hours):

    gui_req = get_user_idRequest()
    gui_req.Session = sessionid
    user_id = portType.get_user_id(gui_req).Return

    print "user_id", user_id

    se_req = set_entryRequest()
    se_req.Session = sessionid
    se_req.Module_name = 'Meetings'

    se_req.Name_value_list = []
    for (n, v) in [('date_start', date_start),
                   ('time_start', time_start),
                   ('name', name),
                   ('duration_hours', duration_hours),
                   ('assigned_user_id', user_id)]:
        nvl = ns0.name_value_Def('name_value')
        nvl._name = n
        nvl._value = v

    se_resp = portType.set_entry(se_req)

    meeting_id = se_resp.Return.Id

    # Now let's associate this meeting with the current user, to make
    # it appear in this user's calendar

    sr_req = set_relationshipRequest()
    sr_req.Session = sessionid
    sr_req.Set_relationship_value = sr_req.new_set_relationship_value()
    sr_req.Set_relationship_value.Module1 = 'Meetings'
    sr_req.Set_relationship_value.Module1_id = meeting_id
    sr_req.Set_relationship_value.Module2 = 'Users'
    sr_req.Set_relationship_value.Module2_id = user_id

    sr_resp = portType.set_relationship(sr_req)

    return sr_resp

if "__main__" == __name__:
    (portType, sessionid) = login('username', 'password')
    response = add_meeting(portType, sessionid, '2006-09-14',
                           '15:00:00', 'Soap Meeting', 1)

Piece of cake, huh? :-)


RSH - an unpleasant guest from the past

Published: 2006-03-04 13:25 UTC. Tags: software sugarcrm

Yesterday I spent some time evaluating the Open Source version of SugarCRM, since the salespeople at work wants to see if a CRM can help them.

I installed an extension called ZuckerMail to allow reading of mail stored on our IMAP server, and was irritated by the long time it took to get the list of mail, or to read a single mail.

I did some strace:ing, but that didn't help very much - it only revealed the fact that something was waiting for 10 seconds. A process listing however revealed that there was several rsh procesess trying to contact the IMAP server. Also, my firewall's log had blocked several connection attempts from this machine to the IMAP server on port 22 (ssh).

Aha.. but why!

It turns out that the IMAP library for PHP is built on top of the ancient c-client library from the UW IMAP. If you're trying to make an connection without explicitly telling it that you want to connect with ssl (something the GUI for configuring the connection did not have an option for - only STARTTLS, which is another thing), the c-client library tries to run rimapd on the host via rsh. There is a /usr/bin/rsh on the machine, linked to /usr/bin/ssh via /etc/alternatives (Debian sarge).

You can turn this behaviour off in a configuration file for c-client. I solved the problem a bit more drastically - by removing /usr/bin/rsh. This made all IMAP operations go much faster.