Sunday, April 29, 2012

CRM, Cookies, and You

I went out on an adventure to find out if I could pass extra data into a web service Message from the client, and discovered that it is possible to set a cookie at the browser (or an ISV page, if you’re into that kind of thing), and pick it up inside of a Plugin.  There are a few limitations and gotchas to this process, not the least of which being that this is considered an unsupported customization.

However, there are often interesting needs and situations for which you may want to pass extra data along to a Plugin, but don’t really have a good way to do it.  For instance, I wanted to watch a sub-grid for changes to records and identify only those changes which were made while the parent record was opened.  In this case, I wanted to catch an array of changes once the parent record was saved, and I needed this array to be specific to the singular “session” of the form’s lifetime on the screen.  (If anyone can think of an alternate, supported method for this that doesn’t involve a ridiculous amount of return trips to CRM, I’d love to hear it.)

Practically speaking, I was producing a rich audit trail with contextual links to changes with related records.  Because this was for CRM 4, there was no existing audit feature as with CRM 2011—however, I’m fairly certain this process can be applied to CRM 2011 with the consideration that it may fail in sandbox mode.

What I did was push indicators from the child window into a JavaScript array running on the parent window.  Then, I serialized these indicators into a JSON string, and established a cookie (again, in JavaScript).  By examining the “Request.Cookies” object at the plugin (after importing the necessary namespaces), I could identify and deserialize the contents and perform work at the Plugin.

Also, I discovered that “Response.Cookies” can be loaded with information by an ISV page (though depreciated in CRM 2011, are still available for on-premise use) and also discovered by the Plugin.  This can effectively overload a CRM web service transaction with extra information without messy things like temporary records (which will shoot SQL indexes to hell) and extra attributes.

I ran into trouble, however, when trying to set a cookie from JavaScript within an ISV page.  The Plugin would not identify this cookie, and I believe it’s due to the difference in the way the browser treats cookies from the runtime versus cookies from the domain (served in the HTTP response of the ISV page).

So, what are the limitations and gotchas?

  2. CRM 2011 Plugins operating within sandbox mode will probably be prevented from accessing the “Request” or “Response” from the “Page” context.  Again, I haven’t tried this with CRM 2011 yet, but that’s the assumption I’d have to make.
  3. The Plugin will only have access to the cookie from the “Page” context while operating synchronously.
  4. Cookies are persistent.  Most web developers understand this, but it’s easy to forget.  Once a cookie is set, it must be forcibly removed or allowed to expire.  Never assume that a cookie will not have survived its previous instantiation.

Cookies can be a two-way street of information, so there are likely many different and exciting uses for them to extend CRM’s functionality and encourage cross-talk between various UI elements that may otherwise have no sensible means of sharing data.  If you have used Cookies with CRM before, I’d love to hear what purpose they served!

No comments:

Post a Comment

Unrelated comments to posts may be summarily disposed at the author's discretion.