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.

Click play below for a demonstration of the Settings Manager.

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.

The only good solution I can think of is to create a change playback queue of actions on any controller calls. This is theoretical at this point, but I believe one could create a custom state booking controller that uses the default Navitaire SkySales booking controller and queues calls through it. The only problem with this approach (and it’s a big one) is that Navitaire used a concrete implementation of the booking controller in all of their controls instead of an interface. This means that you cannot step in between those controls and the controllers without messy overrides. This solution would only work on custom code.

We can only hope that SkySales will continue to mature and move more toward interfaces. Unfortunately interfaces are the only Object Oriented way in C# to gain some control over what is going on under the covers.

The PaymentInput control was created with a tabbed paradigm in mind:

Figure 1 - CebuPacific’s Default PaymentInput Control

The original idea was that since the customer could have multiple forms of payment available to them (vouchers, credit, credit cards, etc) and they could pick and choose between adding types of payment by clicking on tabs to enter into the specific payment mode. The concept probably sounded great because the forms of payment are dynamic, so it’s easy to add and remove tabs based on what the customer has available to them. In practice, airline websites just don’t work that way.

The major problem with the default payment control is that it’s bound by the ASP.NET postback model. A postback to the server is required to change payment modes and to change credit card types. Both of these are confusing to a customer and cause discomfort and discord at the moment of sale.

A secondary problem is that since the control is attempting to handle all forms of payments, it’s output and structure is a mess. It’s complicated enough as is, but to customize it quickly becomes a bigger mess. After seeing a competent team’s attempt at customizing the base payment control and seeing the spaghetti code created to coax the control to add simple business functionality, I decided that it needed to ultimately be deconstructed and rebuilt from the ground up.

The following diagram shows the before and after structure of the payment control:

Figure 2 - Before Refactoring

And now after we refactored the code into nice specific chunks:

Figure 3 - After Refactoring

The new payment control set follows basic object orientated principals by having an abstract base control that contains common functionality needed by most controls and the concrete implementations of the different forms of payment are left to specific payment classes.

This structure is now easy to understand with events and well-defined points of integration.  If a carrier decided to accept an alternate form of payment like PayPal, they would simply need to create a new simple concrete class that collects the payment information, creates the appropriate payment class and submits the payment.

Another feature of having independent payment classes is that they can co-exist on a payment page together. Remember, with the default Navitaire payment control you had to be in a certain payment mode. You can’t have vouchers and credit cards both ready to be utilized on the same page at the same time with out getting your hands messy in the default control.

The last benefit of this refactored control is in the realm of refunds. Without carefully configured rules, it may be possible to use the payment page in the booking path as a way to get refunds in certain circumstances. Having explicit forms of payment defined on that page prevents those scenarios.

That’s it! By implementing your own custom payment control you can easily control your own destiny with one of the most critical parts of the booking process: the cash register.

If you’re interested in the production code that goes along with this article, please contact me.

Why Wait?

A wait page on the internet (also referred to as an interstitial page) is usually a mundane step in an e-commerce process that’s only purpose is to convey to the user that the system is processing their request and that they should wait patiently. The SkySales wait page has a singular purpose: to persist until all payments on the reservation receive a definite status back from the payment acquirer.

The out-of-the box wait page up through the current 2.x version of New Skies uses sleep methods to jump into a polling pattern that essentially creates a long running process (shown in the diagram below).

Wake me when we get there

The profiled result of a process like this will show a large amount of time spent in the polling method. An IIS thread on the web server and a worker thread are sitting in a Sleep() state most of this time because the actual call to check payment status is tuned and responds sub-second. The result of this is that a precious IIS thread is blocked and not able to serve other requests on the web server. Microsoft published an article on the dramatic effects of Sleeping a thread on not only the pages which use sleep, but on other pages as well.

Keep it simple, silly

I’ve been implementing and customizing on this platform for over two years and never really thought about the performance of something as simple as the humble Wait page. The SkySales wait page is often the “forgotten” page when a new carrier implements a Navitaire reservation system. I frequently see it in it’s non-customized default state on a number of live implementations for New Skies and Open Skies.

It really wasn’t until I saw that we were spending over 90 seconds in three automated passes through our booking process that made me take a look at alternatives. The result is a much more simplified process:

The code to implement the new wait page is about as simple as the process itself. The previous long running process has been replaced with a simple client-directed polling pattern.

The new custom Wait control calls the Remoting Client on all loads except the first one (the payment system wouldn’t be ready for the initial load). All subsequent page loads are done with a JavaScript refresh based on the system payment settings for the role of the logged in person (anonymous in most cases).

That’s it! This new pattern should keep your IIS threads working hard for you. The code for this is available, but I’d rather not just link to it. Send me a message and I’d be happy to forward the code on.