PowerBuilder Reviews and Articles

Al Soucy

Subscribe to Al Soucy: eMailAlertsEmail Alerts
Get Al Soucy via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java Developer Magazine

Java Developer : Article

PowerBuilder Initial Baseline Load Process

Using PowerGen by E. Crane Computing

Presently, I am the administrator of AllFusion Harvest for the State of New Hampshire. I manage 100 applications housed in AllFusion Harvest and support 180 developers using the product. The development tools we currently use are PowerBuilder v8 and v11, Visual Studio 2003 and 2005, Java, and Visual Basic.

As the software configuration manager, I provide the administration of the source code management tools. This includes the entire infrastructure of the environment for development, from developing the life cycles to providing the best practices, procedures, processes, and training of all the developers on proper source code management with the development tools in our environment.

When the State of NH first began using PowerBuilder, we realized immediately that storing pbls in a source code control product and managing the versions of pbls was just not very practical, nor did it give us the version control at the object level that we desired. After some investigation we were steered toward using the export function of PowerGen to create ASCII flat files and manage the objects embedded in the PowerBuilder libraries. This allowed us to store the entire PowerBuilder application in a flat file format and use the HarPB interface to check out/check-in files and maintain the version history of the files contained in the PowerBuilder libraries. Once the PowerBuilder application is baselined as a flat file directory, status accounting of all objects in the PowerBuilder libraries is easily maintained. All new objects that are introduced to an existing PowerBuilder application are exported and loaded in Harvest via packages and promoted/demoted through the Harvest life cycle based on new releases.

This article focuses on the step-by-step process involved in using PowerBuilder, PowerGen, and Harvest and completing an initial baseline load of a set of code for a PowerBuilder application using the PowerGen export function.

Before I get into the initial export and load process specifically, I want to first provide a definition of PowerGen because this product is used in the initial export of the PowerBuilder objects as ASCII flat files and the rebaselining process for PowerBuilder applications. PowerGen is also used in conducting formal compiles of PowerBuilder code for testing and creating executables for production builds.

What Is PowerGen?
Since its first release, PowerGen has been focused exclusively on automating the build process for PowerBuilder applications. First released for PowerBuilder v4, it has allowed for a consistent build methodology through all succeeding PB versions. However, in addition to this function, we are using the export function of the product for all PowerBuilder objects since we store the exported flat files of the PowerBuilder objects in Harvest for source code management of PowerBuilder objects. We use HarPB as the check out/check-in interface for the flat files export/import.

PowerGen has two major functions. The first is producing PB deliverables from PBLs. To do this it offers regeneration, PBD and DLL creation, and EXE creation. To support the users' complete automation requirements it also includes copy, import, export, and optimize functions. With a separate utility VersionEdit, delivered with PowerGen, it can also modify version resource information.

The second major function is producing PBLs from source objects. Starting with only the PB objects in their *.sr* exported source format, PowerGen can create PBLs and repopulate them with their constituent objects. First introduced for PB 5.0, this function is called Bootstrap Import (a term since appropriated by other products). It allows "source traceable builds," an essential element of a good Software Configuration Management (SCM) process. It also lets you maintain only object-level source in your Source Control system, without resorting to versioning PBLs, which was never a good practice.

Using PowerGen Export Function
Once a PowerBuilder application has been migrated via PowerBuilder from one version to another, which is an automated process in PowerBuilder, PowerGen is then used to export all of the PowerBuilder libraries (pbls) into a flat file format. This is done by using a target file, which contains a listing of all the PowerBuilder libraries in the application. For example, once you invoke PowerGen, in the following screen select Project ->New on the top of the menu.

Using the PowerGen Export Function
Once project new has been selected, you then get the application screen. This screen allows you to use many methods to open up an application by either using the pb.ini, pbl, target (reg.), target (*.pbt) or Workspace. I use the target *.pbt file to open the application in PowerGen (see Figure 1).

New projects are created from existing PB applications defined in Targets, Workspaces, and PB.INI files. A project can also be created by choosing the application PBL and adding the libraries individually.

When presented in PowerGen's GUI, the applications in the project are shown in the top list and the PBLs in the selected application are shown in the bottom list. Note that the paths used in the project can be specified as "relative paths." This allows for greater portability. I place the .pbt in the same location as the set of PowerBuilder libraries that I am exporting for the initial baseline load.

I use the .pbt to export PowerBuilder objects by navigating to the pbt location. Once I navigate to that location, I ensure that all the PowerBuilder pbls are also in the same location and click the add feature, which then populates the application in the project list below the selected applications listing (see Figure 2). I then click the OK button.

