All about Plugins

Q. What is Execution Order in Plug-in Registration tool?

Execution order in plugin specifies the order in which plug-ins are executed within a pipeline stage. Plug-ins registered with an order value of 1 are executed first, followed by plug-ins registered with an order of 2, and so on. However, if there is more than one plug-in in a stage with the same order value, then the plug-in with the earliest compilation date is called first

What is the difference between PreImage, PostImage, Target Entity?

In a plug-in there are potentially several ways to access entity data relevant to the plug-in action. For example, on the create message you can access the data on the new entity instance in one of the following ways:

1. Via the Target InputParameter
2. Via an Image Entity registered on the step

Via a Retrieve request in the plug-in code

Availability of the data by stage

The general rules are:

1.       InputParameter is available in all stages. It can be modified in the pre-stage, but changing it in the post-stage will have no effect

2.       A PostImage Entity is available in the post-stage, and a PreImage Entity in the pre-stage only

3.       If using a Retrieve in the plug-in, then the data returned depends on the stage. In the pre-stage, you will see the data before the modification, whereas in the post-stage you see the data after the modification

4.       Some Image Entities are not relevant for some messages - e.g. there is no PreImage for a Create message, and no PostImage for a Delete message

1. All the plug-in events are first stored in  variable called “Target”.

Target  entity available on all steps and contains entity passed in the request message. Target entity can update on Pre-stage and those changes will be post into the database. Changes on Post-stage don’t affect database.

2. Pre-image, you get the image of the record as is stored in the SQL database before the CRM Platform action has been performed.

Post Image, returns the image of the record after the CRM Platform action has been performed. 

PreEntityImages and PostEntityImages contain snapshots of the primary entity's attributes before and after the core platform operation. Following tables describes PreImage, PostImage availability:

	Pre-Image		Post-Image
	Pre	Post	Pre	Post
Create	No	Yes	No	Yes
Update	Yes	Yes	No	Yes
Delete	Yes	Yes	No	No

Note. Target entity only contains attributes platform needs to update.

JavaScript in MS CRM 2013/2015

Get current entity name

var entity = Xrm.Page.data.entity.getEntityName();

Disable the field

Xrm.Page.getControl("telephone1").setDisabled(true);

Hide field

Xrm.Page.getControl("telephone1").setVisible(false);

Get value from one field and set to other field

var phone = Xrm.Page.getAttribute("telephone1").getValue();

    

        Xrm.Page.getAttribute("fax").setValue(phone);

Get Current User Role

Xrm.Page.context.getUserRoles();

Hiding tab
Xrm.Page.ui.tabs.get(tabindex).setVisible(false);
or
Xrm.Page.ui.tabs.get("tabname").setVisible(false);

Showing tab
Xrm.Page.ui.tabs.get(tabindex).setVisible(true);
or

Xrm.Page.ui.tabs.get("tabname").setVisible(true);

Create Custom entities in MS Dynamics CRM 2015 online

1. On the  navigation pane of CRM, click on the Settings --> Customizations --> Customize the system(Also can proceed from custom solution)
2. Click the Entities node in the solution explorer and then click New in the menu bar.

3. Complete all required fields Display Name, Plural Name and Name.

    

4. Select whether the entity will be owned by a user or team/organization

5. Select Areas that display this entity section, select Sales and Marketing.

6. Click Save and Close to close the new entity form.

7. Publish the customization. Entity will be seen under Sales and Marketing.

Show MS CRM Account details in grid view of Asp.net

Hi,

Here is a code to show account details from Dynamics CRM online 2015 to gridview of ASP.Net through late binding.

Add new web form and add one gridview to design form.

 Now add code to code view.

protected void Page_Load(object sender, EventArgs e)
        {
            IOrganizationService service = GetCRMService();
            QueryExpression query = new QueryExpression("account");
            query.ColumnSet.AllColumns = true;
            EntityCollection ecollection = service.RetrieveMultiple(query);

            DataTable dt = new DataTable();
            dt.Columns.Add("name");
            dt.Columns.Add("accountid");

            foreach (Entity entity in ecollection.Entities)
            {
                DataRow dr = dt.NewRow();
                dr["Name"] = entity.Attributes["name"].ToString();
                dr["accountid"] = entity.Attributes["accountid"].ToString();
                dt.Rows.Add(dr);
            }
       
            gridViewAccountName.DataSource = dt;
            gridViewAccountName.DataBind();
        }


        public IOrganizationService GetCRMService()
        {
            string orgUrl = "https://XXXX.api.crm5.dynamics.com/XRMServices/2011/Organization.svc";
            Uri OrganizationUri = new Uri(orgUrl);
            IOrganizationService service;
            ClientCredentials credentials = new ClientCredentials();

            credentials.UserName.UserName = "XXX@XXXXXXXX.onmicrosoft.com";
            credentials.UserName.Password = "XXXXXXXXX";
            try
            {
                using (OrganizationServiceProxy serviceProxy = new OrganizationServiceProxy(OrganizationUri, null, credentials, null))
                {
                    serviceProxy.EnableProxyTypes();
                    service = (IOrganizationService)serviceProxy;
                                   }
            }
            catch (Exception ex)
            {
                throw ex;
            }
            return service;
        }

