Friday, 30 May 2014

Use of String Map Table in MSCRM

Ever wonder how (or where) CRM stores the related values for pick lists or Option set ?

Answer is in String Map Table

So what is string map table actually means in CRM?
String map table basically used in MSCRM for storing the details of Option Set Fields exists in an organization. It contains all the data (Attribute Name, Option Set name, option value , option name, Object Type Code) of option set.

Let’s take one requirement to clear the use of StringMap table, requirement is like:
 “Show the incident by status Name”
like: "CAS-T4R4F-U7Y6T5" shown status as "Problem Solved"
So in this scenario if we will have no string map table then either you need records which contain all the distinct type of record by status or you need hard code value use in report query.
By String Map table you can join the table and can collect all the status present in incident and can collect records number by grouping of them.
So this type of many scenarios can be fulfill by this table

Result of Case with Status Without using Stringmap Table :

Query : select TicketNumber[TicketNumber],statuscode[Status] from incident



Result of Case with Status using Stringmap Table :
Query :
select INC.TicketNumber[Case ID],SMT.Value[Status Name], SMT.AttributeValue[Status Value]
from incident as INC inner join StringMapBase as SMT
on INC.StatusCode = SMT.AttributeValue
where SMT.AttributeName='statuscode' and SMT.ObjectTypeCode=112







Thursday, 29 May 2014

Great Reasons to Register your Plugins in Database Instead of Disk/GAC

I decided to post this article since I am hearing quite often about developers using Disk and GAC for registering the custom plugin assemblies in CRM 2011. I have also heard claims such as “you must register on disk in order to debug” or “it is easier to update the assembly version when they are stored on disk” 
which I will do my best to disprove.

1. Only database assemblies can be packaged in solutions


Solutions are the future of CRM and Microsoft is not supporting packaging disk/GAC assemblies in solutions. Such statement almost suggests that GAC and disk are legacy registration modes, and moving forward only database should be used. Take advantage of being able to export, transport and import your plugin in a solution by registering it on database. 


2. Zero service interruption to update a database assembly


If you register your assembly on disk or GAC and you would like to update it, you might be aware that even after the file is overwritten, the changes will not take effect until you do an “iisreset” which will cause down-time to your organization. Additionally, you must consider whether the plugin is asynchronous in which case you must also restart the CRM Asynchronous Processing service. Besides the down-time, there are also a number of manual steps to restart the services that you would probably want to avoid. If you register on database, all you need to do is click on “update” using the Plugin Registration Tool and update the assembly content. 


This is indeed just as fast (if not faster) than drag-drop-replace but you won’t need to restart the services because the new assembly will take effect immediately after the update! The reason why you don’t need to restart the services is that the assembly loading routine from the bytes works different in .Net. When loading from GAC or disk, the assembly is loaded in the AppDomain as is never loaded again until the AppDomain or process is restarted. Note that if you plan to debug the assembly, you still need to copy the symbols to disk (symbols cannot go in database) and you can debug as usual.


3. Simplified organization backup / import.


If your plugins are registered on disk/GAC then backing up the organization database will not be enough. You will need to also backup all the custom assemblies you might have in the GAC or in disk. When you import the organization then you must also remember to copy those dll’s back into the new server(s). However, if you use database assemblies you only need the database backup and forget about tracking down these custom assemblies in order to restore your organization.



4. Disk assemblies will not support multiple versions


In CRM 2011 there is support for assembly versioning so you can have multiple versions of a given assembly coexisting in the system. For example, the workflow designer lets you select which version of a particular assembly for a custom workflow activity you would like to use:



Because both versions of the assemblies would have the same file name then you cannot register them simultaneously on disk.


5. All assemblies consolidated into a single place


With database assemblies another good thing is that they are all stored in a single place: the database. You don’t need to worry about deploying dll’s to file and GAC in multiple servers. If your CRM deployment is spread out in different server roles for load balancing, then you don’t have to worry about which roles will need your assemblies and on what servers you must deploy which assemblies. It can be really cumbersome with disk/GAC assemblies as you can easily lose track for example of which plugins run asynchronous vs. synchronous so they must be deployed to the web and async servers respectively.


