I keep telling people who come to me for help that it’s always the simple things. That little gotcha you forgot, glossed over, didn’t think about…

A simple thing. An easy peasy every day thing. Disable a column in a PeopleSoft page.

The code resides in an Application Package:

method MyMethod
  /+ &grid_name as String +/ Local array of array of string &enable;   


  Local Grid &mygrid = GetGrid(@&my_page, &_grid);


The above method gets called by a test method in another App Package – I’m using a tool called PSunit for my unit testing:

method Test_MyMethod
   %This.Msg(" ");
   %This.Msg("Test_GridUtils: Test_MyMethod: " | &WRK_TBL);

I attached a test page to the PSUnit component. I figured I’d be able to see the results after I fired the test.The test ran fine. No errors. But… the grid on the test page never changed.

I spent a couple of hours between meetings trying to get the grid on the test page to work. Everything worked fine. Just… no change to the grid. Worse the grid showed the data I sent to it as part of the test, it was the disabling of columns and the hiding of columns that didn’t take place.

After checking and rechecking syntax, spelling, specifications of the methods I was using I finally re-read the specification of the Grid Class in PeopleCode and found this line:

The attributes you set for displaying a page grid remain in effect only while the page is active.


Placed the call to the method in the page activate event for the page.


A simple thing.


Excel VBA Error #1004 – Excel cannot access the file

This is primarily a PeopleSoft nVision post – but it also pertains to Excel developers.  For those not familiar with it, nVision is a wrapper provided by Oracle/PeopleSoft whereby the Excel application can be used by PeopleSoft processes.  What gets produced is an Excel workbook.

Excel is installed on an application server, and is called via the nVision wrapper.  A number of our nVision layouts (Excel workbooks) have VBA macro code associated with them.

A shift in providing reports to consumers was recently made within the company.  Up til recently the reports were available from shares on the application server where nVision/Excel was running.  That’s been changed – the reports now have to be made available on a separate file server share.

And to make things both simpler as well as complex, the older style UNC path would no longer be allowed; instead all paths have to be DFS pointers.

Our users started running into random problems shortly after the change.  The common error was:

Error Source: Microsoft Office Excel.  Error #1004 – Description: Microsoft Office Excel cannot access the file ‘some file name’. There are several possible reasons:

The file name or path does not exist.

The file is being used by another program.

The workbook you are trying to save has the same name as a currently open workbook.

VBA Help Message # 1001004.

I was able to pin point what code was throwing the error, and it was in a section that does the following:

  1. Create a new workbook from a template
  2. Save the new workbook with a unique file name
  3. Copy some text from the source workbook
  4. Paste it into the new workbook
  5. Run some more vba to make the new worksheets pretty
  6. Save the new workbook and close it out

Rinse and repeat another several hundred times.  It took a couple of tries but from what I determined the error would always get thrown when attempting some action on the new (target) workbook.  And since that workbook was now being created in a remote share, DFS was the culprit.

That is a reasonable assumption based on how DFS works.  That’s not a topic for this post – if you want more Microsoft has an article here.  Note this line from the link – DFS requires Domain Name System (DNS) and Active Directory replication are working properly.

I see DNS and I think HTTP, network packets, domain controllers and RPC.  A far too complex environment for VBA to be operating in.

So to resolve the issue I changed where the work was being done.  Instead of saving the new workbook over the wire to the final destination and then doing more work to it via VBA; the work is back to being done in the same place the source workbook is.  That path is guaranteed by getting the ThisWorkbook.Path value of the source workbook.

So the above list is back to getting accomplished locally.  Once step 6 is complete there are two more items to the task list:

  • Use FIleSystemObject method CopyFile – and put a copy of the new workbook in the new reports share using DFS
  • Then user FileSystemObject method DeleteFile to get rid of the local copy of the new workbook.

No more random errors and the users are back to being happy.  And company policy is maintained.

PSUNIT – a few odds and ends

This is a quick follow-up to the earlier posts I’ve made about PSUnit.  To get more familiarity with the tool I had started to build tests against a piece of a project I had just finished up and moved into production.

I was confident the code in the project was good as I had run test files against it continuously as I was coding.

A PSUnit test found a bug.

Ouch.  Glad I found it and not someone else, and it’s good to have found it now while other parts of the project are still outstanding.  And I’m kicking myself for not having used the PSUnit tool while I was writing the code for the project.

One more thing.  I’ve zipped up a project based on the code provided in the readme file you get if you install the PSUnit tool.  It’s available here.  I created it going thru the readme step by step – the code in the zip file is the result.  It was built using PTools 8.51.

