One of the requests for enhancements in the PeopleTools Product Strategy group on Oracle Mix is for the ability to run Application Designer on Linux. This was actually discussed in the session that the PeopleTools Product Strategy group hosted at Oracle OpenWorld this year.

Although most people think it's not possible, read on and see that you can have an Application Designer icon on your Linux desktop that works just like Windows. But first, a bit of relevant history.

History

If I ever want to freak out old-time PeopleTools developers I just need to say the words "Cross-compiler". Back in the 1990's, when all of PeopleSoft was a Win32 client/server application, there was a strong push from the higher education community for Mac support. The idea of maintaining a Mac specific port of the PeopleTools client was not viewed as something that we had the skills or resources to do (either to create it or maintain it if we paid someone else to do it).

I don't know where the initial idea came from, but someone pointed out that the Microsoft C compiler that was in use at the time in PeopleSoft supported cross compiling and targetting the resultant binaries at the Mac platform as well as Windows. Keep in mind that this was long before Apple switched to using Intel for their chips, so it wasn't just a different OS, but a different underlying CPU architecture as well.

To make a long and painful story short, it worked just well enough for a lot of internal PeopleTools development resources to be devoted to working on it, but never well enough for actual production use. It never actually saw the light of day.

It would probably be a little bit easier today, since the PeopleTools internals have been re-factored quite a bit (appserver re-factoring was a big part of this, but other things helped as well (64 bit platforms, Itanium, etc.)). In addition, there have been advances in cross-compiler technology as well. But we're going to take a slightly different approach :-)

Environment

The desktop environment that we're working with is Ubuntu 9.04. The PeopleSoft environment is HCM 9.1, running on PeopleTools 8.50. Here's a screenshot of (a portion of) the desktop.


We've even got a Query icon as a bonus! What happens when we click on the icon?


Yep, that's App Designer. So, what's the trick? Well, we cheated a little bit. We didn't really get Application Designer running directly on Linux (sorry Nicolas!); we used the Linux Terminal Services Client, which ships as part of Ubuntu (it's available for other Linux distributions as well) and setup a direct link to launch Application Designer.

We're also using our Desktop Single Signon product to be able to launch Application Designer without being prompted for our PeopleSoft credentials. Here's what it would look like without single signon.


After filling in your PeopleSoft credentials, then you'd be in App Designer.

Here's what the configuration looks like to make this work. Launch the Terminal Server Client. In Ubuntu the menu path is Applications -> Internet -> Terminal Server Client.


The key things here are the Terminal Server host that I want to connect to and my Windows network credentials. If I didn't fill those in in this configuration dialog, then I would be prompted for the credentials when I first tried to access the Terminal Server.

Not much interesting on the display tab, except that you can set the connection to go full screen instead of just being within a window on your desktop. If you do this, then you just need to press Ctrl-Alt-Enter to get out of fullscreen mode.

The interesting things here are whether you want sound or not (not much reason to for App Designer development so we turn it off) and whether we want a drive from our machine mapped in to the Terminal Server environment.

When you first setup a Terminal Server connection the Programs tab will be blank by default. This will give you the standard Windows desktop when you access the server. In our example above though, we configured it to launch Application Designer.

That's actually not 100% accurate though. Setting it up to directly launch pside.exe will work to get in to Application Designer, but this will leave your Terminal Server session tied up when you quit.

Instead what we do is launch a batch file that will run Application Designer and then when it App Designer is closed will logout the session. That's the little command prompt window that you see in the screenshots above. We use a little batch file trickery (found here) in order to start the Terminal Server session with the command prompt window minimized.

The Terminal Server client lets you save off the different parameters in a .rdp file (named after the Remote Desktop Protocol), which is how we setup the desktop icons to be able to launch the different PeopleTools.

Fun stuff even though we didn't actually get Application Designer running natively on Linux.

Labels: 2009, ApplicationDesigner

I changed sessions at the last minute yesterday and ducked into Todd Sheetz's (AKA Cheesehead DBA) session on using Oracle Enterprise Manager with PeopleSoft. Todd is with Veolia Environmental Services in Wisconsin, and is also active with the IOUG. As I walked in Todd was already deep into how to get things installed and properly configured.

One key takeaway from this for people that are wanting to get started is that you need to have Grid Control already installed and configured before doing anything with the PeopleSoft plugin. Makes sense.

Todd also went through some of the security configuration and potential challenges. Due to the nature of Enterprise Manager actually, you know, managing things, it needs to have a fair amount of access (it needs access to PSHOME, Another part of the configuration is running a discovery defining
the Grid Control Management Agent, etc.). Nothing out of the ordinary, but depending how your organization is structured, you may need to coordinate this with a few different people).

One other good tip that Todd had for setup was to figure out the GUIDs for your environments up front. Todd had a pointer to David Kurtz's blog for the details on how PeopleSoft generates a globally unique identifier (GUID) for each instance. However, if you allow a GUID to be regenerated for an environment when cloning instances (which is a common practice), then the PeopleSoft plugin for Enterprise Manager does not recognize that the GUID has been changed. By generating your GUIDs upfront and keeping track of them, you can restore the proper GUID when you (for example) refresh a test database from production.

Once the plugin has been installed and is up and running on the different hosts that are running PeopleSoft, then you go online and have it discover what PeopleSoft environments that you have up and running. There was some discussion here about possible issues when you have multiple PeopleSoft environments installed on a single host, but using different accounts for them (e.g. a locked down production or production support environment along with other dev/test environments). Todd recommended running the discovery process once for each PeopleSoft environment to help alleviate this issue.

You can define a single PeopleSoft "system" to include all web servers, app servers, process schedulers, and database, but Todd mentioned that he likes to define the database separately so that when you do things like blackout the system he can manage the database blackouts separate from the appserver blackouts. We ended up having some group discussion at the podium afterwards about managing blackouts - one takeaway for me is to investigate integrating the work that we (Grey Sparling) have already done in this area for PeopleSoft with the Enterprise Manager PeopleSoft plugin.

Todd also did some live demos of their production instance of Enterprise Manager. Everything was green (which was good, else Todd might have had to demo how to fix a problem in front of everyone :-). He showed some of the different graphs and charts available, as well as how to define your own.

Labels: 2009, OpenWorld, Sysadmin

Paco Aubrejuan, General Manager of PeopleSoft within Oracle, gave a session this afternoon introducing the new PeopleSoft 9.1 applications.

Before getting into the content, I have to congratulate Paco on doing multiple live demos during his session. I see way too many people these days relying on Flash demos instead of showing things. Yes, that guarantees that your demo won't crash, but it also makes it much more likely that the audience will be asleep before your presentation is over. Leave the Flash demos for your website - the audience wants to see it live! Having someone at the senior management level do this is a refreshing change.

