Introducing Application Engine
Application Engine is the PeopleTool that you use to develop batch or online programs that are effective alternatives to COBOL or SQR programs (for non-report processing). Using Application Engine, you can create programs that perform high-volume, background processing against your data. 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, as you'll see later in this chapter, there are many other reasons to choose Application Engine to develop your batch programs besides performance.
To invoke an Application Engine program from a PeopleSoft application, you can use Process Scheduler or you can use PeopleCode. You can also invoke an Application Engine program manually from the command line. Most Application Engine programs are scheduled to run using the Process Scheduler.
After reading this section, you will be familiar the following:
· The components of Application Engine.
· What Application Engine is designed to do.
· How SQL and PeopleCode fit in.
· The benefits of Application Engine over SQR or COBOL.
· The basic components and terminology with which you will need to become familiar before you delve further into this PeopleBook.
What is Application Engine?
Application Engine is comprised of two distinct components: the "front-end" where you define your batch program and the "back-end," which entails running and monitoring your program. This is analogous to other PeopleTools, such as Process Scheduler, where a definitional component is separate from the run-time component. You can access the Application Engine front-end, or development component, by way of Application Designer. This is where you initially define and, later, maintain an Application Engine program. The back-end is the PeopleTools executable that runs the Application Engine program you developed.
In the realm of Application Engine, a program is a set of SQL statements, PeopleCode, and Program Control Actions (that allow looping and conditional logic) defined in Application Designer that performs a business process. You can use Application Engine for straight, row-by-row processing, but the most efficient Application Engine programs are written to perform set-based processing.
Application Engine does not generate SQL or PeopleCode. It is only designed to execute the SQL and PeopleCode that you include in an Application Engine Action as part of your overall program. Think of Application Engine as a tool that allows you to define a program's framework, as in its algorithm, structure, and looping constructs. But, Application Engine relies on the developer to include the "guts" within the program's framework, such as the SQL and PeopleCode. As you'll see later in this section, there are many reasons why you should choose Application Engine as the "shell" to execute your business logic.
We assume that you have the expertise necessary to construct efficient SQL and PeopleCode to apply your business rules. Application Engine is arguably one of the most powerful tools that PeopleTools offers, but it can not compensate for inefficient program logic. As with any software development tool, it can only do what you "tell" it to do.
As far as SQL is concerned, you can use your native SQL query utility to compose your SQL statements, or you can just use the PeopleTools SQL Editor. Where you decide to write your SQL is irrelevant, although most will find that using the SQL Editor is more convenient. The Application Engine designer interface automatically launches the SQL Editor where appropriate. If you do opt to compose your SQL outside of the SQL Editor, when you're done all you have to do is paste it into the appropriate Action within your Application Engine program.
Being able to add PeopleCode to your Application Engine programs can improve performance, and using PeopleCode means that you don't have to use SQL for everything, such as assignments, conditions, and SQL text building. Also, it allows you to take advantage of features such as the PeopleCode File objects and Interlink objects, Component Interfaces, Application Messaging, and so on. PeopleCode also allows you to reuse online functions and control the flow of the Application Engine program.
To add PeopleCode, just use the PeopleCode Editor. When you've added a PeopleCode Action, you can automatically launch the PeopleCode Editor from the Application Designer interface.
Why Use Application Engine?
As stated previously, we designed Application Engine for batch processing where you have a large (or small) amount of data that needs to be processed without user intervention. An example of a typical batch process would be calculating the salaries in payroll processing (not printing the checks). Another example might be converting data (money) from one currency to another.Well, anyone who is considering the use of Application Engine probably already knows of all the uses for a tool that helps you to develop batch programs. The real question you're probably asking is "Why should I use Application Engine instead of COBOL or SQR?" Hopefully, after reading the following sections, you'll see the advantages that Application Engine offers over its counterparts, COBOL and SQR.
Unlike applications developed using COBOL or SQR, Application Engine programs reside completely within your database. With Application Engine, you do not have to compile your programs, there are no statements to store, and there is no need to directly interact with the operating environment you use.
You can develop your entire program from scratch, including the table definitions, all within the Application Designer, and then you can run and debug your applications without leaving the PeopleTools environment.
Since Application Engine program definitions are defined in and stored as Application Designer objects, they join the growing ranks of PeopleTools components that you can easily upgrade using Application Designer.
You can upgrade Application Engine definitions by project, program, or Section.
Also, you can insert Records and Application Engine programs in the same project. This means that if you change your 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—along with affected panels, and so on. 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 make 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.
Application Engine programs can now invoke PeopleCode. This means that from Application Engine you can call common PeopleCode functions that you use throughout your PeopleSoft system. Conversely, PeopleCode can now invoke an Application Engine program.
This allows many opportunities for sharing and reusing code. Regardless of where you've stored a piece of code, you can reuse it.
Note. Note. Reusing business logic between batch and online generally applies to row-by-row processing, and not set processing.
The restarted Application Engine program locates the last checkpoint, or the last successfully executed and committed Step, and continues with the processing from that point. This type of built-in logic does not exist in COBOL or SQR. You need to code any restart logic for your programs yourself.
With COBOL or SQR, you not only have to resolve the issue that caused the error; you may also need to "undo" what the program processed before the failure. Otherwise, you may perform duplicate processing, which leads to inaccurate data.
Besides offering the obvious advantage of having built-in restart capability, Application Engine's restart capabilities also influence the design and performance of an Application Engine program. Having restart functionality allows the developer to commit more often, without the added burden of coding additional restart logic with every commit. This reduces the overall impact on end users and processes while the background program is running.
Application Engine is fully integrated with the other design time PeopleTools. This means that you use the Application Designer, an intuitive, graphical interface, to define your Application Engine program.
The Application Designer offers Application Engine developers the following benefits:
· Ability to open multiple Application Engine programs concurrently.
· Ability to work on the entire Application Engine program at once. Users of previous versions might remember working on one Section at a time.
· Easy access to the PeopleCode and SQL editors.
· Two views of your program. The Definition view is where you create and modify your programs. The Program Flow view allows you to see the actual order in which your program will execute the statements.
Application Engine Program Definition in Application Designer
You can write your SQL within Application Engine, or you can copy SQL statements into Application Engine from any SQL utility with few, if any, changes. This enables you to write and tune your SQL statements before you try to incorporate them into an Application Engine program. In fact, you may find yourself spending more time developing in an external SQL utility, and then cutting and pasting your SQL into the corresponding Application Engine Actions.RDBMS platforms have many differing syntax rules, especially in regard to date, time and other numeric calculations. For the most part, you can work around differing syntax using PeopleSoft meta-SQL, which Application Engine supports. This language is designed to replace RDBMS-specific SQL syntax with a standard syntax, called meta-strings.
For example, if you reference a date field called AE_DATE in a SELECT clause, you specify it as %DATEOUT(AE_DATE). This meta-string will be resolved to the appropriate value as required by the current RDBMS platform.
n addition, PeopleSoft meta-SQL enables you to dynamically generate portions of your SQL statements. For example, if you wanted to join two tables on their common keys, you could use the following code:
%Join(COMMON_KEYS, PSAESECTDEFN ABC, PSAESTEPDEFN XYZ )
At runtime, the function would be expanded into the following:
ABC.AE_APPLID = XYZ.AE_APPLID
AND ABC.AE_SECTION = XYZ.AE_SECTION
AND ABC.DBTYPE = XYZ.DBTYPE
AND ABC.EFFDT = XYZ.EFFDT
Note. Much of the recent PeopleSoft meta-SQL (constructs added since PeopleTools 8) is not supported for COBOL or SQR programs.
If using dynamic SQL, you'd have to control it with something similar to the following statement:
IF DBTYPE-SYBASE OF SQLRT...
However, in Application Engine, you have the ability to call different versions of a Section for different platforms. You can specify a Section to be one of the following:
· (base). Think of this as the common denominator or global version.
· Any supported RDBMS platform, as in DB2/UNIX, Oracle, Informix, and so on.
Most Sections will only have a (base) version, and, even in cases where you refine a particular Section for a specific RDBMS, a (base) version of that Section will also exist. When Application Engine executes a Section, it will use the version that's specific to the current database platform if one exists. If there is no RDBMS-specific version, Application Engine uses the (base) version.Within platform-specific Sections, you also have the ability to call base portions of SQL statements by using the %SQL construct. This means you can write your generic SQL portions just once, and then you can reference them from your different platform versions.
Even if you don't intend to develop platform specific versions, using %SQL is still a benefit since you can refer to external SQL objects from within Application Engine SQL. This allows for reusing SQL and dynamic SQL.
Unless you've developed them to anticipate changes in field attributes, COBOL applications usually need to be modified when the definitions of your meta-data change. For instance, if a developer increases a field's length, then it may need to be changed in every instance where the COBOL program references this field as a BIND or SELECT variable.
Correcting such discrepancies can consume a considerable amount of time and resources, and, if not handled properly, an unaccounted for change in your meta-data can cause interesting errors that are often difficult to pinpoint. For example, if the length of a field in your COBOL code is wrong, one of the following may occur:
· An error message may appear.
· The field may get truncated.
· Or, the program may run without a problem.
If you've ever had to perform such a manual update of COBOL code, then there's no need to imagine the degree of irritation a programmer can experience. Regardless of the outcome, by using COBOL, you are potentially restricting other developers from making changes to the meta-data since a simple change may send a time consuming, ripple effect throughout the system. On the other hand, with Application Engine, developers enjoy the freedom of changing meta-data as needed thanks to the PeopleTools data dictionary.
One of the cornerstones of PeopleSoft functionality is Application Designer. Because of the way it works, most field attributes, such as type, length, and scale, only need to be specified once, and that change will be reflected globally. If the same field appears on more than one record, you know that the same attributes reside in each record definition. If needed, there are attributes you can override at the record level, such as a default value or whether a field is a key and so on.
For the most part, these global definitions, our meta-data, allow a developer to change the database to meet the site's current needs and then ALTER the affected tables, as needed. Although some cosmetic changes to panels might be required in some cases, typically, no SQL or PeopleCode program changes are required.
Because Application Engine works in harmony within the PeopleSoft system and references the data dictionary for object definitions, changes to meta-data in the database have little or no impact on Application Engine programs.
Program Components and Terminology
An Application Engine Program is made up of several key components. It is important to understand the relationship between the components and the hierarchy in which they exist. Although you will encounter many more terms that are specific to Application Engine within this book, here we cover the basic terms with which you will want to become familiar before you continue. If you are an experienced Application Engine developer, you may already be familiar with these basic terms.
An Application Engine program identifies the set of processes to execute a given task. A program must contain at least one Section. The execution of the program always starts with the Section defined as "
An Application Engine Section is comprised of one or more Steps and is equivalent to a COBOL paragraph or an SQR procedure. All Application Engine programs must contain at least one section entitled "MAIN."
A Section is a set of ordered Steps that gets executed as part of a program. You can call Sections (and other programs) from Steps within other Sections.
A Step is the smallest unit of work that can be committed within a program. Although, you can use a Step to execute a PeopleCode command or log a message, typically, you'll use a Step to execute a SQL statement or to call another Section. The SQL or PeopleCode that a Step executes are the Actions within the Step.
When a Section gets called, its Steps execute sequentially. Every program begins by executing the first Step of the required Section called
There are multiple types of Actions that you can specify to include within a Step. Keep in mind that it is common to have multiple Actions associated with a single Step. The following sections briefly describe each type of Action. These Actions are explained in more detail when we approach more advanced topics related to building Application Engine programs.
Program Flow Actions
A Program Flow Action contains a SQL SELECT statement designed to return results on which subsequent Actions depend. For instance, if a SELECT returns no rows, subsequent Actions may not need to execute. A Program Flow Action is equivalent to a COBOL PERFORM statement and has similar constructs. Here are the four types of Program Flow Actions:
· Do While.
· Do When.
· Do Select.
· Do Until.
SQL
Most SQL Actions are comprised of a single SQL statement. These statements can perform the following types of SQL statements:
· UPDATE
· DELETE
· INSERT
· SELECT
The SQL Action differs from the Program Flow Actions, which also contain SQL, in that the SQL Action does not control the flow of the program.
PeopleCode
You can include PeopleCode in, of course, the PeopleCode Action. Application Engine PeopleCode provides an excellent way to build dynamic SQL, perform simple IF/ELSE edits, set defaults, and other operations that don't require a trip to the database. It also gives you the ability to reference and change active Application Engine State Records.Most importantly, PeopleCode provides access to the PeopleSoft Internet Architecture's integration technologies such as Application Messaging, Business Interlinks, Component Interfaces, and XML File Processing.
Log Message
A Log Message Action can be used to write a message to the MESSAGE_LOG based on a particular condition in your program. This gives your program multi-language capability. The system stores the message generically as a message set, message number, and parameter values. When the end user views the messages using the Application Engine Messages panel, PeopleTools retrieves the appropriate message string from the Message Catalog based on the user's language preference.
Call Section
You can also insert an Action that calls another Section. The "called" Section can be in the same program as the calling Section, or it can be in an external program. This allows you to "chunk" your program into more maintainable, reusable pieces. If a Section already exists in one program, rather than copying it into another program, just call it.
Note. Application Engine supports up to 99 levels of nested Call Section Actions. For example, the first called Section can call a second, which can call a third, and so on, and so on, up to 99 calls.
An Application Engine State Record can be either a physical record or a work record, and any number of State Records can be associated with a program.
0 comments:
Post a Comment
Phaniraavi@gmail.com