| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 | ||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 TEST CENTER Setting sale for the future By Jon Udell February 11, 2002 SALESFORCE.COM'S Web-based CRM solution hit the sweet spot for a lot of customers who needed to manage sales opportunities now for relatively little cost and implementation hassle and who needed it running sooner rather than later.
These features all flow from an architecture that has been in place for some time, and which nicely positions the product to move into a world of interoperable Web services. The product's engine is Oracle 8.1.7, and its business logic is written in PL/SQL. This engine implements a security model which, in the Enterprise Edition, is extended to include role-based permissions and detailed audit logging. Wrapped around the engine is a layer of Java, which exports two kinds of interfaces. One is the HTML application that browsers will still consume directly. The other is an XML-RPC (Remote Procedure Call) API Salesforce.com built last March to support the synchronization client that relays contact information back and forth between Salesforce.com and customers' Outlook inboxes and PDAs. The XML-RPC API is also intended as glue for connecting a Salesforce.com CRM implementation to other systems, such as a customer's HR system. And, in the Enterprise Edition, the API defines the XML data model that supports the offline feature. Ubiquitous Internet access always seems to be right around the corner, yet mobile workers keep finding themselves disconnected. Enabling these folks to access and update CRM information while offline presents an interesting challenge for an ASP with a purely browser-based application. The solution? Take maximum advantage of the XML and XSL (Extensible Stylesheet Language) capabilities built into Internet Explorer 5 and later. When a user syncs to go offline, new or changed CRM data is serialized as XML and streams down as a set of files stored on the local disk. At the same time, a corresponding set of XSLT (XSL Transformation) stylesheets is generated dynamically and streamed to the client. Browser-based scripts process these files through stylesheets to create an offline UI that is essentially the same as the online version. Although created differently, the two interfaces share the same security and customization features because these are encapsulated in the engine. Local data is, of course, a valuable resource even when you are connected. The Enterprise Edition uses it as a cache, which can therefore optimize performance on slow links. Because IE's security sandbox limits the size of objects kept in its UserData store to 1MB, according to Dave Moellenhoff, CTO of Salesforce.com, it was necessary to create an ActiveX wrapper for the Microsoft XML components. This tactic compromises the zero-install nature of the solution, but only slightly -- far less than would be true were an embedded database required. Although users sometimes have to work offline, they don't like to. "If it takes a long time to sync," Moellenhoff notes, "people will send their laptops back to the admin and ask to have it done for them." So the online system remains primary, and the offline version limits what can be done: You can add a new customer, for example, but not a new case. Minimizing the amount of offline data and the scope of the synchronization task is the key to successful adoption of an offline solution, Moellenhoff says. To that end, the sync tool eventually will offer filters that manage the flow not only of contact records, but also of opportunities, tasks, and events. The XML technology woven through the Enterprise Edition is distinguished as much by what it isn't as by what it is. The XML data store, for example, doesn't depend on one of the emerging breeds of XML databases; it relies only on the file system. The XML API avoids defining complex objects that encapsulate a lot of application behavior; it focuses on low-level row-and-column access to data. The protocol isn't SOAP (Simple Object Access Protocol), it's XML-RPC. These choices reflect a commitment to solving today's problems today while preparing to solve tomorrow's. Considering what tomorrow will bring is worthwhile. Sooner or later, the Windows file system will likely morph into a database -- one that furthers the SQL/XML hybridization we see in SQL Server already. An application that uses file-oriented XML data now will be well-positioned to exploit a local database engine, if and when such a thing becomes a standard part of the installed base. Similarly, a Web services architecture, which is currently still the exception, will rapidly become the norm, we expect. An application built around an XML-oriented API and an XML data store can move easily into that world. "The day will come," Moellenhoff says, "when you can point to a URL at Salesforce.com and drag and drop the account into your Oracle financials app, but the tool vendors aren't there yet." When the need arises, he expects to be able to switch from XML-RPC to a SOAP/WSDL (Web Services Description Language) stack in a matter of weeks. Salesforce.com today has a multitenant architecture -- its thousands of customers share a partitioned infrastructure. Tenants will increasingly want to share data directly with other tenants. Historically, that has meant living under the same roof. The landlord could set the rules of engagement and was motivated to do so in a proprietary way. But proprietary exchanges are clearly not the way of the future. An XML architecture isn't strictly required to enable Salesforce.com's tenants to congregate, but it's a good way to enable them to do so without locking them into their lease.
 RELATED ARTICLES  Customer-centric CRMRELATED SUBJECTS Business IntelligenceSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
