Joe

I've just updated and republished an article that compares Self Service with the SOAP web services.

community.sagecrm.com/.../crm_2700_s-webservices-and-crm_2700_s-com-based-web-selfservice-some-observations.aspx

Probably the most important thing to realise about the Self Service API is that it based on the COM objects, these handle the data interaction but are also responsible for generating the HTML used in the interface.

The COM objects place a restriction on how Self Service can be invoked, essentially they were designed for classic ASP and although they can be used (with some effort and creativity) with ASPX.

The wonderful thing about the Self Service API is that you can decide how your contacts interact with the data in Sage CRM. You can guide some data as tightly as you wish, requiring authentication or you can service some data anonymously. For example you may want to allow any visitor to see knowledgebase articles contained in the Solutions table without need to authenticate. Please note that this is not the same as 'logging on' to the main user interface - visitor authentication for contacts is a different mechanism from user authentication.

This is very different from either SData or SOAP web services which require a user (requiring a user license) to be log on. The SData doesn't have an anonymous way of accessing the data, although you can design applications to use a standard set of credentials to grant access to the data. There is no concept in the SData and SOAP interfaces of a contact or visitor. If you wanted to use theses interfaces within a corporate web site to give access to Sage CRM then you would need to build a parallel additional authentication mechanism for 'contacts' to authenticate.

This is do-able but not something straight out of the box.

The developer program has videos and resources that discuss many of these issues in more detail.

Thank you for the clarification! I'll go with using ASP.