Microsoft Dynamics CRM. Plug-ins (plug-ins) and extensions (add-ons)
Microsoft Dynamics CRM - one of the most common CRM systems. A significant advantage of this system over competitors is the flexible ability to expand and modify, using both the internal capabilities of the system settings and external extensions. In Microsoft Dynamics CRM, it is possible to implement flexible integration functionality with external accounting systems, workflow systems, call centers, and email servers.
Quite a common situation is when the standard features of Microsoft Dynamics CRM are not enough or you cannot configure the operation of some objects or entities in the system. It happens that it is necessary to alter the behavior of certain entities, due to the specific business processes of the Customers.
In these non-trivial cases, consultants and CRM developers use plug-ins (Plug-Ins) and extensions (Add-Ons), the purpose of which and the difference between these entities we consider. When developing these software products there are also a number of limitations, some of which I will try to briefly describe.
Plug-ins (Plug-Ins) is a customizable business logic that you can integrate into Microsoft Dynamics CRM to change the standard behavior of the platform. With the help of plug-ins, the interruption and replacement of existing CRM event handlers is performed. Plugins are widely used to integrate CRM with other software systems.
Extensions (Add-Ons) are the add-ins above CRM that are being developed as separate projects, allowing for the introduction of new entities and objects, as well as new forms of modifying these entities in CRM.
')
Plug-ins usually do not have visual forms of the system's add-in. In contrast to plugins, extensions can include visual forms. Plug-ins and extensions after development are embedded in CRM.
All objects, entities and CRM structures are stored in a database. Plugins and extensions must be implemented using CRM SDK. CRM SDK is an API for developers that allows you to manage various CRM objects. Formally, it is possible to implement a direct connection to the database bypassing the CRM SDK. This can be used in plug-ins and extensions developed for internal needs. But not desirable. You cannot implement a direct connection to the Microsoft Dynamics CRM database bypassing the SDK in plug-ins that will be distributed to customers. Plug-ins and extensions that use a direct connection cannot be registered with Microsoft.
In addition, when directly connected to the CRM database, the security scheme and rights of users of Microsoft Dynamics CRM will be violated. This is due to the fact that during a direct connection to the database, the operator will have access to all the objects allowed by the database user you use for the connection.
When directly connected to the database, it is also harder to maintain event handling in CRM, which can trigger certain processes. This support is more complicated because the addition to the database is done directly to the tables. And, accordingly, the internal CRM event handlers will either fail or trigger, but not in all cases.
Plugins and extensions are a .NET assembly. To develop plug-ins and add-ons use the Visual Studio tool environment. Technology Development - ASP. As programming languages C # or Visual Basic NET. Plug-ins and extensions must be designed in a special way in accordance with the requirements of Microsoft. In this design - a lot of nuances that will affect the behavior of the application. I will focus on this in more detail in the following publications.
When developing visual forms of CRM extensions, it is necessary to make the appearance of these forms so that these forms fit into the existing CRM design, and the behavior of the components should be similar to the behavior of standard CRM components. There is some difficulty in this, since Microsoft, unfortunately, does not provide such components for developers. And, therefore, various developers independently modify the existing traditional components of the development environment, adjusting the behavior of these components to the behavior of standard CRM components. Someone from the developers get it better, and someone worse. But, users of Microsoft Dynamics CRM, in any case, are accustomed to the standard behavior of components and in their extensions it is desirable to adhere to this methodology.
If you develop plug-ins and extensions focused on multiple sales (and not for a single implementation), you will certainly have to face the issues of generating installation keys and licensing the software being developed for a certain number of users. Usually, the cost of the product depends on the number of users used by the product. In this case, two approaches are possible. In the first approach, during installation, check the number of users in Microsoft Dynamics CRM. And require the client to buy as many licenses as CRM users. The second approach is more flexible, when you first launch a plug-in or an extension by a specific user, attach the purchased license to this user. In this case, the client pays only for the licenses of those users who actually use the plugin or extension.
If it is interesting, then to be continued ...
Quite a common situation is when the standard features of Microsoft Dynamics CRM are not enough or you cannot configure the operation of some objects or entities in the system. It happens that it is necessary to alter the behavior of certain entities, due to the specific business processes of the Customers.
In these non-trivial cases, consultants and CRM developers use plug-ins (Plug-Ins) and extensions (Add-Ons), the purpose of which and the difference between these entities we consider. When developing these software products there are also a number of limitations, some of which I will try to briefly describe.
Plug-ins (Plug-Ins) is a customizable business logic that you can integrate into Microsoft Dynamics CRM to change the standard behavior of the platform. With the help of plug-ins, the interruption and replacement of existing CRM event handlers is performed. Plugins are widely used to integrate CRM with other software systems.
Extensions (Add-Ons) are the add-ins above CRM that are being developed as separate projects, allowing for the introduction of new entities and objects, as well as new forms of modifying these entities in CRM.
')
Plug-ins usually do not have visual forms of the system's add-in. In contrast to plugins, extensions can include visual forms. Plug-ins and extensions after development are embedded in CRM.
All objects, entities and CRM structures are stored in a database. Plugins and extensions must be implemented using CRM SDK. CRM SDK is an API for developers that allows you to manage various CRM objects. Formally, it is possible to implement a direct connection to the database bypassing the CRM SDK. This can be used in plug-ins and extensions developed for internal needs. But not desirable. You cannot implement a direct connection to the Microsoft Dynamics CRM database bypassing the SDK in plug-ins that will be distributed to customers. Plug-ins and extensions that use a direct connection cannot be registered with Microsoft.
In addition, when directly connected to the CRM database, the security scheme and rights of users of Microsoft Dynamics CRM will be violated. This is due to the fact that during a direct connection to the database, the operator will have access to all the objects allowed by the database user you use for the connection.
When directly connected to the database, it is also harder to maintain event handling in CRM, which can trigger certain processes. This support is more complicated because the addition to the database is done directly to the tables. And, accordingly, the internal CRM event handlers will either fail or trigger, but not in all cases.
Plugins and extensions are a .NET assembly. To develop plug-ins and add-ons use the Visual Studio tool environment. Technology Development - ASP. As programming languages C # or Visual Basic NET. Plug-ins and extensions must be designed in a special way in accordance with the requirements of Microsoft. In this design - a lot of nuances that will affect the behavior of the application. I will focus on this in more detail in the following publications.
When developing visual forms of CRM extensions, it is necessary to make the appearance of these forms so that these forms fit into the existing CRM design, and the behavior of the components should be similar to the behavior of standard CRM components. There is some difficulty in this, since Microsoft, unfortunately, does not provide such components for developers. And, therefore, various developers independently modify the existing traditional components of the development environment, adjusting the behavior of these components to the behavior of standard CRM components. Someone from the developers get it better, and someone worse. But, users of Microsoft Dynamics CRM, in any case, are accustomed to the standard behavior of components and in their extensions it is desirable to adhere to this methodology.
If you develop plug-ins and extensions focused on multiple sales (and not for a single implementation), you will certainly have to face the issues of generating installation keys and licensing the software being developed for a certain number of users. Usually, the cost of the product depends on the number of users used by the product. In this case, two approaches are possible. In the first approach, during installation, check the number of users in Microsoft Dynamics CRM. And require the client to buy as many licenses as CRM users. The second approach is more flexible, when you first launch a plug-in or an extension by a specific user, attach the purchased license to this user. In this case, the client pays only for the licenses of those users who actually use the plugin or extension.
If it is interesting, then to be continued ...
Source: https://habr.com/ru/post/96098/
All Articles