The session started out on a good note - I ended up sitting in the front row next to Steve Tennant (founder of the PeopleSoft Alumni Network), who was smart enough to find the power outlets embedded in the floor, and nice enough to share it with me.

As Paco got into the content, he shared some interesting statistics with everyone. In support of the statement that interest in PeopleSoft is still strong, he shared that there were over 250 new PeopleSoft customers last year and that customer retention rates are at high levels. Over 50% of the PeopleSoft customer base are now live on post-acquisition releases. Even folks that haven't been engaged for years are coming back alive (he told story of a government customer that was still on PeopleSoft 6 and was now upgrading to 9.1 based on some of the new functionality; PeopleSoft 6 shipped in 1996, so it's been 13 years)

He also talked about the fact that out of the 21 new solutions in PeopleSoft 9.1, only 3 are new products (meaning that there are additional license fees) - the rest are included, so it's part of what your maintenance money goes for. Across the board 9.1 has 1350 new features and 150+ customers were directly involved in the product planning, beta testing of 9.1. As a result of the underlying enhancements in PeopleTools 8.50 (which is the minimum PeopleTools release for the 9.1 apps), 28,000 pages now have Web 2.0 functionality.

In addition to having a number of demonstrations during his session, he also talked about the need for attendees to be able to easily articulate business value for why upgrading would make sense. In several cases he followed up the feature/function side with some hard numbers about financial impact (Steve Tennant was smarter than me by taking pictures of the slides while the session was going so hopefully he captured a few of these).

The high level breakdown of the business value was in 3 areas.

1. End users.
2. Line of business
3. Lower Cost of Ownership

End users were described as having been short-changed a bit in the past because of focus on specific feature/functions, but not as much on simplicity. One example that Paco demoed was getting a Treasury alert (via the new RSS feed functionality in PeopleTools 8.50) and then drilling in to a workbench that allowed some modeling of different financial options ("if I save X by paying some vendors early and taking a discount, can I put the money to better use?"), then collaborating via related discussion threads and then having some collaboration on different payment proposals over the internet. Nothing that couldn't have been accomplished before, but now it's simple enough that it can be demoed live in a keynote session (this was also the demo where Murphy showed up ; one of the pages didn't load properly on the first click so Paco had to logout and log back in and then was back in business.)

For the Line of Business category, Paco went through different things that have direct appeal to CFOs, CIOs, VP of HR. An example was announcing the new Oracle iReceipts for the iPhone. Bi-directional syncing with PeopleSoft Expenses is supported, including the ability to take a picture of a receipt and have that submitted directly for reimbursement. I would have killed for this when I was still at PeopleSoft and had to deal with the expense system.

Another example was showing some of the HCM functionality around Talent Management. Paco pulled up the Succession 360 view for succession planning. A very nice looking page showing current succession planning for a given person was shown with some drag and drop for re-arranging the view, etc. The supporting data popped up inline via the PeopleTools 8.50 Ajax support and showed off some slick comparison tools for looking at different potential candidates for a position (the demo user that he looked at was named Rosanna Channing, which kept making me think of the old Roseanne Roseannadanna character).

He also had an interesting technique for showing some of the Financials close process enhancements. The business process map showing the high level flow along with subordinate bullet points was augmented with customer logos for the customers that had worked with PeopleSoft development in that area for the 9.1 release (e.g. Sprint helping with the reconciliation process).

There was also discussion around the cost of ownership. One big example for improving this was surveying customers for the most common customizations that people implement and incorporating the main ones into the product.

There were some other interesting tidbits sprinkled in the presentation such as PeopleBooks is now available on the Kindle. Also, updated training and documentation were both available at PeopleTools 8.50 GA for the first time ever.

Labels: 2009, OpenWorld, PeopleSoft

Duke Energy did a great session this morning at OpenWorld about how they handle PeopleSoft maintenance and upgrades. After Scott Shafer of Oracle kicked off the session with some introductions and background info, Keith Jenkins and Richard Donaldson of Duke Energy took over and described how they "won the battle" with dealing with maintenance and upgrades.

They started by describing how things had gotten a bit out of hand with falling behind on maintenance. Falling behind on maintenance was not really a planned strategy, just something that the organization sort of fell into. The longer being off maintenance, the harder to get back on maintenance, which (among other things) led to a lot customizations. On the order of multiple thousands of customizations.

This got bad enough that they went for a period of about 4 years without taking any new PeopleSoft functionality at all and began having a harder time dealing with things like OS level upgrades because they so were far enough behind with PeopleSoft.

Part of the problem with an environment that is slowly eroding is that there isn't any one incident that causes change. However, they were having financial closes take 11 ("grueling") days, cases where it wasn't obvious what the source of the truth was, and other SOX related issues. The net is that they did finally come to the realization that, as an organization, they could still meet their business requirements even with doing more advance planning and process management of their PeopleSoft environment.

The major project in this transformation was their upgrade from Financials 8.0 to Financials 8.9. This upgrade not only involved financial process re-engineering, but a switch from running PeopleSoft on DB2 on the mainframe to running on Oracle on AIX.

A Financial Program Office was created as well. One of the outputs from the Financials Program Office is a roadmap of where they are headed as an organization (related to Financials), and how that translates down to application projects. They made sure to include things like applying PeopleTools maintenance as specific items on the roadmap, recognizing that infrastructure investments are part of the overall health of the application. This has now been successfully in place through other upgrades and maintenance (although nothing else the scope of the 8.0 to 8.9 upgrade).

They had a number of practical tips and techniques, such as involving their production support teams earlier on in projects, so that the transitions are smoother when new functionality goes live.

They did a good job of taking questions from the audience during the session as well. After the first few people stood up and asked questions in the middle of the session, I had my doubts that they would be able to finish in time, but it actually worked out fairly well.

Labels: 2009, OpenWorld, Upgrade

As mentioned in the previous post, we've built out some environments with the GA release of PeopleTools 8.50 and have really been liking what we've been seeing so far.

One of the brand new features is the RSS Feed Publishing Framework, which enables you to create RSS feeds from a variety of different PeopleSoft sources. There's actually enough functionality baked in that the Feed Publishing Framework warranted it's own new PeopleBook. It's a reflection of the importance of PeopleSoft Query as a source for RSS feeds that the Feed Publishing Framework PeopleBooks is categorized with the Reporting and Analytic tools (but Query is not the only place to generate RSS from).

This Wednesday we will be taking a closer look at the Feed Publishing Framework in our popular "Social Networking Your PeopleSoft application" webinar. We'll also be including content from previous versions of the session as well, but we'll make sure to have plenty of time for the new PeopleTools 8.50 content since there's so much interest in that these days.

You can register directly from our upcoming events page.

*** Update - October 26, 2009 ***

We have taken the content presented in our webinars and created the following blog entry. Hopefully, this will help you get started with this cool new feature.

Labels: 2009, EnterpriseRSS, PT850, webinar

Just got my first login on a local PeopleTools 8.50 installation. The installation was great - kudos to the PeopleTools development team.

Things worked perfectly after finally getting it downloaded (I get the feeling that there were a lot of downloads from Oracle's site today :-). Here are some quick random observations.

• The installers not only worked well, but they look a lot nicer. They also look a lot more consistent across the entire install (Tuxedo, WebLogic, PeopleTools).
• I was caught off guard for a second when the Tuxedo installer asked for "Oracle Home" instead of "BEA Home" :-)
• The WebLogic and PeopleTools installers both prompt you to subscribe to Oracle Security Alerts and guilt you a little bit when you turn them down. I forget the exact wording, but something to the effect of "failure to keep on security alerts makes you a bad person" :-) This is a Good Thing ; encouraging/shaming people into keeping up on current security threats will have an overall net positive effect.
  
