Scribe Insight cross-reference drop-down and pick-list mapping approaches (option sets in Dynamics CRM)

In your Scribe workbench dts package you usually need to map a dropdown (or picklist) to another dropdown or optionset (as in Dynamics CRM). This is a common requirement as part of data migration and data integration projects to link between drop down menus in source system to those corresponding to the target system.

For example, the source system (assume it’s a file) has Salutations values as:

id-value
1-Mr
2-Mrs
3-Ms

 

The target connection on the other hand (assume it’s Microsoft Dynamics CRM 2011 system), has option set values as follows:

Value-Label
100000000-Mr
1000000001-Mrs
1000000002-Ms

 

To achieve this mapping between the id and values of both source and target systems, there are a number of approaches and methods as listed below:

 

Method 1: Use a cross reference (Xref.ini) file for mappings. This is the standard approach (I claim) for mapping two optionsets in Scribe Insight. All you need to do is create a new file, call it anything such as XREF.INI. Within this file, build all your mappings as follows:

[Salutation_Code]
1=100000000
2=1000000001
3=1000000002

 

[Title_Code]
1=Owner
2=President
3=Manager
4=Executive Director
5=Principal

 

As you can see in the file, there are two sections. You can have as many sections as you want all in one file. Each section will map two drop down menus together. The first section, Salutation_Code, maps Mr (id=1 in source file) to Mr (id = 1000000000 in target CRM).

Once you add your mapping section in the file, you can then write a formula to cross reference the value on the target to the source. The formula for the Salutation target field can be something like in this example: FILELOOKUP(S7, “XREF.INI”, “Salutation_Code” )

The following screenshot shows a sample forumula:

What will happen is that, based on the source value (in our case s7), the corresponding salutation in the cross reference file will be inserted to the target

More details can be found on Scribe Insight Online help here: http://community.scribesoft.com/helplibrary/mergedProjects/Insight/Formulas/Functions/FILELOOKUP.htm

 

Method 2: Map and crossreference drop downs and pick lists using Scribe Work bench formulas

In this method, you either create all your option set values in the target Dynamics CRM system to have the same id as the source (for example: 1=1) or you do a formula to manually do the mapping. This could work in cases where there is two or three options but otherwise, it gets too complicated for no real benefit.

The formula can be something like this:

IF(S7=”1″,”100000000″,IF(S7=”2″,”100000001, “”))

In other words, if the source = 1 (Mr), then set the target = 100000000. Else, if source = 2 (Mrs), then set target = “100000001”. Otherwise, leave target blank.

Methods to Bulk Delete Microsoft Dynamics CRM records and Using Scribe Insight to perform a Bulk Delete of all CRM records.

I’m sure many people needed to do a bulk delete operation on Microsoft Dynamics CRM 4.0. You may have uploaded thousands of records from an imported file or migrated them through Scribe or even used a .NET application to mass create records.

Unfortunately, and as far as I can see, there is no straight forward way to do bulk records deletion on Dynamics CRM 4.0 using the out of the box functionality and interface of Dynamics CRM 4.0.

To bulk delete records in Dynamics CRM 4.0, you have the following main options:

  • Get a third party tool or CRM add-on to bulk delete records. This option is a straight forward one but you might have to pay for purchasing or using the tool. It may also have security issues. I would not recommend it to my clients as most probably the tool is created by a small company or an individual which I don’t know. Hence, it will be rather difficult to put this tool on a live Production environment or client server. Let alone adding it to CRM Online or to a CRM hosted solution by a partner.
  • Use CRM SDK to write a .NET application (or a .NET console application) that will run and delete all records for a specified entity or entities. This is a more robust way of doing it, but it may take longer time and is probably not suitable for people who do not come from .NET development background.
  • Use Scribe Insight. This is what this post is about really.. Using Scribe Insight to bulk Delete Dynamics CRM records.

Please Note: This is a work around. It is not supported by Scribe and the advice in this post is provided as is with no warranty. I have tried it and it works perfectly but can not guarantee it will have the same acceptable results in any other environment.

