The benefit of a progress bar to the users is that they can tell at a glance how far through a long running process is.

There are inherant problems with progress bars of course, in that they’re often less than 100% accurate.  Most people have at some point joked at the time estimates for file copy progress bars within Windows, and ‘Microsoft Minutes’ is sometimes used as an ananlogy for inaccurate and super-cautious time estimates.

Despite this, I believe they have a place.  For some processes – particularly those that run row-by-row – it’d be pretty easy to work out how far through it is by comparing the row number to the total number of rows.

Here’s how it’s done …

You can output a rudimentary progress bar by using an HTML table with a single row, and many columns.  Leave the cells empty but set the background colour differently for the cells representing the completed portion to those representing the incomplete area.

The code could look as follows (HTML formatted over more than one line for legibility):

&strl_progbar = "
<table width='300' cellspacing='3' cellpadding='0' border='0' height='20'>
   <tr>
      <td BGCOLOR=""#AAFFAA""></td>
      <td BGCOLOR=""#AAFFAA""></td>
      <td BGCOLOR=""#AAFFAA""></td>
      <td BGCOLOR=""#AAFFAA""></td>
      <td BGCOLOR=""#AAFFAA""></td>
      <td BGCOLOR=""#AAFFAA""></td>
      <td BGCOLOR=""#AAFFAA""></td>
      <td BGCOLOR=""#FFAAD4""></td>
      <td BGCOLOR=""#FFAAD4""></td>
      <td BGCOLOR=""#FFAAD4""></td>
   </tr>
</table>";
&nret = &api.notifyToWindow(AEPORTALCSS_AET.PROCESS_INSTANCE, &strl_progbar);

As you can probably see, this would produce a table with 7 green cells (the done proportion) and 3 red (the remaining work), and would look something like this:

The HTML may look a little clunky, but it’s to work around a couple of limitations.  For instance if you try to pass a percentage sign through to the HTML it gets stripped out.

Once this is up and working it’d be preferable to wrap this up in a short function rather than have the HTML long hand each time.

The default setting for ReUse is ‘No’, which means that each time the SQL Step is called it is recompiled and new execution plan generated, bad news if the SQL has to run a large number of times. If the ReUse setting is ‘Yes’ then any %Binds in the SQL statement are converted into ‘:1’, ‘:2’ etc. This means the statement can just be compiled once and the same plan used each time, resulting in really quite dramatic improvements in processing time.

In addition to the performance gain from the above, some databases also have an area of memory cache where recently used SQL is stored. Oracle definitely has this cache, I’m not sure about other databases. As each SQL statement would contain Binds rather than literals it would be an exact match for the previous SQL Statement enabling the database to use the cached SQL and thus giving a further performance boost.

As always, there are some exceptions. If the %Bind is either part of either a record or column name (using ‘NOQUOTES’) then it shouldn’t be used. If this is the case the record and/or field is changing each time and as a result a new plan would be needed, therefore PeopleSoft converts the Binds to statics.

The performance gains that this gives will vary depending upon your SQL and the data, but a recent opportunity I had to set the ReUse flag to Yes dropped processing time for an AE Section from 15 mins to just under 2. Well worth considering next time you write an App Engine …

The post was on IT Toolbox (peoplesoft.ittoolbox.com) and the poster was a guy called Neil Pak (at least that’s what the email said, I guess his real name could be anything).

The issue being discussed was one that’ll be familiar to all developers who’ve written a few App Engines in their time – needing to bounce the Process Scheduler to clear the cache, to get the Process Scheduler to use the latest changes. Sometimes it picks them up, sometimes it doesn’t, particularly if you’re changing an existing object – and for me this has happened mostly with SQL Objects.

The normal solution is to bounce the Process Scheduler and clear the cache, however this isn’t possible all the time. Perhaps there’s a long-running job that’s processing, or perhaps your friendly DBA/SysAdmin is busy getting a cuppa etc. Other times I’ve just cloned the SQL Object in question and appended a digit to the object name and used that version instead. This works also, but you do tend to end up with a stack of similarly named SQL Objects in your project.

Neil’s solution – and you’ll need access to the Process Scheduler server for this – is to delete some specific cache files. To quote Neil:

I did some testing and found that, at least for app engines that finished successfully, I could go in and delete the .dat and .key files (but not the cache.lok) and basically the cache was deleted … One could probably just delete all the .key and .dat files without much regard to which folder it was since any files still in use would not delete.

Note: I haven’t tested this myself yet.

Edit:

The original post did say that this was tested with the AESRVs disabled.  I had a quick test today and couldn’t delete any of the cache files under the AESRV directories.  I guess the processes keep them locked, or perhaps it was just that we had lots running.   I’ll update this post again if I find out more.

This occurred because our State Record was set as a Derived/Work record and our App Engine did not have restart disabled. As a result it was performing Commits after each Section (the default behaviour), and – this is the gotcha – a commit clears down the State Record!

According to PeopleBooks, this is by design. If you wish to have commits in your App Engine then your State Record must be setup as a SQL Table to keep its values.

This implies that you may need 2 state records for larger/more complex AEs. One SQL Table AET to hold variables that you wish to reference throughout your program, and one Dervied AET to hold values that you’ll reference immediately (i.e. variables that you wish to use in Dynamic SQL, like within a DoSelect).

There is a Customer Connection case explaining it further:
http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/C1C_MENU.C1_SOLN_SUMMARY.GBL?page=C1_SOLN_SUMMARY&SETID=SHARE&SOLUTION_ID=201024788