As I was solely responsible for the development of Monarch’s Avis car hire in SkySales, I quickly discovered that there wasn’t much information I could draw on to help with development issues.  Monarch had previously sold Avis rentals on the confirmation page using a separate site that was connected directly to the Avis API.  Irregardless of the quality of that API, it was easy to troubleshoot problems because it was a two-party handshake.  However, with Travel Commerce the simplicity of a two-party negotiation now turns into a contentious arbitration process.

An example of this was when the SkySales code was failing to pass certain required fields through to Avis.  Travel Commerce didn’t object and tried to sell the car (ignoring and not relaying any Avis error messages).  The result was a car that was considered sold as far as Travel Commerce was concerned, but awaiting confirmation (which Avis would never send).  It was only through asking Navitaire to dig through XML log messages on their side that we were able to discover the rejection messages Avis was sending.

I’m not sure if my experience developing against Travel Commerce is due to an immature Navitaire Avis connector or if it’s because just a few carriers are using Travel Commerce at the moment.  Regardless, I’ve got my battle scars now and am able to offer Travel Commerce customization to my list of professional service offerings.  If your airline is considering using Travel Commerce, feel free to contact me for a down to earth point of view.

Normally, once the SkySales retrieves this information from the reservation core, it’s cached for future calls. This is great unless you’re a developer who is constantly restarting the site. In that case, developers will experience the empty Country / State cache slow down more often than not.

The problem lies in how Navitaire has structured the retrieval of states. If you examine the GetStates method in the ResourcesCacheService class you’ll find that it’s performing a loop on each country in order to retrieve its states. This amounts to about 75+ calls to core, which individually would be quick, but when combined together they equal a bothersome slowdown.

One solution to this would be to override the resource cache with your own custom cache. You could then limit the amount of calls to, say, the US and Canada (where states are commonly used). However, this approach is problematic because you’d also have to override any controls that used the original resource cache as they are bound to the Navitaire version and not any custom version you provide.

For issues like this, I suggest that Navitaire make the resources cache an interface contract that can be overridden (most everything else now is interface-based in their 3.x framework anyway). However, for this specific issue, it definitely wouldn’t hurt for Navitaire to write a custom database call that brought back all countries and states in one shot, thus saving the repeated (unnecessary) round trips through core to the New Skies database.

Special note: Thanks to Greg from Spirit for helping track this annoyance down!

Seasoned developers have in their toolbox a handy tool called Reflector that will allow them to examine and even debug into the assemblies that Navitaire ships.  For enhancing and working with SkySales controls, this is an absolute must.

Site Note

Navitaire is aware that their customers routinely decompile the SkySales assemblies.  It’s not a big secret.  If they were concerned about this, they would obfuscate the code to make it very difficult to understand when viewed through a decompiler.  It makes you wonder why they don’t ship the plain code alongside the compiled code.

Being able to snoop through SkySales code is invaluable.  However, there is a danger to having this decompiled code available to the novice developer.

I’ve seen many times where decompiled SkySales control code was taken wholesale from the decompiler and pasted into a new custom control (variables named “num3″ are a dead giveaway).  Modifications are then implemented (usually without comments) to certain portions of the Navitaire code where needed.  Don’t get me wrong, this can be a time saver when a project deadline is looming.  However, what you gain in short-term development speed, you loose in long term maintenance.  Are future developers going to be able to understand all of that code you just dropped into the project?  Will they know exactly where the vendor’s code stops and your custom code stops?  And the biggest question of all:  How will that code be updated when your airline takes an upgrade?

If you’re doing at least a moderate level of customization to your SkySales solution, you’re going to have a situation where you must use some or all of a decompiled control.  But how can you do this with minimal maintenance issues?  Below is the best method I’ve found to have the best of both worlds.

In your project, create a special folder to place any classes you must decompile fully.  Examine the class and determine the best entry point for your modifications.  Once you fully understand what the Navitaire base class is doing, insert events at the points in the base methods where you need to insert your customizations.  Your modifications should be well commented and should be a single event line.  You will then create a new class that will contain your business logic and subscribe to the custom event you created in the parent control.  The following is an example of a custom event:

DisplayingBoardingPass(this, new DisplayingBoardingPassEventArgs(pass, segment, passenger));


This was done for a client in the notoriously monolithic OnActivatedPreRender method for the BoardingPassDisplay control.  In this case, the client just wanted to add some XML data inside the boarding pass node being constructed.  However, because the boarding pass node doesn’t use any events or virtual methods when creating it’s XML structure, the control had to be decompiled in order to allow an insertion at just the right point.  Events will also allow you to pass objects to child classes so you can implement some intended side effects on those base objects.

Now, when it comes time to take the next Navitaire upgrade, the client can reflect on the new BoardingPassDisplay control and run a compare to easily see what has been changed.  Since our modifications consisted of one line here or there, the original code is intact and devoid of the various business logic that creeps into custom controls over time.

While the method described above will work and has been tested as a viable way to reduce maintenance costs through upgrades, we should ask: “Why is this necessary”?  The SkySales team must believe that the methods they have marked as virtual are all any one will need to successfully modify the base control functionality.  This is not the case.  The SkySales controls were not written from an implementers point of view.  I suggest that Navitaire should run through their SkySales controls and sprinkle them with events.  As implementers, we need events in the middle of large loops, before and after objects are committed, and in methods that are not easily overridden because of their reliance on private methods.

Out of the box, SkySales loads up the submit form button with a few actions such as client-side validation in the form of javascript functions like: “validate(this)”. That particular validate method determines which form elements are child members of the control submitting the form and then runs the appropriate validation for each element on the form. We’ll use a similar method for tackling the enter key problem.

For this fix, I’m assuming the use of the jQuery framework (which has officially been shipping with SkySales since the 2.x version). The following **code is how we’ll capture the enter key from the XSLT file:

<script langugage="javascript">
$(function()
{
$("input[@id^='<xsl:value-of  select="/*/@clientID"/>']").keydown( function(event) { checkEnter(event, '<xsl:value-of select="//CONTROLS/LINKBUTTONSUBMIT/*/@id"/>'); });
});
</script>

Notice in the code above that we are just checking for inputs that start with the clientID of the SkySales control we are using.  If your control is inside a control group, this code should be in the control group XSLT so it covers all of the elements inside the group.  If you had some select boxes on your form that you wanted to add enter key support on, you would simply expand the jQuery selector to **include select elements:


$("select[@id^='<xsl:value-of  select="/*/@clientID"/>'], [input[@id^='<xsl:value-of  select="/*/@clientID"/>']")... etc


The checkEnter function will basically create a new function for client script residing in the onClick method for the button id that is passed in, and then fire the href event.  This function should reside in a common javascript file that gets included on every page.  The source can be downloaded here.

I believe this small bit of code can help your SkySales site out by helping it behave the way people expect pages to behave on the web.

** Special note **: The code samples work with earlier versions of jQuery. The current version doesn’t require the @ symbol in front of attribute identifiers so modify your code appropriately.

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.

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.