• PeopleTools installer is now smart enough to understand that installing from CD copies on the filesystem is common. So if you unzip everything with Disk1, Disk2, and Disk3 all in the same directory the installer continues along. Of course I was already installing from Disk1 before Disk2 had finished downloading so I didn't get the immediate benefit...
• I did minimal installs for Tuxedo and WebLogic. Those took about 1GB of disk space.
  
• I did the full install of PeopleTools (multi-language, SDK, etc.). That took about 5.5GB of disk space.
  
• Nothing prompted me about the new separation of binaries vs log files in PSHOME. When I created a domain in psadmin though it was automatically created under a subdirectory of the user account that I was logged in with; PSHOME didn't get touched.
  
• After logging in and clicking around through the environment I noticed that things just felt snappier. I haven't done any extensive testing on this yet, but even places that aren't impacted by the new Ajax functionality seemed to load quicker (portal home page, component loading, etc.).
  
• No more "Processing" image blinking when server trips happen :-) Now it's a very Web 2.0-ish looking spinner.
  

There's a whole lot more to write about, but overall first impressions are that this is a top notch release. If you're trying to avoid upgrading for some reason, then you'd better keep your users away from playing with this because the reality matches the hype.

Labels: 2009, PeopleTools, PT850, Upgrade

The PeopleTools Product Strategy group is looking for your input on ideas for new PeopleTools enhancements. Yes you! The person reading this right now :-)

I'd personally recommend taking a look at the PeopleTools 8.50 pre-release notes before submitting your ideas though. There's 190 pages of new goodness listed in there, so you don't want to propose ideas that are already implemented. You'll need your My Oracle Support credentials in order to access that link.

The proposed ideas will be discussed at a session on Wednesday afternoon during OpenWorld.

Labels: 2009, OpenWorld, Oracle, PeopleTools

Well, it's Open Enrollment time here in the United States (or at least it will be very soon).