6. Sandbox and CRM Online only support database assemblies


If you have your assemblies registered on database, you could include them in a solution. Therefore, you can easily migrate to CRM Online by exporting/importing the solution and you can mark your assemblies as sandboxed. You would not be able to sandbox your assemblies for disk/GAC and you would not be able to package them to migrate to CRM Online.

When should I Use Disk mode to register Plugin/Workflow ?????????

only put a plugin on disk if you want to remote debug it because you then need to put the dll and the pdb file on the server.

How to Debug Custom Workflow Activity and Async Plug-In in MSCRM

One of the most common requirement while developing, testing and/or troubleshooting is the ability to debug our code. This is not an exception in the case we are developing a Dynamics CRM plug-in or workflow assembly.
Hence, I decided to briefly describe here steps to debug your code in MSCRM which might be either Sync Plug-In or A Sync Plug-In or Custom Workflow

To debug a Custom Workflow Activity Follow below steps :
  1. Copy the .pdb file for the assembly to the %installdir%(c:)\server\bin\assembly or 
  2. C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly

  3. folder. The assembly can be deployed as on-disk or stored in the database. The recommended deployment is in the database, but for debugging you should choose on-disk. 
  4. Next, attach the debugger to the CrmAsyncService.exe process. 
  5. Make sure that you remove the .pdb & .dll file when you have finished debugging because it uses memory to have it loaded.

To debug a Asynchronous Plug-In Follow below steps :
  1. Firstly Build Plug-in solution
  2. Register it on Plug-in registration tool
  3. Go to Plug-in solution in Visual Studio 2012
  4. Add Debugger at specified location within code.
  5. Attach process from Tools >Attach To Process > CrmAsyncService.exe(both) > OK
  6. Perform action for debugging Plug-in Solution

To debug a Synchronous Plug-In Follow my below post :

 http://arpitmscrmhunt.blogspot.in/2014/04/how-to-debug-plugin-in-mscrm-2011-on.html


Note : 
Make sure that you remove the .pdb and .dll file when you have finished debugging because it uses memory to have it loaded and it will give "Plug-In assembly could not be loaded" error while you import Plug-In Solutions from one organisation to other have different Database.
To Import Plug-In solution from Organisation1 to Organisation2(both have different database) make sure all the plugins of Organisation1 must be in Database



Hope it will help someone to debug Plugin & Workflows :)


Wednesday, 28 May 2014

Retrieve N:N relationship records by Query Expression in MSCRM

Sometimes we have requirement to get records from N: N relationship. So today I would like share how we can get these relationship records by query expression in code. When we create N: N relationship between 2 entities, it creates an intermediate entity (i.e., Relationship Entity) . Below screen shot showing N:N relation between account and marketing list.
for details attribute you can see the database table with same relationship entity name as here is “contactleads
Contact Lead N:N Relationship 



contactleads(Intersect Entity) fields in DB


I am taking example of existing  2 entities “Contact” and “Lead” with N:N association as above screenshot showing . Because an Contact can be in multiple Leads or Vice-Versa
for e.g we have requirement to get all the ‘Leads’ which the Contact with name “Arpit Shrivastava” is associated . for this query code viz:
string entity1 = “Contact”;
string entity2 = “Lead”;
string relationshipEntityName = “contactleads”;


Private  EntityCollection getM_to_M_Record(string entity1 ,string entity2, string relationshipentityName)
{
QueryExpression query = new QueryExpression(entity1);
query.ColumnSet = new ColumnSet(new string[]{"firstname"});
LinkEntity linkEntity1 = new LinkEntity(entity1, relationshipEntityName, “contactid”, “{Entity 1 Primary field}“, JoinOperator.Inner);
LinkEntity linkEntity2 = new LinkEntity(relationshipEntityName, entity2, “lead”, “{Entity 2 Primary field}“, JoinOperator.Inner);
linkEntity1.LinkEntities.Add(linkEntity2);
query.LinkEntities.Add(linkEntity1);
// Add condition to match the Contact Name with “Arpit Shrivastava”
linkEntity2.LinkCriteria = new FilterExpression();
linkEntity2.LinkCriteria.AddCondition(new ConditionExpression(“firstname”,ConditionOperator.Equal, “Arpit Shrivastava”));
EntityCollection recordcollection= service.RetrieveMultiple(query);
return recordcollection ;
}

Show ASPX Grid inside IFrame in MSCRM 2011

Today I am going to show one interesting thing that i have recently done in MSCRM. Hope it will help someone in any scenario.

Recently I got one requirement to call one of the web service (Search API), which will return number of Customer records stored in other Database(Not in MSCRM DB) based on some input like Name, Email ID, Mobile No, Head of Family, State etc.
Then Select only one record(actual record) from the number of records and create Contact of the same in MSCRM.

Visual Representation of Requirement :








Implementation in MSCRM:

APPROACH ?
We should use grid inside Contact form which will contain Fields to take Input Search Parameter and Grid to show searched record provided by 'Search API'.
Show Aspx Page inside MSCRM Contact form would be the best approach to do this task.Do you have any other optimize approach for the same it would be welcomed

WHY this Approach ?
We cannot do this task using MSCRM itself. Since to show searched record coming from API, we need to store in MSCRM DB first without storing in DB it is not possible to show in MSCRM platform either in Sub Grid or in Grid. Because both itself a Entity in MSCRM.
Data coming from API might contains multiple records for entered Input parameter, some of records might be useless. For Example - i have searched 'Arpit' as name. 'a@gmail.com' as EmailID, '8787874785' as Mobile No etc, it might possible API return 5 records for the same. but among 5 record only 1 record is mine and rest of records are useless, so there is no need to keep these record in MSCRM DB

Step 1:   Create I Frame in Contact Form. Host C# Web Application in IIS and give URL inside I Frame.Make sure 'Restrict Cross-Form Scripting' must be unchecked to avoid aspx page redirect to another window as shown below:
























Step 2:  Click on Search Button from Ribbon, aspx Grid inside I Frame will get highlighted. Type Input Parameter to search Customer Record




Step 3: Select Customer Record


















Step 4: Create Contact of selected Record 





Cheersssssssss :) :)

Sunday, 25 May 2014

Overview of Entity in MSCRM

Entities Overview – Microsoft Dynamics CRM

Entities form a vital piece of the Microsoft Dynamics CRM framework. Essentially, entities are used to model and manage business data. Some common entities that most Dynamics CRM users are familiar with are Account, Case, Campaign, Contact, Lead, and Opportunity. These entities deal with many of the most common sales, service, and marketing data with which a CRM user frequently engages.


Types of Enity in MSCRM


There are three main types of entities: system, business, and custom. In Dynamics CRM, system entities handle internal processes such as workflows. It is important to note that system entities cannot be deleted or customized. Business entities are the default entities within Dynamics CRM which include Case, Account, and Opportunity. One of the most important elements in Microsoft Dynamics CRM is customization. Custom entities provide organizations with a way to meet their needs head-on. One example of this is that you can create a vendor entity if you are a retail business and then dictate how it relates to different entities within your organization. Since each entity supports a variety of actions, streamlining communications processes among est your organization is now an attainable goal.



Entities Ownership – Microsoft Dynamics CRM

