PowerBuilder Reviews and Articles

Al Soucy

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

Related Topics: Enterprise Architecture, Enterprise Application Performance, Software Configuration Management


PowerBuilder Build Process with SCM R12

Using PowerGen we have defined a process that includes a full Bootstrap Import and build

This article will focus on the PowerBuilder Build Process using E. Crane Computing product PowerGen with CA Software Change Manager (SCM) R12.0.2. I am writing this article because we recently upgraded to SCM R12 and it was a good time to visit our PowerBuilder build process and see what has changed.  I felt it would be beneficial to share this process with other users in the field. I want users to be able to use this article as a checklist of activities to be aware of when performing the PowerBuilder build process with the latest version of Harvest SCM R12 and PowerGen.

Every Software Configuration Management tool is different in terms of functionality and navigation; however, they all have common threads of functionality that are consistent with all Software Configuration Management tools. Common activities include checking out, checking in, adding new files, deleting existing files, obsoleting files and loading an initial baseline of source code. The way these tasks are achieved is of course different from tool to tool but many of the SCM tools perform these basic activities. I prefer SCM tools that have a relational database behind them for security, disaster recovery, retrieval and storage capability.

Presently, I am the administrator of SCM AllFusion Harvest R12. SCM AllFusion Harvest is a process-based Software Configuration Management (SCM) tool for managing application source data assets. I manage 198 applications housed in SCM AllFusion Harvest and support 163 users using the product. The development tools we currently use in our development environment are PowerBuilder PBV8, PBV11; Visual Studio 2003, 2005, 2008; Visual Basic V6.0; IBM RAD V7.5.5; and Eclipse Europa.

As the Software Configuration Manager (SCM), I provide the administration of the source code management tool. This includes creating the Harvest environments, developing life cycles, environment phases, processes, users, user groups, level of access to Harvest environments, loading repositories for archival purposes, documentation of software methodologies; maintaining build machines; providing best practices and training all users on proper source code management using the development tools in our environment.

Prior to using our PowerBuilder code I invoke PowerGen to take our PowerBuilder libraries and export them as flat files in a directory structure that resembles the PowerBuilder library, as it would be seen in Powerbuilder. This is the first step in not only managing our PowerBuilder source code assets but the first step in storing all of the source codes assets for a PowerBuilder build later.

Figure 1: PowerBuilder application

The first thing I do is identify the PowerBuilder application (see Figure 1) and the PowerBuilder objects that are associated with the application. I also must make sure that I have a specified target file created for the application as well (e.g., test.pbt). This target will be used by PowerGen to export all of the PowerBuilder objects as flat files to load into a Harvest repository for storage and retrieval.

Figure 2: Identified location of where PowerBuilder Objects are to be exported. In this example, C:\Export1\

Figure 3: Export files to directory tree and PowerGen exports the files into a folder for you to load as a PowerBuilder library

Once I identify where I want the files to be exported (see Figure 2), I use PowerGen to export the files as flat files to that location and PowerGen creates a folder for me with the exported files in it as a PowerBuilder library or a PBL (see Figure 3). Once the files have been exported, I then load this directory/PBL to a Harvest repository in the SCM 12 Harvest Administrator GUI. Prior to loading these files I create a new repository in SCM 12, provide a level of access to that repository, and once the source data assets are loaded, I will configure that repository to the SCM 12 Harvest environment that has a small life cycle and processes that were used as a test environment for this SCM 12 and PowerGen 7.5 build process. Figure 5 illustrates the success or failure of the exported PowerBuilder objects and the location specified where the objects are populated, and Figure 6 illustrates the flat file export location and the files as they appear once the export of the PowerBuilder objects is complete.

Figure 4: PowerGen pointer to the exported file location

Figure 5:

I did not use a Change Request package for the initial load of these files to the SCM 12 Harvest repository. I used the Load Repository process from within the SCM 12 Harvest Administrator to create a new baseline version zero of these files. I could have created a new Change Request Package and loaded the files to that package and then promoted that package through the entire Harvest life cycle and that would have left the footprint of the new baseline version zeros across all views. However, I prefer to load the baseline at the Administrator level and this way the environment has zero packages in it. This provides a pristine environment that is ready to use with a new baseline available for development activities.

Figure 6:

In Figure 7 you can see how the initial load of the flat files is viewed from the SCM 12 perspective. The .srd and .srw extensions are stored as baseline zero and these flat files are associated with one PowerBuilder library under the SCM R12 Harvest repository view in the Development State.

Figure 7: Loaded flat file view in SCM 12 repository

Once all files have been stored we now need to extract the files from the SCM 12 Harvest repository to populate a location where PowerGen will be used to perform a complete compile of the source data assets.

We have developed a DOS script that encompasses the SCM 12 Harvest Check Out Command, which uses the command-line utilities to retrieve the source data assets from the SCM 12 repository. You can find this information in the Harvest documentation, but for those who don't have it in front of them I'll define the commands for you. The HCO is the Harvest Check Out Command; -b is the Harvest Broker/Server name; -usr is the user name assigned to performing the build process; -pw is the password for that user; -vp is the View path in SCM 12 or the Harvest repository view; -en is the Harvest Environment or Project name; -st is the Harvest State view that you want all the source assets extracted from and this would mean the baseline code and any deltas associated with any packages in that view; -pn is the process name in our case the process is called "CHECK OUT FOR BROWSE/SYNCHRONIZE"; -cp is the client path or where you want the files to all be checked out to for the compile to occur; -br is a browse read-only copy of the code; -r is to check out all of the files recursively; -op is for option; and pc is for preserve and create path structure for the check out. This will keep the entire directory intact upon using the HCO command for the compile process and finally the -s is for the file name pattern. This is on page 40 of the Harvest reference guide.

