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!

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.

%d bloggers like this: