Thursday, May 30, 2013

Scribe Insight - XML with repeating nodes in a nutshell

In my daily work I run into integration projects where xml files are exchanged between source and target systems. In some situations you will have more complex xml structures, which contains repeating nodes. The process is simple, we basically loop several times through the source file.

In this post a method is described how you can configure your xml with repeating with Scribe Insight.

You start with your xml and create associated xsd schema (this is optional) with your xml software like Visual Studio or XML spy or other flavor :-)

Example customer xml file
 The next step would be to configure a new connection in the Work Bench for your xml file, of course this is only the sample file. For integration the contents will change e.g. its dynamic. Keep in  mind that you will need to change this files too as some fields are added or removed from the source.

In the following screenshots you see the steps you have to take. In short you open the connection manager, choose for XML > dynamic > Select your xml and xsd. The files should be located in your collaboration folder.
Example customer xsd file

After your connection has been created you can define connection to  your target. In this example I used a custom table in Scribe Internal database called customers. When you define your source a window will popup where you can define your repeating node(s).

Ok, here is the flow in screenshots..... just like your TV at home :)

Add Connection > Choose XML
Use as Source

Its dynamic :-)

Choose your files e.g. xml & xsd (in this case)

Your connections

 At this time you did configure your connections, when you Configure Source (see screenshot below), you will go to XML and select the Customer node of your xml. A new window will popup where you can define your repeating node(s)

Configure your source
Here the magic happens :)

After your created your source, target and mappings, just hit the "Test Run" button and in my case you would loop three times through the xml file.

Your basic mapping
first run

second run

third run

No where to run :)

This is in nutshell how you could loop through your source XML file with repeating nodes.

Happy happy happy repeating repeating repeating :)

Thursday, May 16, 2013

CRM 2011 & database mirroring

In most scenarios where you implement CRM 2011 in Enterprise segment you would choose for database clustering. The advantage is that your setup is easy, at least I think so :) You have virtual name for your SQL server no need for extra CRM configuration.

Another alternative is to choose for database mirroring, also supported scenario. Please keep in mind that besides configuration of SQL server is more complex. You also need to make changes to CRM, which can be forgotten easily.

For example you need to change some settings in the registry on the server where the web application is installed:

2) Change: configdb

Data Source=MSCRM_Primary\SQL1;Failover Partner=MSCRM_Mirror\SQL2;Initial Catalog= MSCRM_CONFIG;Integrated Security=SSPI

You can image when you do node switch and forget this entry your CRM application will crash. More details at:

More background about database mirroring:

PS If you wondering about the image, read this article about Droste Effect  :-)

Understanding integration concepts

In my experience as Dynamics CRM consultant I am also involved in several integration projects. The requirements should be business driven, but it still happens that requirements for integration are defined by the IT/support organization.

In some cases due to lack of knowledge people tend to define or choose requirements within their comfort zone. Of course this is not surprising because it is for them known area and they basically keep doing their work without being confronted with new technology or new software.

The downside is that the integration design gets more complex as it should be. I prefer to design integration with according to the  'loosey coupled' principle, which basically means that source(s) and target(s) have no direct links.

In this scenario you would have for example a generic account template. A system that want to deliver account information used the template (in xml format) and the integration process moves it to the desired target system. Very import in this scenario that the templates are defined and changes have major impact, so you would need to take time to define a good generic template. Of course in case you use Scribe as integration platform you need to define a xdr or xsd file. In this file you define all fields, required, data types etc.

In the integration scenario where you exchange xml files you would most likely use MSMQ as reliable and proven technology. In my next post I will explain more about this scenario using Scribe Insight.

So, explore new possibilities by stepping out your comfort zone it could make your life less complex....