Attribute maps and importing customizations

0 comments

Posted on 19th January 2009 by Jukka Niiranen in Tips

, , ,

After performing the basic installation of MS CRM, you will have a system that contains the default entities with all their fields, forms and so on. The next step will be to modify the entity customizations to suit the business needs of the organization. Typically there will be a development and/or test environment where the customizations are first performed, before being imported into the production server. This should be an easy operation through the Import Customizations menu, but sometimes you may end up with a nasty error like this:

“This attribute map is invalid. The selected attributes should be of the same type. The length of the target attribute should be equal to or greater than the length of the source attribute and the formats should match. The target attribute should not be used in another mapping.”

This can happen when the source customization has some default attributes mapped in a different way than what they are by default. As pointed out by Will Willson in this blog post, CRM only adds new mappings between entity attributes during the import. It will not delete any existing mappings, so you may end with the source entity having two mappings pointing to the same field in the target attribute.

If you have a hunch on what entity and which attribute might be causing the problem, the quick solution is to go and remove the existing mapping prior to importing the new customizations. If you’ve got no idea on where the conflict is, you can try enabling CRM Platform Trace, reproducing the error, then opening the resulting trace file that begins with “w3wp-MSCRMServices” and searching for the tag “FAILURE”.

(This issue is described in the confidential Microsoft KB article 921977, available through Customer Source.)

The haunted house of callouts

0 comments

Posted on 8th January 2009 by Jukka Niiranen in Configuration

, ,

One of the integrations implemented for our CRM environment includes a feature that writes entries to a dedicated Error Log entity. This can be a convenient way to provide the end users access to error notifications, when the process itself is asynchronous and does not provide a way to prompt the user.

During the development project of this integration, frequent updates were made to this callout dll file and I received new versions to be deployed from the developers almost on a daily basis. After one particular update, we were surprised to notice that the callout was still writing an error messge into the custom entity, which was not supposed to be there. In fact, the whole message string no longer existed in the dll file. Where did his ghost messages appear from?

It turned out that merely stopping and starting IIS does not guarantee that the previous version of a callout would not remain in the cache. If there are any workflows associated with the entities that the callout references, these can keep the old version of the dll loaded up in memory, thus creating the “haunting” effect described.

As a lesson learned, whenever I need to update a callout dll file, I now go through the following steps:

  • Stop the CRM Workflow Service (net stop mscrmworkflowservice)
  • Stop IIS (iisreset /stop)
  • Replace the callout dll
  • Start IIS (iisreset /start)
  • Start the CRM Workflow Service (net start mscrmworkflowservice)

Switch to our mobile site