If you would like to become a superhero to your employees by allowing them to enroll in their benefits this year at their convenience from the comfort of their own home with no cost to you (that's right!! your cost is $0!!), we have an offer for you.

Act Now!

For the next few weeks, we at Grey Sparling Solutions, are offering a free license for our ERP Firewall for PeopleSoft product, which allows you to offer secured access to your PeopleSoft environment for Open Enrollment without jeopardizing the rest of your PeopleSoft system. . .

The license is for the full product for use through the end of the year, and includes support as well as the services to set up and configure it.

That sounds great, but what is an ERP Firewall and how does help with my PeopleSoft Open Enrollment?

The short answer is that the ERP Firewall for PeopleSoft can allow access into the parts of PeopleSoft that you deem are appropriate for external access while blocking external access to the rest of PeopleSoft. All configured through easy to use, PeopleSoft specific setup pages, not coding, so even if you have customized your Open Enrollment process you'll still be up and running in about an hour.

How can I learn more?

Take a look at the Flash demo on our website that shows how it works.

We're also doing a webinar this Friday that shows the product in action. You can register for the webinar here.

I'm interested. What do I do?

There are a limited number of licenses available in this offer and we will taking them on a first-come, first-served basis. So give us a call

(1 925-217-1298 x 270)

or just email us directly

It's our contribution to the great healthcare debate. Time-limited socialism, then switch to capitalism :-)

Labels: 2009, Firewall, OpenEnrollment

Continuing on from our previous post, we had just gotten Oracle JDeveloper 11gR1 installed and we had launched JDeveloper Studio.

When you start up JDeveloper for the first time it will prompt you for a role. These are not security roles, but rather to help with the usability of JDeveloper. JDeveloper provides a lot of different features and is targeted to different audiences, so you can limit how much of the user interface is exposed depending on what sorts of things that you typically do.

You'll notice in the screenshot below that there are roles specifically for Java development. For the purpose of writing Java to extend PeopleSoft, the plain Java role is fine.



We ended up selecting the Default Role option to have everything available to us. Clicking OK then gave us the JDeveloper splash screen.



Since this was the first installation in this particular machine, we were also prompted about associating certain file extensions with JDeveloper. Unless you have specific reason not to, we'd recommend just taking all of them as associated with JDeveloper.



The other thing that we need to do since this is our first time using JDeveloper in this environment is to create an application. In JDeveloper an application is the top level container for work. An application will have at least one project associated with it, but in can have more.



Here we are creating an application called "HelloJDeveloper" using the "Generic Application" template. This is a pretty basic template that just creates a single project to hold our work. You can see in the list of templates that "Fusion Web Application (ADF)" is an example of an application template that will create more than one project. A template is just a starting point though, you can extend and change what is created fairly easily.



Since we had started with the generic template, there were no default technologies and we added Java from the list ourselves. If we had chosen a template that pre-defined the technologies, those would have been pre-selected here, but we could have added additional ones if desired.



Since we added Java as a technology to work with, we get one extra step in the wizard for setting up the Java configuration. Here we have selected com.greysparling.hellojdev as the default Java package, along with the default paths for our Java source code and the Java classes that will be generated from our source code.



Now we have our JDeveloper workspace properly configured and can begin working.

If you're just used to PeopleSoft's Application Designer, the first thing to notice is that although there are a few more child windows opened inside JDeveloper, it actually has a similar model to Application Designer where there is a primary window for working with whatever you are working on, and some supporting windows to help navigate, view status of different operations, etc. As with Application Designer, you can hide the child windows if you want to maximize the screen real estate for what you're working on.

In many cases JDeveloper will provide shortcuts for creating new definitions. For example, in the screenshot above you can see that where we are looking at the summary of the Java files in the project, there is a New button on the summary where we can create new Java files directly. There's also the traditional File->New menu option available, which provides some additional choices.



Here we can see that, in addition to being to create new Java classes and interfaces, we can create other new things such as connections to other systems, deployment information, additional projects, etc. Here's what creating a new Java class looks like.



We've given the class a name (we're calling it "Hello"). The package name has been defaulted in for us, so the fully qualified name of our class will be com.greysparling.hellojdev.Hello. The only other option that we changed was turn on the check box for having a main method. A main method in Java allows you to run a class directly from the command line (similar to what we've shown in the past for PeopleCode by utilizing Application Engine).

We're missing the screen capture for the base file that JDeveloper created for us after clicking OK. Essentially it is the skeleton framework for the code. It compiles, but it doesn't actually do anything yet. The following screenshot shows after we added our own "speak" method to the Hello class.



In the main method, JDeveloper had created the first line for us, which created an instance of our Hello class. By entering a "." on the "hello" variable, JDeveloper (like most IDEs these days) automatically popped up the list of valid methods and properties that are associated with our hello variable. By typing "s", JDeveloper automatically trimmed down the list of choices to our newly typed in "speak" method.

The other nice thing that JDeveloper is doing for us is automatically syntax checking/compiling as we go. Notice the little red warning flag on the left of the line that we are adding to call the speak method. Because we have not actually chosen the speak method from the type-ahead list at the moment the screenshot was taken (mainly so that we could actually show the type-ahead functionality :-), JDeveloper is highlighting the fact that the line of code, as it stands at that exact moment won't work. As soon I as hit the Return key in the type-ahead list, JDeveloper removed the warning flag letting me know that the code was valid again.

Now we can run our code by clicking the green button at the top of JDeveloper. That will compile the code if it has not been compiled yet, and then run it.



JDeveloper shows us the command line that it executed (always nice when GUI tools show you the underlying details instead of hiding them), along with the actual output. The main method invoked the speak method on our Hello object, which in turn printed out the proverbial Hello World (except in our case it's "Hello JDeveloper!").

Now we've gotten JDeveloper installed and gotten our feet wet with some simple code. The next post in this series will pull what we've done so far into an existing PeopleSoft environment. The content is actually done for that, but Blogger (our blog hosting platform that we use) seems to have gotten very slow here as I've been adding these last few images so it won't get posted tonight.

Labels: 2009, Fusion, Java, Oracle

I mentioned in a previous post about our recent "Extending PeopleSoft with Java" webinar. Although you can use any Java development environment when extending PeopleSoft with Java, we wanted to put the brand new Oracle JDeveloper 11gR1 through it's paces. It's nice that we can use the same IDE that the Fusion application developers are using right now to work with existing PeopleSoft applications (we used PeopleTools 8.46 with HCM 8.9 in the webinar). Try hooking up the latest PeopleTools to PeopleSoft 7.5 and see how far you get :-)

To start with, you'll want to download the JDeveloper installer. For the purposes of this blog entry (and a few followups in the future) we're going to use the JDeveloper Studio install since that includes everything that we'll need (at the cost of a larger download).

After the download finished, we ran jdevstudio11111install.exe. It takes a bit for the installer to get everything prepared, but it'll show you it's progress along the way.



Once the installer is ready, there are some straightforward prompts to fill in. First we'll tell it where to install. Since we don't have any other Oracle Fusion Middleware products installed here we'll just accept the default directory of c:\oracle\middleware

The installer will then give the option of a complete or custom install. We'll select custom so we can get a peek at all of the various different options. We don't need the ADF Framework or the WebLogic Server parts for this blog entry, but we will install those anyways since we will be using them in the future.


A few more prompts (we accepted the bundled Java JDK since this environment didn't have Java 6 installed previously, and we chose to start WebLogic manually instead of setting it up as a service).

Then it's a quick review of everything to be installed and we'll be ready to go.




After the installer has done it's work, we'll take it up on it's offer for launching Quick Start. Quick Start provides a bunch of links to help you get started. We'll just go ahead and launch JDeveloper Studio from here though.





Completing the installation and launching everything provides a good stopping point for this post. We'll write some code in the next installment.

Labels: 2009, Fusion, Java, Oracle

We've written before about using a Continuous Integration server called Hudson for use in implementing automated testing of your PeopleSoft applications.

Hudson is an open source project from Sun, and it was just announced that Sun will be selling formal support for a branded version of Hudson, called Sun Continuous Integration Server (SCIS).

This is great news, because Hudson/SCIS is an awesome tool. Since writing up what we have been doing with Hudson and doing some webinars about it, we've had a number of folks asking about getting going with it themselves, so having a formal support channel for it helps quite a bit.

In other Java news, we had a great turnout for our "Extending PeopleSoft with Java" webinar today. Folks got to see using the brand new JDeveloper 11gR1 (just released last month) in conjunction with PeopleTools for extending PeopleSoft business logic. Some good questions got asked during the Q&A portion as well.

We'll put some of that webinar content into some upcoming blog posts, but I have to say that JDeveloper 11g is looking very nice.

Labels: 2009, Business, Hudson, Java, Support, webinar

I've recently been using Vista a lot more as a client machine lately (I know - just in time for Windows 7 to come out I finally start using Vista on a regular basis :-) I hit an interesting problem when running an older version of PeopleTools on Vista though. Resolving the issue ended up using some of the techniques that we have shown in our "Troubleshooting PeopleSoft" presentations, so I figured it would be a good blog entry.

We're connecting to a PeopleTools 8.46 environment running SQL Server. PeopleTools is being run from a network server.


So far, so good. Putting in a password and clicking OK triggers the invalid user/password dialog.

I know that I have a valid access ID and password entered via Configuration Manager. Let's check out our ODBC data source info in Control Panel to be sure that we defined that properly.






That looks good. We've verified database connectivity, but we get kicked out very early in the login process for PeopleTools. I've skipped showing it here, but if you run a SQL trace for PeopleTools right now, you'll see that the error message is correct; it's the initial login to the database that PeopleTools is attempting that is failing.

At this point I fired up Process Monitor to see what was happening. Process Monitor is one of suite of freely available tools from Microsoft that can provide some good low level info about what is happening on Windows. It's not the same Process Monitor that is part of the PeopleSoft Process Scheduler.

After closing Application Designer, I launched Process Monitor, then restarted Application Designer and tried to login. As soon as I got the login error, I switched back to Process Monitor and had it stop capturing activity.



Stopping the capture is important because Process Monitor captures large volumes of detail. If you look at the bottom left of the screenshot above, you'll see that in just the amount of time it took me to try logging in to PeopleSoft, Process Monitor captured over 300,000 different events.



Thankfully Process Monitor has a very cool filter feature. Here we've told Process Monitor to filter the events captured by process name so that we can just see what is happening with pside.exe, and not all of the background processes that are running in Vista.



Filtering just the pside.exe activity still left us with over 8000 events to go through, so we need to do some more filtering. We're suspicious of the database connectivity, and those ODBC entries are stored in the registry, so in the screenshot above we have filtered by operation and limited it to operations starting with "Reg" so that we pick up the registry activity that pside.exe is doing.



That still leaves us with over 1800 events though. That's quite a bit of registry activity being done by Application Designer! Since we were trying to connect to the HCM89 database, we'll do a little bit more filtering. For events like registry and file system access, Process Monitor lets you filter by path as well.

By limiting the registry access events to only include cases where the path references HCM89, we've gotten our original 300,000 events down to just 73. We can see several NAME NOT FOUND errors in reference to ODBC entries for HCM89, so we may be on to something.

A closer examination of those and we discover that PeopleTools tries reading the ODBC entries from HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\HCM89, and then when that fails it is trying to read from HKEY_LOCAL_MACHINE\Wow6432Node\SOFTWARE\ODBC\ODBC.INI\HCM89.

What is Wow6432Node? Microsoft's Knowledge Base has a document on this. The purpose of this is to keep 32 bit programs and 64 bit programs to keep from stepping on each other.

Did I forget to mention that I'm running 64 bit Vista? (sneaky users - never tell the support people key info until after the fact :-)

A quick check with regedit to see what values are actually in the registry reveals that the ODBC entries that were created with the Control Panel applet are in the registry in HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\HCM89, and there are no entries in HKEY_LOCAL_MACHINE\Wow6432Node\SOFTWARE\ODBC\ODBC.INI\HCM89.

So I copied the HCM89 entries into the correct Wow6432Node, then launched Application Designer.


Bingo!

The next step from here would be to investigate how to make this work without requiring manual registry edits, but that will have to wait for another blog post.

Labels: 2009, Support, Sysadmin, Vista, Windows

We wrote awhile ago about how to enforce password protected screensavers in Windows. Password protected screensavers that automatically kick in are nice because they secure the users' desktop when they walk away, which protects their email, local documents, etc. in addition to their PeopleSoft sessions. Lots of customers that use our Desktop Single Signon for PeopleSoft product have implemented this.

In some cases though, locking the current session isn't the desired behavior. In kiosk environments or other types of shared workstations, you want someone else to be able to login, so having the workstation locked to the last user isn't good.

It turns out that Microsoft has a screensaver, winexit.scr, that will log the user out when the screensaver activates. The screensaver is part of the Windows Resource Kits; here's the download for the Windows Server 2003/Windows XP Resource Kit. There are lots of writeups out there about using winexit.scr, but the best one that I found was from David Carlin at Case Western Reserve University. His blog post describes his experience implementing this at one of the computer labs there.

There is at least one commercial product out there (ActiveExit XP) that handles similar requirements, although we don't have any experience with it.

Labels: 2009, Security, Sysadmin, Windows

I had a question the other day about getting going with PeopleSoft Performance Monitor so I thought I'd post a quick roundup/summary of the various material out there.

For those that don't know, Performance Monitor is included with PeopleTools since PeopleTools 8.44. There's a little bit to learn on setting it up / understanding it, but it's a great tool and well worth learning.

Documentation.

You'll certainly want to have the Performance Monitor PeopleBook handy while going through setting up Performance Monitor.

Presentations.

Back in April Oracle had an Oracle Advisor webcast on the setup and configuration of Performance Monitor. Here is the recording of that (Customer Connection/Metalink/My Oracle Support login required).

Lorne Kaufman of System Efficiency gave a great session at Collaborate this year about setting up Performance Monitor. Unfortunately, I can't seem to find a link to the actual presentation anywhere. We'll have to hassle Lorne about that.

David Kurtz of Go-Faster Consultancy has a nice selection of Performance Monitor presentations on his website. He also has a few different blog entries with tips and techniques on Performance Monitor. Those include some performance tuning tips for Performance Monitor itself which he figured out by having Performance Monitor monitor itself :-) He also mentions some issues that they had in a large scale environment where Performance Monitor was handling 20-30 million rows of history data each week! Good stuff.

Performance Monitor enhancements.

Brent Martin of ERP Associates has a writeup on their blog about how to get Performance Monitor to send emails when certain conditions are triggered.

Performance Monitor incidents

Here are some quick searches for Performance Monitor incidents by PeopleTools release.

• 8.49
• 8.48
• 8.47
• 8.46

Labels: 2009, Performance, Sysadmin

I helped some folks the other day with an issue that had the potential to be very serious for them; exposure of production data without someone needing to login to the production system. Not good.

The Problem

For testing purposes they have copies of their production PeopleSoft databases; one for Financials and one for HCM. These copies are refreshed regularly and there are scripts run against them to handle some cleaning/sanitizing of the production data, so that the database can be used for testing.

They have some people that they allow to login to these test environments with any account so that they can confirm the results of basic processes. The accounts don't have default passwords, so this access was limited to the people that they authorized to do testing, but testers with access to these cloned environments could login as anyone.

One of the testers (we'll call him Fred) was logged in to the Financials test environment as some other user (we'll call her Sally) to test some process that would normally be initiated by Sally in the production system.

While doing this testing, Fred wanted to enter his timesheet data so he clicked on a link to go to the production HCM system for time entry. Much to his surprise, he was logged in to HCM as Sally! So Fred goes back to the test Financials environment, logs in as a different user, clicks the link into production HCM and sure enough he is logged in as that user in production HCM. To Fred's credit, Fred alerted the PeopleSoft support team there instead of snooping around in HCM.

How did that happen?

The problem comes from the fact that the production environments were configured to trust each other for PeopleSoft Single Signon, but the node names and node passwords were not changed as part of the environment cloning logic.

So when Fred signed on to the cloned Financials environment, the PS_TOKEN cookies generated are identical to what the production environment would generate (the details of PS_TOKEN cookie are documented in PeopleBooks, but the node name and node password are the important pieces here).

How could this be prevented?

There are several different ways of preventing this from happening. Let's take the pragmatic ones first.

1) Change the node password as part of the refresh script.

