Philip Richardson

Refer: Part 1, Part 2

Connecting to CRM 4.0 will use one of two methods: SQL and Web Services. Both a valid techniques but they are far from symmetrical in functionality (for good reasons).

SQL:

This approach involves making a regular SQL connection (with a technology like ADO.NET etc) and executing SQL Statements. CRM 4.0 has a set of special SQL views which we call the 'FilteredViews'. Each entity in CRM has a corresponding Filtered View. For Example: the Contact entity has a view called FilteredContact. These views join together all the information for this entity and they also link to the security tables containing the row level security information. This means that if a user has access to only 15432 contacts out of the 3 million in the database – when that user does a SELECT * FROM dbo.FilteredContact they will only see 15432 rows. The FiltereViews are only good for reads. You should make changes to the database data or schema using SQL with CRM 4.0. Our middle tier needs to handle all data and schema transactions. It doesn't matter how smart you think you are. It doesn't matter how many times you've run the SQL profiler over the DB and are sure exactly which tables/columns to update. Never make changes to the database. Never.

OK – so what does one use the FilteredViews for. Reporting is the #1 scenario here. You'll use these views to generate most of your analysis and reporting for CRM 4.0. You might also use them ADO.NET (or similar technologies) when writing applications. Please be aware that the views can be locked down by system administrators. My advice: only use the filtered views for analytical applications.

Web Services:

This is the standard way of connecting to CRM and manipulating the data and schema of the system. It's important to understand the multi-tenant nature of CRM 4.0 and how many assumptions you might have made with CRM 3.0 (which is single tenant) need to be reconsidered. Our web service is a SOAP service which we feel is a great fit for a complex business system like CRM. We have three web services which you need to consider in your application architecture:

• CrmDiscoveryService: You'll use this service to 'discover' information about tenants (organizations) on a server (deployment). In some modes it will also issue security tickets.
• CrmService: This is the 'main' web service. It handles the manipulation of an organization's transactional data.
• MetadataService: This service handles the manipulation of an organization's metadata (schema).

Understanding authentication plays a role in how one connects to CRM. There are four ways to accomplish authentication and not all are available to every deployment.

Integration Authentication: Use this within your firewall – where Integrate Windows Auth works best.

1. Connect to the Discovery Service and get the Organization Details using System.Net.CredentialCache.DefaultCredentials.
2. Create a CrmService using some info from the Organization Details.
3. Conduct transactions using the CrmService using System.Net.CredentialCache.DefaultCredentials.

Windows Authentication: Use this when you want to specify credentials. Often used if your client holds a different set of credentials.

1. Create a Network Credential (using Domain, User, Password).
2. Connect to the Discovery Service and get the Organization Details using the Credential you created.
3. Create a CrmService using some info from the Organization Details.
4. Conduct transactions using the CrmService using the Credential you created.

Internet Facing Deployment (IFD): This is Active Directory at the back end but the credentials are collected using a Forms Auth approach. In CRM 4.0 you can only use AD as the Identity store for on-premise (Live uses Windows Live ID).

1. Connect to the Discovery Service and get the Organization Details using the UserName/Password in the request. SSL is a must when using IFD!
2. Create a CRM Ticket using the Discovery Service and the UserName/Password. A CRM Ticket is Organization specific.
3. Create a CrmService using the CRM Ticket and Organization Details.
4. Conduct transactions using the CrmService. The CRM Ticket will be passed in the SOAP header it will authenticate you for a period of time (tickets do timeout) against a specific orgs.

CRM Live: This is a Windows Live ID (WLID aka Passport) based SOAP web service. Unlike many other SaaS offerings out there – each user uses their own credentials when they connect. There is no 'admin one size fits all' key/token for CRM Live.

1. Make an anon request to the Discovery Service to get the CRM Live Passport Policy.
2. Connect to Windows Live ID and supply the Policy, WLID UserName/Password. It will give you back a Passport Ticket.
3. Connect to the Discovery Service and get the Organization Details using the Passport Ticket.
4. Create a CRM Ticket using the Discovery Service and the Passport Ticket. A CRM Ticket is Organization specific.
5. Create a CrmService using the CRM Ticket and Organization Details.
6. Conduct transactions using the CrmService. The CRM Ticket will be passed in the SOAP header it will authenticate you for a period of time (tickets do timeout) against a specific orgs.

The SDK contains samples for conducting each pattern. Your apps which connect to CRM will need to understand the following concepts:

• Where to find the Deployment. This really means: What is the URL for the Discovery service. For CRM Live is the one Discovery Service URL for all of CRM Live.
• What org do I want to connect to. Some apps will always know this. Others may want to query the discovery service a list of all orgs which a user has access to and then have the user pick (using your UI) which org to connect to.
• What type of Authentication is being used: Integrated, Windows, IFD or WLID. Maybe your apps will support some of these – if so – remember you are responsible for the UI – so help out your users when connecting. Our Outlook Client is a good example of one these types of apps. It's worth taking a look at how we solved these UI problems and see what works/doesn't work in your application.
• You have a choice of using our compiled Type Proxy or the WSDL when connecting to CRM. Note there is not a Type Proxy for the Discovery Service: however the WSDL is the same for Windows, IFD and WLID.

Here is a basic auth class I use for apps which Connect to CRM. This code sample is unsupported – please do not send in questions. Link