How to convert a RetrieveMultiple query written Server side to SOAP message to be used in Javascripts

It has often been seen that a RetrieveMultiple query that is very easy to write using the server side Query Expression objects using CRM webservices becomes difficult to achieve if we need to create a SOAP message for the same.

In this article we hope to explain each of the elements involved in the writing of SOAP messages to be used through Javascripts.

Let us take a simple RetrieveMultiple code as an example.

While writing the SOAP message the first component required is the SOAP envelope. This is the same at all times for all SOAP messages.

"<?xml version='1.0' encoding='utf-8'?>"+
"<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'"+
" xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'"+
" xmlns:xsd='http://www.w3.org/2001/XMLSchema'>"+

Next we need to add the Authentication Header that needs to be passed along with the SOAP message for successful authentication with the CRM Web service. CRM has an inbuilt function GenerateAuthenticationHeader() that can be used for this purpose.

var authenticationHeader = GenerateAuthenticationHeader();

SOAP Body is where the actual SDK message to be executed is included.

"<soap:Body>"+

In our example we are using the RetrieveMultiple Message so we provide the Message name and the schema reference to the CRM webservices

"<RetrieveMultiple xmlns='http://schemas.microsoft.com/crm/2007/WebServices'>"+

The parameter to a Retrieve Multiple Message is always a query expression

QueryExpression query = new QueryExpression();

"<query xmlns:q1='http://schemas.microsoft.com/crm/2006/Query'"+
" xsi:type='q1:QueryExpression'>"+


Now include all properties of the Query object that you set.

Entity name

query.EntityName = EntityName.incident.ToString();

"<q1:EntityName>incident</q1:EntityName>"+

Column Set

query.ColumnSet = new AllColumns();

"<q1:ColumnSet xsi:type='q1:ColumnSet'>"+
"<q1:Attributes>"+
"<q1:Attribute>title</q1:Attribute>"+
"<q1:Attribute>incidentid</q1:Attribute>"+
"</q1:Attributes>"+
"</q1:ColumnSet>"+

Criteria

ConditionExpression condition = new ConditionExpression();
condition.AttributeName = "title";
condition.Operator = ConditionOperator.Like;
condition.Values = new string [] {strSearchText};

"<q1:Criteria>"+
"<q1:FilterOperator>And</q1:FilterOperator>"+
"<q1:Conditions>"+
"<q1:Condition>"+
"<q1:AttributeName>title</q1:AttributeName>"+
"<q1:Operator>Like</q1:Operator>"+
"<q1:Values>"+
"<q1:Value xsi:type='xsd:string'>"+searchtext +"</q1:Value>"+
"</q1:Values>"+
"</q1:Condition>"+
"</q1:Conditions>"+
"</q1:Criteria>"+

Here, we have used 'Like' condition operator, likewise one can use any of the sdk supported operators and change the values to be matched accordingly.

Order by

OrderExpression oe = new OrderExpression();
oe.AttributeName = "title";
oe.OrderType = OrderType.Ascending;
query.Orders = new OrderExpression[]{oe};

"<q1:Orders>" +
"<q1:Order>" +
"<q1:AttributeName>title</q1:AttributeName>" +
"<q1:OrderType>Ascending</q1:OrderType>" +
"</q1:Order>" +
"</q1:Orders>" +

Once you have set all of these… your SOAP message is ready for execution.

How to Bulk Edit Attributes that show up Disabled on the Bulk Edit Form