This is the easiest, most expedient thing to do. It is the absolute minimum way to solve this problem.

Although this solves the security problem, it introduces a headache for security auditors because the app server logs in the production environment will be full of warnings about failed logins from bad node passwords. That means that testers accessing production while logged in to the test environment will be indistinguishable from someone trying to break in by generating their own PS_TOKEN cookies.

It's not nice to annoy your security auditors by purposely creating log entries that look like break-in attempts, but are actually OK :-)

2) Change the node name.

Changing the node name when you clone environments will also solve the problem (because then the production environments will no longer trust the cloned nodes since they don't recognize the new names). This also solves the log problem mentioned in the previous item.

Changing the node name can have an impact on Integration Broker testing, but that just means that your integration test scripts need to be aware of this. Not a huge drawback in my opinion.

3) Use distinct passwords for each account in the test environment.

This is easy enough to do, it's mainly a question of distributing the passwords to the testers so that they can get in and do their jobs. Depending on your organization, this may or may not be easy.

4) Don't provide passwords to the testers, but allow them to reset them on demand.

Similar to the previous item, but gets around the distribution issue by making it an after the fact auditing issue. If Fred requests the CEO's password in the test system, it's very easy to audit for that and force Fred to explain why he felt that was necessary.

Computer security is typically focused on preventing people from doing things, but in some cases this model of auditing and disciplining after the fact may be OK.

