This section is intended to help you begin developing Apply Engine scripts. While your initial efforts may be a "Proof of Concept" or POC, involving only a handful of source and target datastores, the typical Apply Engine implementation eventually grows to encompass tens if not hundreds or even thousands of "parts" making how you have decided to name and organize them critical to your long term success.
Before beginning to write a script it is important to gather information about the environment in which it will run; identify both the source and target datastores; and finally, determine the business rules that define the data transformations that must be performed by the script. In other words, all the requirements needed to properly create and maintain the target datastores. Those requirements will also be used to make decisions regarding the organization and management of the component parts that will together make up the script.
Unlike most "programs", Apply Engine scripts almost always work with data from different platforms and different types of source and target data structures. Source data might be non-relational, such as IMS and be described by an IMS DBD and COBOL segment layouts while the target might be relational Oracle tables described by DDL. Another script might replicate relational DB2 data to a SQL Server Relational database. In both cases, Descriptions of the source and target data structures are required when the script is parsed, which almost always requires a copy of the Descriptions on a platform where it was not needed prior to the implementation of Connect CDC SQData.
The Apply Engine scripting language is procedural and is used to create a simple text Apply Engine "script" combining source and target (datastore type dependent) Descriptions, physical source and target Datastore definitions and connection information, Variable and field level specifications, main processing loop instructions and one or more called procedures maintained either as part of the main script or as "included" sections. While external environmental constraints may place limits on Component file names, they do not apply to many of the parameters associated with the Commands and Functions used in Apply Engine scripts.
Like other programming languages, Apply Engine scripts will reference datastores, variables and called procedures. Implementing naming conventions for those items facilitates both script development and ongoing maintenance and enhancement. Together with the liberal use of comments, good naming conventions can facilitate the development of self documenting Apply Engine scripts. For these and other reasons that will become clear, deciding how to organize the "parts" and how they are maintained becomes critical. Wherever possible Precisely recommends using existing Change Management (CM) systems to manage Apply Engine parts.
The following sections discuss the organization and naming of "parts", the appropriate use of Upper and Lower case characters as well as the use of comments and spacing in Apply Engine scripts, all intended to simplify and standardize both the process of script development and the structure and readability of the scripts themselves. Apply Engines can run on Linux, AIX, Windows and z/OS for that reason some recommendations and conventions are either dictated or recommended based on the characteristics of the platform. As will be explained later, it is also possible to develop an Apply Engine script on one platform and run it on an entirely different platform.