Welcome to MSDN Blogs Sign in | Join | Help

Where should the existing maps be customized?

Integration comes with out-of-box schema/maps so that user can customize them according to their own use. In integration/biztalk box if you have visual studio and biztalk SDK then you will be able to compile them very easily(provided you have updated path to a new strong key file). But in another machine where integration is not present, there you have to update paths to the assemblies which are under the bin folder of integration installation. Otherwise you will find numerous errors during compilations. Just updating the reference of functoid, crmschema and gpschema dll will not work. Functoid dll internally refers to quite a good number of dlls of integration. This was not the case in case of integration box as the dll(s) were already present in GAC. So I think better do it in integration box as it seems less cumbersome to me.

I have imported new schema from CRM; using schema exporter tool. When I am trying to open the xsd file, it's throwing error. What's the issue?

When schemas are exported using schema exporter tool; then the schema refers to Types.xsd and CoreTypes.xsd. These two xsd(s) will be available with the tool itself. Add these two xsd(s) and then try to open, The schema will get opened without any error.

Importance of types:

When you are customizing the existing schemas; ensure that you don't change the types of xsd(s). Example: I have exported account xsd. Out of box type is Micosoft.Mbsintegration.CRMSchemas.Account. If you change this and try to use it to compile maps then there may be some compilation errors in functoids. Try to preserve the type.

Have you ever experienced that after exporting the new schema the compilation is giving error: "<some> type is already defined...". Check the types.xsd and coretypes.xsd and ensure that there are no collisions of types.

Deployment of new map dll with same name: A tweak

If you go through integration user guide it's perscribed that you can't use the same dll once it's deployed. Example: I have created 3 maps for CRUD in abc.dll. I deployed 2 maps out of 3. Now I want to deploy the third one and the dll is already deployed!!

It's simple; stop biztalk services; delete the abc.dll from bin folder. Then deploy the third map. Done!!

Warning: I am assuming that the previous 2 maps have not been changed and of course this is not a prescribed way to do it.

 

 

 

 

If you have any questions or are looking to provide feedback/inputs on the Microsoft CRM Connectors, you can do that at http://blogs.msdn.com/microsoftcrmconnectors/contact.aspx. Your feedback is extremely valued and will help us improve future Microsoft CRM Connector releases.

The Microsoft CRM Connector for GP Setup does not allow customers to use an existing Microsoft CRM Connector for GP database. However, customers can change a registry setting to point to another Microsoft CRM Connector for GP database once Setup has installed the Microsoft CRM Connector for GP.

 

Details of this registry setting are as follows:

  • Change the string value of INT_DB under HKLM\Software\Microsoft\MSCRMIntegration\DataSources to Initial Catalog=<ExistingDatabaseName>;Data Source=Integration DB Server;Integrated Security=SSPI

Microsoft CRM Connector for Microsoft Dynamics GP Setup does not allow installation to proceed if BizTalk Server 2004 is already installed. However there is a registry setting which can be used to turn off this check.

Registry key name: HKLM\Software\Microsoft\MSCRMIntegration

Set the string value of UseExistingBTS under above key to 1 to avoid installation and configuration of BTS 2004 by Integration.

BizTalk Server 2006 Adapter for Microsoft CRM will be available in the 3rd quarter of CY06. More details available on: http://www.microsoft.com/presspass/press/2006/mar06/03-27Convergence2006CRMPR.mspx.

Audience: Customers/Partners who want to customize the CRM Connector for GP to support update/delete of new entities (entities which are not supported out-of-box). It is expected that  the user performing these steps is aware of the map creation process in BizTalk Server 2004.

 

Scenario: You wants to integrate new entities (example: CRM Lead and GP Prospect) and support create/update/delete operations asynchronously.


A “Create” map is comparatively easier but for a "Update" or "Delete" map the primary key of the destination system will be required.
The primary key in the destination application is required to determine which entity instance needs to be updated or deteled. (For example: to update the CRM Lead on update of a GP Prospect, the CRM leadid (primary key of CRM Lead) will be required to identify which CRM Lead needs to be updated)


This piece of information can be easily queried from the CRM Connector for GP database, if you know how links are managed by the CRM Connector for GP.
 

