PeopleSoft Developer Notebook

GenerateComponentContentURL() Fail

2011-08-26T09:01:00.001-07:00

We have a custom PeopleSoft module that handles requests from another web application. After authentication, this web application initially forwards the request to an iscript that, after identifying the user, redirects her to the appropriate home page. The redirect URL is created using the built-in PeopleCode function, GenerateComponentContentURL(). Here is an example:

%This.approverHomePage = GenerateComponentContentURL(%Portal, %Node, MenuName.MY_MENU, "GBL", Component.MY_HOME, "", "");

...
%Response.RedirectURL(&userIdentity.getHomePageURL());

This was working fine until the web application was updated. At that point, the redirect started to fail silently. After a lot of false starts, I determined that GenerateComponentContentURL was returning an empty string, but I could not figure out why.

Long story short, the newly-configured web application was using a URL for the iscript that had an invalid node. The url was:

https://myapp.com/psc/dbname/EMPLOYEE/PSFT/s/WEBLIB_CUSTOM.NAV_FUNCTIONS.FieldFormula.IScript_Navigation

but should have been:

https://myapp.com/psc/dbname/EMPLOYEE/PSFT_HR/s/WEBLIB_CUSTOM.NAV_FUNCTIONS.FieldFormula.IScript_Navigation

This caused %Node to return PSFT, an invalid node. One would think that GenerateComponentContentURL would throw an exception in this case, but it just returned an empty string. I also find it interesting that even with an invalid node in the URL, the iscript still ran.

Thus is life customizing PeopleSoft.

Custom Buttons on Modal Pages

2011-08-11T11:03:00.000-07:00

There are lots of good reasons to use modal pages and components in PeopleSoft. However, one thing you sacrifice is control, especially if you use the delivered Save and Cancel buttons that PeopleTools adds to your pages. There is nothing to stop you from adding your own buttons to the pages, but if you do the delivered buttons are still there, perhaps confusing the user. At least for the modal component, there is a solution. I tried disabling the toolbar in the component internet properties, but the buttons were still there.

Then a co-worker (thanks Giri) pointed out that if you actually uncheck the Save and Cancel checkboxes, the buttons are not shown. Wow. He's right. Problem solved. Is this a bug? Probably. Btw, we use PeopleTools 8.49.

Get Rid of Unwanted Save Warning

2011-08-08T10:21:00.000-07:00

Have you ever had a component that gave you unwanted Save Warnings. I recently had to deal with this problem on a page that had a custom button that among many other things called doSaveNow() and then a transfer. Despite calling doSaveNow, the transfer resulted in a Save Warning. I traced the PeopleCode, but could not find any change between the save and transfer that should result in the warning. Frustrated, I searched online for a solution. I found an undocumented PeopleCode function designed for this situation - SetSaveWarningFilter( True).

Calling SetSaveWarningFilter with True input parameter causes the subsequent page to ignore the SaveWarning. It's not perfect because user is shown the page that would display the Save Warning, but then routed to the next page as if the user clicked the cancel button on the Save Warning dialog. In our situation this was good enough.

How Select Options are Set on a PeopleSoft Page

2011-04-12T17:07:00.000-07:00

I just learned something new about how PeopleSoft pages work. We are using PeopleTools 8.49.29. Your mileage may vary.

It appears that if more than one Select (dropdown) have the same options, PeopleTools puts the options into a JavaScript array, then populates the options with JavaScript after the page loads. I learned this the hard way because I had a qQuery function that ran on page load and uses the select values. It was not working right because the select values were not set when the script ran.

The function that populates the options and sets the selected values is setSelectElemOptions_win0(). I solved my problem by creating a proxy for this function and adding a call to my function. This ensures that my function runs after the Select options are set. See my previous post on how to create a proxy.

Here's the code.

// proxy the setSelectElemOptionsProxied function to ensure Select Options
// are set before totalHours is called on page load
var setSelectElemOptionsProxied;
(function() {
// proxy setSelectElemOptionsProxied
setSelectElemOptionsProxied = setSelectElemOptions_win0;
setSelectElemOptions_win0 = function() {
setSelectElemOptionsProxied(); // call the original function
totalHours(); // my function
};
})();

Using JavaScript in PeopleSoft: Creating your own dialog boxes

2011-02-17T13:14:00.000-08:00

