July 25, 2005

Application Engine: Disadvantages

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, consider AE.
• 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.

Until next time...