PeopleSoft Grid Fun

I’ve been re-engineering an overly complicated page for the last year.  It has multiple grids on it – and it suffers hugely from the software anti-patterns Shotgun Surgery and Feature Creep to name a few.

For this first go-around of re-engineering / refactoring I’ve been pushing code into an App Package.  The page is maxed out regarding the ability to add objects – I don’t know if there’s a Christmas Tree design anti-pattern out there but if there is the page would be the poster child for it.

And the business wants more information.

I’ve designed it to use a secondary page for input, and all the code including the page activate code to be written into the App Package.

The page is going to be very basic – a grid plus the delivered secondary page OK and Cancel buttons.  It’s the grid that’s been fun to deal with.

I need to relabel the grid columns, set columns to be editable or not – and hide columns based on data values.  A perfect candidate for using the Grid Class SetProperties method, right?  Based on the documentation:

Use this method to set multiple properties (column enabled, column visibility, and column label) for one or more columns in a grid.

Here’s the problem with PeopleSoft documentation.  Let me show you the example supplied:

Grid Class Methods

&ARProp= CreateArrayRept(CreateArrayRept("", 4), 0);
&ARProp.Push(CreateArray("JOB_DETAIL", "Y", "Y", "Job Detail"));
&ARProp.Push(CreateArray("JOB_TIME", "Y", "Y", "Job Time"));
&mygrid.SetProperties(&ARProp);

Uhm.  I’m using this in an App Package class.  I have to declare all my variables.  This method of the Grid class requires a four-dimensional array.

Okay – so a two dimensional array is declared:

array of array of <some type>  <array name>

I figured a four dimensional array is declared:

array of array of array of array of <some type> <array name>

Tried it – and it worked… I could declare it, create it, push data into it.

Grid.SetProperties threw an error every time I tried to use that array.

Left it alone for a couple of days – did some other things – circled back.  Looked for examples where it’s used.  And found my perfect example in HRS_COMMON.HRS_CONTENT.UI.ContentGridLayout:

Local array of array of string &ARProps;
&ARProps = CreateArrayRept(CreateArrayRept(“”, 4), 0);
&ARProps.Push(CreateArray(Column Name, Column Enabled Y N, Column Visible Y N, Column Label));

If &ARProps.Len > 0 Then
&grid.SetProperties(&ARProps);
End-If;

Uhm.  Okay – so that array declaration looks… like it’s not what I’m expecting.  My C experience makes me not trust what I’m seeing – I’ve declared a two dimensional array, right?

It’s the CreateArrayRept method that looks to be the secret sauce here.  It’s created four sub-arrays in the second dimension of &ARProps.  And if arrays tend to give you a headache, thinking of that likely brings on a migraine.

So I refactored my code – made changes based on the above example – it works.

 

Gaaaaaaaah!

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);
  &mygrid.EnableColumns(&enable);
  &mygrid.ShowColumns(&enable);

end-method;

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);
   &utils.MyMethod(&WRK_TBL);
end-method;

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.

Oh.

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

Works.

A simple thing.

GAAAAAAAAAAAAAAAGH!

Application Package Weirdness

I’m in an environment that is at PTools level 8.53.  I’ve got a App Package with three classes, and I’m using PSUnit to test the various class methods before I use them in as part of a project I’m working on.

I’ve got a method that simply finds the next Saturday from the current date.  It’s very simple:

/**
* Sets the amend effective date to the
* next Saturday following the current system date.
*/
method SetNextSaturday
Local string &sql = “SELECT NEXT_DAY(sysdate,’SATURDAY’) from dual”;

SQLExec(&sql, &amend_effdt);

end-method;

The output bind variable &amend_effdt is defined as a private instance for the class.  The method SetNextSaturday is invoked within the class constructor, meaning that as soon as the class object is instantiated the method gets called.

My test is also very simple:

method Run_DateUtils
%This.Msg(“TestAmendUtils.Run_DateUtils”);
Local ZG_NEG_AMEND:AmendNegotiation:DateUtils &util = create ZG_NEG_AMEND:AmendNegotiation:DateUtils();
Local date &amend_dt = &util.amendEffDt;
Local string &sql = “SELECT NEXT_DAY(sysdate,’SATURDAY’) from dual”;
Local date &next_sat;
SQLExec(&sql, &next_sat);
%This.AssertDatesEqual(&amend_dt, &next_sat, “Method DateUtils not deriving amend date correctly!”)
end-method;

When tested this error is thrown:

Test [ZG_NEG_AMEND_TEST:TestDateUtils] failed!
SqlExec: parameter 2 is neither a record object nor a name. (2,284)

Odd.  The SQL runs perfectly in SQL Navigator.

And then I looked at the error explanation.  Parameter 2 is a problem.  Hmmmm.

So I refactored by declaring a local date variable in the method, then assign it’s value to the instance variable.  That worked.  That’s also ugly.

This has also been a problem since 2008 PTools version 8.44 based on this post.  It seems that a property cannot be an output argument of a function, and that an instance variable is treated as a property.

What makes this more confusing is apparently an instance variable is fine for input.  It can be read from, just not written to.

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);
   End-If;
  
