CRM development - early bound approach supporting multiple organizations

Question

We are facing the problem when we would like to develop a CRM library (manager) in C# which will support the communication with more than one CRM systems - i.e. the situation when you are running more than one CRM instances at once (e.g. two different organizations).

Requirements for the CRM library:

1. Use early-bound instead of late-bound (because of type safety)

2. Able to communicate with more CRM systems (organizations) through one manager

3. Only one method for one operation (avoid code duplication) used for all CRM systems (organizations) - it will be necessary to create an utility for parsing generated entity files (crmsvcutil tool) for each organization. The result of the parsing will be list of interfaces and partial classes for the entities defined in the entity files. The interfaces will be implemented in the partial classes according the attributes which they contain, like IAccountNumber etc. There will be two groups of interfaces - first one for the entity attributes common in both organization e.g. interface ICrmAccount will define AccountNumber, Name, Address1 attributes etc. The second group of interfaces will be for the attributes which are unique for entity and are not present in entity of ALL CRM systems (organizations). The general CRM manager will than offer all methods for the communication, like CreateAccount(), GetAccount() etc. which will then work with the specific CRM system due to implemented interfaces.

We have designed a solution which is now able to communicate with two different CRM systems but it is not able to use implemented interfaces for the specific account, see enclosed solution which contains comments of the code.

The solution can be found here:

Link for download

Description of solution:

CRM_BusinessLogic - contains CRMManager which holds all methods for the communication and initialize correct data context in constructor

CRM_Interfaces - contains all generated interfaces which are result of entity files parsing (this will have to be done with separate parsing tool). Now contains only iCRMAccount holding only one attribute common for both organizations and iCRMContext which contains the entity which are implemented in both data contexts - now both contexts implementes same entity Account.

CRM_SCEurope - contains generated entity file for the first CRM organization SC Europe - SCEuropeEntities.cs, generated data context by the parsing tool (implements list of interface according which entities are present in the organization context) - SCEuropeContext_generated and SCEuropeContext.cs which returns the correct assembly

CRM_SoSW - the same content as CRM_SCEurope, contains the data related to the second CRM organization

CRM_Test - contains the test console app which will communicate with both organizations

Please note that enclosed solution only contains Account entity with only Name parameter which is enough for the basic testing of designed solution.

Important: Before run of the project you have to set credentials for the manager in the Program.cs file (CRM_Test project).

As you can see if the Account data are loaded from the CRM using the generated partial classes (SoSwContext,SCEuropeContext) with implemented interface iCRMContext, the application throws an exception "Invalid 'where' condition. An entity member is invoking an invalid property or method - see the method implementation.".

We will appreciate if anybody will find a solution how to solve the exception.

Thanks

Pavel

Answer 1

For my current employer, they have multiple CRM organizations, some are nearly identical, and we actually are able to use the exact same early bound classes, with a 20 some lines of custom code to handle the differences. Other organizations are not, and so we have a separate dll with an organization specific namespace containing the generated early bound types. There is no reason that they couldn't all be in the same dll, but you'll have issues if they're all in the same namespace, since each will define it's own definition for Contact, Appointment, etc.

Just remember, you can use the early bound types for a different org, as long as you don't attempt to select or update a particular field or entity that doesn't exist. So if Org 1 has a CompanyId on the Contact entity, and Org 2 doesn't, you can still use the early bound types for Org 1, for Org 2, as long as you don't populate the CompanyId (ie place it in the entity parameters collection)