Shared variables in Dataverse plugins. Surprise, surprise…

By | November 29, 2020

It’s a rare situation when 3 different Dataverse developers, all having quite a bit of experience with plugins, start talking about plugins functionality and can’t agree on how it actually worksSmile

Yet, this is exactly what happened when Daryl LaBar suggested that I should be using shared variables to handle the problem described in the previous post

Actually, what led me to writing that post is exactly that shared variables did not work. However, I did forget that I should have looked in the parentContext, too.

That was an apparent omission, so I figured I’d find my shared variable in the parentContext. I ran a quick test… and it was not there. Huh?

Anyway, if you are curious, here is the code I used – highlighted is the line where the plugin will be throwing an error if there is no shared variable. And that’s the error I saw:

image

This is where Martin Tölk mentioned we might be able to add shared variables from the organization service as per the link below:

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/org-service/use-messages#add-a-shared-variable-from-the-organization-service

Well, that’s where I had my “aha” moment! Because that should work, should not it?

image

Looks simple… so, here is my code this time:

image

Here comes the moment of truth… and it’s a bummer:

image

What just happened?

After digging around a little more, here is what I’ve found:

image

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/understand-the-data-context#shared-variables

Turned out this method only allows “tag” variable to be passed to the context.

Finally, my shared variable is there (I had to replace “test” with “tag” in the code sample above):

image

So, basically, I think the way shared variables work is:

  • When all plugins in the execution pipeline are sharing the same context,  we can use context.SharedVariables to pass variables between plugins.
  • If the context changes, though, we can only pass 1 variable using the method above, and it has to be called “tag”

 

By the way, we can also add that “tag” variable through Web API:

image

Well, that’s a viable option.

Although, given it’s only one shared variable we can use that way, I might stick to the “dummy field” method described yesterday, at least for the time being. Otherwise, there is always a chance “tag” variable would mean something completely different if other plugins/developers start using it for their own purpose, too.

Besides, it has one advantage over shared variables, since it could be used from SSIS and other ETL tools if I wanted to stop plugins from running when modifying data in the Dataverse (data migration would be one common scenario).

Well, this was interesting – not sure I’m still missing something there. Would not be too surprised (this time) if I amSmile

Leave a Reply

Your email address will not be published. Required fields are marked *