end-method;

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;
      End-If;
   End-While;
  
   &_sql.Close();
  
   Return &_rtn;
  
end-method;

The SQL definition is fairly simple:

SELECT ‘X’
  FROM PS_JOB A
 WHERE A.EMPLID = :1
   AND A.EFFDT = (
 SELECT MAX(A1.EFFDT)
  FROM PS_JOB A1
 WHERE A1.EMPLID = A.EMPLID
   AND A1.EFFDT <= SYSDATE)
   AND A.EFFSEQ = (
 SELECT MAX(A2.EFFSEQ)
  FROM PS_JOB A2
 WHERE A2.EMPLID = A.EMPLID
   AND A2.EFFDT = 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”);
   End-For;
  
   /* 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”);
   End-For;
  
end-method;

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.

PSUnit Assert Tests

PSUnit provides a series of Assert tests.  In the article provided as part of the zipped download Jim Marion goes step by step into the process of creating a test.  However he only uses a single test: AssertStringsEqual.

I dug into the code and listed the tests you can do with PSUnit.

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

If the value in &isTrue is False, then the test fails.  From the program notes:

The first argument must be a boolean expression, which should evaluate to true.  If false, PSUnit throws an exception to indicate that the test failed.  The test runner catches the exception, marks the test as having failed, and continues on to the next test.

AssertStringsEqual(&str1 As string, &str2 As string, &onFail As string);

AssertStringsDiffer(&str1 As string, &str2 As string, &onFail As string);

AssertNumbersEqual(&num1 As number, &num2 As number, &onFail As string);

AssertNumbersDiffer(&num1 As number, &num2 As number, &onFail As string);

AssertDatesEqual(&date1 As date, &date2 As date, &onFail As string);

AssertDatesDiffer(&date1 As date, &date2 As date, &onFail As string);

AssertRowsetValuesEqual(&rs1 As Rowset, &rs2 As Rowset, &onFail As string);

Method first checks the ActiveRowCounts between the two rowsets.

Then the method tests that both rowsets come from the same Record.

Finally the method tests the fields in each row of each rowset for equality.

If an Assert test fails, the exception text which includes whatever message you pass on as part of the variable  &onFail gets sent to Class AssertFailed; which then calls the PeopleCode function CreateException.

PeopleSoft PSUnit

I first came across PSUnit in Jim Marion’s book PeopleSoft PeopleTools Tips & Techniques.  It’s a different tool from Test Framework – and you should consider it as complementary to PTF.

Jim has a write up of it here; there is another small explanation of it here.  Both articles give a link to the code, or you can get it here.

PSUnit is a Test Driven Development tool.  With Test Framework you code, create a page, and then put your page into a component.  The component gets applied to a menu which then get set into the registry.

With PSUnit you create a test framework Application Package, which gets plugged into an already existing test page.  Better yet – while Test Framework can help to point out where a transaction throws an exception, PSUnit lets you dig further and find out why.

From Jim Marion’s blog piece PSUnit Unit Testing Framework:

You, the developer, receive a notification from a user that page X of component COMP_X is calculating the wrong values. The user informs you that the calculation and error occur when he/she clicks save. From this information, you speculate that the calculation happens in the SavePreChange or SavePostChange event of the component or some record used in the component. Unfortunately, you are not familiar with this page or component.

With a PeopleCode trace, you are able to identify six potential events. You notice that these events call FUNCLIB’s and App Classes creating a horrendously deep call stack. From what you have in front of you, it is obvious that a quick review of this 3,000+ line trace file won’t provide an easy solution.

At this point you have several options:

Continue to treat COMP_X as a black box, investigating it from the outside.

Dig into the code and speculate as to its purpose.

Configure app server debugging and step through the deep call stack.

Start adding MessageBox statements to the delivered code so you can interrogate the state of the application as it runs.

We will choose the final option, the MessageBox option. Yes, this will require us to modify delivered code, but this modification should have no impact on the behavior of the code. The modification doesn’t concern me as much as forgetting to delete one of those MessageBox statements after I find and fix the problem. And then, once I find the correct combination of MessageBox statements to show the problematic data or logic, I hate to delete them, knowing I may have to visit this code at a future date (sooner then I want, but far enough in the future that I’ve already forgotten how I solved the problem). Wouldn’t it be nice if, once you found the appropriate combination of logging statements, you could just leave them in the code?

You should read the entire post.  I’ll list the various Assert tests that are available in another post.

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:

private
Constant &INVALID_EMPLID = 1;

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

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

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 +/
Return &INVALID_EMPLID;
end-get;

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:

ftp://anonymous:hobbit1@ftp.ps.com

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 www.savarese.org.

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;

protected

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

end-class;

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

The constructor does the heavy lifting for us:

/**
Constructor
*/
method FTPClientExtended

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

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

end-method;

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(“com.peoplesoft.hr.hr.ftpclient.ExFTPClient”);

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

end-method;

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();

end-method;

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();

end-method;

method rename

/+ &from as String, +/

/+ &to as String +/

/+ Returns Boolean +/

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

end-method;

method deleteFile

/+ &pathName as String +/

/+ Returns Boolean +/

Return &_ftp.deleteFile(&pathName);

end-method;

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.

%d bloggers like this: