Oracle9i SCM and Oracle9i Forms Integration

Introduction

Oracle9i Forms and Oracle9i Software Configuration Manager (SCM) are integrated so that software configuration management can be done directly from Oracle9i Forms Developer. Oracle9i SCM provides source control options, such as checkin/out capability, versioning, compare and merge utilities, and impact analysis. With Oracle9i SCM, you can effectively manage your Forms development environment allowing the parallel development and control of multiple development streams. This document describes how to use the integrated products.

Setup

Oracle9i Forms Developer and Oracle9i SCM are part of Oracle9i Developer Suite. An SCM repository, built on the Oracle database, must be installed. Follow the SCM install guide and ensure that you can connect from the Repository Object Browser to the SCM repository. Oracle9i SCM access from Forms Developer is enabled from the Windows Start menu, select Programs / Oracle9iDS / Oracle SCM then select Use as Source Control for Developer. This is a one time operation per client and sets the required registry variables, enabling the SCM menu options from Forms Developer.

Open the Repository Object Navigator (RON) and create a default workarea. This will have a rule of LATEST(MAIN) meaning that this workarea will see the latest versions of files on the MAIN branch, but only in those containers (Applications and Folders) accessible to the currently connected user.

Loading Existing Forms

Typically existing Forms files need to be loaded into the SCM repository. You must decide whether or not to store derived objects, such as .fmx files. The advantage is that all files belonging to an executable application can be grouped with their source code. The disadvantage is in storage space requirements.

Create a Folder from within the RON, then check it in and out again. This assigns the version 1.0 on the MAIN branch to the Folder. Upload all the Forms files into this Folder (see Figure 1), and check in all the files and the folder. Both actions can be performed from the right mouse button context sensitive menu.

At this point it is useful to create a configuration based on the contents of this workarea. This acts like a checkpoint, and enables the original set of files to be easily accessed if necessary. To access these original versions create a workarea based on this new configuration, map the folder to a new area on your local hard disk, and download the files.

Figure 1  Repository Object Navigator showing Workarea, Folder and Versioned fmb files

Working With Versioned Forms

Oracle9i Forms Developer requires the .fmb and other associated files to be located on an accessible disk, i.e. outside of the Oracle9i SCM repository. Thus to edit a .fmb file it must first be downloaded to a file system. Simply map the parent folder to a new local file directory and download the files. This action can be performed on individual files, or more typically in a Forms application with many interdependent files, the whole directory may be downloaded. Note that at this point all the downloaded files are read only.

Start Oracle9i Forms Developer and open a .fmb file from the new directory in the file system. If you make a change and try and save the file, the operating system recognizes that the file is read only and prevents the save. The file is set to read/write by checking it out. Go to the File/Administration Check Out option. After entering the SCM repository username and password, select the workarea created earlier and similarly select the correct SCM repository container. On check out, the option is given to overwrite the local file system version of the file. Normally this is correct and ensures the file being edited is the correct version; however, if you have made many changes without realizing that the .fmb is read only you may choose to check out the file without overwriting the local file. The new changes may then be saved.

Make the necessary changes to the Form and save the file. After testing the Form .fmx executable the .fmb is checked into the SCM repository from the File / Administration Check In menu option, which creates version 1.1 on the MAIN branch. Return to the RON and highlight the modified Form. Examine the property sheet for the modified Form, and notice that the version is now 1.1. Note that the Folder has not changed version, the Folder is only versioned when files are added or deleted, thus keeping track of the contents of the Folder.

Examining Changes

Forms .fmb files cannot simply be compared using text compare utilities. Oracle9i SCM provides .fmb compare facilities whereby changes between any two versions of a form can be identified. Either select a .fmb file in the RON and choose to compare with the previous version, or open the Version History Viewer and compare any two versions of the same file as shown in Figure 2.

Figure 2 Version History Viewer and Compare Window showing differences between version 1.0 and 1.2 of a Form

Parallel Development

There are many reasons why parallel development might be required:

·         Distributed development teams

·         Multiple customer releases of a similar product

·         Multiple release cycles

·         Bug fixing in earlier versions

To fix a bug in an earlier release of the application, i.e. not in the latest code, a workarea is created based on the configuration of the code as it was in the version the bug was reported in. The configuration or stripe across the code can be created at anytime, though it is typical to create a configuration at each product release point. Create a new workarea based on the configuration with a default check in branch other than MAIN, e.g.:

LATEST(forms_bugfix_br)

INCLUDE_CONFIG(forms_cfg{MAIN;1}=Configuration)

The above will identify the latest versions of files on the branch ‘forms_bugfix_br’, and if a file does not exist on the branch, the version made available from the configuration ‘forms_cfg’ will be used. Note that the MAIN mentioned in the INCLUDE_CONFIG refers to the branch on which the configuration is checked in, not the branch on which the files within the configuration are necessarily checked in. Therefore, if a file is checked out of the workarea and checked in on the new branch, the new version of the file appears in the new workarea. On editing a form and then checking it back in on a branch you should see a Version History similar to that shown in Figure 3.

Figure 3 Version History View and Compare of  Parallel development

Note that in the above example the original changes made in version 1.2 of the form, as shown in Figure 2, are not present. Several objects have been modified and a new visual attribute has been added. At some point in the future the file on the branch would be merged to the MAIN branch. Automatic merge is possible, but conflicts where the merge engine cannot make the decision as to which version of an object to include will result in a merge window opening as shown in Figure 4, allowing the developer to make an informed decision as to which version to include. Merging from the MAIN branch to the bug fix branch allows testing on the branch without breaking the whole application, which still resides on MAIN. Once testing is complete, a further merge back onto the MAIN branch is required. This may be seen as overkill, but does ensure the MAIN branch never contains unusable code.

Figure 4 Merge of Version 1.2 with Version 1.0.1.0, the check boxes select the correct item to appear in the merge file

Merging from the MAIN branch to the bug fix branch allows testing on the branch without breaking the whole application, which still resides on MAIN. Once testing is complete, a further merge back onto the MAIN branch is required, as shown in Figure 5. This may be seen as overkill, but does ensure the MAIN branch never contains unusable code.

Figure 5 Merges from Version 1.2 to 1.0.1.1 and then from 1.0. 1.1 to 1.3 on MAIN

The use of the Difference and Merge tools allows multiple developers to work on the same file and merge their changes. This may not be appropriate for all development environments, but Oracle9i SCM supports working at this level of complexity for development teams that require it. The Strict Locking Policy, when selected, prevents any version of an object being checked out from a branch when one version is already checked out on that branch, thus preventing two developers from editing the same file on a single branch.

Summary

Oracle Forms are used in some of the largest software development projects in the world. Code control is mandatory on such projects. Combining Oracle9i SCM and Oracle9i Forms Developer allows simple code control via check in and check out from the Oracle9i Forms Developer menu. This also enables development teams to compare and merge forms, thus facilitating parallel development. The ability to 'stripe' the releases and manage them as complete configurations ensures that each release has a known set of versions, enabling bug fixes to earlier releases.