Creating a Passenger Name Record

by Ken Tabor

Introducing this Sample Code

We offer an API called Create Passenger Name Record to help you prepare your travelers for their trip by creating a full reservation. Through using it, in one request, your application can do the following:

  • Create a PNR containing information for one or more travelers
  • Add agency details
  • Book one or more air segments
  • Halt processing based on acceptable pricing limits

How can this API do several things in one request? It’s a software architecture design pattern referred to as an “orchestrated service.” We want to make the developer experience easier by bundling together several actions typically performed as part of an app’s user workflow.

Creating a Passenger Name Record (PNR) is an important step in the shop-and-book workflow. A PNR is a travel-industry standard way of encoding a complete trip itinerary for one or more passengers along with their necessary personal information. A PNR is a unique identifier stored in global distribution systems (GDS).

The significance PNRs have influenced our choice to create a new sample app. It shows how software developers can call Create Passenger Name Record, parse the results, and display the content. Our goal is making it quicker for developers to get started using the API.

Consider this article as a partner to the sample app source code. You’ll find explanations and additional resources written here to add context whenever possible. Source code for the sample app is stored in a repo on our GitHub account. If you don’t know about GitHub, it’s a popular hosting provider for storing code using the git revision control system. Accessing our source code is free and easy.

Another resource is a screencast-style, code walkthrough video, that shows how to approach the sample app’s source code.

What does the sample app look like when it runs? Here’s a screenshot:

How it Works

The sample app associated with this article is driven on the command-line. It reads search criteria from a config file, authenticates, makes a request to create a PNR, stores the response, parses through the results, and displays the created PNR. Choosing a simple, clean, text-based UI is meant to focus the learning for an audience of software developers.

Find the source code repo here:

https://github.com/SabreDevStudio/create-passenger-name-record-sample-nodejs

Leverage the sample app as a jumping-off point for learning the PNR API. Experiment by changing the app’s search criteria file, the request model, and the response view.

Setting-up the Sample App

There are a few one-time-only steps for installing pre-requisites listed below.

Installing NodeJS

The sample app is written in NodeJS. You’ll need to have its run-time installed on your local development computer. If you’ve never installed NodeJS please refer to the Node Foundation to find an installer most appropriate for your O/S.

Cloning with Git

Take a copy of the source code from our repo stored on GitHub. When you browse the PNR sample app repo you’ll find the green button labeled “clone”. Clicking it reveals the URL you’ll use to “git clone”, which is how source code is first copied down from the server to your computer.

Getting Sabre API Credentials

You’ll need your Sabre REST APIs CERT-environment credentials. They’re used by the sample app as part of the authentication flow to call Create Passenger Name Record.

Installing Project Dependencies

Once you’ve installed NodeJS, and pulled down a copy of the source code, you’ll need to install the app’s open-source dependencies. That’s accomplished by running this command in the local copy of the source code:

npm install

The npm (Node Package Manager) tool will pull down copies of all open-source code this app refers to. File transfers might take a few minutes.

Encoding Credentials

Using the APIs requires entering credentials so that the app can find them. Part of its logic is requesting a token in order to properly call the Create Passenger Name Record API. Tokens are gained in part from private credentials.

Simply open up the app’s source code and look at the file named Config.js to find where they’re declared. There are two attributes (secret and PCC) where values can be copied-in as hardcoded strings. Alternatively, they can be picked-up from O/S environment variables that you create on your local development machine.

exports.api = {
   endpoint: 'https://api.test.sabre.com',
   secret: process.env.SWS_API_SECRET || '',
   pcc: process.env.SWS_API_PCC || '',
 };

Environment variables are preferred in this sample app because it keeps them hidden and protected. In this case, all code is publicly visible in revision control, and that’s not the place for private information.

  • PCC – is the pseudo city code (your agency’s unique identifier)
  • secret – is a base64-encoded string computed from steps you can read more about

Running the Sample App

The sample app is ready to run after setup. Enter this command in the local copy of the source code to run the sample app:

npm start

When this works normally the app renders a status code from the API as well as the PNR. What you will see should look very similar to the image found in this article above. Results match a flight origin and destination pair for a particular date and time.

Updating the Search Criteria Config File

Changing flight search criteria is easy. Simply open up the app’s source code and look at the file named SearchCriteria.json to find the flight information used to create a PNR. Update any of the attributes with valid values and restart the app to see the search results.

{
   "flightNumber": "6020",
   "airlineCode": "DL",
   "departure": {
     "airportCode": "DFW"
   },
   "arrival": {
     "airportCode": "JFK"
   },
   "daysInAdvance": 14
 }

Occasionally, the booking is prevented because the flight is not found. In that case, adjust the daysInAdvance parameter to move it a little farther into the future. Some flights simply don’t exist on some days.

Sabre APIs Used

Sample apps like this one are meant to highlight how a software developer might use particular APIs in the real world. Two Sabre APIs are highlighted in this example: Create Passenger Name Record and Authentication.

Create Passenger Name Record API

The sample app features the PNR API. App code demonstrates setting up and making a request. Then it demonstrates how to parse through the response to display parts of it. For more information on the Create Passenger Name Record API look at this Sabre-hosted documentation:

Authentication API

Most APIs are protected in some way. For example, they require authentication, and that a valid token is sent up as part of the request header. Sabre APIs have this feature. The sample app demonstrates how to call the Authentication API with private account information (PCC and secret) to receive an access token in reply. The token is sent along subsequent API calls to prove the request is valid.

For more information on the authentication process look at this Sabre-hosted documentation:

Next Steps

Make use of this sample app as a testing tool. It’s a simple, flexible, jumping-off point for learning how to use Sabre APIs in general and Create Passenger Name Record in particular. Look up the PNR docs and discover all that it can do. Find something interesting? Call it by changing the request attribute values found in the file PNRModel.js. Save the file and run the app to see how the updates perform.

Get in touch with us. GitHub allows communication through its repo-level issue and pulls request channels. Use the built-in issues section.

We also have an active community on Stack Overflow.

About Ken Tabor

Ken Tabor is a veteran programmer with years of experience developing websites, mobile apps, and video games. He shares his enthusiasm for technology as a writer, teacher, and frequent speaker at conferences including South by Southwest, DevNexus, and Big Design. Ken is currently a software architect at Sabre helping foster a modern developer experience for its future API platform. Areas of interest include NodeJS, Kubernetes, UX, machine learning, and design thinking. He is the author of, Responsive Web Design Toolkit, published by Focal Press. When Ken isn’t working he’s having an adventure with his daughter. They’re always looking for the best chocolate, books, and coffee in Dallas.