Sugar Integration Best Practices

[alec.maki]

We're evaluating whether to invest in Sugar or not. We have .NET applications that would require communicating with Sugar. We want to make the right decision. Sugar, obviously, has web-services. But, from our standpoint, these services are limited. Issues we've come across with the Soap API, to this point:

• The services are quite granular and basically provide access to the backing database
• There is essentially no documentation except for a couple of tutorials, the WSDL file, and documentation with the source files (all written in PHP). This has made it difficult to get started. We asked for an overview document and Sugar responded with a block diagram of the system (which makes little sense), a tutorial and basically the WSDL data. Not much help. The good news is that the Sugar community has responded well to questions we posted on this forum.
• An intimate knowledge of the database is required to understand the semantics of the services and their use. Instead of working against objects, we are required to work against the database--across a web-service. This is far from a best practice.
• The services provide no object model. The service calls return no typed information, but rather just strings and arrays of strings. Thus, to effectively use these services, we must translate these strings into useful objects and properties.

Given these issues, it is apparent that integrating Sugar with existing (or new) enterprise applications is a fairly heavy lift. For example, it appears that, if we go with Sugar, we'll have to develop wrapper/service classes to translate the string information returned from the services into a usable object model. Of course, this will hold true for almost any company seeking to integrate with Sugar, regardless of their particular software platform.

So the question we have is this: are there Sugar integration best practices? Are these published? All we've seen to this point are limited examples that merely scratch the surface.

Another question: are there open source (or commercial) "wrappers" to the SOAP API? For .NET, Java, and other platforms? If there were such wrappers available (that wrapped most of the details of database knowledge and string-to-object translation), it would make the decision to move to Sugar much more palatable. Companies such as ours would gladly make the transition. As it stands, we love the core product--but these integration issues are making an otherwise easy decision very difficult.

Another question (more of a demand): better documentation, with real-world concrete examples, needs to be provided on usage of the Soap API. Best practices must be defined and shared.

[alec.maki]

No replies?

I thought this would have, at the very least, invited a discussion on how SugarCRM could move forward with its web-services. The experiences of my company provide a great case study for clients with integration needs. But this requires dialogue. So far, we're getting very little. This is discouraging. It seems to me that SugarCRM would want to make its web-services as accessible and integration-friendly as possible--to meet the needs of a diverse customer base. If this is a false assumption, let us know. If SugarCRM is focused solely on meeting the needs of the PHP community (with respect to integration), with little regard to other development platforms, we need to understand this. This is vital information for my company's decision-making process (and, I"m sure, to many others too).

To me, it seems, this represents a potentially large business opportunity for SugarCRM--whether or not to include non-PHP customers with integration requirements. Based on the limited engagement we've seen to this point, it appears that SugarCRM is excluding this potential market segment. This is the growing perception.

Is this true? If not, please engage in a dialogue. We want to understand best practices for integrating non-PHP applications with SugarCRM. This is important. If there are no best practices, then that, too, must be understood. Let us know that. Then let us know whether or not you intend to develop best practices. If so, perhaps we (and others) can help. If not, then my company will probably not invest in this otherwise great product.

[susiewilliams]

Hi there and thank you for your posts.

I'm assuming you have found the API documentation that's posted in our wiki. You can find a variety of information there by searching on the keyword "SOAP" in the Developer wiki. There are also tutorials and code samples, and articles on how to use the API with Ruby and CSharp and LDAP, among others. We are working to extend our APIs to handle a larger varitey of scenarios; look for these extensions to happen sometime on or after the 5.0 release.

As for an in-depth discussion on the direction we are headed with respect to our web services and integration capabilities, I'll defer that to our CTO to address. We're right in the middle of a release push, working to get the 5.0 Release Candidate out the door by the end of the week, so I hope you understand that we're a bit focused on our own development now. When we get this release out the door, there will be more opportunity for discussion on this topic. Keep a watch out for Sugar Developer User Group (SDUG) webinar events, where you can ask questions of the development team members and the CTO in an informal setting. Our Global Developer conference (coming up next February) is also an excellent place to talk with our management team regarding strategic directions of our products.

[alec.maki]

Susie,

That would be great. We'd love to have an in-depth discussion with your CTO about these issues, and explore SugarCRM's plans for integration and web-services. Please let us know how to begin this dialogue. Thanks.

[Lampkin]

I'm in a similar situation. What I've done so far is generate a set of classes based on the database structure. I've used reflection to then populate my objects based on what's returned by the sugar web service and vice versa. This works for basic things like adding emails, simple relationships and contacts based on already existing structure. I used code smith to generate my data objects. It didn't take long to setup and worked well with the wrapper class example.

I'm starting to customize Sugar now, I'm hoping it will carry on as smoothly...fingers crossed.

I did have a play with Sugar 5.0 but found the web service to be unreliable. For example getting contacts by email address does not work (at least I couldn't get it working). The database has now been normalized a bit which is good but as above states, the web service is made in such a way that we work against the database. Working with the new database structure and what appears to be a currently limited web service proved extremely difficult.

See post: http://www.sugarcrm.com/forums/showt...2554#post92554

I'm thinking that maybe the functionality is there but I'm not understanding it, I hope this is the case for futures sake and also hope that more documentation will start appearing. The examples provided only cover basic scenarios. If you look in my post it explains where I struggled.

I have moved back to version 4.5.1, due to it's almost flat file structure it's easy to work with.

[dtokeefe]

Hi Alec and Lampkin,

There are many ways to integrate SugarCRM with other apps. The SOAP API (get_entry, set_entry, etc.) is handy (few functions to access all modules) but limited as you point out. You might also discover that working with get_entry_list and set_entry_list can suffer from performance problems, when many records are involved.

On the other hand, have you looked at the functions in the various files in the folder soap? There are methods that return the field structure of beans, so your app can figure out in run time how to work with the get_entry and set_entry functions.

In some of our integration projects, we have also written custom web methods to extend the SOAP API. This is a relatively simple and involves changes to soap/SoapPortalUsers.php.

In other integrations, we have used tools like Jitterbit and Talend to de-couple Sugar from the other app(s).

I hope this helps.

Best regards,

David

[Lampkin]

Thanks for the reply, do you mean SoapSugarUsers.php though? Well, I placed a simple test function in there, which appeared to work.

If i can write my own soap calls, I may be able to move back to Sugar 5 as I'm finding out they are wanting a lot of customization that looks suited to custom modules rather than trying to hack apart the existing ones. (it doesn't appear as simple a task to add custom modules in sugar 4.5.1)