This error is triggered when the application server detects that the last updated date/time of the booking in the database doesn’t match what it has in memory. While this is a valid sanity check to prevent the application server blindly overwriting a booking in the database, we had no idea who or what was modifying the booking in between our commits.

After some digging, we discovered that the last user updating the booking was a process account (ProcessMaster). This can be seen when whatever action it took left a trace in the booking history (viewed in SkySpeed).

As Navitaire doesn’t seem to have a solution for the problem, the best recommendation was to re-retrieve the booking when this error was found and try the commit again. This would refresh the application server with the most recent copy of the booking and reset things on the web server as well.

This unfortunately has a side effect of killing any changes the user has just requested to their booking. It’s less painful if they have to repeat just one screen of changes, but it’s worse if they just finished a change process involving a number of steps.

If you absolutely had to be graceful with the customer – you could write a lot of code to queue up and retry those changes made. Unfortunately, the most common (and cheapest) approach is to throw up your hands with an error and blindly ask the customer to repeat to you what they just did.

The bottom line is this: Don’t assume that once a booking is created, you’re the only one working with it. What I’ve described above is a corner case, but a well-known one at that.

To be successful at change management in New Skies, carriers resort to a gatekeeper concept where a single person or group is responsible for changes in the development / test / production environments.

The tools that ship with New Skies out of the box fall short of managing settings across multiple environments.  This is either a manual process of having two management windows open at the same time and tediously ensuring the settings are the same in both environments or a request is put in to an understaffed Navitaire operations group to run a database script to bulk copy settings between environments.  I’ve developed a tool that makes settings management between environments simple.

The Settings Manager tool has two modes, Compare and Sync.  Compare allows the comparison of two settings snapshots.  These could be brand new snapshots between two environments or even two different historical snapshots of the same environment.

If you’re a publicly held company in the US then you’re all too familiar with Sarbanes Oxley requirements.  New Skies is an IT system that directly affects financials, therefore, you’ll need the ability to audit changes to those settings.  The NewSkies database schema fails to provide an auditing of system settings; only saving information on the time a setting was last changed and the user who changed it.  Once a few changes to the same setting has been made, the original information is overwritten.

The Settings Manager can be scheduled to take snapshots of settings on a periodical basis and archive them for auditing.  Snapshots are then archived on disk – there’s no database to worry about or maintain.

Feel free to contact me for further info.

Why a World With Rules?

An unsecured SkySales instance can allow customers to do unexpected things with a booking. Here’s a real-world scenario that would make marketing teams roll over [in their sleep]:

3rd Party Travel Reseller (Screen Scraper) uses automated tools to book the lowest fares for highly desired markets as soon as the fares are made available. Reseller then sells the fares on their site, Ebay, Craigslist, or some other channel for a nice markup. Once the fare is purchased by the actual customer, the reseller retrieves the booking, changes the name through the booking process and commits it through the wait page. (This scenario is assuming that name change fees are not set)

Strange things can happen when a customer retrieves a booking then types in a booking flow page name. Most of the controls used in SkySales don’t care if the booking they are operating on is brand new or if it is a previously committed one. This is not a fault of
the product. The SkySales developers were counting on the proper configuration of rules in the various flows a carrier sets up. If Quality Assurance isn’t on top of their game, it’s entirely possible to overlook the implementation of rules during a conversion to New Skies.

Rule Philosophy

The most effective rule philosophy is to keep you rules very simple and descriptive. This allows developers the ability to understand the rule by just reading the name. For instance, if we had a rule that required a booking to have at least one new flight, our rule should
only be checking for a single, non-committed flight and should be called something like NonCommittedFlightRule.cs. Don’t combine logic in rules, remember we can stack them in order of precedence!

Proper rule configuration allows us to not be concerned about what page the users are linking to. If a user had, for instance, bookmarked their confirmation page – we could redirect them to the home page which would have a widget for the user to retrieve their booking. Without a rule on the confirmation page, we may get a
strange-looking page or a nasty error from the controls attempting to
retrieve a booking in session that was empty. If we decided to
get really customer-centric and bookmark friendly, we could store the
state we were attempting to access when the committed booking rule
failed, take the visitor to a custom page that collects enough
information for us to retrieve the booking, then take them back to the
page they were attempting to link to (where it makes sense).

Rule Bouncing

While rules should not be overlooked, they can cause “bouncing” that may be hard to trace. If you have a tiered set of rules that bounces the person back in a process flow until it reaches an acceptable state, it’s difficult (without some tracing or debug help) to know how many states the user has passed through or the rules that have failed. Here’s an example of a bouncing flow:

User types in: [airlinesite.com]/Payment.aspx in a new browser

The site attempts to load Payment.aspx, but it has a rule that there must be Flights on the booking. The flights rule redirects to the Select.aspx page where the user may select a flight.

However, on entering the flight select page, a rule is run that looks for a flight search request in the session and it redirects to the homepage.

The effect is that we type in Payment.aspx and the homepage loads (with payment.aspx still sitting in the address bar). It can be helpful to write in some rudimentary logging so that web testers can check that the rules are working.

Custom Base Rule

The best way I’ve found to gain control over the rules framework is to write your own abstract base rule inherited directly from the Navitaire BaseRule. What the out-of-the-box Navitaire SkySales rules fail to do is to supply a good base rule that gives you ready
access to all of the objects you’ll need when writing your own rules, namely: UserSession, Controllers, runtime attributes, ResourceCache, etc. Child classes should not have to override
methods just to store critical objects like the ObjectManager themselves.

Below is a link to a base rule I’ve created and a simple rule that checks the booking state to demonstrate how simple custom rules are that use that base class:

WebBaseRule.cs File

NonCommittedBookingRule.cs

I hope this has been a decent introduction to the concept of rules. If you’d like some help setting up rules on your site or have comments on the rules I’ve provided above, don’t hesitate to contact me.