Example: Consider you need to create an "Update" map between CRM Lead and GP Prospect. PROSPID in GP and leadid in CRM are the primary keys for these entities. When an update on a GP Prospect occurs an xml for that prospect reaches the CRM Connector for GP which has the PROSPID populated in it. In the update map, you need to keep an advanced functoid between PROSPID and leadid. This functoid will query the CRM Connector for GP database to determine which leadid is linked with the PROSPID. I suggest you create your own dll which has a public method which can query the link. Then in the advanced script functoid you link this dll and the method.

 

Link management in CRM Connector for GP database

Intentityinstance(Table in integration database): Primary key is instanceid. Each row will correspond to one entity instance of  an application. “appentitykey” will contain the information about the primary key of that entity instance. So all the integrated entity instances of either CRM or GP will have entries in this table.

 

Intentityinstancelink(Table in integration database): Instanceid1 and instanceid2 of this table are corresponding to instanceid of Intentityinstance table. Linkid is the primary key. So this table is actually just linking two instances of Intentityinstance table.

 

So in our example, to find out leadid in CRM, first query Intentityinstance table where appentitykey contains PROSPID and the value of PROSPID. So you have the instanceid of the prospect instance.

Now query intentityinstancelink table where either instanceid1 equals to “the instanceid of propect instance” or instanceid2 equals to “the instanceid of propect instance”. If the link exists you will find one link in this table. If instanceid1 matches then you take instanceid2 or vice-versa. So you have “instanceid of lead instance”.

Now query intentityinstance table again to query the lead instance. Appentitykey will contain the leadid guid. Parse and extract the value and copy this to the leadid node of crm schema in the map.

 

