In http://www.tridiondeveloper.com/intro-to-the-event-system I described the overall event system, listing many of the options available, but not describing them in detail. One of these options requires further examination: Asynchronous Events.
Asynchronous Events happen outside of the regular process of the code that is running. They may run now, or they may run later. You can think of Asynchronous Events as “Fire And Forget” rockets. Sometimes that’s exactly what you need, and sometimes that’s exactly the wrong thing. Let’s look at some scenarios for both.
One of our clients uses Tridion 2013 SP1, and has strict audit requirements for their publishing. We need to know what is on the site at any particular point in time. The auditors might ask, for example, what the user saw if they viewed the site two weeks ago last Tuesday at 3am.
We have to track what gets published, and make sure that we have no significant performance degradation while we’re doing that. Publishing for our releases already take several hours, and we can’t extend that by any significant amount of time.
These tests let us look at different options for this timing. Once the tests have been run, we will then have a better idea of which one to implement.
We have a number of environments that we work with and we move data from one environment to another using both the generally available and highly customized Release Manager and, of course, the Content Porter. This post is about what we’ve found that works best in this scenario, and helps us to ensure that the release happens as smoothly as possible.
An event, in any computer system, is an interruption in the current process. The computer is busy doing what it should be doing, and then something happens to stop it and send it in a different direction. In old systems this was limited to the user clicking a keyboard key or a mouse button. Now, with much more complex systems, it can include state changes, network events, new data, and nearly everything else. Continue reading