We came across this really tricky situation and we would like to thank Microsoft for having a KB article (http://support.microsoft.com/kb/949941) for this.

We wanted to bulk edit a few of the accounts using the Actions => Edit option. The form that comes up here displays all attributes available for the Account entity. You would however notice that some of them are disabled though. Since we had 2 custom picklist type of attributes, one showing up as enabled the other disabled, it was easy to identify the possible reasons for disabling this one had custom code written on its onchange event while the other did not.

But we still wanted to be able to Bulk Edit this attribute without having the need to create a custom page just for editing a custom picklist attribute. Our search lead to the following KB article that explains the steps to enable this.

To have this explained in short, the entity customization file has a property “BehaviourInBulkEditForm” for the event tags. This determines the behavior of the attribute and the code written on the event. The valid values are

Enabled -- If you use this value, the field is enabled. Additionally, the code for the event is run when the event is called.
Disabled -- If you use this value, the field is disabled.
EnabledButNoRender -- If you use this value, the field is enabled. However, the code for the event is not run when the event is called.

Exporting the customization and making the below change should enable the attribute and not have the code written on the onchange event fired

<event name="setadditionalparams" application="true" active="true" behaviorinbulkeditform="EnabledButNoRender">

Converting ACT! Legacy data to Dynamics CRM

There has always been a request for bringing in legacy data to Dynamics CRM before they migrate to you. One of the key points for going through with the shift from one system to another is the ability to have access to all the records in their legacy system in Dynamics CRM.

The easy way out most often is to look for Data Export options from the current system to generic file formats like XML, CSV, XLS etc. Same is the case with ACT! as well. However though a quick and easy way out this does not necessarily guarantee the quality of the data migrated. Often not all data is exported from the ACT! System and sometimes the data exported is not in a format that can be easily imported to CRM.

ACT! however has its own SDK made available that allows us to read every entity data from ACT! And this way we have more control over the data and format in which we want to bring it into CRM.

Writing information to CRM is not a difficult task for a proficient Dynamics developer. With good knowledge of the SDK of both systems we have been able to successfully bring in not just the Account/Contact and basic details but also bring in Opportunities and history as well.

A couple of tips that would help you when writing your own import tool for ACT!

1. When importing activities, ACT! Allows you to store the activity description in rich text format. In CRM the activity details is a plain text attribute. So it is essential to make sure that all the RTF tags from the activity description read from ACT! are stripped off before writing the data to CRM.

//read act history details to RTF

RichTextBox rtf = new RichTextBox();

rtf.Rtf = oHistory.Details;

//Get the plain text desc from RTf to add to CRM

Desc = rtf.Text

2. When processing history be carefully while parsing the duration field of ACT! CRM requires duration to be specified in minutes.

3. ACT! allows to associate Primary contact as well as additional Secondary contacts with a company. The main contact of ACT can be set as the primary contact in CRM and additional contacts can be made as Contacts by setting the Parent account of these correctly.

4. ACT! provides for creating custom attributes and often you would want to bring to CRM as well. The custom attributes in ACT! are available just as any other field of ACT! and is not stored separately in a different entity.

There are a number of migration tools available in the market to take care of ACT migration if you do not like to reinvent the wheel. One of the unique tools is available here with us, where we offer it as a service / product by testing with your data and verifying the details as well as making small changes according to your specific needs. Check this tool out here.

Maplytics for Dynamics CRM

Further to our post on Maps integration for Dynamics CRM using Live Maps https://community.dynamics.com/blogs/crminogic/archive/2009/04/27/maps-integration-for-dynamics-crm-4.aspx we have been able to compile a list of mapping components that can be made available on different entities of CRM with the aim of enabling Geo analysis of the data stored in CRM.The entities covered are:
1. Lead/Account/Contact – Plotting of the primary address of these on the map. It also provides the directions to the customer address starting from the organization address.
2. Plotting of Accounts from a selected range of Accounts that come within the specified distance. The aim here it to be able to list out all accounts that are within a given range from the Starting point.

3. Geo mapping of Leads/Accounts on the map with the aim to allow the users to analyze their customer based on geographical regions.

4. Geo mapping of Sales/Opportunity on the map with the aim to allow the users to analyze their sales by geographical regions and thereby be able to design strategies focusing on a given region.Some of the features are:
Ø Each of these when plotted on the map allow the users to drill down ability and also be able to open Contact/Lead/Account etc CRM form to check further details of these.

Ø While searching for directions, you can specify the Route that you want to take and you would get the direction via the specified location.

Ø View Summary or Detail information

Ø Use of Advanced find view for providing the record selection to be plotted on the map.

Preview:

Here clicking on Get Direction one can see the following screen.

Click here to check further details.

Adding Money type attributes in Advanced Find causes error

If you were to add a money type of an attribute as one of the columns of a view you are designing, when you try to run the view, the results page will show an error message.

This is because the money type attributes require that the currency always be specified along with the money type attribute. To fix the above error all you need to do is include the currency attribute in the view and it will work just fine.

If you design a new custom Entity in CRM, the moment you add a money type of attribute, it automatically adds an attribute for currency called “transactioncurrencyid”.


If you forget to add the currency attribute on the form, when you try to provide a value in the money type attribute it will throw an error.

We have had various requests from customers who find the “Currency” attribute unnecessary as they work in a single currency and would like to avoid it. It is possible to remove the currency attribute from the form. But you can hide the currency attribute through scripting.

So in short… Money attributes require Currency attribute to tag along with them for them to function correctly.