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 works
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:
This is where Martin Tölk mentioned we might be able to add shared variables from the organization service as per the link below:
Well, that’s where I had my “aha” moment! Because that should work, should not it?
Looks simple… so, here is my code this time:
Here comes the moment of truth… and it’s a bummer:
What just happened?
After digging around a little more, here is what I’ve found:
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):
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:
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 am
I am unable to change “tag” once it is set. Something about the key already exists — can’t remember the exact message.
https://docs.microsoft.com/en-us/powerapps/developer/data-platform/understand-the-data-context#:~:text=For%20a%20plug,contains%20the%20collection.
I went through the same experiment though I was working to depth 4 — price list, price list item, discount list then discounts. I think passing it via field is the only way that works. Fist of all, as you stated, the “tag” is immutable. For that matter I guess so is every SharedVariable pair. The documentation above shows creating the SharedVariable spawned in one plugin at PreValidation stage followed by another consuming it in a different plugin in a later stage. But the note statement seems to make it clear that that arrangement is NOT the only one.
Well, I tried it with two different plugins not of the same entity and two different areas of the same plugin that executed in different stages. Consuming both context and context.ParentContext neither worked.
What exactly is the purpose of have context if none of this works?