| Application Engine: Advantages | KEVIN RESCHENBERG
07-18-2005 |
Today I'll start tackling the question that comes up for every
installation—when to choose Application Engine instead of, for example,
COBOL or SQR, for custom batch processes.
To simplify the discussion, let's assume that SQR is the most common
alternative to App Engine.
Between App Engine and SQR, which is better? We can give a couple of easy
answers to this right now. First, if you are developing a report, use
SQR. App Engine doesn't do reports, unless you want to write the output
to an intermediate file or table and then process it further using, for example, SQR
or Crystal Reports.
The second easy answer to the question: If you are applying for a job at
Oracle, or trying to pass a certification test, or working in an all-AE shop,
then remember that "App Engine is always the best choice." If, on the other
hand, you are more concerned with actual real-world considerations, the question
is more difficult to answer.
Today let's look at the advantages of App Engine. (Next week we'll
have a look at the Dark Side.) PeopleBooks is eager to have us use AE, so
we can get a good list of the "pros" there. (The following were taken from
the 8.1x version of PeopleBooks, which probably represents a good average of the
current release levels.) My comments, some admittedly tongue-in-cheek, follow
in italics.
Performance: "Our in-house testing reveals that a well-constructed
and properly tuned Application Engine program achieves performance metrics
comparable to COBOL and SQR. In some cases, the Application Engine program
can out-perform both COBOL and SQR. However,...there are many other reasons
to choose Application Engine to develop your batch programs besides performance."
I've often heard that AE programs are faster but have never seen any
published evidence. I believe that this is an "urban legend" arising from the fact that
SQL set processing is generally much faster than row-by-row processing, and
AE does set processing. Actually, AE encourages set processing because it
makes row-by-row processing so difficult. SQR and other tools do set processing
too, but they don't force it. If we read the first sentence above, it
says that a well-constructed and properly tuned AE program is "comparable" to
(poorly constructed and untuned?) SQR. In other words, a good AE program
is approximately as good as an SQR program. I don't doubt that. But I have no
reason to believe that AE is faster than SQR. For a programmer who won't
write efficient SQL unless forced to do so, AE might be a good choice.
Encapsulation: "Unlike...SQR, Application Engine programs reside completely within your
database. ...you can run and debug your applications without leaving the PeopleTools
environment." PeopleBooks also points out that there are no compiles or "stored statements,"
which apply to COBOL only. This is a weird use of the word "encapsulation," but
it's true. Whether it's much of an advantage is debatable. I've never had much
trouble handling file folders. But this point leads into the next one...
Upgrade support: "[AE programs] join the growing ranks of PeopleTools
components that you can easily upgrade using Application Designer. ...if you change
[a] record definition, you can put the modified record into a project, and you can
then also include in the project any Application Engine programs affected by the
change... Then you upgrade the entire project all at once. With COBOL and SQR,
you have to do the record change, then modify your batch programs using some
other mechanism all while [making] sure to keep track of what was changed and how and
where it affects the batch program. With Application Engine and PeopleTools, it's
all taken care of automatically." OK, it's a little over the top, but this
passage is trying to say that compare reports and upgrade|copy operations are
supported only for PeopleTools objects, not files. But it also says that once you
write an AE program, you no longer need to be concerned with any record definition
changes, nor do you need to keep track of what was changed and how it affects your
AE programs. There is a grain of truth in this, but it applies only to limited
cases, especially where you are using meta-SQL. In the real world, no, it's not that
easy.
Reuse business logic: "Application Engine programs can now invoke
PeopleCode. ... Conversely, PeopleCode can now invoke an Application Engine
program." Finally, a real advantage! PeopleCode has a large amount of functionality
that can't be called directly from SQR. I recently developed some real-time
online update functionality and needed a batch version of the same thing.
AE was the only logical choice for this, since I could simply call the online
code instead of rewriting it again in another language.
Built-in restart logic: "[In an AE program], each COMMIT becomes a
checkpoint that Application Engine uses to locate where within a program to
restart after an abend. ... This type of built-in logic does not exist in
COBOL or SQR. You need to code any restart logic for your programs yourself."
AE does handle restarting "natively." When is this an advantage? Well, if
you have a process that tends to crash, it can come in handy. Of course, while
developing the process, you need to be sure that restartability is appropriate.
It is not always true that you can pick up where a program left off and
get the correct results. I'll go out on a limb and recommend better testing
as an alternative to planning for crashes. But this is, in fact, an advantage.
Just be sure that your users know when to restart and when to delete and
rerun!
Graphical user interface: "[With AE, you use] Application Designer,
an intuitive, graphical interface...[offering] the following benefits:
Ability to open multiple Application Engine programs concurrently; Easy access
to the PeopleCode and SQL editors; Two views of your program [the Definition
and Program Flow views]." Any text editor can open multiple SQR programs
and gives easy access to the editing window. AE does have an advantage in
that the code can be syntax-checked at some level. And the Program Flow
view is good. On the other hand, you'll have much better luck managing
your screen real estate using a text editor than with App Designer's views.
Overall, a small advantage for AE.
Enhanced SQL/meta-SQL support and Platform flexibility: These
two entries work together. "Meta-SQL" is a PeopleSoft extension that
will expand to the correct SQL. (This is outside the scope of today's
discussion.) It can save work, adjust to some table changes automatically,
and allow you to write code that will run under different RDBMSs. The
time-saving aspects can be helpful, as long as you don't want to test out
your SQL first, since your SQL client won't understand the meta-SQL
and the "resolve meta-SQL" function doesn't seem to do anything
in AE programs.
The platform flexibility aspect would seem to be more helpful for
PeopleSoft development and consulting organizations than for end users.
(How often do you
uproot your RDBMS and install a different one?) The meta-SQL that lists
fields from a record definition can be very useful, and this is not
available in SQR. The trouble is, it's needed in many cases because of
the way AE encourages the program to shift data around in ways that
would normally not be necessary. Overall, these points add up to another
relatively minor advantage for AE.
Data dictionary integration: This entry describes how AE overcomes
difficulties such as the need to adjust field sizes when a field
definition changes. "If you've ever had to perform such a manual
update of COBOL code, there's no need to imagine the degree of
irritation a programmer can experience." This problem, such as it is
(and I can tell you it's nowhere near the horror described in this
passage), occurs with COBOL
and we can ignore it here.
Effective dating: This one is not mentioned among the advantages
in PeopleBooks, but people sometimes point to it. AE program elements
are effective dated. This seems to fall into the "so what" category,
which I'm guessing is the reason it's not highlighted by PeopleBooks.
So where did we end up? With a couple of good advantages and some
so-so ones. Next Monday: The not-so-good side of AE.
|
