I have been asked about using Sage CRM Self Service API with ASP.NET.

Imagine that you may have a customer that is using ASP.NET as the underlying technology of their corporate website. You may now have implemented Sage CRM for them and they now want to bring some of the data from their internal systems to their public facing website. And naturally they want to continue using ASP.NET.

So the type of features that they want include might be:

1) Authentication of Visitor against logons stored in Sage CRM
2) Registration of New Customer via website - Allowing Visitors anonymous access to some parts of the site to allow them to submit their details.
3) Opportunity registration from website into CRM & run a workflow mechanism from the website that links to the workflow in Opportunity
4) Editing Customer profile on line & saving into CRM
5) Interaction with Third Party Back Office System via API
6) Direct Interaction with Third Party SQL Server Database

If the corporate website was using ASP pages then the Sage CRM Web Self Service API would allow each of these tasks to be easily accomplished.

But do we need to use the COM Self Service API? The Customer wants to use ASP.NET so can the standard COM API be allowed?

In fact the Self Service COM API can't be used in ASP.NET pages. This is largely down to the failure of the init() method to initialize the object correctly for the ASP.NET environment and there are no plans to change this.

So we are left with the idea of using perhaps the Web Services API.

But the main point we face where ASP.NET pages are used in the corporate website is simply that the COM API is not available. If a customer insists on using ASP.NET pages then our two options are:

1) Contain the Self Service ASP pages in within ASP.NET page.
2) Rebuild the Self Service Feature using Web Services

The first choice is easy and relies on an intellectual compromise. But "Mash-ups" and blended pages are very fashionable at the moment. And Self Service via the COM API will give you full and complete access to all of the Sage CRM tables and also linked third party database tables. The Self Service tables of Visitor and VisitorInfo are in separate database from the main CRM database. So it would be very easy to use the Sage CRM Self Service API to deliver ERP data to the corporate website. BUT you will need to think carefully about the write back to the database especially in ERP environments and it would be essential to use the API of that ERP system to do that.

The second choice is harder but purer. You don't get the interface generation capabilities with the Web Services API (no blocks) but it does mean that you have clear data access using ASP.NET pages directly. You can then use the ASP.NET controls to create the screens that exactly match the existing corporate ASP.NET applications.

BUT It is a more complicated matter about accessing third party databases via the Sage CRM Web Services. This means that it is not longer straight forward in handling the authentication checks for visitors as the Visitor and VisitorInfo tables are not Sage CRM core tables.