|Application Engine: Disadvantages||KEVIN RESCHENBERG|
Last week's item discussed
some of the advantages of Applicaton Engine, mostly based on the list provided
in PeopleBooks. App Engine offers clear advantages over COBOL, but the
focus was on SQR. In that case, I concluded that App Engine has one
real advantage: Access to PeopleCode's rich functionality, which also allows
us to duplicate online processing. In addition, App Engine natively
supports restartability. When it is appropriate, this can be an important
consideration, although I can't think of too many processes that need this and
I question the stability of a process that needs to be restarted all the
time. The upgrade|copy support for App Engine is
useful, altnough it doesn't eliminate the need to
evaluate and retrofit changes, as PeopleBooks implies.
There were also a few other slight advantages that apply in some cases.
Today I'll talk about some of the disadvantages of App Engine. With one
exception, these are
not highlighted in PeopleBooks for some reason! But they are easy to find.
The one disadvantage—or limitation—mentioned in PeopleBooks is that App Engine
doesn't do reports. Even if you prefer AE, you'll still need Crystal Reports, SQR
or some other method of producing reports.
Now let's consider AE as a programming environment.
App Engine doesn't let us see the entire program, or even pieces of it,
in a listing. If you want to see the actual code, you need to find the
correct step and open it to see just one "action." One online commentator, speaking of App Engine, called this
"programming through a keyhole." It's disorienting and time-consuming.
Formatting of code is another major problem. App Engine was specifically
designed to string together SQL steps (PeopleCode was added only recently).
The set processing and performance "advantages" claimed by PeopleBooks relate
to SQL. How does AE display SQL? It does its own formatting. Since AE encourages
us to abandon normal procedural coding and cram everything into SQL, the
SQL can become tricky, to put it mildly. Even straightforward SQL can contain
multiple levels of nested subselects. Naturally, we would like to format the
SQL to make it readable and understandable. That's fine, except that App Designer
will then throw out your formatting and push everything over to the left margin.
Your SQL becomes difficult or impossible to understand.
We could help with the understanding of our SQL by adding inline comments,
or by commenting out individual lines of a large SQL block to show where changes
were made. But AE doesn't seem to allow this. (I've been able to comment view text but
not AE SQL.)
Ah, but there's always the ability to add comments within the AE designer,
right? Yes. One problem, though: The user must know that the comment exists,
because it's normally invisible. To see the comment, you need to know (or
suspect) it's there, and open it up!
Section and step names are restricted in length, so it's common to see steps
named STEP01, STEP02...you get the idea—and not always even in that order.
There is a small box to the right of the step name, but since it's not part
of the actual "code" (as a programming language's procedure or function
name would be), how often is it used?
So why use AE at all? As I noted earlier, AE was designed for SQL. Once
PeopleCode was added as an option, I thought that AE finally had a good
reason to exist. But
when I attended a PeopleSoft training class on the new version, the instructor specifically
discouraged using AE to run PeopleCode! I'll respectfully disagree here and
say that PeopleCode makes AE an option. My recommendations:
- If you prefer to use PeopleCode or need access to it in order to duplicate
online functionality or in order to use its large feature set, use AE
instead of SQR.
- If you require restartability and AE supports your other requirements, use AE.
(But think about why restartability is a requirement.)
- If your process is going to be relatively small, with simple SQL,
- Otherwise, avoid App Engine. It does nothing to help,
and much to hinder,
development and maintenance.
Occasionally I hear of an installation that is attempting to
standardize on AE and may actually be in the process of converting existing
processes to AE. This is difficult to understand. For processes that
lend themselves to procedural logic or contain complex SQL, AE seems to be a very
poor choice, especially considering the alternatives available.