HCO command we use:

hco -b "server name" -usr "xxxxxxxx" -pw "xxxxxxxx" -vp \Powerbuilder_Test_Project -en Powerbuilder_Test_Project -st "ACCEPTANCE TEST" -pn "CHECK OUT FOR BROWSE/SYNCHRONIZE" -cp c:\Powerbuilder_Test_Project\ -br -r -op pc -s "*.*" -o output.log

Once we have run the DOS script to retrieve the source data assets from the Harvest server, environment, state, and repository, we have the script setup to automatically invoke PowerGen. PowerGen is used to take the flat files checked out of Harvest, which I call the mass check-out, and then do a Bootstrap Import of those flat files into PowerBuilder objects and into formalized PowerBuilder libraries, and then create PBDs and executables from the newly created PowerBuilder libraries.

We use three files to make this process happen. The first is our PowerBuildertest.bat file that defines all the parameters for what we are acquiring and from where, and the processes we want to invoke for processing. We then use the PowerGen import list that defines the names of the flat file PBLs based on the mass check-out command (flat files) and the location and name of the PowerBuilder libraries that we want created. Last, we have the .Gen file that establishes the name of the icons, PBDs and executable that we want created based on the mass checkout and the PowerBuilder library creation.

This build process creates three folders as represented below:

Mass_CK_Out, Create PBLs and Executables

Two logs are created, which are represented below:

A_HARVEST_INTO_PBLS.LOG, Test-Project-Make-PBDs-EXEs.log

In these two logs the status of whether the build was successful or failed is recorded as follows:

Application Name
Test-Project    C:\Test-Project\SIT\Create_Pbls\Test.pbl

0 errors found

Log Ended on 11/2/2010 12:13:01 PM

Creating Executable

0 errors found

Log Ended on 11/2/2010 12:34:45 PM

When the build process is complete, we then take the executable that was generated from this process and populate it in a location where we can invoke the executable and test its functionality to ensure we have a solid verifiable build.

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.

It 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. (VersionEdit also works with any standard Windows executable such as EXE and DLL.)

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.

A sister function of the Bootstrap Import, the Synchronize function, will update a set of PBLs with modified source. In the Synchronize function PowerGen examines each object in the PBL and compares it with the exported source. It updates the object in the PBL only if it's changed. It also adds new objects, represented in export files, but not present in the PBL, and removes objects that exist in the PBL but have no corresponding source. The advantage of the Synchronize function over the Bootstrap Import is that the Synchronize function is usually an order of magnitude faster.

PowerGen first introduced the Bootstrap Import for PB V5.0. Its purpose is to rebuild an application completely from just the exported object syntax (*.sr* files). So PowerGen enabled source traceability in the SCM processes long before it was possible with PB. Later this became a critical issue for PB8.0 when PB's source control architecture changed and there were no longer "registered" PBLs to use for a build. As soon as PowerGen offered the Bootstrap Import, we chose to use it rather than rely on the registered PBLs, because it wasn't possible to verify the contents of those PBLs.

PowerGen's Bootstrap Import uses a three-phase import process. In the first phase, global types and basic object signatures are established. In the later phases the complete object information is added back in. This progressive import is required to avoid fatal errors caused by a fully formed object that may contain many references to objects that haven't been imported.
The finesse required to import selected parts of an object in successive phases requires an automated method. Attempting to do it by importing complete objects (which we tried), even in a carefully selected order, is futile.

Because PowerGen introduced the Bootstrap Import in an early version of PB, it has had to deal with several interesting issues. Until PB8.0 was released, there was no information available about which objects belonged in which PBLs. Obviously this was essential information for rebuilding PBLs from object sources. So PowerGen introduced the Object List File (OLF) that provided the mapping between object files and PBLs. There are two forms of the OLF. In one all of the objects are enumerated along with their corresponding PBL:

.\Code Examples\Example App\pbexbm\benchmark.sra,.\Code Examples\Example App\pbexbm.pbl,"Comment"
.\Code Examples\Example App\pbexbm\d_benchmark_report.srd,.\ Code Examples\Example App\pbexbm.pbl
.\Code Examples\Example App\pbexbm\d_dddw_cust.srd,.\Code Examples\Example App\pbexbm.pbl,...Etc.

In this form each line contains two four-comma-separated parameters. The first names the object file, the second the PBL, and the optional third and fourth the object comments and PBL comments, respectively.

In the second form the object file names can include a wild card:

.\Code Examples\Example App\pbexbm\*.sr?,.\Code Examples\Example App\pbexbm.pbl,"Comment"

In this form every file with an *.sr* form in the pbexbm subdirectory will be included in the PBL.

Our Experience
We develop and maintain more than 198 applications at New Hampshire's Department of Information Technology. 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 PowerGen we have defined a process that includes a full Bootstrap Import and build whenever an application version is promoted to system integration testing and user acceptance testing. We use CA SCM R12 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 DoIT for eight years. During that time it's saved thousands of man-hours and delivered a consistent high-quality result.

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.

Please feel free should you have any questions regarding the product (CA SCM R12) and its use in our environment with various development tools to contact me.

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.