In previous posts, I've described how I have been using JavaScript to enhance our PeopleTools 8.49 application. I've covered calculations and validation, and showed how you can proxy "delivered" PeopleSoft JavaScript to enhance your pages.

In this post I'll show how we are replacing the Peoplesoft confirmation (Yes/No OK/Cancel) message box with our own slick modal dialog boxes. I'm sure you'll agree with me that the bare, ugly pages produced by using PeopleCode messageBox() for confirmation aren't up to modern web standards. I went searching for a way to replace it. I found jQuery UI dialog. jQuery UI is a jQuery plugin designed to provide JavaScript UI elements that complement jQuery. Dialog provides a robust set of tools for creating flexible client-side dialog boxes. Here's an example of a typical OK/Cancel confirmation dialog produced by Dialog.

Dialogs are typically defined statically and called by dynamic Javascript. I've settled on a pattern that seems to work well with PeopleSoft. I define the dialog based on an empty <div>, but set most of the properties, including the html displayed in the dialog, from the event-driven code and bind variables.

Here's a typical definition.

   var $confirmDialog = $('<div></div>').dialog({
       title: '%BIND(:10)', 
       autoOpen: false,
       resizable: false,
       modal: true,
       minHeight: 400,
       minWidth: 350,
       buttons: {
            OK: confirmOK,
            Cancel: confirmCancel
       }
 });

A few things to notice. The dialog html is an empty div (<div></div>). The actually html shown in the dialog is set when it is called from a function. I'm setting the dialog title with a bind variable. autoOpen is set to false; otherwise the dialog would open when the page is loaded. The button actions are defined as named functions. They can be anonymous functions, but I find that using named functions here is cleaner, more flexible and can be reused. In many cases, I replace the actions when I call the dialog.

Here' s a function that calls the $confirmDialog:

  function confirmIt(msg){ //msg must be formated as html
     $confirmDialog.dialog('option' , 'height', 450);
     $confirmDialog.dialog('option' , 'width', 400);
     $confirmDialog.dialog('option' , 'buttons' , {OK: confirmSubmit, Cancel: closeDialog} );
     $confirmDialog.html(msg);
     $confirmDialog.dialog('open');
 }

In this case, I'm replacing the button functions with:


 // OK button function for confirm dialog
 var confirmSubmit = function() {
     $(this).dialog('close');
     $('#TC_DERIVED_CONFIRMED').val('Y'); //hidden field
     return submitProxied.apply(window, localArgs); // continue submit process
 };

 var closeDialog = function(){
    confirmed = false;
    $(this).dialog('close');
 }

confirmSubmit:

closes the dialog box;
sets a hidden field that I've added to the page with JavaScript following the PeopleTools naming convention that I can query in PeopleCode to confirm that the user has confirmed the submit on the client-side;
passes the processing to the standard PeopleTools submit processing JavaScript. (I describe how this works in a previous post.)

closeDialog sets global confirmed to false and closes the dialog. This, in effect, cancels the submit and leaves the user on the original page.

You can define as many buttons as you wish, each with its own function.

The Validation Chain

This works fine for a single-step confirmation - something like "Submit your timesheet? You will not be able to make further changes. OK Cancel." But when you call a dialog box you are turning over processing to the dialog code. Unlike a PeopleSoft messageBox, it never returns a value to the calling code. So, what if you need to process several validations and confirmations? To handle this, I use a technique I call the validation chain. In the validation chain, each step is a function that can stop the processing or call the next step until the chain is complete.

Here's an example.


   function myFunction () {
       ...
       //validationChain is declared global

validationChain = [validateInOut,validateZeroHours,validateTimeOnHoliday,validateSubmit];


       return nextValidation();

...

  }

   // call the next validation in the chain
   function nextValidation() {
       var next = validationChain.shift();
       var nextUndefined = next == undefined;
       if (!nextUndefined) {
            return next()
       };
       return true;
  }

First, we set up a global array of validation/confirmation functions; the validation chain. Then we call nextValidation().

nextValidation removes the first function from the chain and stores it in variable next. Then, if the function is defined, it is called.

Now each function can do validation or confirmation including calling a dialog box. To stop the process the function returns false. To continue, the function, or the dialog it calls, calls nextValidation(). Here's an example validation function that can be added to the validation chain:


 // User confirms time on holiday  
