I'm working on a project using Episerver CMS 7.9. The Staging setup uses 2 servers into the load balancer for the public website and a separate server for the CMS website.
I am trying to use the Episerver Event API to trigger an update on all web servers when a CMS job is executed in Staging. I used the following documentation as a reference: http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/75/Event-management/Event-Management-API/
If I pass an empty string as the parameter to the custom event, the event is successfully triggered on all 3 servers. However, if I pass a custom object or even a non-empty string, the event is only raised on the CMS server (I ran the CMS job manually), but not on the other servers.
Note: I would need to pass a custom object as a parameter when the event is raised.
Did anyone face this issue before? I didn't found other developers mentioning similar issues in my searching.
Should I adjust the configuration in any way?
Ihad similar problem a few weeks ago. Try serializing object to json and pass it as a string.
Thank you for the quick response.
It's still not working by serializing the parameter to JSON. I tried again with a random string and the result is the same.
It works with empty string, though.
Look at a later version of the docs, for example http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Event-management/Event-Management-API/ under "Using custom event arguments".
Basically adding [DataContract, EventsServiceKnownType] to your class should do the trick, WCF will now allow to serialize unknown types.
I tried decorating the class and properties with the attributes mentioned into the Episerver doc, though the first test wasn't very successfull. I will do more tests tomorrow and will keep you updated.
Thank you for the help!
It works now, though not all the times. I was looking into the size of the object, but it's much smaller (~50kB) than the limit mentioned into the Episerver doc. I will look more into this.
The issue I initially reported is now fixed. Thank you for the help, Per!