This model reminds me of when we took our dog to a dog trainer a long time ago that recommended leaving a steak or something else on the kitchen counter for the dog to find. This was in conjunction with hiding around the corner so that at the moment the dog put his paws up to grab the steak, you would jump out and impress upon the dog that it wouldn't be wise to do that again. A real-time security audit if you will :-)

What are some of the less pragmatic options?

5) Have a new version of PeopleTools that can detect when a database is copied, and automatically scrub key information like node passwords, GUID, etc.

The implementation of this would be platform specific, but do-able. It would complicate things like having a hot database backup server though. I'm sure those sorts of issues could be addressed though.

6) Embed additional information beyond just node name and node password (like database name) in the PS_TOKEN cookie.

One issue that I can think of with this is that older PeopleTools versions would not be able to interoperate with this, but it could be a flag on the node definition as to whether interoperability with earlier versions of PeopleTools is required. If interoperability was required, then the existing PS_TOKEN format would be used, otherwise the newer format would be used.

Why didn't they know about this?

PeopleSoft Single Signon is documented in PeopleBooks, but there aren't any great writeups out there on the implications of it when cloning a PeopleSoft environment.

There are lots of writeups out there on "How to Clone a PeopleSoft Environment", and some discuss the importance of getting the node configuration correct, but they typically come at from the perspective of just making sure the environment works; not the security implications of it.

PeopleSoft Single Signon is well documented in PeopleBooks, but it just doesn't seem to jump out at people when thinking about cloning. I will give a shout-out here to Brent Martin of ERP Associates. Brent's writeup on cloning a PeopleSoft database is the only one out there that I could find that mentions this issue at all.

Labels: 2009, Audit, Security, Sysadmin

A short follow-on to an earlier post about PeopleCode variable weirdness; did you know that you can use Unicode for PeopleCode variable names?

Great fun with your co-workers at code review time :-)

Labels: 2009, Global, PeopleCode

In our previous blog post we introduced a Continuous Integration server called Hudson to run automated tests against a PeopleSoft system for us. We didn't really get into any test content itself though; we just ran some dummy Application Engine code to show how Hudson can work with PeopleSoft.

Now that the framework piece is in place though, we can begin creating tests. For this blog post we're going to focus on testing functional aspects of PeopleSoft, not performance testing.

Functional Testing Webinar

Before getting into the details, I wanted to point out that we have an upcoming webinar on this exact topic on May 20th, so if you're interested be sure to register for that.

Functional Testing Options

There's a variety of different ways for doing functional testing. Dave Bain from Oracle recently announced the availability of a PeopleSoft specific unit testing tool called PS/Unit. We'll look at PS/Unit in an upcoming post, but if you're not familiar with unit testing you can think of it as testing the lowest level "units" of your code.

Another approach is doing browser-based testing. Browser based testing means having automated tests that drive an actual web browser instance and simulate an actual user's behavior. The primary benefit of browser based testing is that you can be reasonably sure that you are testing PeopleSoft as your users will be seeing and working with it.

In fact, browser based testing can be thought of as automating the way that most people test their PeopleSoft implementations today; which, sadly enough, is by having some of their functional users run through a series of manual tests in their browsers. Expensive, error-prone, incomplete are some of the adjectives that spring to mind when describing manual testing. Not to mention just the hassle of trying to get the functional users to participate in testing. They may be willing to participate once or twice, but if you need to incorporate any additional testing beyond your original project plan, it is a major hassle.

Browser based testing

Back in the old client/server days, PeopleSoft used to bundle SQA Robot (later purchased by Rational/IBM) because it understood something about the Windows controls used PeopleTools for creating the UI. These days the PeopleSoft UI is HTML/Javascript and there are lots of freely available tools that we can use for testing.

One tool that we like for functional testing via the browser is called Selenium. Selenium can run tests across multiple different browsers, and there is a plugin for running Selenium tests via Hudson so we can automate the execution and management of our automated tests.

Getting Started with Selenium

Before we get into running our Selenium tests in Hudson, we need to create some tests. The easiest way to do this is with the Selenium IDE, which is a Firefox plugin and can record, edit and debug tests. The tests themselves can be executed in other browsers, so we're only dependent on Firefox for our initial test development.

So if you're not already in Firefox right now, switch over to Firefox and launch the Selenium IDE plugin installer. Here is the current link, which is for version 1.0 beta 2, but you can check their download page as well to see if there are updated versions available.

Your First Test

After installing Selenium IDE, you can launch it from the Tools -> Selenium IDE menu in Firefox.



When Selenium IDE launches it automatically starts in recording mode, so you can switch back to your main Firefox window and begin working. For this first example, I

• Entered the URL for the PeopleSoft signon page


• Typed in the password (the user ID was already defaulted for me)


• Clicked "Sign In"


• Waited for the portal home page to load


• Clicked the "Logout" link

Then I switched back to the Selenium IDE window and stopped recording by clicking the Red button in the recording toolbar (unfortunately there are not keyboard equivalents for the Selenium recording toolbar). Let's see what Selenium captured for us.



The first thing to notice is that Selenium has captured http://www.gsdemo.com as the base URL. All URL commands will be relative to this (there are some extra things to know if you plan to write tests that go across more than one base URL).

The first actual command that Selenium has captured is the open command. All Selenium commands take the form of Command, Target, Value. Here the target is the URL /psp/ps/?cmd=login, which gets combined with the base URL. This opens the login page.



Next is the type command, where we entered the password. In this case Selenium realized that the pwd DOM ID for the password field was the simplest choice that would work. You'll notice that the Target editbox has become a dropdown box which shows some alternate methods of referencing the password field.



The next command is the clickAndWait command. Selenium recognized the Sign In button via it's DOM ID of Submit and used that.



The last command is also the clickAndWait command, but when we logged out, there was no unique DOM ID that was associated with the Logout link, so Selenium recognized the click by noting that the link text was Logout (eagle-eyed readers will note that the logout text in this environment has actually been customized from an earlier blog entry).

At this point we can repeatedly click the play button in the Selenium recording toolbar and watch the browser login and logout. There are actually two play buttons, one is for the current test case and one is for playing back an entire test suite (which is many test cases grouped together). In this instance it doesn't matter, but once you actually create test suites, then you'll want keep them straight in your head.

If you have any problems at this point playing back the test, you can try adjusting slider control in the Selenium IDE toolbar towards the "Slow" end. This causes Selenium IDE to wait a bit longer for commands to show some results.

Modifying the Test

Each of the commands that Selenium captured for us is modifiable, including being able to delete it. So to make our test a bit more exciting, we highlight the last command (the clickAndWait command that logged out) and delete it, since we don't want to logout just yet.

