Archives

Archives / 2018 / August
  • Things to Consider for Plug-in Deployment

    At the time of Plugin Assembly Registration, you can specify about Plug-in Deployment.

    • Firstly, you need to identify the deployment type i.e., CRM Online or CRM On-Premise.
      • For CRM Online, plug-in assemblies must be registered in Sandbox.
      • For CRM On-Premise, plug-in assemblies can be registered in Sandbox or outside the Sandbox (select radio box None).
    • If the isolation mode is Sandbox, the location is always Database, the advantage is that plug-ins stored in the database are automatically distributed across multiple CRM servers in a data center cluster.
    • The disadvantage is that you can't install external assemblies to the database, so if your plug-in uses an external assembly you need to merge it with your plugin assembly before the registration or deploy the external assembly manually to the GAC or the CRM bin folder.
    • If you register plugin assembly outside the Sandbox (i.e., CRM On-Premise), you can choose to deploy it to the GAC. In this case, the advantage is that you take full advantage of the GACs versioning system preventing conflicting versions of the same assembly, if multiple versions are needed. The disadvantage is that the registration requires gacutil.exe and this can be an issue for some deployments.
    • If you choose to deploy to Disk, the plug-in assembly will be copied to the CRM bin folder. In this case, the debug will be easier, but you will lose GAC versioning advantage that is available by deploying plug-in assembly in the database.

    Need help in CRM Plug-in Deployment? Talk to our CRM experts now. You can write to us at salesteam@mtccrm.com. 

  • What is Secure and Unsecure Plug-in Configuration?

    Microsoft Dynamics CRM provides two different configuration fields for plug-ins, namely Secure Configuration and Unsecure Configuration.

    Use Secure Configuration, when a setting is sensitive and shouldn’t be readable by any CRM user or if you don’t want that setting to be moved between environments while importing/exporting solutions.

    Secure configuration is only viewable by CRM Administrators while the Unsecure Configuration is viewable by any CRM user. Also, unsecure configuration will automatically move between environments with your CRM solutions while it is not the case in secure configuration.

    How to Handle Exceptions in Plug-ins?

    Handling exceptions means establishing alternate ways to continue the flow of a program.

    • The exception message for asynchronous registered plug-ins is written to a System Job.
    • For synchronous plug-ins, you can optionally display a custom error message in the error dialog of the web application by having your plug-in throw an InvalidPluginExecutionException with the custom message string as the exception Message property value.
    • For asynchronous plugins, no error is prompted to the user.
    • If there are any exceptions in plug-ins, the code will execute in database and the plugins will rollback. So, exception handling needs more attention.
    • In plug-in code, you need to place below lines of code to catch the exception thrown by plugins.

       catch (FaultException ex) 
       {

        throw new InvalidPluginExecutionException("Err occurred.", ex.Message);

       }

    • Plug-in trace log in Dynamics CRM, which made for debugging a plugin.
    • The Plug-in trace log feature saves trace log information with the advantage that trace log information will be available even when the plug-in doesn’t throw an exception

    Need help in CRM Plug-in Development? Talk to our CRM experts now. You can write to us at salesteam@mtccrm.com. 

  • Event Pipeline, Pre-Images & Post-Images in Dynamics CRM

    Event Pipeline: The even pipeline allows you to configure when in the event the plug-in code will execute. There are 3 Event Pipeline stages namely, Pre-Validation, Pre-Operation, and Post-Operation.

    Pre-Validation: In the pre-validation stage, security checks are performed to verify whether the calling or logged on user has the valid permissions to perform the intended operation.

    Pre-Operation: Plug-in will run after validation and before the values are saved in the database.

    Post-Operation: Plug-in will run after the values have been inserted or changed on the database.

    Pre-Images & Post-Images?

    Entity images are snapshots of CRM records that are stored on database either before the database operation is completed or after the completion of database operation.

    Pre-Image:

    It is the snapshot of the entities’ attributes data before saving on the database. The following image shows pre-image availability.

    Post-Image:

    It is the snapshot of the entities’ attributes data after saving on the database. The following image shows post-image availability.

    Pre-Image & Post-Image Example:

    Whenever a parent account field is updated on the account entity, we want to retrieve the old value of the field and update in pre-value field.

    Register a plug-in in account entity and register a step update account name field and select stage as post-operation.

    Register an image step on update step. Give some names to pre-image and post-image checkbox Select attribute to display pre and post image values.

    Example Code for Pre-Image and Post-Image

    Here we update the account name and parent account.

    Pre-Image value updated with parent account value and Post-image value of phone field updated with postvalue of parent account field.

    Need help in Microsoft Dynamics 365/CRM Plug-in development? Contact salesteam@mtccrm.com.

     

  • Workflows vs. Plug-ins

    S.NO

    Workflows

    Plug-ins

    1.

    Workflows have limited events like create, update, send mails, etc.

    Plug-ins have more events

    2.

    Synchronous plug-ins can increase the platform’s response time because they are part of the main platform processing.

     

    Asynchronous plug-ins have less impact on server response time because the code is run in a different process.

    Less impact on server response time because the code is run in a different process.

    3.

    Workflows can be created by an end user who may not have developer skills.

    Plug-ins can be created developers only because it needs coding and developer skills.

    4.

    Workflows triggered automatically run under the security context of the workflow owner.

     

    Plug-in execute under the security context of the crm web application pool identity.

     

    5.

    Works well for either short or long processes.

    A plug-in registered for synchronous or asynchronous execution is restricted to complete its execution within a 2 minute time limit. 

    6.

    When the Microsoft Dynamics CRM for Outlook client is offline, Workflows do not execute.

    Plug-in works in both offline and on-line.

    7.

    Workflows cannot use impersonation.

    Plug-ins can perform data operations on behalf of another system user.

  • What is Shared Variable in Plug-in?

    A Plug-in is a custom business logic code which is used to execute an action when a particular event takes place. It acts as event handlers in CRM and is triggered in events like create, update, delete, etc. Plug-ins are used to automate processes like sending emails to customers when some events take place in CRM.

    Shared Variables in Plug-in:

    Shared Variables in Plug-in was introduced in CRM 4.0. Shared variables are used for passing data between plug-ins registered on both pre and post events. So, instead of storing values in custom attributes, they can be stored in context variable. Read and write data into shared variables of context.

    Real-time Shared Variables Business Scenario:

    In the invoice entity, we wanted to change the exchange rate field but couldn’t do it because we were unable to change the value of base currency. So, we decided to use shared variables to change the exchange rate field of the invoice entity.  Let’s see how it’s done.

    Add a data into shared variable context in plug-in.

    And the below code shows shared variable data used in another plug-in.

    After completing plug-in registration in CRM, register a new step, i.e., select update event and primary entity as invoice and select pre-operation.

    Register a new step into another plug-in, i.e., select retrieve exchange rate event &primary entity as transaction currency and select post-operation.

    Do you have any requirement for CRM Plug-ins? Get help from experts. Contact salesteam@mtccrm.com now!