PSUnit – Adding Tests

In my previous post I showed the various Assert tests that come with the PSUnit project.  I decided to add another test to the code.

There is only a single boolean Assert test – which checks if the value is True.  But there are times when a boolean False is the correct response.  So I added an AssertFalse test to the code:

AssertFalse(&isTrue As boolean, &onFail As string);

If the value in &isTrue is True, then the test fails.

Clearly you need to have pulled the PSUnit project into a PeopleSoft database instance and created the tables.  From here, start App Designer and open the TTS_UNITTEST Application Package.

You want to click on the TestBase app class and view the PeopleCode associated with it.

In the class TestBase I added the method definition:

  • method AssertFalse(&isTrue As boolean, &onFail As string);

Then I added the code for the method:

/* This was added to test for boolean False values */
method AssertFalse
   /+ &isTrue as Boolean, +/
   /+ &onFail as String +/
   If (&isTrue) Then
      throw create TTS_UNITTEST:Exceptions:AssertFailed(&onFail);

How is this useful?  Let’s take an example of checking for a valid emplid.  I have a method:

method isEmplidValid
   /+ &empID as String +/
   /+ Returns Boolean +/
   Local boolean &_rtn = False;
   Local string &_msg;
   Local SQL &_sql;
   &_sql = GetSQL(SQL.VALID_EMPLID_CHECK, &empID);
   While &_sql.Fetch(&_msg)
      If &_msg = “X” Then
         &_rtn = True;
   Return &_rtn;

