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.