Summary: Guest blogger, Microsoft PFE, Bill Grauer, talks about using Windows PowerShell to check in for a flight.

Microsoft Scripting Guy, Ed Wilson, is here. Today we have a new guest blogger—Bill Grauer, a Microsoft PFE…

As a Windows PowerShell instructor, I try to drive home a simple point to my students, whether they are absolute beginners or more seasoned scripters. Becoming proficient in a language, whether it be Spanish or Windows PowerShell, requires practice. This means finding every opportunity you can to accomplish some task you're currently doing manually, and automating it.  These opportunities don't all have to be work related.

Every year my family takes a trip north to visit the grandparents and cousins. On our last trip, we ended up taking a Southwest flight that departed at 6:35 AM. For those who've never flown Southwest, you don't get a seat assigned when you book your ticket. Instead, Southwest allows you to board the aircraft in the order in which you checked in for the flight.

Check-in can be done online, and it opens 24 hours prior to your scheduled departure time. Generally, if you don’t check in shortly after it opens, you will end up sitting in a middle seat in the back of the plane. I don't want to be up that early for my flight and I definitely don't want to be up that early to check in. So, when you don't want to do something manually, you automate.

It turns out that using Windows PowerShell to check in for my Southwest flight was pretty straight-forward. The process involves navigating to the correct URL in Internet Explorer and populating some form fields. After the fields are populated, I needed to click the Check In button.

All the Microsoft Office products are scriptable via Windows PowerShell by leveraging the application's COM interface.  To instantiate an Internet Explorer object in Windows PowerShell, I will use the New-Object cmdlet with the -ComObject parameter. The name of the object I instantiate is InternetExplorer.Application, and I will save it in the $IE variable:

$IE = New-Object -ComObject InternetExplorer.Application

Note: All Office products follow the same COM naming convention of product.application.

$word = New-Object -ComObject Word.Application

$excel = New-Object -ComObject Excel.Application

$Outlk = New-Object -ComObject Outlook.Application 

I can interrogate this object and look at its type, along with its members, by using the Get-Member cmdlet:

Get-Member -InputObject $IE

In the output, you can see a Navigate method. Unfortunately, there is only partial information here as it relates to the variable this method takes. It can take up to five parameters, a string, and four variants. But what do these represent?

For more information, see the following MSDN article: InternetExplorer object.

From this article, I learn that the first parameter is the URL I want to navigate to, and it is the only one required.

$Url = http://www.southwest.com/flight/retrieveCheckinDoc.html?int=HOME-BOOKING-WIDGET-AIR-CHECKIN

$iE.Navigate($Url)

If you ran the current three lines of code, they should have executed successfully, but you probably don’t see anything yet. The $IE object has a property named Visible that is set to False by default. This is intentional on all the Office COM objects. The idea is that if you are automating, you may not want or need to see what’s happening.

Let’s set the Visible property to True to see our progress.

   Note  It is not required that the page be visible to check in. This will be important later when I discuss running the
   Windows Powershell script as a scheduled task.

$IE.Visible = $true

Now that I’ve successfully navigated to the check-in page, I need to populate the Confirmation Number, First Name, and Last Name form fields on the page.

These fields are simple HTML input elements of the web page being rendered for us. If you knew the element's name or ID, you could set their values to whatever you wanted.

Getting the input element name can appear tedious at first glance. I could right-click the page in Internet Explorer and choose View Source to see all the markup. I would then have to search though this markup for the input element I suspect is correct, based on its name.

Luckily, Internet Explorer provides a much better way of finding this information. If I click the settings gear icon in the upper-right corner of the page and choose F12 Developer Tools (or simply press the F12 function key), the Internet Explorers Developer Tools suite is loaded at the bottom of the page. From here, I can choose the Select Element tool (CTRL+B) and then hover my mouse over the element with the markup that I want to view. Notice how Internet Explorer puts boundary markers around the element, which makes it easy to see what I selected.

Now that I can see the element name and ID (confirmationNumber), I can interact with these elements via Windows Powershell.

The markup is stored in a property named Document in the $IE object:

$Element = $IE.Document.getElementById("ConfirmationNumber")

This property has the GetElementByID or GetElementsByName methods that I can use (note that it's ElementS in the second method):

As you can see, GetElementByID returns an object, which I will save in $Element. This returned object has a Value property, which I set to the value I want reflected in the form field:

$Element.value = "123456"

Now all I need to do is repeat the previous steps, get the elementID for the First Name and Last Name fields, and set them:

$Element = $IE.Document.getElementById("firstName")

$Element.value = "Bill"

$Element = $IE.Document.getElementById("LastName")

$Element.value = "Grauer"

After these six lines of code run, my form looks like this:

I still have to click the Check In button, which is just more of the same. I use the Select Element tool to hover over the button and get its ID.

When I have the return object back from GetElementByID, I use its Click() method to invoke it:

$Element = $IE.Document.getElementById("submitButton")

$Element.click()

If all works as planned, you should receive an error message on the Southwest page that indicates it was unable to retrieve the reservation. That’s probably OK—unless you put in a valid confirmation number.

That’s all there is to automating this process. The few lines of Windows PowerShell I shared here are not enough to accomplish a fully automated check-in. For that, I would have to embellish this a bit. I need to add some code to handle errors, validate that I'm on the page expected, and set up a way to have this code run at 6:35 AM while I snooze. For the full solution, see SouthWest Airlines Automated Check-In in the TechNet Gallery.

~Bill

Thanks, Bill, for sharing your time and knowledge.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy