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.

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.

Our ideal candidate is one who has grown beyond their current position and is looking for the chance to make a large positive impact with our company and our airline clients.

The core competencies we’re looking for are:
- 3+​ years of C# experience in WinForms and ASP.​NET
- Proven ability to problem solve /​ debug given the tools available (VS2010, logs, events)

Suggested experience/​technologies:
- Airline Reservation System programming
- XSLT/​XML

Because we’re a small professional shop, we don’t believe in unnecessary process as we prefer to Get Things Done.​  You can expect a friendly, organized environment run by developers.​  We use the latest software tools and equipment.

To apply, send an e-mail your resume to jobs at coltcooper.com.

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.

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.