The result is like below:

name	accountid
vdvzsdf	ae87e930-d691-e511-80fa-3863bb345bf8
Fourth Coffee (sample)	1af02229-5582-e511-80fe-3863bb347758
Litware, Inc. (sample)	1cf02229-5582-e511-80fe-3863bb347758
Adventure Works (sample)	1ef02229-5582-e511-80fe-3863bb347758
Fabrikam, Inc. (sample)	20f02229-5582-e511-80fe-3863bb347758
Blue Yonder Airlines (sample)	22f02229-5582-e511-80fe-3863bb347758
City Power & Light (sample)	24f02229-5582-e511-80fe-3863bb347758
Contoso Pharmaceuticals (sample)	26f02229-5582-e511-80fe-3863bb347758
Alpine Ski House (sample)	28f02229-5582-e511-80fe-3863bb347758
A. Datum Corporation (sample)	2af02229-5582-e511-80fe-3863bb347758
Coho Winery (sample)	2cf02229-5582-e511-80fe-3863bb347758
Adventure test cycle	7668e02f-238d-e511-80f4-3863bb36ef98

Workflow Vs JavaScript Vs Plugin comparison MS Dynamics CRM

	Workflow	JavaScript	Plugin
Synchronous	Asynchronous	Synchronous	Either
Can Get External Data	No	Yes	Yes
Maintenance	Business Users	Programmers	Programmers
Can Run As	User	User	CRM System
On Demand	Yes	No	No
Nested Child Process	Yes	No	Yes
Executed After Saving	After	Before	After
Triggers	Create, Field Change, Status Change, Assign to Owner, On Demand	Field change or Form Load	Create, Field Change, Status Change, Assign to Owner, Delete

What are different stages used in Plug-In registration?

Event	Stage name	Stage number	Description
Pre-Event	Pre-validation	10	Stage in the pipeline for plug-ins that are to execute before the main system operation. Plug-ins registered in this stage may execute outside the database transaction. Security Note The pre-validation stage occurs prior to security checks being performed to verify the calling or logged on user has the correct permissions to perform the intended operation.
Pre-Event	Pre-operation	20	Stage in the pipeline for plug-ins that are to execute before the main system operation. Plug-ins registered in this stage are executed within the database transaction.
Platform Core Operation	MainOperation	30	In-transaction main operation of the system, such as create, update, delete, and so on. No custom plug-ins can be registered in this stage. For internal use only.
Post-Event	Post-operation	40	Stage in the pipeline for plug-ins which are to execute after the main operation. Plug-ins registered in this stage are executed within the database transaction.

Difference between CRM Discovery Service and CRM Metadata service?

CRM Discovery Service:

A single Microsoft Dynamics CRM installation can host multiple organizations on multiple servers therefore it is important to specify which organizations need to be accessed. The Discovery Web service returns a list of the organization the specified user belongs to and the URL endpoint address for each organization. It will only give organization related information.

CRM Metadata service

It is specific to CRM records. Use to interact with entities and attributes like create, update or delete, retrieve or add value to pick list. It holds information about entities and attributes.

• An index in a book is Metadata, it helps you categorise/segment the information
• Metadata is the characteristics of the data e.g. data type, length, description
• It can show the relationships between data
• Metadata allows efficiently classify and a structured way to organise data for ease of use

Use the IOrganizationService web service to read and write data or metadata.

One of the common uses for Metadata is to retrieve the string value of an optionset.  OptionSets are stored in the CRM database as Int numbers and the string values are in the Metadata.

Security concepts for Microsoft Dynamics CRM

Microsoft Dynamics CRM uses security model to protect the data integrity and privacy in or organization and also supports efficient data access and collaboration.

The goals of the model are as follows:

• Support a licensing model for users.
• Provide users with access only to the appropriate levels of information that is required to do their jobs
• Categorize users and teams by security role and restrict access based on those roles.
• Support data sharing so that users can be granted access to objects they do not own for a one-time collaborative effort.
• Prevent access to objects a user does not own or share.