Ownership is a key factor in how entities work. In Microsoft Dynamics CRM, most entities have an owner, which is determined by the ownership type. There are four ownership types in CRM: organization, business, user, and none. Organization-owned entities can be accessed by an entire organization. These records cannot be assigned to an individual owner (or shared). Business-owned entities belong to a Business Unit, while user-owned entities are owned by one specific CRM user and typically contain customer-related data. Accounts, Contacts, and Cases are examples of user-owned entities. A few entities in Dynamics CRM have no ownership type. They are not owned by another entity (user, business unit, or organization) within CRM.
The following table lists the complete ownership types:
Ownership TypeDescription
Organization OwnedOrganization-owned entities typically contain data involving something that belongs to or that can be viewed by the whole organization. Organization-owned entities cannot be assigned or shared. For example, products are owned by the organization.
Business OwnedBusiness-owned entities belong to a business unit.
User OwnedUser-owned entities are associated with a user. User-owned entities typically contain data that relates to customers, such as accounts or contacts. Security can be defined according the business unit for the user.
NoneThe entity is not owned by another entity. For example, the uom (unit-of-measure) and workflowlog (workflow log) entities are not owned by another entity.

Relationship Behavior in MSCRM

In Microsoft Dynamics CRM you can create different types of relationships. Below are the relationships that can be created:
1.     1:N
2.     N:1
3.     N:N
In a relationship you can configure relationship behaviors. Below are the different relationship behaviors that can be configured in CRM:






1.     Parental
In parental relationship, any action taken on the parent record is also taken on the child entity record.  For example if the parent record is shared with a user, all the child records will also be shared with the same user.

2.     Referential
In a referential relationship, the action taken on the parent entity record will not impact the child entity record

3.     Referential, Restrict Delete
In a referential, restrict delete relationship, the action taken on the parent record will not impact the child entity record but you cannot delete the parent record until the parent record exists

4.     Configurable Cascading

Configurable cascading allows the user to choose the behavior they want to be apply. Below are the behaviors that can be configured:

·        Cascade All – This behavior performs an action on all the related child records. For example if my opportunity is assigned to an another user then all the child records should be assigned to the same user

·        Cascade None – This behavior performs no action on the child records

·        Cascade Active – This behavior performs action only on the active records

·        Cascade User- owned – This behavior performs action on the child records which are owned by the same user as parent

·        Remove Link – This behavior only removes the link for the child record without modifying anything on the record.

Cheersssss :) :)

Saturday, 24 May 2014

What's new in MSCRM 2013.

With all the hype and boom around the new version of Microsoft Dynamics CRM 2013 release, let’s take a look at a comparison of what features and functionalities between current version (CRM 2011) and the new version (CRM 2013).  Hopefully, the differences will you help decide if upgrading to CRM 2013 is worth the investment.
Here I am going to show some screens of MSCRM 2013 new features which can understand you much better :

1.  New Navigation Model 




2.  Quickly Accessable




3.  Excellent Form Structure and Design


4.  Enter Data 'On-The-Fly' with Quick Create



6.  New Command bar



7. Work Anywhere,AnyHow



Wednesday, 7 May 2014

Bye-Bye Succeeded System Jobs at One-Click to Improve CRM System Performance

Fortunately, in CRM 2011 there is a simple one-click solution that helps maintain the size of the AsyncOperationBasae table. If you open your workflow definition and go to the Administration tab, you will find the “Workflow Job Retention” option. If you click on the checkbox, it means that every time this workflow job is executed AND if it succeeds, the system job will be deleted. 

Selecting that option is perfect for processes that you don’t need to audit and you just need the logic to execute. However, if you need to keep a history of which workflows have executed on which records you should not select this option to delete the workflow job on completion (note that this option is disabled by default).

Setting to Auto Delete Succeeded System Jobs :


For Workflows :

If you open your workflow definition and go to the Administration tab, you will find the “Workflow Job Retention” option, under this you will see option to check “Automatically delete completed workflow jobs (to save disk space)”, 


For Asynchronous Plug-In:

if you want plug-in related system jobs automatically deleted when the status is successful. (Note that this option is disabled by default for all asynchronous plugin steps).

In case If your AsyncOperationBase table becomes too large in Microsoft Dynamics CRM, you can follow my below post to reduce the size.

http://arpitmscrmhunt.blogspot.in/2014/04/clean-up-asyncoperationsystem-jobs.html


Blogger Widgets