witch one is better having a plugin per entity with an SDK for common functions or creating specific plugins and generic plugins with multiple steps for multiple entities just to avoid redundancy ?
*This post is locked for comments
You need to design the plugin considering the existing functionality. For example if you have a workflow (Async) which updates the status to say In Progress. Then if you wrtite a plugin (sync) to change the status to Draft then it won't work as when the workflow runs it will change the status back to In Progress.
So before implementing any custom logic (be it plugin, workflow etc), you need to review the current implementation and design based on that.
@Ravi Kashyap then how do you manage that confilct? , or a plug per entity would be recomanded in this case
Hi,
"doesn’t that mean that we could have some plugin interfering with the work of others? " - Yes and this happens lot of the time not only with custom plugin but with OOB plugins as well. I have seen spo may cases now where we have custom plugin on quote/quote details for the tax calculate which are interfering with Dynamics.Sales.Plugin OOB plugins.
@Mohamed HAJJI: No switch statements. While they are, like any other control structure, useful in certain scenarios more often than not, they are abused. The Case Management plugin is specifically for any actions on the Case entity.
So, I wouldn't have any switch statements (I wouldn't write code with any switch statements if I can help it) on entity. I am assuming that you meant switch based on attributes? If so, no...that is an almost bad idea unless the change of two different attributes triggers the exact same business logic.
In my example, I have OnCaseTypeUpdate.cs - this is a plugin class which will be triggered only when the case type field is updated. If I wanted functionality on update of classification field of the Case entity, I would rather have a plugin class called OnCaseClassificationUpdate unless you want the exact same logic to be executed on update of either field (but then again, if you wanted some additional custom logic, you run into the same problem of creating plugin class for update / create mentioned above).
- Sara
Sara W Ellis, sorry i didn't specify , i was talking about entity dependent actions (like update a specific field when this happened ...) , i'm assuming that for the Case Management Plugin you have a switch base on entity sometimes?
if yes my second question would be why separate by action and not by entity for example?
Ravi Kashyap if we sort plugins by common Requirement, doesn’t that mean that we could have some plugin interfering with the work of others?
Hi,
As you have mentioned Common Requirement, it is better to go for the single plugin. However, If you have some common requirement which you think can be reused across multiple entity then you can go for Custom Workflow Activity. This is one of the criteria I revisit to decide between Plugin & Custom Workflow. The advantage of CWA is that you could have input / output parameters and non technical users can also use it without having to connect to PLT and registering new steps. More control with respect to maintenance.
Hope this helps.
This is a largely subjective question and I do not think there is any one correct answer.
Here is a scenario.
Requirement #1: Document Management System
Requirement #2: Case Management
You can design them as two different plugin assemblies, one for Document Management System and other for Case Management. The Document Management System assembly, will contain a plugin for each of the requirements. Similarly, the Case Management will contain a different plugin assembly with a plugin for each of the requirements.
I would generally have one plugin assembly but separate plugin for Create / specific Updates / status change (split them into - one for close and one for reactivated?...or is that taking it too far? :-) ). My plugin folder will look something like this
-Plugins
|--Case Management Plugin
| |--OnCaseCreate.cs
| |--OnCaseTypeUpdate.cs
| |--OnCaseClose.cs
| |--OnCaseReactivated.cs
| |--OnCaseAssigned.cs
|--Document Management Plugin
| |--OnCaseCreateRefreshDMS.cs
| |--OnCaseTypeUpdateRefreshDMS.cs
| |--OnCaseCloseRefreshDMS.cs
| |--OnCaseReactivatedRefreshDMS.cs
| |--OnCaseAssignedRefreshDMS.cs
I haven't listed the other folders (CrmPackage) / and files Entities.cs, but you get the idea.
The general thumb rule (in my opinion, based on how CRM is organized - i.e., within Sales you have Opportunity, Quotes, Orders, Invoices etc., and within Service you have Case, Entitlements etc., ) is to segregate by entity and then by functionality to identify how many plugin assemblies you require. Within the plugin assemblies, I would keep the triggers as isolated as possible. There is little point in combining a Create and Update (yes, there are scenarios when a lot of is just common code) in the same plugin class, only to realize a month later that you need to start writing statements such as
Share
Report
All responses (
Answers (
if (localcontext.PluginExecutionContext.MessageName.ToLower() == "create")
{
//Do specific functionality for create
}
else
{
//Do functionality for update
}
//Continue with common functionality.
Instead, just put the common functionality in a Shared Library and call them from within the two plugin (classes).
However, there is always generic functionality, but that should be ideally entity agnostic.
For instance, if you have a requirement to send emails (use workflows!) for when one of these entities is created and set the regarding to that particular record, then create
Hope that helps.
-Sara
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,280
Super User 2024 Season 2
#2
Martin Dráb
230,235
Most Valuable Professional
#3
nmaenpaa
101,156