I am now prepared to begin the export function of PowerGen, which will produce the exact PowerBuilder libraries in the target to the path I choose in an ASCII flat file format directory that matches the PowerBuilder application for an initial baseline load. The directory of PowerBuilder libraries will be exported as a mass export.

I export the objects to a directory tree generally on my C:/ as to not use network resources for storage, since this entire directory will be loaded into a Harvest repository soon after the export (see Figure 3 - Test_Documentation is the Harvest Repository in this example).

After I've selected the directory tree, the screen shown in Figure 5 appears, which allows me to navigate to the location where I want to create the new directory in a flat file format (see Figure 4 and Figure 5). Figure 5 shows the directory path on my C:/ to perform export on all PowerBuilder objects.

I generally use a temp folder (Export) on the C:/ or create a folder. When the objects listed in the .pbt have all been exported in a flat file format, I can then load those files in their directory structure into a Harvest repository. PowerGen creates a .gen file (also referred to as a project file). This project file can be used with PowerGen to do formal builds at a later point. Figure 6 shows the results of the exported files, their respective path where the export has occurred, and any errors that may have occurred.

Now that I have the PowerBuilder exported libraries, the directory can be loaded in Harvest via the Harvest Administrator/Load Repository. After the files are loaded and the baseline configured to the correct environment in Harvest, the files are now ready to be updated in Harvest using the check out/check-in processes in the Harvest Workbench.

The Harvest Administrator load window allows you to select the directory and repository to load files into. Once this has been done, select recursive to load the entire directory until it is complete. This is accomplished in the repository tab in the Harvest Administrator.

Once the directory is loaded, you must then configure the repository and baseline that has been loaded by using the Harvest Administrator to select the repository to add and make it read/write so it can be modified via the Harvest Workbench (see Figure 7).

The directory of exported PowerBuilder objects is baselined as a 0 version across all states in the Harvest life cycle. This leaves the footprint of that baseline across all states and logical views in the Life Cycle or Harvest environment.

When the export is complete and you exit PowerGen (see Figure 8), the tool asks if you want to save the .gen file or Project file. If you say yes, you can name the file and use this project file in conjunction with an import list and a .bat file to perform builds. If you say no, the tool just exits out and you are finished with the export.

The project file is saved as a separate file with a .gen extension. The file is ASCII and is fully documented with the understanding that users may want to modify or create their projects programmatically. Although the information saved in the project file has been expanded through the various releases of PowerGen, each new PowerGen version can open any previous version's projects. Most of PowerGen's options are saved in the project file, although a few are saved in the registry. The ones saved in the registry are judged to be more germane to the build environment than a specific project. For example, the option of whether the resulting PB applications exhibit "New Visual Styles" is saved in the Registry.

Our Experience
We develop and maintain 40 PowerBuilder applications at New Hampshire's Department of Health and Human Services. The applications are used extensively in our welfare and health services delivery agencies. Example applications are for child-care licensing and managing adult and elderly care. Throughout the state the applications are used by hundreds of users.

Using the PowerGen export function and storing PowerBuilder applications as flat files has allowed us to have more control over version control of all the objects within a PowerBuilder application. This also allows for status accounting at the object level, which provides users and management with greater detail in the development environment from an application standpoint. I should add that one of the main reasons that we chose to use the PowerGen export function is because PowerGen rebuilds the object(s) from scratch by placing in new header and footer information and doesn't add any new information to the file. It is a very clean export and we have had fewer issues with corrupt objects as a result of using this product for this purpose.

We use AllFusion Harvest from CA for our software configuration management tool and have versioned our PowerBuilder applications at the object level since we adopted PowerGen. When we're ready to release a version to test, we "get" the labeled objects from Harvest and then run PowerGen scripts that completely automate the import and build process.

We've been using PowerGen at NH-DHHS for eight years. During that time it's saved thousands of man-hours and consistently delivered high-quality results.

Because of the importance given to compatibility between PowerGen versions (and an initially well-conceived design), we haven't had to change our build process through all the versions of PowerBuilder that we've used. In and of itself this has been a huge time-saver and has let us remain very confident in the quality of our build procedures.

More Stories By Al Soucy

Al Soucy is software configuration manager at the State of New Hampshire's Department of Information Technology (DoIT). In that role Al manages software configuration for dozens of PowerBuilder applications as well as applications written in Java, .NET, and COBOL (yes, COBOL). Al plays bass guitar, acoustic guitar, electric rhythm/lead guitar, drums, mandolin, keyboard; he sings lead and back up vocals and he has released 8 CDs.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.