function validateTimeOnHoliday() {
   if (timeOnHoliday()){
       var msg = '%BIND(:2)'.
       replace('%1',holidayDateString);
       $confirmDialog.dialog('option' , 'buttons' , {OK: confirmContinue, Cancel: closeDialog} );
       $confirmDialog.html(msg);
       $confirmDialog.dialog('open');
       return false; // we'll only get here if the user cancels
   } else {
       return nextValidation()
   };
  }

// Continue button function for validation chain dialog

var confirmContinue = function() {

$(this).dialog('close');

return nextValidation();

}

 // Close the dialog without taking any action - this will end the validation chain
 var closeDialog = function(){
     $(this).dialog('close');
 }

Now you can call any number of validations and confirmations before submitting the page to the server.

I hope you have found my JavaScript blog entries helpful. If you have your own ideas on how to use JavaScript to improve PeopleSoft applications, please let me know.

Using JavaScript in PeopleSoft: Proxy PeopleSoft Functions

2010-11-17T17:42:00.000-08:00

In my last post, I showed you how to do dynamic field level validations in JavaScript with the help of jQuery. In this post we'll take it to the next level by doing validations on submit using a function proxy technique.

JavaScript is a very flexible language. One aspect that separates it from other languages, such as Java, is that everything is an object. This includes functions. At first glance treating a function as an object doesn't seem very useful, but, in fact, it leads to a number of cool capabilities. One of those capabilities is the ability to proxy a function.

Here's a non-PeopleSoft example to illustrate this. Let's say you have a vendor-created web page that already has a validatePage() function that is called by the two buttons, mySaveButton and mySubmitButton.


function validatePage(source) {
    if (!validateRequiredFields())
        return false;
    if (!validateDates())
        return false;
    if (source == 'mySubmitButton') {
        if (!validateTotals())
            return false;
        }
// ...
    return true;
}

We would like to insert another validation step without having to modify the existing code. We can do this by creating a proxy for the original. (This is all standard JavaScript - no jQuery.)


 (function() { 
    // proxy validatePage 
    var proxied = validatePage; // capture the original function 
    validatePage = function() { 
        // replace it with our custom version 
        var result = true; 
        var localArgs = arguments; 
        var button = arguments[0]; 
        if (source == 'mySubmitButton') { result = validateTotals(); } 
        if (result) { 
                return proxied.apply(this, localArgs); // call the original function. 
        } return false; 
        }; 
})();

So what's happening here? The first line of our anonymous function gets a reference to the original validatePage function object. Then we replace the validatePage object with our new function. arguments is a special object available in the body of every function. It's an array of the arguments passed to the function. We use it here to access the argument of the original validatePage function call, in this case the button that called the function. If the calling button was mySubmitButton, my custom validation is run. If the validation passes, the next line calls the proxied function to perform the rest to the validations. There is a lot of flexibility here. We could have executed code after calling the proxied function or not even called it at all. I'll use this later option below when proxying the PeopleSoft saveWarning() function.

How do we apply this to a PeopleSoft page? If you dig around in a typical PeopleSoft page, you'll find that all buttons and links in the main frame that call PeopleCode on the server call the PeopleSoft JavaScript function submitAction_win0(document.win0,'CUST_PB_WRK_CUST_CRSPDSEL_PB'); where the second argument is the id of the button or link field. By proxying this function, we can inject our own validation code that is called whenever a button or link is clicked.

// proxy the peoplesoft submitAction_win0() function

// Called for all peoplecode buttons and links

