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.