Role-Based Security:

It use to group sets of privileges together into roles that describe the tasks that can be performed by a user or team. Microsoft Dynamics CRM includes a set of predefined security roles, each of which is a set of privileges which combine to make security management easier. The bulk of the privileges define the ability to create, read, write, delete and share records of a specific entity type. Each privilege also defines how broadly the privilege applies: at the user level, business unit level, the entire business unit hierarchy or across the entire organization.

For example, if you sign in as a user that is assigned the Salesperson role, you have the privileges to read, write and share accounts for the entire organization, but you can only delete account records that you own. Also, you have no privileges to perform system administration tasks such as install product updates, or to add users to the system.

A user that has been assigned the Vice President of Sales role can perform a wider set of tasks (and has a greater number of privileges) associated with viewing and modifying data and resources than can a user who has been assigned to the Salesperson role. A user assigned the Vice President of Sales role can, for instance, read and assign any account to anyone in the system, while a user assigned the Salesperson role cannot.

There are two roles that have very broad privileges: System Administrator and Customizer. Use of these two roles should be limited to a few people in your organization. Each deployment can also customize existing roles and create its own roles to meet their needs.

Record-Based Security

You can use record-based security to control user and team rights to perform actions on individual records. This applies to instances of entities (records) and is provided by access rights. The owner of a record can share, or grant access to a record to another user or team. When this is done, they must choose which rights they are granting. For example, the owner of an account record can grant read access to that account information, but not grant write access.

Field-Based Secuirty

Access rights apply only after privileges have taken effect. For example, if a user does not have the privileges to view (read) account records, they will be unable to view any account, regardless of the access rights another user might grant them to a specific account through sharing.

You can use field-level to restrict access to specific high business impact custom fields in an entity only to specified users or teams. Like record-based security, this applies after privileges have taken affect. For example, a user may have privileges to read an account, but can be restricted from seeing specific fields in all accounts.

Deployment-wide administrative-level security

During installation, Microsoft Dynamics CRM Server Setup creates a special deployment-wide administrator role and attaches it to the user account that is used to run Setup. The Deployment Administrator role is not a security role and does not appear in the Microsoft Dynamics CRM web application as such.

Deployment Administrators have complete and unrestricted access to all organizations in Deployment Manager in the deployment. For example, Deployment Administrators can create new organizations or disable any existing organization in the deployment. On the other hand, members of the System Administrator Role only have permissions where the user and security role are located.

Microsoft Dynamics CRM Extensibility Architecture

                                                                             Microsoft Dynamics CRM Extensibility Architecture

WCF Web Services

Microsoft Dynamics CRM provides a dynamic Web service interface for applications to use to access and manipulate platform data, metadata, and to interact with platform services, implemented using the Windows Communication Foundation (WCF). These services allow you to write .NET applications using Microsoft Visual Studio or non-.NET applications using other developer tools by simply referencing the Web services. The Web services exposed by the platform are WSI BP 1.1 compliant. This compliance support makes the Web services interoperable with non-Microsoft platforms. 

Processes (formerly Workflows)

The process feature supports extending the functionality of the Microsoft Dynamics CRM system by enabling the user to create and execute custom business processes. A Microsoft Dynamics CRM process is built on top of Windows Workflow Foundation, which provides the programming model, run-time engine, and tools for quickly building processes. This includes XAML processes and custom process activities (.NET assemblies). There are two categories of processes in Microsoft Dynamics CRM: workflows and dialogs.

Plug-ins

Microsoft Dynamics CRM provides an extension mechanism for implementing validation and custom platform-based business logic. You are not limited to creating custom business logic through workflow processes alone. You can also construct business logic that is integrated with Microsoft Dynamics CRM and executes in response to a particular system event for a specific entity.

Plug-ins support an event handler interface that is based on a pipeline execution model. The pipeline model allows for event handlers, also known as plug-ins, to be executed before or after the core operation of the system. When an action occurs caused by user interaction with the Web application or a Web service call, the platform checks for registered event handlers. If a handler is registered for notification, the platform executes a well-defined event handler method, passing it run-time information.

Reporting

Microsoft Dynamics CRM includes reports that provide useful business information to the user. You can use these reports as templates for creating your own custom reports using Microsoft SQL Server Reporting Services Report Builder. You can also use filtered views to create custom reports within Microsoft Dynamics CRM and directly in Microsoft Office Excel and Microsoft Access. There are two types of reports in Microsoft Dynamics CRM: SQL-based reports and FetchXML-based reports.