(function() {

// proxy submitAction_win0

var submitProxied = submitAction_win0;

var submitAction_win0 = function() {

var button = arguments[1];

var msg = "";

switch (button) {

case "SAVE_BUTTON": // Save

if (validateForSave()) {

                                return submitProxied.apply(this, arguments); // call the original function

}

break;

case "SUBMIT_BUTTON": // Submit

if (validateForSubmit()) {

msg = '%BIND(:3)'; // Confirm Submit

if (confirm(msg)) {

                                        return submitProxied.apply(this, arguments);

}

break;

default: // all other buttons and links

return submitProxied.apply(this, arguments);

}

};

})();

Again our proxy function gets a reference to the original function and then substitutes our new function. The switch checks which button called the function and runs a custom validation. If the validation passes, the original function is applied which, in this case, continues the PeopleSoft submit process. The default case simply applies the original function for all other buttons and links.

Proxy the saveWarning Function

To me the standard PeopleSoft save warning is counter-intuitive. I think the OK button should continue the action I originally selected while the Cancel button should cancel that action. Since my pages are exposed to an audience of non-PeopleSoft users, I decided to change it (It's good to be King!). I found that the save warning is raised by, of all things, the saveWarning() function. Here's how I replaced it. Note that I never actually apply the original function, so this proxy completely replaces the it.


 var saveWarningURL;
 var saveWarningProxied;
 var saveWarningTarget;

 //proxy the peoplesoft saveWarning(frameName,form,target,url) function
 (function() {
  saveWarningProxied = saveWarning; // Not doing anything with this
  saveWarning = function() {
   // console.log("arguments[1]: " + arguments[1]);
   localArgs = arguments;
   var frameName = arguments[0];
   var form = arguments[1];
   saveWarningTarget = arguments[2];
   saveWarningURL = arguments[3];
   var changed=null;
  
   if (form)
     changed = checkFormChanged(form, null);
  
   if (changed==null && top.frames && frameName.length>0 ) {
     objFrame = top.frames[frameName];
     if (objFrame)
       changed=checkFrameChanged(objFrame);
   }
  
   if ((changed==null) && top.frames)
   checkAnyFrameChanged(top.frames);
  
   if (changed) {
    if (confirm('%BIND(:7)')) {
        open(saveWarningURL, saveWarningTarget);
                                }
   }
  };
 })();

Here's what it looks like in action.

That's it for now. In the next post, I plan to show how to create your own modal dialog boxes to replace the standard alert (error/warning) and confirm (yes/no ok/cancel) messages.

Happy coding!

Using jQuery in PeopleSoft: Validating, Formatting and Totaling

2010-11-02T10:29:00.000-07:00

In my last entry, I introduced using JavaScript and, specifically, the jQuery library to enhance your PeopleSoft pages. Now we'll take a look at how to apply this to browser-side data validation, formatting and totaling. This is the application that inspired me to look into using JavaScript with PeopleSoft in the first place.

Experienced PeopleSoft developers (and why would you be reading this if you're not one?) know that in order to force data validation and page update as soon as a user leaves a field, we must deactivate "deferred processing" so that the page will be submitted when the data changes. On pages with many fields, it can be very disruptive to efficient data entry to submit the page on each change. This also increases the load on the server. On the other hand, real-time data validation and page updates provide the user valuable feedback.

The solution is to do basic data validation, formatting and totaling on the browser-side with JavaScript.

One caveat, never rely solely on browser-side data validation. You cannot control what happens on the user's computer. It is not that hard to hack a web page and subvert the validation. Always do server-side validation also to insure that data you receive is safe and valid.

jQuery makes it easy to detect changes and take action on them. The basic code looks like this.

$(document).ready(function(){
  $('#MY_INPUT').change(function () {
    //do something here
  });
});

The .change() method causes the enclosed function to be called whenever the selected object value is changed and the object loses "focus." An object losses focus when the user "tabs out" or otherwise selects another object on the page. A similar method, .blur(), can also be used. The blur event occurs when the object losses focus, whether or not the value has changed.

Let's say we have a simple time entry page where the user will record her time for the week. Each day has an hours text input element, HOURS1, HOURS2 ... HOURS7. We can watch all seven inputs with one line of code and do some validation and totaling.

$(document).ready(function(){
 $('input:text[id^=HOURS]').change(function () {
  try{
   var hours = parseNumber($(this).val());
   if (hours < 0 || hours > 24){
    alert('Daily hours must be between 0 and 24.');
   }else{
    $(this).val(formatNumber(hours));
   }   
  }catch(er){
   alert ($(this).val() + ' is "' + er.toString() + '"');
  }
 });
 
 // parse text to number.
 function parseNumber(n) {
  var out;
  if (n == ''){
   out = 0;
  } else{
   var out = parseFloat(n);
  }
  if (isNaN(out)) {
   throw 'Not a number';
  }
  return out;
 }

 // format number to text with 2 decimal point. If 0 return ''
 function formatNumber(n) {
  var out;
  if (n == 0) {
   out = '';
  } else {
   out = n.toFixed(2);
  }
  return out;
 }
});

Each time one of the HOURS inputs is changed, this code is called. First we parse the value of the input ($(this).val()) to a number. If it's not a number, the user gets an alert. Same if the value is not between 0 and 24. Finally, the number is formatted with 2 decimal places and we update the input element value.

All this takes place on the browser without submitting the page to the server. Let's take one more step and provide a total. I'll add a totalHours method:

function totalHours() {
  var total = 0;
  $('input:text[id^=HOURS]').each(function () {
   total += parseNumber($(this).val());
  });
  $('#TOTAL_HOURS').val(total.toFixed(2));
 }

and call it from my original code:

...
   }else{
    $(this).val(formatNumber(hours));
    totalHours();
   }   
...

Note how easily I can loop through each of the HOURS inputs and total them up using the each() method.

Now, a couple PeopleSoft-specific tips.

By default, PeopleTools gives each input an id attribute equal to the concatenated record and field names. This can be awkward and sometimes not very descriptive. You can override this behavior by setting the "Page Field Name" in the "General" tab of the Edit Box Page Field properties. The value you set here will be used as the id and name of the element in the html. Just be sure the value you set is unique for the page.

The Edit Box "Display-Only Appearance" should be set to "Disabled Edit Control" in the "Use" tab of Edit Box Page Field properties. This causes the Edit Box to become an "addressable" text <input> element rather than <span> element with no id. This does cause some formatting issues depending on the browser. I'll describe my solution to this in a later post.

So now you can validate, format and total data on the browser side without having to submit your page to the server.

In my next post, I'll show you how to intercept the delivered PeopleSoft submit process so you can do validations and verifications on submit.

Using jQuery in PeopleSoft: Introduction

2010-10-20T17:41:00.000-07:00

At my company, management decisions have kept most of our PeopleSoft applications on PeopleTools versions prior to 8.50. So we haven't been able to take advantage of the new AJAX features that come with the most recent versions of Tools. However, we are now working on a application that will be exposed to an large audience outside of our corporate firewall. We realized that we would like our users to have a modern browser experience including: dynamic page updates, client-side validation, modal dialog boxes. How can we do this with PeopleTools 8.49? The answer is to do our own JavaScript programming.

Having done some JavaScript for my wife's business web site GetRolling.com, I realized that using "straight" JavaScript to program modern features is a lot of work, so we went looking for a framework. We quickly settled on jQuery, a popular, open-source JavaScript library with lots of support and many add-ons. We had also heard that Oracle was using jQuery with the most recent versions of PeopleTools (true?), so it would help "future-proof" our experience.

The core strength of jQuery is its selectors, which allow you to easily select and act on one or more DOM objects without having to traverse the DOM hierarchy. The multitude of selector options can be a bit daunting at first, but after learning some common patterns, I found them to be very efficient. While the jQuery project provides plenty of documentation on their site, I found this Ref Card from DZone very handy when trying to figure out how to write my selectors.

A key concept is that your jQuery code should be wrapped in document ready block:

$(document).ready(function(){
    // your code
});

This ensures that you code does not get called until the DOM is loaded in the browser and ready. You will use $(selector) throughout your jQuery code. $() is just shorthand for the core function jQuery(). jQuery also makes liberal use of anonymous functions like the function(){...} above.

Getting Started

I'll skip the traditional HelloWorld as it's not very instructive for our use and get right to a concrete example. Let's say you want to validate a user entry immediately after the user leaves the input field. In PeopleTools, you would need to add FieldChange PeopleCode to the field and uncheck "Allow Deferred Processing." This would force the page to be submitted to the server whenever the field value is changed so that the validation PeopleCode can run. This can be very disruptive to the user experience and place extra load on the server.

With jQuery, we could write this (USA-centric) code:

$(document).ready(function(){ $('#ADDRESS_ZIP_CODE').change((function () { if($(this).val().length < 5) {

alert("Please enter a valid Zip Code"); } }); });

What's happening here? # is the id selector. The fragment $(#'ADDRESS_ZIP_CODE') "selects" the object with an id='ADDRESS_ZIP_CODE'. After the DOM is ready, jQuery adds an anonymous function to the onChange event of this object that happens to be a text input element. When the value of the input is changed, the function is called. Inside the function, $(this) refers to the selected object. val() returns the value attribute string and .length is the standard JavaScript length property of the string. As you can see, you can write some very concise code with jQuery.

Here is another handy example I use in PeopleTools grids.

$('input:text[id^=HOURS]').each(function(index) {
  // your code
}

This selects each of the input text elements whose id attribute starts with HOURS. each() iterates through each element in a loop. In a PeopleTools grid, each field id is suffixed with $i where i is the row number, e.g., HOURS$2, so you can see how useful this can be.

In future blogs I'll describe some more powerful things you can do with jQuery, but I'd like to use the rest of this blog to show how to get this code on to your page.

The basic mechanism I use is to write the JavaScript in an application designer HTML object and use page activate PeopleCode to put that HTML into an HTML Area that I've included on the page. The position of the HTMLArea does not seem to matter much, but I try to place it near the top of the page.

It's important to include a reference to the jQuery library in your code. Here's an example of how it looks:


<script src="/rhijs/jquery-1.4.2.min.js" type="text/javascript"></script>

<script type="text/javascript" >
$(document).ready(function(){
 $('#ADDRESS_ZIP_CODE').change((function () {
  if($(this).val().length < 5) {
   alert("Please enter a valid Zip Code");
  }
 });
});
</script>

I had my admin put the file jquery-1.4.2.min.js on our web server in a custom directory so it can be referenced by my pages. This is the "minified" version of the library. The code is nearly impossible to read, but the file is much smaller to load and should be used for production. There also a standard version with the full source that can be used for reference and debugging: jquery-1.4.2.js.

If you don't have access to your web server, a good option, if your network allows, is to hot link to a CDN as described here: http://docs.jquery.com/Downloading_jQuery#CDN_Hosted_jQuery

The basic PeopleCode to include your JavaScript in your PeopleSoft page is:

MY_REC_DERIVED.HTMLAREA1.Value = GetHTMLText(HTML.MY_JQ_ZIP_VALIDATE);

A powerful technique is to use the text replacement functionality of GetHTMLText to "customize" your code on the fly. For instance, instead of hard coding the error message in the JavaScript, we could modify the alert line to read:

alert("%BIND(:1)"); // note the quotes around the bind

and change our PeopleCode to:

Local string &invalidZipMsg =  MsgGet(29000, 85, "Message not found");
MY_REC_DERIVED.HTMLAREA1.Value = GetHTMLText(HTML.MY_JQ_ZIP_VALIDATE,&invalidZipMsg);

That's it for now. In future blogs I'll introduce a technique that allows you to intercept calls to delivered JavaScript, so you can trigger your own validation and verification code; show you how to format input; how to create your own modal dialogs; and how to add an Auto-Complete textbox to your page. I'll also discuss some tools that are essential to your success in browser JavaScript programming.

I'm certainly not the first one to use JavaScript with PeopleSoft. There are plenty of examples on the Internet. I'm in special debt to Jim Marions' blog and his new book PeopleSoft PeopleTools Tips & Techniques.

I'm Back

2010-10-10T17:37:00.000-07:00

I'm reviving my blog with a new emphasis on my professional activities as a PeopleSoft Application Architect and developer. I'm leaving my old posts up as they're fun to revisit, but in the future expect more technical content. My next post will be about using the jQuery JavaScript library to enhance the user experience for PeopleSoft Applications.

The Eucalyptus Trees

2007-09-23T17:04:00.000-07:00

Another ride with the Diablo Cyclists - my last hard ride before Waves-to-Wine . Walnut Creek through Danville and Blackhawk. Out Tassajara Road to Highland, Collier Canyon and return.

The pace to Blackhawk was moderate, but things started to pick up after the rest break. We had a big pack going 28 mph on Tassajara. Turning on to Highland, the hammer went down. I hung on until the second roller, dropping off with one other guy. We stuck together until the rest break including a fun 30+ mph stretch.

When everyone got rolling after the break, it was pretty much a repeat. I hung on as long as I could with my heart rate in the low 160s. I paired up with a different partner for the ride back to Danville and finished just before noon. 50 miles, 33 mph max, 17.6 mph average.

Sunrise Sunset - Two Movies

2007-09-23T05:14:00.000-07:00

We watched two small but amazing movies this weekend: Before Sunrise and Before Sunset. Both starring Ethan Hawke and Julie Delphy, and both are essentially long conversations. In Before Sunrise, released in 1995, their characters, American Jesse and Celine, a Parisian student, meet on a train traveling through Europe and get off together in Vienna. They spend the night walking and talking - knowing they may never see each other again.

The 2004 Before Sunset is the sequel. Jesse returns to Europe, a successful author touring a book essentially about their Vienna encounter. Celine shows up at his last stop in a Paris bookstore. They have a few hours to pick up where they left off nine years ago before Jesse flies back home.

Delphy radiates a natural beauty, enthusiasm and charm that had me in love with her. She hardly changes in the nine years (story-wise and in reality) between their encounters. Hawke, young and dashingly handsome in the first, is a bit world-worn four years into the new Millennium.

Their conversations are never dull and amazingly naturalistic with no hint of scripting. Director Richard Linklater and crew pull off long, uninterrupted steady cam shots as Jesse and Celine talk their way through the streets of Paris.

In the special features on the second DVD, we learn that Before Sunset was was shot in 15 days - a collaboration between the two actors and Linklater. Delphy wrote much of the script and is credited with composing the song she sings near the end.

Definitely watch them in order. They could easily been one long movie, but it's more fun to see the actors as they have actually matured rather than through makeup. Both are available on DVD from Netflix.

Paradise Beach

2007-09-22T18:07:00.001-07:00

There are lots of Paradise Beaches in the world. You've probably been to a few. Last weekend, I visited my favorite.

We went south to the Pismo Beach-Arroyo Grande, CA area to spend the weekend with Liz's 78 year-old dad, Jerry. Liz's sister, Laurie, had died two years earlier of ovarian cancer. To commemorate the day, we went hiking on the beach – one of her favorite activities.

In the tiny Guadalupe Dunes parking lot, we ran into Laurie's husband who was visiting some of their favorite spots. From there, we headed south along the nearly deserted beach. Shortly, it was just us and a few surf fishermen. Off shore was a great stream of birds; mostly gulls and pelicans, also heading south. Apparently the anchovies were schooling and the birds feasting. Shortly we saw a mass of birds diving into the waves turning the surface to foam.

Just before the bluffs of Mussel Rock started to rise, we worked our way up into the dunes. The dune complex here is huge. As recently as 1982, vehicles were allowed to roam this area. Jerry was one of the dune buggy pioneers. He and Liz often reminisce about family outings in the dunes. Following a rough path through the dunes and beach scrub, we worked our way up over Mussel Rock. Stopping to chat with a couple coming the other way, we learned they had found some cougar (mountain lion, puma) tracks. There are plenty of tracks of all sizes in the sand: reptiles, birds, mammals. I'm not much of a tracker, but we think we saw tracks from snakes, centipedes, mice, rabbits, coyotes, deer, turkey vultures, and the rumored cougars.

The walking surface varies from loose sand, to hard pack and exposed sandstone. The wind had blasted the sand so hard in some spots that we barely dented the surface. It was a bit disconcerting to walk across a steep, open slope wondering if our soles would stick to the rock-like surface. There are a few exposed spots where the eroding sand drops over cliffs to the crashing surf below. Don't look down!

From the top of Mussel Rock, there are great views: north over the dunes, west over the ocean far below and south to Paradise Beach. We could see three fishermen. Aside from them the beach was deserted. A steep gully separates Mussel Rock from the beach. A trail of sorts leads straight down into the gully. Someone has installed a rope. It was a welcome aid as we, one-by-one, worked our way down the narrow, steep, loose-sand covered “trail.” In the bottom is a year-round stream, that drops over a 20-foot fall to the beach. Because of the drop, we had to work our way another hundred yards or so further south before we could safely descend to the beach. Calla Lilies grow along the cliffs. Some had been rooted up, apparently by wild pigs.

Liz and I backpacked here some years ago coming in from the Point Sal road to the south of the beach. At that time there had been a small, quaint driftwood shack up against the cliffs, but it had been washed away in later winter storms. Driftwood to driftwood.

Continuing south on the two mile long beach, we passed the fishermen – one had a fair-sized surf perch. Down further was a gathering of a dozen or so turkey vultures feasting on a seal carcass. They reluctantly scattered to the cliffs as we approached. In the carcass were still a few chunks of fresh-looking liver. Yum!

Sandstone cliffs supported some lovely hanging gardens above which the steep slopes rise over 400 feet. We spotted tracks in the sand that we guessed were from a mother cougar and two cubs looking for food washed up on beach.

The tide was in as we approached the southern end of the beach where we found a rocky inlet and stopped to have our lunch. There were six sea lions frolicking in the relatively calm pool. I found a spot that would have been great for diving, but despite the sunshine, it was a bit cool for swimming. Nearby tide pools were full of anenomes, little crabs and other life.

On the way back Jerry took the hard way up the cliff to the trail while we could only shake our heads at his tenacity as he struggled for sandy hand and foot holds. We conquered the rest of climb with the welcome help of the rope. Jerry took his time but seemed no worse for it after a rest at the top.

Large flocks of gulls and curlews resting on the sand from their earlier feast parted for us as we strode back up the Guadalupe Beach. We were tired but satisfied with our wilderness beach experience as we arrived at the parking lot after our nine mile round trip.

PeopleSoft and the Load Balancer

2007-09-12T20:51:00.000-07:00

We are doing a PeopleSoft PeopleTools upgrade among with upgrading our server environment to a "high availability" configuration. In PeopleTools, we are upgrading from 8.43 to 8.48. Many "little" things have broken. I'll write more about that in the future. This time I want to discuss a problem we had with the "high availability" configuration.

Our UNIX (Solaris) server setup includes a Cisco CSS Load Balancer, two boxes that host our redundant web servers (Weblogic) and Application Servers, and two boxes that host the database server (Oracle) and two process schedulers. There is a overall network that connects the load balancer and all four machines and a private network to connect the Application Servers to the database server.

The CSS has a virtual address to connect to the PeopleSoft web application (PIA) and balances the sessions between the two web servers. Each of the web servers is configured to use all four application server domains. This allows quite a bit of flexibility for fault tolerance and maintenance shutdowns. It also allows for horizontal scalability transparent to the users.

However, one of the problems we ran into involved the UNIX process schedulers and their ability to post files to the report repository. We have always used the FTP method for posting files. PeopleSoft also offers an HTTP post. As we learned through our troubleshooting, the FTP method has two steps. First the distribution server FTPs the files to report repository FTP address, then it sends an http query to the repository to confirm that the files are there. We initially configured the http address to our load balanced virtual host name. Our Windows process schedulers were able to successfully post files to the the report repository. Our UNIX process schedulers, however, would stay in Posting status and eventually go to Not Posted. By reviewing the logs, we figured out that the FTP was working fine. The files were actually in the repository, but http confirmation was failing. After a lot of testing, our network engineer determined that the http request was routed from the process scheduler through the CSS to a web server, but the web server response was routed directly to the database/process scheduler box through the private network. To the process scheduler distribution server, the response appeared to be coming from a server different than the one the request was sent to so the response was discarded.

If we configured the report repository http address to the actual host:port of one of the web servers, the distribution worked fine, but we lost the redundancy of the dual web servers for this function.

We also found that if we disabled the private network between the application servers and the database server, the http response was routed back through the CSS and distribution server was happy. This was not an ideal solution, though, because PeopleSoft is a very database intensive application and you want to optimize any communications between the application servers and the database.

Eventually, the network engineer came up with a solution involving a third NIC on the database server. I don't have details at the moment, but it works. I will post more information when I get it.

In future posts, I will go into other details of our architecture and the PeopleTools upgrade.

Biking the Bears

2007-09-09T21:22:00.000-07:00

I rode this morning with the Diablo Cyclists. They have changed their starting spot since the last time I rode with them to Heather Farms Park in Walnut Creek. To get more miles I rode from home to the start. It was a short (30 miles) but challenging ride around Briones Park. Reliez Valley and Alhambra and over Happy Valley to Lafayette. As usual, I was in the middle of the pack. Three tandems showed up, but with the hills they were trailing the whole way.

The lighter riders have the advantage on the climbs. The two women, both strong riders, would blow by me only to be caught on the downhills. It's a good club to ride with if you want to go pretty hard. I'm training for the Waves-to-Wine MS fund raising ride at the end of September so it was good to be with a group that could push me. Total miles: 46. Max speed: 40 mph.