CRM Plugin Constants / Key Value Pair Web Config Strategy

(0) Share

Report

Posted on by Community Member

Hi,

In our CRMPlugins solution, we have a Constants.cs class that defines the following constants:

Guids
Picklist values as enumerations
Role names
Email addresses
IsTesting booleans
API keys
URL root bases
Connection strings
Directory paths
Environment indicator (dev, staging, live)
Other constants

Instead of having to re-deploy the project after changing a constant, we would like to control these constants outside of the project. One route is to use an entity that would contain the key and value pairs similar to what a web.config does.

If at any point we need to use a constant, we would just make an SDK call for that value. What if we need to retrieve a lot of key/value pairs? That's a lot of calls. Instead, we can load all of the records. It wouldn't be that many (max 100 records containing 2 attributes).

Questions:

Would you recommend that I create a SDK call in our base plugin class to retrieve all key/value pair records and set it to a dictionary accessible anywhere in the main plugin execute method or any of its sub-classes?
Is it possible to cache the record values in the context once every amount of time (30min, hourly)?
- This way just do one retrieval that all plugins can use

Please answer the two above questions so that I can eventually mark your answer as the best answer :).

Thank you for taking the time to read this thread and reply to it!

*This post is locked for comments

All responses (3)

Answers (1)

Suggested answer

Community Member on at

Like (0)

Report

RE: CRM Plugin Constants / Key Value Pair Web Config Strategy

Hi Anatoly,

i use a file like yours, filled with static values, shared "as link" with all plugins.

No need for cache or retrieve: never had a problem.

Hope it helps.

If you found the answer helpful, please mark as Verified

Join my network on LinkedIn Follow me on Twitter

Thank You & Best Regards

Francesco Picchi

Microsoft Dynamics CRM Consultant, Bologna+Milano, ITALY

Independent Contractor

http://www.francescopicchi.com
Suggested answer

ashlega 34,477 on at

Like (0)

Report

RE: CRM Plugin Constants / Key Value Pair Web Config Strategy

Hi,

if you use a static cache, for example, there will be no way to invalidate it (and, also, it'll be a copy of that cache on every sandbox).

Most likely, you'll just have to query configuration data for each plugin run.

One option might be to store all configuration data in the secure configuration of the plugin steps(could be unsecure configuration, too.. but secure config will be copied with the solution from one environment to another), but you'll need to implement an additional plugin/code to update all those configuration steps whenever you change anything in the configuration.

Then you might add serialization/decerialization code to the plugin base.
Verified answer

Aric Levin 30,188 Moderator on at

Like (0)

Report

RE: CRM Plugin Constants / Key Value Pair Web Config Strategy

Hi,

We use a Configuration/Application settings entity in a lot of our solutions, which hold values in Key/Value Pairs.

We usually call a Retrieve method (if need a single value), or if multiple values like you said Retrieve multiple and store it in a List of Key/Value Pair or dictionary if you want.

If you look at the following post, there are a couple of recommendations for caching.

community.dynamics.com/.../177138

Also, see the following from the following page:

For improved performance, Microsoft Dynamics 365 caches plug-in instances. The plug-in's Execute method should be written to be stateless because the constructor is not called for every invocation of the plug-in. Also, multiple system threads could execute the plug-in at the same time. All per invocation state information is stored in the context, so you should not use global variables or attempt to store any data in member variables for use during the next plug-in invocation unless that data was obtained from the configuration parameter provided to the constructor. Changes to a plug-ins registration will cause the plug-in to be re-initialized.

msdn.microsoft.com/.../gg328263.aspx