Here is what you need to do:

  1. Create a new Scribe workbench DTS (or Job). Point to your usual source file (even a sample one) and point to CRM: either IFD Forms for hosted CRM or direct connection.
  2. Configure the targe: Create one delete step on the target.
  3. Make sure that the option to “Allow multiple record matches on updates/deletes” is ticked under the All steps tab.
  4. Under Step control tab, leave failure to go to next row but change all the success records (Success (0), Success (1) and Success (>1) ) to End Job. Select success radio button at the bottom and write a message to your log such as: “All records Deleted”.
  5. No Data links are important as you are only deleting.
  6. On the Lookup link, just make the lookup condition impossible. Such as: where Account Name = 123456789 or whatever.
  7. Run the DTS.

The Job will read the first source line. Will then try to find this record at the target (remember it is update/delete). Since we have setup the lookup link to look for something “impossible to find”, the result of the update will be Success (0).

Once this happens, Scribe will go and delete all records for your chosen entity (or CRM table). This will be a complete bulk delete of all CRM records using Scribe.

Remember, it’s a work around… that works.

Scribe Console: Renaming Source Text files before running a job and after processing and regularly changing source file names.

This post applies for Scribe Insight version 6.5.1. It may well apply to all Scribe version 6.5.x

Have you ever looked in Scribe Insight for a way to rename a source file before processing it. Scribe console creates collaborations where integration processes can be configured so that they wait for a file to be added to a specific location and then run a specified job. Once the file is added the job will run and process the file. Also, Scribe DTS jobs can only be setup to process a source file that has its name always fixed and unchanged. So a DTS can be setup to process a source file named: customersdata.txt. It will never run if another source file is added to the location the Scribe console is looking at. In this case, if you get a source file with the date (and time) stamp in its name will need to rename it so the the DTS can detect it and run. So if the source file comes with time and date stamp that varies every day (for example: customers_1453_21092009.txt), you will need to rename “customers_1453_21092009.txt” to “customersdata.txt” only to get the DTS to work.

After some research, I found out that you can only do this using pre and post processing commands step of the process. Every integration process has step 2 in it called pre and post processing commands. In this step, you can specify a pre-processing and post-processing commands or scripts. This feature lets you specify a pre and post processing file that can do this renaming for you. Accepted pre and post files are: *.vbs, *.js, *.vbe, *.bat, *.cmd, *.exe, *.com

You will then create a pre-processing script that finds all files that start with “customers*” in our example and rename it to customersdata.txt which is the source file name the job is expecting. Post processing can be to rename the file to something else so that you keep a record of processed files.

In step 3 of the Integration process, Scribe also gives you two options (in the form two check boxes) that I find very useful. You can either select to delete the source file after processing or you can select to rename it. So the source file will be processed and renamed to something like customersdata.L1.txt. Unfortunately Scribe doesn’t give you the choice to choose the new name of the file. Hence, you will need to write a post processing script again for renaming it afterwards if you are after a specific file name.

I’m not sure if there is any other way of renaming source files (also called event files by Scribe) before processing them or specifying a new name for them after processing.

SCRIBE: Return the GUID of an entity record in Microsoft Dynamics CRM using a lookup field value.

I am working on an Integration project between Microsoft Dynamics CRM and SAP. I am using Scribe as the Integration tool/application.

The source in this case is SAP. The target is Microsoft Dynamics CRM. I am using Microsoft Dynamics CRM Scribe Adaptor.

I’m not an expert in Scribe (as yet) and I wanted to do a simple step. I wanted to get the GUID of a record in Microsoft CRM entity using a lookup field value.

The whole Scribe step is just an update to the Account form. I have the Contact name and I need to get the Contact GUID to input this GUID value (pointer to the Contact) into the Account form primary contact field. This is an N:1 relationship between Account and Contact.

So if the primary Contact name of an Account record is John Smith, the question was: how can I get the GUID of the John Smith contact to update the Account record.

Thanks to my colleague John Ball, the answer is to use the simple DBLookup function (formula).

To do that: Select the target Scribe CRM adaptor field. In my case this is custom_account_primarycontactid. Select it and then click formula. In the formula window look for the DBLooukup function. You can use the DBLookupCached function for an enhanced performance if your values are not changing before or after in any of the steps.

The formula should be something like that:

DBLOOKUPCached(S2 , “T”, “contactentity”, “contactname”, “custom_account_primarycontactid” )

 

That should be it. It’s quite simple.