Introduction to the DataDumper Logger

Introduction to the CHG_DataDumper Application Class used for logging.

I want to introduce the data dumper PeopleCode Application Class. I’m releasing this code into the open. I think it will be extremely helpful for PeopleCode developers who need a more fine-tuned debugging platform for PeopleCode and PeopleTools objects. The full API Documentation is at DataDumper Documentation

There are different ways to do debugging in PeopleSoft, many of them are extremely robust and often times they are too robust for what is needed. So let’s review our debugging options that we have out of the box.

The first option is the trace utility. There are different trace options, and generally this traces your whole session. The trace can be invaluable tool to gain insight into what the code is doing. The problem with tracing is that it’s extremely robust and often times can produce huge files. There are many times that you just want to drill down and look at one piece of code or just one function or one object at a point in time. When you do a trace it takes time to get it off the server, drill down to the section you need and then decipher what is in the trace. Tracesql files take some experience to read efficiently and they are not very user-friendly.

The next delivered debugging option available for the PeopleCode developer is the online PeopleCode debugger. This is an extremely robust tool. It does have some quirks, but it is very powerful and very slick for PeopleCode developers. If you are trying to do debugging on a few sections of code the debugger allows you to set break points. Additionally, when you are in the debugger mode you can view the different types of variables, objects and the component buffer. I like the Debugger and it has been invaluable to me over the years. The problem I find with the debugger is that when I go to different clients it is not always enabled. Often times the database you need to debug in is a test database where the debugger may not be configured. I have run across some system admins that will just not turn it on or it may take days for them to get around to it.

The next reasonable option is to open up a file using the GetFile function and do WriteLine calls to dump strings out to the file. This works and can be cumbersome and introduces a large amount of duplicate code. This method can be really useful for a very narrow scope of debugging.

Jim Marion has also documented a slick alternative using the log4j java library. That looks very promising. However, it requires that some java class files be put on the server. I have several clients that are highly restricted of what goes on the server. So this option will not always work.

This is where my new DataDumper Application Class comes. It is an application class that allows you to selectively dump different types of PeopleSoft objects to a file.

The debugger has the ability to dump the following object types to a file.

• Strings
• Record
• Array of Records
• Rowset
• Row
• Array
• Array of String

Additionally, it can email the file results straight to you. Since this is written as a PeopleCode application class, no server components are required. You just need to import the application Class and start using it.

My vision for the DataDumper was to allow me to dump objects to a file and have them actually be readable without a PHD in Trace files. When I write Peoplecode, I often pass record objects and rowset objects as parameters. This datadumper has allowed me to quickly find issues with my code an not waste unwanted time stepping through the PeopleCode debugger or wading through 200,000 line trace files. Since the DataDumper class can also email you the file that was created, it makes debugging even faster because you get the file right in your inbox.

So let’s go over what it takes to create and use the data dump.

The first step is the import app package. You must import the application package into your database.

The next step is to declare the data dumper object. This object you be using methods on to do all dumping of object history. This takes an optional filename which we created on the application server “logs” directory. If you don’t pass in a file name, It will actually create one for you based on your userid of the person logged in. The important thing to note here is that when it opens the file it will actually overwrite any existing content. So if you are calling the instantiation method in a for loop, the file will get overwritten and at the end you will be left with the data from the last loop.

import CHG_DEBUG:dataDumper;

Local CHG_DEBUG:dataDumper &z = create CHG_DEBUG:dataDumper("myDebug.txt"); 

Start Dumping Data. See the full documentation for a list of methods.

In this example lets dump the the PSOPRDEFN table

import CHG_DEBUG:dataDumper;
Local CHG_DEBUG:dataDumper &z = create CHG_DEBUG:dataDumper("myDebug.txt");
Local Record &recOpr;
&recOpr = CreateRecord(Record.PSOPRDEFN);
&recOpr.OPRID.Value = "PS";
&recOpr.SelectByKey();
&z.dump("Here comes the PSORPDEFNDUMP");
&z.dump("I am going to change the description field to demo the output");
&recOpr.OPRDEFNDESC.Value = "MY NEW VALUE";
&z.whiteSpace(3);
&z.indentLevel = 2;
&z.dumpRecord(&recOpr);
&z.emailDumpFile("someuser@somedomain.com"); 

The output of this would be the following: MyDebug.txt

In this example, we just demonstrated the small piece of the functionality. Please see the full documentation for all available methods.