Then play the script again. This time when the script finishes you will be left on the portal home page (since we're not logging out). Pressing the Record button will start recording again at the end of the script.

This time we will navigate via the portal menu navigation to PeopleTools -> Security -> User Profiles -> User Profiles. Once the User Profiles component search page is up, we type in PTDMO and then press the Search button.

Before playing back this script, I made one manual edit. I changed the very top command from navigating to cmd=login to cmd=logout. PeopleTools will send back the signon page in both cases, but by starting with the logout command you clear server resources from the previous script run. Your system administrators will thank you for this small act of kindness :-)

When playing back the script, I have a small problem; the script does not playback successfully. It tells me that it can't find a frame named "NAV".

The source of the problem is that Selenium does not quite understand the way that PeopleTools is doing it's navigation. When we click on the first navigation link from the Portal home page Selenium records the following two commands.

1. Command: clickAndWait, Target: link=(the name of the link)


2. Command: waitForPopup, Target: _parent, Value: 30000

After we leave the portal home page though, we are getting into PeopleTools generated HTML frames. The next command that Selenium IDE records is Command: selectFrame, Target: name=NAV. The NAV is the name that PeopleTools gives to the menu frame once we leave the portal home page. What we want at this point is for Selenium to wait for the NAV frame to load before we select it, but the commands that Selenium is generating are only waiting for our top level page to load.

Rather than run the entire test at a slower rate so that we're sure that the navigation frame is loaded, we'll insert an extra command before the selectFrame command that will tell Selenium to wait for that frame to load. To do that we

1. Right click on the selectFrame


2. Select "Insert New Command" from the popup menu


3. Type waitForFrameToLoad in the Command edit box


4. Type TargetContent in the Target edit box


5. Type 30000 in the Value edit box

One cool thing about Selenium IDE is that as you enter commands, you get type-ahead support for what commands are available. Once you select a command, then you get the help text for it automatically displayed at the bottom of the IDE window. Very nice! Here's a full list of all of the different commands that Selenium supports.

The other nice thing about the IDE is that we can copy and paste our waitForFrameToLoad command instead of typing it in everywhere. There are a few more places in our navigation script where the selectFrame command is used, so we'll paste it before each one. That allows us to run our script at full speed, but have it wait for the navigation to finish loading if the webserver is slow for some reason. Note that after we finish navigating we are then waiting for the frame called "TargetContent", so we use that name instead.

Skipping Navigation

In some cases you may want to include the navigation portion in your tests, but in many cases you'll want to just test a certain functional area. A good trick for doing this is just have Selenium go straight to the page that you want instead of navigating to it.

The open command in Selenium can be used in the middle of your test scripts, not just at the beginning, so we can replace all of the navigation commands with the open command and the value "/psc/ps/EMPLOYEE/PT_LOCAL/c/MAINTAIN_SECURITY.USERMAINT.GBL". Note that we used the psc servlet instead of the default psp. That will completely bypass the portal and just load the underlying component itself.

Making Assertions

Part of testing is making assertions about the behavior that is seen. Selenium supports making assertions about things as simple as text being on the page to whether specific cookies are present (a good way of checking that you are logged in is asserting that you have a PS_TOKEN cookie) and even as detailed as making assertions about the HTML source code that has been generated for a page.

There are somewhere in the neighborhood of around 100 different things that Selenium can make assertions about, so you should be able to come up with something that helps you validate the desired functional behavior that you are testing. For the example that we have been going through I added a the assertTextPresent command with the Target set to "Confirm Password" since that is the label for one of the fields on the User Profile page. This assertion will return true if "Confirm Password" is present anywhere on the entire page.

We can make some tighter assertions by narrowing the focus from the entire page to specific elements. The above assertion could also be implemented as the assertText, which takes an element locator in addition to the text that is being checked. We saw the use of element locators when working with the login form above; an element locator is just some way of identifying a single element on the page.

PeopleTools will typically generate unique IDs for each form field on page. These are normally the underlying record name and field name for the underlying value in the database (with row numbers if working with multiple rows). In the case of checking a label, PeopleTools will generate a "label" element, with the "for" attribute referencing which form field the label is for.

In this case, we end up with our element locator as //label[@for='PSUSRPRFL_WRK_OPERPSWDCONF'] because we want the label for the OPERPSWD_CONF field from the PSUSRPRFL_WRK record.



In the above screenshot we can see that our assertTextPresent assertion passed, but our assertText assertion failed. Selenium IDE provides the reason for the failure in the log though. The assertText assertion is making an exact check of the element's text, while the assertTextPresent assertion merely checks that the text exists at all across the entire page. Since PeopleTools is generating a colon at the end of the label, we would need to incorporate that in our assertion.

Saving Our Tests

Up to this point we haven't saved our test logic at all. In the Selenium IDE window, select File -> Save Test Case (or press Ctrl-S for a keyboard equivalent). You'll be prompted for a file name. I selected TestUserProfile.html. By default Selenium stores it's list of commands in a special HTML format, which is why we used that extension.

You can also have Selenium export a test case to various other programming languages (Java, C#, Perl, PHP, Python, and Ruby are all supported currently). The benefit to using a programming language for controlling Selenium is that you can then do things like have conditional logic, common subroutines, etc. The drawback is that you lose the ability to use Selenium IDE to work with them at that point. We'll stick with the plain HTML format for now while we're still getting familiar with Selenium, but future blog posts will get into using the programming language integration.



In the above screenshot you'll notice that I expanded out one section of the Selenium IDE window. That shows us the current test case being worked (TestUserProfile). If we click File -> New Test Case, we'll get an "Untitled" entry added in the list of test cases and an empty list of commands. We would then build up our test case just like we did above and save it.

Once you have a few test cases, then you can select File -> Save Test Suite to group the test cases together. You can copy and paste commands between different test cases, so if you find one test case is starting to cover too much functionality, you can break it into multiple test cases this way. Selenium lets you run either single test cases or run an entire test suite together, so you can break things in manageable chunks without losing the ability to group things appropriately.

I did notice a bug in the test case re-ordering within the Selenium IDE window though, so after you save your test suite, you'll probably want to open to the open the test file and re-order the tests listed there so they match the order that you want to run things in.

Wrapping Up

Now that we can start coming up with some meaningful tests, the next steps from here are to incorporate the execution of our tests into our Hudson environment so that they can be run automatically for us.

We'll also want to start integrating all of this with version control. We not only want to start keeping track of the different versions of our tests, but we also want to tie the execution of our tests to changes that are happening with the underlying PeopleSoft objects.

That way if a working test starts throwing assertion errors at some point, we'll be able to see exactly what changes were implemented in PeopleSoft that caused the problem, along with who did it and the underlying reason that the changes were implemented. And if necessary, revert those changes to put things back the way they should be.

Labels: 2009, Browser, Sysadmin, Testing, VersionControl

One of the reasons that we built out Grey Sparling Version Control for PeopleSoft on top of an industry standard version control tool (Subversion) instead of building our own proprietary repository is the sheer volume of other tools available that integrate with Subversion. There's a whole host of other reasons for using Subversion as well. If you'd like to learn more about Subversion you check out the presentation that we've given at OpenWorld and various other user conferences or go check out the Subversion website.

We're going to focus on a tool called Hudson. Hudson is an open source continuous integration server from Sun (so now it's from Oracle :-). A continuous integration server can do things for you like grab your latest source code, compile it (if necessary), run tests against it, and keep track of what happened.

We're not going to be compiling any code for this blog post though. We're just using Hudson for running tests against a PeopleSoft system. This first blog post is part of a new series of blog tests covering testing PeopleSoft. We're also have some upcoming webinars on these topics as well.

Installing Hudson

One of Hudson's strong points is it's ease of installation and setup. It's taken me longer to type this much of the blog post than it did to get Hudson up and running in a demo environment.

Head over to the main Hudson website and download the latest Hudson.war file. If you use IE it may get confused and save it with a .zip extension (both .war and .jar files are just .zip files that specific meaning for Java), so be sure to rename it as hudson.war once it's downloaded.

The only dependency that Hudson has is Java 5. You can type

java -version

at a command prompt to check which version you have. You then start Hudson running by typing

java -jar hudson.war

Hudson is very configurable, but we will accept defaults for now. You can change it later if you want. By default Hudson will create a directory called ".hudson" in your HOME directory when you launch it. This directory holds all of job definitions, output, logs, etc. Note that if you want to delete Hudson later for some reason just delete this directory and the hudson.war file.

Configuring Hudson

Now that you've started Hudson you can go to http://localhost:8080/ and you'll see something like this.



I created a user account before taking this screenshot, but by default Hudson will allow anonymous access (that's actually how I was able to create the user account), so don't run the initial setup on a non-trusted network.

Next we click the link that says "create new jobs". We called our job "Application Engine Test" since we're going to have it run an Application Engine program for us (keep the name reasonably short since it goes in a lot of URLs) and we selected "Freestyle Software Project". For our purposes of running tests against a PeopleSoft system we will always select "Freestyle Software Project" for our job type.



Now we get to the job configuration page. There's a lot of options here, but we'll skip over most of them to get started. Next to each input field is a "?" link that you can link to have inline help expand if you're curious about what the items do though.



The only thing that we changed in the first section was to add some descriptive text to our job. That will appear on the job home page. It can include HTML so you can do things like add links, styling, etc. It's not required, but it's a nice touch.



In the next section of the job configuration page is where we would specify where to pull things from version control. We'll save that for a future blog post, and just leave it as "None" for now.

This is also where we configure build steps for the job. Since we're running this on Windows, we choose Windows batch command. We won't cover it in this blog post, but Hudson can also run on Unix/Linux and have multiple instances of Hudson up and running together (technically there is one master instance of Hudson which can manage multiple "slave" instances).

The command line that put in for the job is

e:\pt849\bin\client\winx86\psae -CT ORACLE -CD PTSYS -CO PTDMO -CP PTDMO -R hudson -AI HUDSON_DEMO

A fairly standard command line for Application Engine. For now we have hard-coded the user/password, but those can be externalized. The -AI parameter is the name of the Application Engine program. We created a simple one called HUDSON_DEMO for the test.

That's good enough to try things out. Scroll to the bottom of the page and save the job. This will return you to the job home page.

Running Hudson Jobs



On the left side of the page are the various actions that you can take with the job. Click the "Build Now" link to run the job (the "Build" terminology comes from the fact that compiling or building software is one of the primary purposes of a continuous integration server).

You can't see it from the screenshots, but Hudson has some nice Ajax functionality that will update the page with what is happening as the build is running.



We can see in the Build History now that we have a successful build. Clicking on the link takes us to the build results.



The output shows "No Changes" because we haven't hooked this up with version control yet. Once that is done you would see a list of whatever program changes had taken place since the last build here. We also have the build timing information (19 seconds for it to start psae and run our program). We can also see the console output from the Application Engine program.



That "Hey, it worked" message is coming the PeopleCode that we put into the HUDSON_DEMO Application Engine program.



Pretty simple, but it lets us see that the environment is properly configured. Let's see what happens when we change the PeopleCode so that it fails. We'll just add an error statement in the PeopleCode to force it to fail. Then we run the Build again.



Now our job summary page shows that the job has failed. Let's look at the console output.



More normal error messages that you might see here are from SQL errors (for example someone altered a record definition that the App Engine program depends on, but didn't update the SQL). When we get into version control integration in the future, we'll see how to use the version control repository to help us figure out why something broke.

Let's spice up our job definition a bit. Here we kicked things off manually so we could tell that it failed, but we don't want to do things manually. Manual steps cost money! We want automation.

So go back into the job configuration page. In a previous screenshot we skipped over the "Build Triggers" section, but Hudson can automatically kick off builds in a variety of ways.

One way is by monitoring the version control repository for changes. If a check-in will cause some sort of breakage, then Hudson will pick it up right away, which is much better than after rolling something into production.

Another way is after other projects/jobs get built. We use this a lot within Grey Sparling. Once our tests run successfully, that kicks off other jobs that package things up for delivery.

Another way is to have Hudson run things on a schedule. This is a good way to catch any changes that you didn't realize that you were dependent on. Kick off everything once an hour or once a night or something just to be sure that nothing is broken.

You can also have external systems trigger Hudson builds if you need something else to control when builds should be run.

Once you have decided on which methods will trigger automated builds (you're not limited to just one method), then you decide on the post build notifications.



In this example, we have setup Hudson to send emails every time we have a problem with the build. If we kick off the build again, we'll see what this looks like.



The nice thing is that we get the output in the email so we can get some idea of the nature of the problem even through our Blackberries and iPhones :-)

If we fix up our test Application Engine program and run the Build again we'll get a single notification email that the build has returned to a successful state. By default you only get success emails when the build returns to a successful state after having problems; you won't get emails every time that a successful build occurs.



The link in the email goes to a permanent link for that build so it's easy to go back and review what happened months afterwards.



You'll also notice that we can start seeing trends in the Build History here. There's a few other views in Hudson that give us these high level "weather reports" (as Hudson calls them) that we'll get into in future blog posts.

Future

Hopefully you found this introduction to using Hudson for testing PeopleSoft useful. In future blog posts we'll cover more test automation topics such as:

• Having Hudson pull changes from version control into a pristine test environment before running the tests


• Running browser based tests via Hudson


• Integration with the newly released PS/Unit unit testing tool

If you have other topics that you would like to see covered, feel free to let us know; either via comments, email or join us on some of our upcoming webinars covering these areas.

Labels: 2009, Hudson, Testing, VersionControl