Sage CRM's SOAP Web Services and Sage CRM's COM based Web Self Service API.

The two APIs that I wish to consider in this article are mature, well developed and stable. They've been in the product for a very long time. Nevertheless, they are still used and still very much a useful pair of development options. In fact, they both play a very important part in integration and the Web Self Service interface is used by the Connector which provides the integration between Sage 200cloud (UK) with the Sales, Marketing and Service modules that form the heart of Sage CRM.

Web Self Service is COM based extension to Sage CRM using classic ASP pages.

Web Services is an XML, SOAP and HTTP-based Remote Procedure Call API.

Web Self Service uses the COM objects that provide not only the data access for database Create, Read, Update and Delete (CRUD) tasks but also the HTML generation capabilities. The Sage CRM Web Service provides CRUD access but no interface generation. The web service client application must include this if necessary.

The Web Service client application relies on the WSDL description of CRM services (the objects, methods and properties etc) and this is not automatically kept up to date. If the metadata in CRM changes, for example, new fields are added to the entities then the web reference link to the CRM WSDL file will need to be refreshed and the client application recompiled. The web service application should include some form of periodic checking for newer versions of the WSDL.

Web Self Service makes direct use of the CRM metadata and the objects of the COM API. If a change is made to a metadata then this is reflected immediately in the ASP pages of the Web Self Service application.

A Web Service client must log on as a user and create a Sage CRM session. Access to data is controlled by the user's security profile and territory rights just like in the diagram below.

Web Self Service accesses the CRM data without logging on as a User. Access to data is controlled by causing the visitor to be 'Authenticated'. For example, Simon Yaltoy as a contact may be given rights to view the Opportunities that are linked to the company Gatecom, but this access is completely at the discretion of the Web Self Service application author. Other parts of the self service site may allow anonymous access, so that any visitor access the CRM functionality, for example, creating a lead directly in CRM.

If the Sage CRM Web Server is down neither the Web Service client nor the Web Self Service ASP pages will work. Having said that the Web Service client making it's RPC calls is reliant on the fact that HTTP is a 'best-effort' delivery service and that any request to the Web Server could simply be dropped. The Web Service client would have to be coded to handle that possibility.

Both the Web Service requests and the Web Self Service requests to the CRM tables will pass through the application data management layer, so may trigger table level scripts as new rows are inserted, or existing data is updated or deleted. This allows audit trails to be created. Web Self Service is able to keep track of 'visitors' and typically you would track the authenticated access to data. Web Services access because it requires a user session to be created it automatically logged in the user activity tables within CRM.

HTTP is the application protocol for Sage CRM's web service and works well with network firewalls. This means that the web service client accessing Sage CRM can be beyond the corporate Firewall.

Web Service requests are considerably slower than COM requests. This may not matter when only small messages are sent. But Web Services are XML based. This is both a strength and a limitation. The messages in XML that are passed are easy for humans to read but are verbose. COM has a much smaller binary message format.

SOAP overheads include extracting the SOAP envelope and parsing the contained XML information. The XML parser will also have to carry out type checking and conversion. There also needs to be "well-formedness" checking, or ambiguity resolution, and this all affects speed.

The Web Service SOAP messages potentially may move much more data than the average HTTP GET or POST call generated by the main user interface which may adversely impact network performance. Repeated SOAP-client calls to access the server could start to degrade the performance. So you may have to consider the design of the web service client application.

To ensure secure transfer of XML data then HTTPS is essential for external Web Service access. Web Services that only use HTTP are vulnerable to eavesdroppers and "man in the middle attacks". HTTPS requests are very slightly slower than HTTP requests.

There is a range of factors that will affect performance such as web server response time and availability, client application execution time, database views and indexes that are implicitly referenced in Sage CRM.

  • Laura

    There are two tables in the Self Service database that are relevent (Visitor and VisitorProfile). You can easily extend the information that you keep about the visitor using those tables. Investigate the method CRM.VisitorInfo().

    var x = CRM.VisitorInfo("visi_ipaddress")

    retrieves the data.

    CRM.VisitorInfo("visi_ipaddress") = x;

    sets the data.

    If the 'visi' prefix is removed then the data is stored in the visitorprofile table in a similar way to the usersettings table.

    e.g. to set the data

    CRM.VisitorInfo("FavoritePage") = "mypage.asp";

    and to use the data


    I hope this makes sense. If you would like more information on this and how it works and how to use this technique then please let me know.

  • Jeff, is there anywhere in CRM that collects the access details of a WebSelfService visitor, i.e. number of times CRM is accessed, date of access, length of time, etc?