I am attaching a code snippet(in C#.Net) which will give the feel of how you can query the integration database. This code can’t be used directly(as variables and references are not specified), I suggest you understand the logic and modify the code to suit your purpose.

Microsoft Dynamics GP requires each sales order to have an Order Type. For orders submitted through Microsoft CRM, Sales Users can either specify the Order Type explicitly with each Sales Order (the CRM Sales Order form is customized to contain the Great Plains Order Type), or the administrator can set a default Order Type through the Settings and Administration Tool. This Order Type will be used if an Order Type is not specified in the Sales Order submitted through Microsoft CRM. If an Order Type is not set either in the Settings and Administration Tool or specified in the Microsoft CRM Sales Order, the following error will be received when a Sales Order is submitted through Microsoft CRM (after the CRM Connector for GP is installed): 

Procedure or Function 'taSopHdrIvcInsert' expects parameter '@I_vDOCID', which was not supplied.”

In order to be able to specify an Order Type in a Microsoft CRM Sales Order or set a default Order Type in the Settings and Administration Tool, you need to migrate any existing Order Types from GP to CRM through the Data Synchronization Tool after deploying the CRM Connector for GP (all Order Types created subsequent to the CRM Connector for GP installation will be automatically synchronized and do not need to be migrated using this tool).

Microsoft Dynamics CRM 3.0 Expands Customer Choice With New Hosting and Connector Initiatives

The Microsoft CRM Connector for Microsoft Dynamics GP has three components:

  1. CRM Adaptor
  2. GP Adaptor
  3. Integration System

Now depending on the deployment configuration each of these components could be on a different server or on a common server (The Adaptor components need to be installed on the respective applications with which they interface – the CRM Adaptor on the CRM server and the GP Adaptor on the GP server). The Integration System uses BizTalk Server 2004 and hence has a dependency on SQL Server 2000. None of the other two components have this dependency.
 
So for instance if you have a three server configuration where each of CRM Server, GP Server and Integration Server are different, you could use SQL Server 2005 on the CRM and GP Servers but you would have to use SQL Server 2000 on the Integration server. If you have a one server configuration you would need to have SQL Server 2000; similarly on a two server configuration you would need to have SQL Server 2000 on the server on which you install the Integration System.

Demand Planning & Scheduling

·         Allows customer centric demand planning and scheduling across the company and with its suppliers

 

Improve Customer Experience

·         Improve customer experience by giving customer/channel access to product development/delivery status

 

Optimize Operations

·         Enable job scheduling based on customer priority by providing real-time customer information

 

Empower Marketing and Sales

·         Empower salespersons with real-time access to customer information, pricing and availability

·         Enable customer/channel to directly configure products/services

 

After-Sales Service

·         Enable service personnel by providing them with complete transaction history of the customer

 

Standardization

·         Data Standardization

·         Process Standardization

Key Benefits to the Sales User

  1. View Credit Information for Customers before creating Orders
  2. View current Site Inventory Information for each Product in Microsoft CRM 3.0 itself
  3. View Tax information for Sales Orders submitted to Microsoft Dynamics GP almost instantaneously in real-time
  4. Have Invoices created in Microsoft Dynamics GP automatically created in Microsoft CRM 3.0
  5. View status of all Sales Orders on a single page in Microsoft CRM 3.0 without having to contact the back-office
  6. View detailed status of each Sales Order in Microsoft CRM 3.0 as it is processed in Sales Order Notes

Product Overview

  • Integrates Microsoft CRM 3.0 with Microsoft Businesss Solutions Great Plains 8.0 (US English only) and Microsoft Dynamics GP 9.0 (US English only)

 

 

 

Deployment Configurations

Microsoft CRM Connector for Microsoft Dynamics GP supports various deployment configurations to support customers of all sizes. Possible deployment configurations are:

  • Single server deployment (where Microsoft CRM 3.0, Microsoft Dynamics GP 9.0 and Microsoft CRM Connector for Microsoft Dynamics GP are all installed on the same server)

  • Two server deployment (where Microsoft CRM 3.0 is on one server and Microsoft Dynamics GP 9.0 and and Microsoft CRM Connector for Microsoft Dynamics GP are on another server)

  • Three server deployment (where Microsoft CRM 3.0, Microsoft Dynamics GP 9.0 and Microsoft CRM Connector for Microsoft Dynamics GP are each on separate servers)

      

 

System Requirements

  1. SBS 2003 SP1 (single server deployment configuration), Windows Server 2003 SP1/Windows Server 2000 SP4(single server deployment configuration for Windows Server 2000 is not supported)
  2. SQL Server 2000 SP4
  3. .Net Framework 1.1 SP1 (Note: .Net Framework 2.0 is not supported)
  4. Windows Services
    1. IIS 5.0/6.0
    2. Message Queuing
    3. WWW Publishing Service 

Integration Points

Entities

Great Plains 8.0/9.0

Microsoft CRM 3.0

Remarks

Customer

CRUD

CRUD

Asynchronous

Product

CRUD

Read Only

Asynchronous

Sales Order

CRUD

CRUD

Synchronous – orders can be modified in Microsoft CRM 3.0 after submission; pricing by Great Plains only. Order from GP to CRM is Asynchronous.

Product Site

CRUD

Read Only

Asynchronous

Order Type

CRUD

Read Only

Asynchronous

 

Data Synchronization Tool

The Data Synchronization Tool is a graphical tool that you can use to synchronize customer, address, product, order, and invoice data between Microsoft CRM 3.0 and Microsoft Great Plains. The Data Synchronization Tool performs the following functions:

  • Migrates data from Microsoft CRM 3.0 to Microsoft Great Plains
  • Migrates data from Microsoft Great Plains to Microsoft CRM 3.0
  • Synchronizes data that exists in both Microsoft CRM 3.0 and Microsoft Great Plains

Rules

The Data Synchronization Tool uses rules to classify records. In this context, a record is an instance of an entity, such as a certain customer record or a particular order.

Rules establish how records are classified. There are six different classifications:

  1. Linked Records: A record is classified as linked if a link exists for it (with another record in the destination application) in the integration system. Linked record pairs suggest that the record pairs have been successfully synchronized at least one time.
  2. Matched Records: These records are not linked to a destination record and all mandatory and optional rules for the entity pair are matched.
  3. Partially Matched Records: These records are not linked to a destination record and all mandatory rules for the entity pair are matched; however at least one optional rule is not matched.
  4. Unmatched Records: These records are not linked to a destination record and no matching record is found in the destination application.
  5. Conflicting Records:  These records are not linked to a destination record and more than one record in the destination application is identified as a match. Conflicting records can occur when there are duplicate records in the destination application or if the rules that are defined are too permissive.
  6. Unresolved Records: This record’s parent record does not have a link to a destination record. For example, a customer address that has a parent customer record that is not linked will be in the unresolved records category.
 
Page view tracker