skip to main content

TAMU Webmaster's Blog


Information and insight from the A&M Webmasters

Emergency Notice Publication

October 17th, 2012 by Erick Beck

We have crossed a milestone this week.  We now have Code Maroon alerts automatically published to not only the emergency information site, but to the main university site and the mobile site as well. The exact methodology for each site was a bit different, but the first two rely on web services built into the Hannon Hill Cascade web content manager.

The problem was brought to us after the last Code Maroon incident two months ago.  The event occurred over the lunch hour, and the person who normally entered the Code Maroon message into the sites was unavailable.  This led to about a 10 minute delay in getting the information onto the web sites.  The emergency team decided in their after-action meeting that the process should be changed and alerts posted automatically rather than manually.  This led us to examine our options and try to come up with a best solution.

Whenever a Code Maroon alert is issued, it triggers the publication of an RSS feed on the Code Maroon website.  This is considered the authoritative location for the anyone who wants to retrieve the alert notification.  The first step, then, was to set up a cron job that would monitor the feed and note any change.

The easiest of our web sites to update to automatically publish the information was actually the mobile site.  It runs on PHP, so it was no problem to have the site read the contents of the RSS feed and publish the results to a static include file on the server.  The page logic would then include this file and display any alert that had been issued.

The emergency site and university site were more complicated.  Both sites are simple, static HTML.  We intentionally do not even run PHP on the server, so using the site’s internal programming to pull in the alert was not an option.  We do not even run server side includes on these sites in an effort to maximize efficiency.  The content for both is handled by a CMS, so common includes are not something needed to make page editing easier.  This, then, eliminated running any kind of cron job to update an include file.

We also eliminated javascript/ajax as an option.  This is actually how the Code Maroon website works.  It uses ajax to querry the RSS file and write the information into the page dynamically.  This wasn’t an option for us on either site.  The emergency site was set up purposefully to be very lean.  It includes only HTML, CSS, and a single sprite image.  We designed the site like this because of its nature as the emergency information location.  We don’t want to drop traffic during a crisis, and having to load something as heavy as jquery could easily cause a site to fail during a traffic spike created by a large public crisis event.  While www.tamu.edu does include jquery we decided that we wanted to handle both sites in a similar process if possible.

Another reason we stayed away from a dynamic content insert or include file was that we wanted to be able to maintain an audit trail of all changes.  After an event there is always a post-mortum of the process, and we need to be able to go back and look at exactly what was published at a particular time.  This information gets lost if it is simply embedded directly into the web site.  What we needed was something that would create a permanent record of the alert being issued and published.

At this point we knew that our content management system was the only element of the publication workflow that would be able to offer a viable solution.  Our first thought was to have Cascade simply pull in the RSS and publish any new updates.  It became quickly apparent, though, that this approach was overly simplistic.  Yes, it would create the archived record that we were looking for, but in order to make the page auto-updated we would have to republish the page every minute in order to have it pull in and read the RSS.  Technically possible, but not a direction we wanted to take.

We finally settled on a little used feature of Cascade server – its built in web services.  Cascade allows external scripts to authenticate into the system and send commands to update content and even publish pages via SOAP.  This was the perfect solution for us.  We could use our original cron script to monitor the Code Maroon RSS feed, and then if it detected a new alert message we could have it process the message into the HTML that we wanted to see on the page and then pass it along to the web service in a SOAP envelope.  In essence the contents of the SOAP envelope authenticate into the CMS, tell it to edit a particular information block with the content that we provide from the RSS feed, and then publish the page.

The emergency site was very straightforward to add this logic to, and it was done in only a few days.  The university site was a bit more complicated because of the structure of the site within the CMS, but even still we were able to have the SOAP identify the proper edits to make and then publish the site.

Everything works fine in our testing, but of course the ultimate test will be when CIS publishes their monthly Code Maroon test.  If everything goes well you should see the test message automatically published onto emergency, www, and mobile.

Wednesday, October 17th, 2012 Code Maroon
Share this article

2 Comments to Emergency Notice Publication

  1. Eric – although we’re not part of your institution, we wanted to thank you for this post. We’re facing the exact same struggle here and your insight has been helpful in our discussions here. Thanks

  2. Christopher Akin on October 17th, 2012
  3. We’re looking forward to the monthly test next week to see this in action. Thanks for posting this!

  4. Tracy Persky on October 17th, 2012

Leave a comment

Categories

Archives