The SQL definition is fairly simple:

   AND A.EFFDT = (

This method validates emplids against the JOB table.  A return of False is a correct data state in this instance.  The Assert test would throw an error even though I should expect some values to return as false.

Next I create the tests.  I have two arrays – one has valid emplids for the organization; the other has invalid emplids.  I can now do both positive and negative testing with this method:

method TestIsEmplidValid
   %This.Msg(“TestFieldsCheckField: TestCheckChars”);
   Local boolean &rtn;
   Local integer &i;
   &rtn = False;
   Local PKGE:EMPLOYEE:CheckEmplid &target = create PKGE:EMPLOYEE:CheckEmplid();
   /* First the positive test */
   For &i = 1 To &_EmplidArray.Len;
      %This.Msg(“TestIsEmplidValid: Assert Test Value: ” | &_EmplidArray [&i]);
      &rtn = &target.isEmplidValid(&_EmplidArray [&i]);
      %This.Assert(&rtn, “Assert method failed”);
   /* Then the negative test */
   For &i = 1 To &_BadEmplidArray.Len;
      %This.Msg(“TestIsEmplidValid: AssertFalse Test Value: ” | &_BadEmplidArray [&i]);
      &rtn = &target.isEmplidValid(&_BadEmplidArray [&i]);
      %This.AssertFalse(&rtn, “AssertFalse method failed”);

Having the AssertFalse method allows me to confirm that my checking routine is working correctly.  I’m able to test that my program can gracefully handle invalid/incorrect data.

More fun with Application Packages – Instances

In my last post I had made this statement:

Instance variables are like Static variables in Java.

Hat tip to Helena who provided insight:

One comment though – instance variables are not static variables (in terms of scoping rules, one the same private instance variable is not shared by multiple instances of the class); they are in fact instantiated for each instance/object of the class.

So if I have a class definition ClassDef, with 1 private instance variable &InstanceVar, and I instantiate 2 objects of type ClassDef, I will have 2 instances of &InstanceVar in memory, not just 1.

This contrasts with static member variables in Java, where the variable is shared and in the example above, only 1 instance of &InstanceVar would have been allocated in memory.

Good point – so lets dig into this a bit – as others have here and here.

Since I made the statement like Static variables in Java let’s look at what those are.  From Oracle’s Java Tutorials on Understanding Instance and Class Members:

When a number of objects are created from the same class blueprint, they each have their own distinct copies of instance variables. In the case of the Bicycle class, the instance variables are cadence, gear, and speed. Each Bicycle object has its own values for these variables, stored in different memory locations.

Sometimes, you want to have variables that are common to all objects. This is accomplished with the static modifier. Fields that have the static modifier in their declaration are called static fields or class variables. They are associated with the class, rather than with any object. Every instance of the class shares a class variable, which is in one fixed location in memory. Any object can change the value of a class variable, but class variables can also be manipulated without creating an instance of the class.

I added the bolding and underlining in the above.  So as Helena pointed out, in Java the same memory location is used by every instance of the class having a variable defined as static.  Each instance of a class gets a reference (having been weaned with C I would say pointer but a Java purist would start throwing acorns at me) to the location in memory where the value actually resides.  Which falls in line with how memory allocation works in Java.  Java stores objects on the heap, variables sit on the stack.  But variables are ‘merely’ pointers/references to the objects sitting on the stack.  Enough teasing – I also know there are differences between a pointer and a reference – but that is a C++ convention, not C.  In any event, it’s efficient for Java to have Static variables work this way.

PeopleBooks provides this tidbit in Declaring Private Instance Variables:

A private instance variable is private to the class, not just to the object instance. For example, consider a linked-list class where one instance needs to update the pointer in another instance. Another example is the following class declaration:

class Example private instance number &Num; end-class;

A method of Example could reference another instance of the Example &Num instance variable as:

&X = &SomeOtherExample.Num;

Avoid making every instance-scoped variable a public property. You should consider each variable individually and decide if it belongs in the public interface or not. If it does, decide if the variable warrants get or set modifiers and therefore should be a public property. If the variable only serves internal purposes to the class, it should be declared as a private instance variable.

Again, I added bolding and underline.  But note the word pointer – a double plus unJava word.  So lets look at a language that does use pointers.

I’m a pack rat.  I don’t throw books away.  So I looked in my collection and grabbed my copy of Deitel & Deitel C++ How To Program:

Each object of a class has its own copy of all the data members in the class.  In certain cases only one copy of a variable should be shared by all objects of a class…  A static class variable represents “class-wide” information. 

Let us motivate the need for static class-wide data with a video game example.  Suppose we have a video game with Martians and other space creatures.  Each Martian needs to be brave and willing to attack other space creatures when the Martian is aware that there are at least 5 Martians present.  If there are fewer than 5 Martians present, each Martian becomes cowardly.  So each Martian needs to know the martianCount.  We could endow class Martian with martianCount as a data member.  If we do this, then every Martian will have a separate copy of the data member and every time we create a new Martian we will have to update the data member martianCount in every Martian.  This wastes space with the redundant copies and wastes time in updating the separate copies.  Instead, we declare martianCount to be static.  This makes martianCount class-wide data.  Every Martian can see the martianCount as if it were a data member of the Martian, but only one copy of the static martianCount is maintained by C++  This saves space.  We save time by having the Martian constructor increment the static martianCount.  Because there is only one copy, we do not have to increment separate copies of martianCount for each Martian object.

Hmmm.  Something fishy here.  Both C++ and Java are using static variables the same way.  Let’s look at PeopleSoft some more.  There is some code here that bolsters what Helena had pointed out.  The instance in an App Package class gets instantiated as its own distinct block of memory – so it breaks the notion and value of having a C++/Java type static variable.  However it’s able to be referenced and changed by another instance of the same class.   So take the less efficient part of the Deitel explanation and there you have it.

To my mind this is bordering on an architectural bad smell of connector-envy, and can lead to some code smells on the part of development.

Defining and Using Constants with PS Application Package

I’ve used Application Packages more and more after reading about them in Jim Marion’s PeopleSoft PeopleTools Tips & Techniques.  And I like using them far more than creating functions in a FUNCLIB_ library.

I’ve got an App Engine program I’m developing, and I’m using an App Package class for error handling.  I’ve a small list of error codes that get sent by the exception handler routine and those codes are used to get a description.  I could use message catalog for the texts of course, but in this case I’m going to be lazy and keep the values in the code.  This is for a batch process that will be scheduled to run nightly; it isn’t customer facing.

To avoid having magic numbers appear in my code I wanted to define a set of constant integer values in the App Package class.  PeopleBooks gets a bit obtuse on this subject though.

So, let’s go thru the exercise of creating them, then how to use them.

In the class definition I create a private constant:

Constant &INVALID_EMPLID = 1;

So far, so good.  any methods inside the class can use that value:

Evaluate &errCode
&msg = “Invalid emplid provided.”;

But I want the code throwing the exception access to the same constant.  PS App Package definitions are – well – eccentric.

Java, C++ and C# class structures look similar.  You define the class, then add fields if needed, and the methods of the class.

App Packages have methods, but then bring in the idea of properties and instances as well as Constants.

A property is exactly that, it’s a property of the instantiated object from the class – it’s the Has A of the object.  As in my class House Has A property of RoomColor.  PeopleBooks provides an explanation for a property as an attribute of an object.

Instance variables are like Static variables in Java.  An instance is private to the class, not just to the instantiated object.

Which gets us nowhere in terms of having our constant value used in my exception handling – yet.

Here is the key part – PeopleSoft set up properties to take the place of creating get and set methods.  They consider it more efficient to declare a property (which has no parameters) than to use a method to do get/set routines.

So instead of having a method:

method getSomething() as integer;

You would instead declare a property:

property integer mySomething get;

This was the long way around to explain how I get to use my Constants definition.  You saw above where I created a constant for &INVALID_EMPLID.

I declare a public (this has to be public – PS will bark at you if you try to do anything else with it) property – making sure it has a get as part of the definition:

property integer invalidEmplid get;

Then you write a get routine:

get invalidEmplid
/+ Returns Integer +/

Now my App Engine code can access that constant value – assuming that I’ve declared the App Package Class inside the code:

&errnum = &err.invalidEmplid;

If I find later on that I want to change the value &INVALID_EMPLID points to, I only have to do it in one place.  Less code maintenance, which is the real value of not using magic number coding.

Extending PeopleSoft FTPClient App Package Class

This post will be covering a few items under the same topic.

We ran into problems with the built in FTP PeopleCode functions with 8.51.  So for example, to use GetAttachment, one of the parameters you are to supply is URLDestination, which would resolve to something like:

Where anonymous is the user name, and hobbit1 the password.

If you are in an Active Directory situation, and the domain needs to be a part of the username:

<domain name>/<user name>

With tools 8.51 that slash throws an error.  So to resolve this we stopped using the built-in functions, replaced them with calls to the supplied HCSC:FTP:CLIENT:FTPClient Application Package/Class.

The class FTPClient calls an open source netcomponents.jar file, provided by

There is a problem with the delivered app package however, the developers never allowed for the FTP return codes.  I’m providing a simple fix. While I was at it, I added FTP rename and delete functionality.

I created an App Package, then added a new class with the methods I wanted:

class FTPClientExtended extends HCSC:FTP:CLIENT:FTPClient
/** Constructor*/
method FTPClientExtended();
Returns the integer value of the reply code of the last FTP reply.
You will usually only use this method after you connect to the FTP
server to check that the connection was successful since connect is of type void.
method getReplyCode() Returns integer;

Returns the entire text of the last FTP server response exactly as it was received,
including all end of line markers in NETASCII format.
method getReplyString() Returns string;

Renames a remote file.
Parameters:from – the name of the remote file to rename.
to   – the new name of the remote file.
Returns:True if successfully completed, false if not.
method rename(&from As string, &to As string) Returns boolean;

/* Deletes a file on the FTP server.
Parameters:pathname – The pathname of the file to be deleted.
Returns:True if successfully completed, false if not. */
method deleteFile(&pathName As string) Returns boolean;


/** holds reference to Java ftp object */
property JavaObject _ftp;


Note the extended keyword.  This class is now a subclass of the delivered FTPClient.

The constructor does the heavy lifting for us:

method FTPClientExtended

/* Create the base class constructor */
%Super = create HCSC:FTP:CLIENT:FTPClient();

/* create pointer to Base class Java object */
&_ftp = %Super._ftp;


We create Superclass references to the class and the base class Java object.   Take a look at the delivered FTPClient Application Class constructor:

method FTPClient

/* Create the base class constructor */
%Super = create HCSC:COMMON:BASE:JavaBase(“”);

/* create Java object for splitter */
&_ftp = %Super.getJavaObject();


The base class FTPClient is iteslf using Superclass references.

The rest gets very straight foward:

method getReplyCode

/+ Returns Integer +/

/* Return the FTP code – use to determine if failed or successful */

Return &_ftp.getReplyCode();


method getReplyString

/+ Returns String +/

/* Returns the entire text of the last FTP server response exactly as it  was received, including all end of line markers in NETASCII format.  */

Return &_ftp.getReplyString();


method rename

/+ &from as String, +/

/+ &to as String +/

/+ Returns Boolean +/

Return &_ftp.rename(&from, &to);


method deleteFile

/+ &pathName as String +/

/+ Returns Boolean +/

Return &_ftp.deleteFile(&pathName);


By creating a new Package and class, I’ve added functionality but without having to customize the delivered code.  Come upgrade time this is (hopefully!) going to be a lot easier to deal with.

PeopleSoft Integration Broker setup for Test Framework – Part V

How to get to the Integration Broker Error Log.

In our environment we use Windows as our web server OS.  So the paths I’m giving here may not be correct for a UNIX flavor environment.

In any event, to reach this log you need to have read access to the webserv directory on your web server.  The path should be something like:

<instance name>\webserv\<instance name>\applications\peoplesoft\PSIGW.war\errorLog.html

This log provides information in this general format:

  • Time and Date of error
  • Error Type
  • Error Level
  • Description of error
  • Message Catalog Information
  • Stack Trace
  • Request
  • Response

The Message Catalog information is from PeopleTools – and it points you in the general direction.  There may or may not be MessageParms which can further help with debugging.

Next, this is a Java web/servlet application.  So the stack trace is a Java exception log.  Sort of useful to read and get a handle on what is going on, but the other two panels may help more.

The Request part shows the SOAP XML request sent by PTF  to the Anonymous Node.  The listener for Integration Broker gets this HTTP request and attempts to route it to the correct node.

The Response part shows the SOAP XML message being returned by the listener.

So what is the usefulness of this?  Well – PTF is kinda dumb, but maybe in a smart way.  If it can’t make a connection to a node it makes you think you put in the wrong user name or password.  Good for a web login for security purposes – but come on!  This tool isn’t for the general user.

So the IB log can tell you things that the PTF login won’t.  I find it useful as I step thru the process of making changes in Integration Broker, attempt to log in, then look at the error log file.  As changes are made you should see different errors thrown until you get to that magic moment where PTF has logged into the node and the tool IDE opens up.

PeopleSoft Integration Broker setup for Test Framework – Part IV

Let’s cover security that is needed to use PTF in terms of Integration Broker.

First of all, the Default User ID of your Anonymous Node.  Let’s cover the roles that user ID should have:

  • PeopleTools
  • PTF Administrator

I’ve also added PTF Editor, PTF User to the node user ID.

Couple of other things – these are settings that should be set by default in your Service Operations.

  • Service Operation GENCOMPONENTURL_SO should have permissions PTPT1000 (PeopleSoft User) and PTPT3400 (PTF Admin).
  • Service Operation PTTST_CONFIG should have permissions PTPT3400 (PTF Admin), PTPT3600 (PTF Editor) and PTPT3700 (PTF User) assigned. All three permission lists should have Full Access.
  • Service Operation PT_SOAPTESTER should have permissions PTPT1000 (PS User) and PTPT 3400 (PTF Admin); again these permissions should have Full Access set.  I usually add permissions ALLPANLS but your mileage may vary.

Your users are also going to have to have one of the thee PTF roles assigned, as well as PeopleTools.

We are winding down here, next post should cover it.  There I’m going to cover an IB error log that can be very useful.

PeopleSoft Integration Broker setup for Test Framework – Part III

Earlier posts dealt with making sure the default local node was set up correctly and some basics on Quick Configuration.  In this post I’m going to talk about the Anonymous Node.

The Anonymous Node is used by Integration Broker.  You should have the following settings at a minimum:

On the Node Definition Tab – Node Type: External; Authentication Open: None; Default User ID: here the ID needs to have access to the PeopleTools roles as well as the PTF roles.  I’ll be covering security in later posts.  Active Tab should be selected as well as Segment Aware.

Connectors Tab – Leave the Gateway ID set to Local, you don’t need a Connector ID.  I have my Delivery Mode set to Guaranteed.  Don’t bother pinging – it should fail.

Portal Tab – I usually set mine up the same as the Default Local Node.

WS Security Tab – the Authentication Token Type needs to be None.

Routings Tab.  Here we run into the real meat of setting up the Anonymous Node for PTF.  I make sure the following routings and service operations are set up for the node:

  • PT_SOAPTESTER_ROUTE, uses the PT_SOAPTESTER Service Operation
  • PTTST_CONFIG, uses the PTTST_CONFIG Service Operation

On all three of these the following properties should be seen on the page:

  • OType – Synch
  • Sender Node – ANONYMOUS
  • Receiver Node – Your Current Correctly Configured Default Local Node
  • Direction – Inbound
  • Status – Active

The Receiver Node will be the tip off if you are having problems – most especially with a database that has been created from a refresh from production.  If there is anything else in the Receiver Node column outside of the default local node the Anonymous Node isn’t set up correctly, and PTF will fail.

You can try to inactivate a bad routing and or service operation and then recreate them – however what I’ve found is go thru the process of renaming the default local node.  I cover that in Part I of this PTF setup.

%d bloggers like this: