Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications


CRM 2011 Instance Adapter: Understanding Object Provider Files

Post Author: Joe D365 |

Basic Types, Complex Types and Multi-Reference Entity Lookups

Mappings for entity integrations with the Microsoft Dynamics CRM 2011 Instance Adapter are supported by Object Provider configuration files that exist inside the adapter’s internal folders.

You can see the location of the Object Providers in the following image:

Object Provider Configuration Files are created utilizing the Configuration Utility that is accessible from the Adapter Settings window in the Connector for Microsoft Dynamics.  Different configuration files are created for both the source and destination portion of the adapter and each organization you configure as well.

Exploring the File

Since all instances of CRM come with some common out-of-the-box entities, we’ll utilize the Account entity in the proceeding document.

If you open the account object provider and were to minimize the first child element of the configuration file, you’d notice a structure like the following:

The main type of the XML structure is the ObjectDefinition, which contains a Types child element and a RootDefinition element.  The Types element is where all of the definition occurs for fields of an entity, while the RootDefinition is the descriptor for the Entity.  Here you can see that Account is the root definition of our ObjectDefinition.

Inside the Types element, you’ll notice a mix of both simple and complex types:

We’ll come back to the account complex type in a moment, but for now, you can see that the types that exist in CRM are being mapped to system types that the Connector can recognize.  OptionSetValues for instance contain both a string and nullable integer value, while EntityReferences contain two strings for a name and type as well as a GUID of the referenced Entity.  Take care with this portion of the configuration file, as it should probably not be changed manually.

Now, looking into the account complex type, we see the following:

You’ll notice that each field on the entity has a representative field in our Object Provider Configuration files.

Multi-Reference Entity Lookups

Well now take a look at a very specific field type in the Object Provider Configuration file, the EntityReference type.  The field “owninguser” is just such a type:

Notice that the TypeName is EntityReference and that there are two additional attributes on the field, “LookupType” and “LookupField”.  These two attributes define what the Connector will use when referencing other entities.  In the case of “owninguser” or referenced entity can either be a systemuser or a team.  The reason two entities are listed here is that an account can either be owned by a User or a Team in this organization.  The LookupFields “domainname” and “teamid” are the fields on the referenced entity that will be used in the lookup procedure.  They must parallel the order of the values in the “LookupType”.  In this manner, “domainname” is the field used for identifying an owning User and “teamid” is the field used for identifying an owning Team.

Joe CRM
By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

PowerObjects Recommends