Oracle Designer 6i Migration Guide
Part 1. Introduction, enhancements and new features
|
Oracle Designer 6i Migration Guide |
This first part of the Oracle Designer 6i migration guide starts with an introduction that highlights the benefits of Oracle Designer 6i. Subsequently this first part will provide an overview of new concepts like version control of repository objects and new administrative or 'grouping' elements, e.g. workareas, configurations and containers. This first part concludes with Chapter 3 "A version enabled repository versus a non-versioned repository". This chapter provides you with ammunition on how to use Oracle Designer 6i and provides an overview of the relevant chapters of Part 2 "Migrating the repository" for each Oracle Designer 6i mode.
Oracle Designer 6i offers the following new functionality:
Note: At the time of writing, Oracle Designer 6i release 4.2 is certified with Oracle database 81700 or higher, and with Oracle9i patched to 9.0.1.2. See metalink.oracle.com for the latest situation.
Specifically, the option of version control of repository objects and related functionality (e.g. workspaces, configurations and storage of file system) offers the following non-tangible benefits:
You could also identify the following tangible benefits as a result of adopting Oracle Designer 6i:
Given this new functionality and benefits you may want to adopt Oracle Designer 6i for one or more of the following reasons:
The above mentioned benefits, offered by the new functionality, can be attained only by migrating your structured data (captured in application systems in previous releases of Oracle Designer) and/or files (captured in a third party source control tool or on the file system) to Oracle Designer 6i.
The term migration refers not only to the upgrade of the client software and server side software. It also covers the migration of the repository content, populating the repository with files and redesign of the migrated data.
Once your structured elements and files are in Oracle Designer 6i - covered in the second part of the migration guide – you can apply five (potentially) different migration scenarios to your Database elements, Developer components (e.g. Forms, Reports, Menus and libraries) and WEB PL/SQL modules.
The migration scenarios listed below are described in detail (e.g. characteristics, steps, when to apply) in Part 3 (migration of database elements), Part 4 (migration of developer components) and Part 5 (migration of WEB PL/SQL modules). Note however that in these parts a specific scenario may be skipped because of its complexity and/or non-applicability.
In this scenario, you will regenerate your entire application from Oracle Designer 6i, including all database elements (e.g. tables, views, PL/SQL definitions), Developer components (e.g. forms, libraries, menus, reports) and WEB PL/SQL definitions.
In this scenario, you will regenerate your entire application from Oracle Designer 6i, including all database elements (e.g. tables, views, PL/SQL definitions), Developer components (e.g. forms, libraries, menus, reports) and WEB PL/SQL definitions. As you regenerate each database element and/or module, you will make use of new features as appropriate.
This is the most complex scenario. In this scenario, you will migrate your application a little at a time, rather than all at once. You will begin by upgrading all of your forms, libraries, menus, libraries, etc. to Developer 6i at the client preceded by an upgrade of your database elements in the context of an Oracle9i database (basically do they compile against an Oracle9i database?). You will then make the changes required to run forms, menus, etc. and database elements generated from your previous release of Designer alongside of forms, menus, libraries, etc. and database elements generated from Oracle Designer 6i respectively.
The first three scenarios all eventually require you to regenerate your application. Any post-generation modifications will be lost. If you heavily modified your application post-generation you might consider only upgrading the runtime environment to Forms 6i, your database elements upgrading to Oracle9i and both types not upgrading to Oracle Designer 6i. This implies that all future maintenance has to be done manually in Developer. You could however use Oracle Repository as your file source control tool by uploading all sources (including the generated WEB PL/SQL code) into Oracle Repository.
If you heavily modified your application post-generation, and you would like to adopt (again) a 100% generation strategy, you may want to consider using the Design Capture features of Oracle Designer 6i.
The introduction and usage of a (migrated) Oracle Designer 6i repository will have significant effects on the working method and writing method of the Oracle Designer repository participants. New configuration management roles will be introduced and/or the task set of existing configuration management roles will change significantly. Therefore you may consider the organization of an Oracle Designer 6i pilot project for the following reasons:
This chapter describes changes to functionality and new features for Oracle Designer 6i.
A structured element is an element whose internal structure (secondary elements, references and properties) is fully known to and understood by the repository infrastructure. The main categories of Structured Element Types at this moment are the Oracle Designer element types (Entity, Business Function, Table Definition etc.) In addition, Oracle Repository has a small set of core element types of its own, such as Folder and Configuration.
Each Element has properties. Properties can be optional or mandatory, system maintained or fixed or updatable, free text or bound by value domains. The properties come in three categories:
Most properties are specific to an element type. A small set of properties is generic: Name, Type, Version Label, Audit properties and IRID. The IRID replaces the ID known from earlier releases. The IRID identifies the Object, not just within its originating repository, but globally. The algorithm that derives the IRID (the SYS_GUID function in Oracle 8) returns a value that is guaranteed not to be produced again, in any repository. You can probably see the benefits this has for migrating data between repositories.
All elements that have a structure that is unknown to the repository infrastructure is, somewhat strongly, labeled Unstructured Element. Note that this term does not claim such elements are in fact without internal structure, it merely states that the repository is unaware of that structure and therefore can only handle the element as a whole. Note that even though the Dependency Parsers know enough about the structure of files such as FMB, RDF, OLB, PL/SQL or Java to extract the dependency details, inside the repository these files are for the rest still managed as singular, unstructured objects.
The ability to store Unstructured Elements or Files in the repository is one of the major changes in the repository architecture. It is a change that will alter the role of the repository significantly. From now on: all project deliverables and system elements can be stored and managed inside the repository! All Run Time Objects (executables), Sources, Meta-Sources (Templates, Designs, Models, Workshop Notes, User Interviews) and Supporting Objects (Test plans, Project Plan, Standards and Guidelines), whether they are structured or unstructured, can all be made part of the repository. And it is our strong recommendation that they all indeed are stored and managed in the repository.
Files are stored as C(haracter) or B(inary) LOB (Large Binary Object) in the table I$SDD_FILES. Files are created and updated through Uploading from any file system and can be extracted to any file system using the Download operation. Upload and Download can be performed on single files, groups of files or entire nested directory structures, from the RON or the Command Line Tool (on Windows NT). You may Open a file by double clicking it in the RON. Based on the link defined in the Windows Explorer (View, Options, Registered File Types) and stored in the User Profile in the Windows Registry, the indicated tool is used to open (view, edit or run) the indicated file. This allows every user to use his favorite editor for opening files from the repository.
Files can be stored in compressed format. The compression and decompression is handled automatically by the repository on upload and download respectively. The compression algorithm is very fast and helps reduce storage space required for files to 2-10%. In the Repository File Registry is recorded which file types (by extension) should be stored as Text (CLOB), Binary format (BLOB) or in compressed format (always Binary). Note that Compare is available for Text Files and the binary files that are produced by Oracle Developer, such as FMB, PLL, OLB and RDF.
A workarea is a user's view of the repository objects on which he or she is working. Within a workarea, repository data is further broken down into application systems and folders, which are known as containers.
In previous releases the systems modeling tools presented repository data in the context of a single application system. In Oracle Designer 6i, repository data is presented in the context of a workarea, enabling multiple application systems and folders to be accessed from each tool.
From the familiar Navigator window, you now interact with the repository through a workarea, which is your own particular view of the repository contents. If you create a workarea, you are the owner of that workarea, though you can assign other users access rights to it. You must have access to at least one workarea before being able to do any work in the repository.
Other repository users may make changes to objects that are visible in your workarea. These changes are not immediately apparent to you in the Navigator window, so a workarea refresh mechanism is provided to bring the display up to date with the latest changes. You can preview the effect on the Navigator window display of refreshing a particular workarea, by listing the objects visible in the workarea that have been created, changed or deleted since the last refresh.
The contents of a workarea are initially defined automatically by the application of rules. However, you can manually override these rules and explicitly include any repository object in the workarea, or exclude any object that is already there.
You now create a repository object in the context of a container, a logical subdivision of the repository. Two types of container are supported in this release: application system (similar to that available in previous releases) and folder (similar to a directory in a disk-based file system). A repository object is created as a child object of its parent, or owning, container.
A completely new system of version control of individual repository objects replaces the existing application system level versioning available in previous releases. A checkout/checkin mechanism ensures that different users do not overwrite each other's changes. Graphical tools are available to display the version history of an object, to display object version details, and to display details of various version control events that have taken place for an object.
A branching mechanism permits the development of multiple versions of a product simultaneously using the same set of source files. Branches can be labeled for ease of identification.
Objects can be checked out with a lock, in which case no other user can perform a locked checkout of any versions of the object on that particular branch. Other users can still check out unlocked versions of the object on that branch, but they cannot check them back in on that branch until the original user has released the lock.
Objects can also be checked out unlocked, permitting other users to check out any version of that object without a lock. In this situation, the first user to check the object back in is permitted to do so, whereas subsequent checkins of the object must be merged with the latest version on that branch.
This release provides you with the ability to version and label your designs, for improved change control and multi user access.
Version control is the process of maintaining multiple versions of software development objects and is the most basic requirement for a software configuration management system.
Both repository and non-repository objects can be version-controlled in the common repository.
The repository manages all repository objects, as well as file system files and directories. This enables the tracking of changes to the organization of the source data, as well as tracking the changes to the contents of individual files.
Versions are organized into a version tree structure with branches. Branches have user-defined labels, typically chosen to indicate their role in the development process. All objects can be identified by a system-generated version number. Important versions can be assigned version labels by the user to indicate development milestones.
Each object in the repository is held as a set of snapshots (called object versions) of its state at certain points in time. The object versions are linked together by associations that record how each object version evolved from its predecessors. This web of associations, represented by the version tree, is called the version history of the object and can show succession, branching and merging.
The version history associations also have a number of version control attributes, including:
Version control starts when an object is checked in. Objects that are checked in are write protected. The object must be checked out before it can be modified.
The checkin and checkout process is initiated from the Repository Object Navigator, or from the Version History Viewer utility or from the command line interface.
Only one version of an object can be included in a workarea and only one version of an object is visible through the workarea view. However, the complete history of an object and all the events that occurred to it can be viewed through tools provided by the repository.
Any file or folder in your file system, as well as repository objects, can be the subject of version control. You can copy files and folders into the repository and copy them back to the file system. You can also synchronize your file system with the repository at any time to ensure both are consistent.
When checking an object in or out you can provide notes to briefly describe the reason for the action.
Once the object is checked out a copy of the object is moved into your workarea. Your workarea contains all the checked out objects you are working with. When the object is checked out, the workarea is refreshed so that the new object version appears in your version resolved view and can be edited by you.
You can undo a checkout but any changes you have made to the object are lost. The system administrator has the privilege to cancel a checkout.
When checking in an object, you can decide if the changes are to be included in the branch from where the object was checked out, or if the changes are to be represented on a new branch. Branch labels can provide some meaning to the development strand, for example, as a set of changes related to bug fixes.
Many of the checkin options are available by default. For example the default action could be to create a new branch, with a specified label. This default would apply to all objects checked in from your workarea. This could enable all the changes made on a given set of objects to be queried from the repository and used in release management or quality assurance procedures.
During the checkout operation, the object can be locked so that no other users can check out a copy for editing. If you choose not to lock the object, there is the possibility that when the time comes to check the object back in, another user may have made changes in the interval. In these circumstances, and depending on who checks their version in again first, the compare and merge tools have to be used to ascertain how to check the object back in.
The repository currently supports comparing and merging of three object types:
However, it is possible that your organization has added support for additional types.
The following version control tools are provided:
Version History Viewer. Illustrates the version history for a chosen repository object in diagrammatic form and allows you to perform version operations such as compare and merge.
Version Event Viewer. Provides detailed information about the check in and check out version operations that have been performed for a chosen repository object. The information is provided in dialog box format.
The version control tools enable you to perform a number of tasks on both repository objects and file system objects. These include:
The Version History Viewer and the Version Event Viewer are available from the Repository Object Navigator and can also be used as standalone tools.
A configuration is a collection of repository object versions that are related in some way that is significant to an application. Usually a configuration represents all the object versions for a checkpoint in development or component of an application, for example, all the object versions that make up a payroll application, or a screen form used in that application.
Any set of specific object versions can be recorded as a configuration, rather like striping or labeling in some configuration management systems. A specific object version that is included in a configuration is said to be a member of that configuration.
For example, when the development of individual objects reaches the stage where you can build a particular application, you need to specify exactly which version of each object is to be used for the build. The same applies when assembling a set of objects to be used for a test or included in a patch release - the configuration defines which versions of which objects are to be used.
Oracle Designer 6i provides a configuration wizard - a predefined set of screen forms that take you through the creation process step by step.
The configuration wizard allows you to create a new configuration, or a new version of an existing configuration containing, for example, all the latest object versions.
An object version that is included in a configuration is referred to as a member of that configuration. Members can be added or removed as and when required. However, only checked in objects can be included in a configuration. Each configuration is a repository object in itself, and can therefore be versioned.
To create a new configuration using the wizard, you start by entering the configuration name and description.
You can base the configuration on:
You can also create a custom configuration.
You then add, remove or change the version of members as required.
If you choose to base the configuration on a template file, workarea or latest versions on a branch, you may then refine it by adding or removing members or changing the versions of members. You can also add or remove selected rules and configurations.
When you create a new version of an existing configuration you have all the features that are available when creating a new configuration. In addition, you can simply refresh all existing members with the latest versions or refine the existing configuration as required.
All external references are displayed, and you can include externally referenced object versions into your configuration.
When you have completed your new configuration or new configuration version you can either save the configuration only, or save it and check it in to version control. You can add checkin notes and specify a checkin branch.
If you choose only to save the configuration you can edit it later without creating a new version.
When you upload a file, the system copies the file from the file system to the repository. Both copies can be opened and edited independently, and this could lead to differences between the two copies of the same file.
Some means is necessary of ensuring that the two copies are kept up to date with respect to each other. Oracle Repository provides a synchronization mechanism which enables you to keep the repository copy up to date with the file system copy or vice versa.
When you perform synchronization, the system checks whether any changes have been made to the repository copy, the file system copy, or both.
The resulting actions are:
|
Repository copy |
Repository copy |
File system copy |
System Action |
|---|---|---|---|
|
Unchanged |
|
Unchanged |
None |
|
Unchanged |
Checked in |
Changed |
Displays dialog for user intervention |
|
Unchanged |
Checked out |
Changed |
Uploads copy from file system |
|
Changed |
|
Unchanged |
Downloads copy to file system |
|
Changed |
Checked in |
Changed |
Displays dialog for user intervention |
|
Changed |
Checked out |
Changed |
Displays dialog for user intervention |
Files where the file system copy has been changed while the repository copy remained checked in are known as "hijacked files". For these and other cases where a dialog is displayed for user intervention, you can choose to upload the file system copy, download the repository copy, check the repository copy in or out and resynchronize, or merge the two copies, resolving the differences one by one.
A few special cases are worth noting:
Repository owners and subordinate users need system privileges to use the repository. For example:
You use the Check Requirements tool on the Repository Administration Utility to assign system privileges.
Note: Only the Oracle database administrator can assign system privileges.
The functionality for repository user maintenance has been greatly extended. The repository owner can now specify whether a particular subordinate user can perform certain repository management operations, such as creation and deletion of workareas, or force delete or purge operations on repository objects. In addition, the repository owner can control a subordinate user's access to individual repository tools, such as the Repository Object Navigator or the Command Line Interface.
You can set repository-wide options that control certain aspects of:
A user with the Set Policy system privilege can impose restrictions on the following versioning features:
By setting policies you can ensure that specific development branches are not populated with new object versions at critical periods in development, for example during a build. It also ensures adherence to system-specified object version labels.
When an automatic branching policy is set, all checked out objects will check in to the default checkin branch set for each workarea.
If a default checkin branch is not set for a workarea, object versions in that workarea will check in to the branch they were checked out from.
When automatic version labeling is set, the user is unable to specify a label for an object version on check in. The repository will automatically assign a label.
When strict locking policy is applied, users are forced to lock objects on checkout. Because two or more users cannot apply locking to object versions on the same branch, a strict locking policy prevents concurrent development of object versions on the same branch.
Without a strict locking policy in force, a user can choose whether or not to lock an object on checkout. In this situation, locking does not prevent another user from checking out an unlocked copy of the same version. It only prevents that user from checking in on the same branch until the locked version is checked in.
The case sensitive uniqueness policy ensures that case sensitivity is applied to the names of file system files and their containers when these are created in the repository. When the policy is in force, for example, you are able to create a file named "MyFile" and a different one named "myfile". When the policy is inactive, these two files would be treated as the same file, so creation of the second one would not be allowed.
This policy is of particular use for files that are uploaded from a UNIX server, where case sensitivity is a feature of file and directory names.
Further options control whether object dependencies are copied by default when a repository object is either versioned or copied. In either case the default can be overridden at the time of the operation.
Shares as we know them in Oracle Designer 6.0 and before no longer exist. You are allowed to create references to elements anywhere in the repository, provided these elements are owned by folders that you have select privileges on. You do not need to create a share to the context folder. In the figure below Column Job in Table Definition HRM/DESIGN/HSD_EMPLOYEES has a reference to a domain JOB TITLES that is owned by Folder CORPORATE. This reference is created without sharing the domain to the HRM/DESIGN Folder. For those amongst you who suffered from dummy and skeleton application systems: they are a thing of the past! Moving an element from one folder to another will not create shares for referenced objects, as was the case for the transfer operation in Oracle Designer 6.0.
The following shows that no share is required in order to have a reference to a domain in a different folder:
A valid question now would be: does this mean we do not have shares at all anymore? The answer is: well, no, but we do have something very similar. And to overcome any ill feelings you may harbor against shares, this new mechanism is called short cut. It is indeed very much like the File System Short Cut you may know from MS Windows. And it offers some nifty features.
A short cut is a link between a Folder and an Element, with the ownership flag set to false. Short cuts are created by dragging & dropping the element to the Folder (or Edit, Copy; Edit, Paste Reference). Select privileges are required on the owning Folder and Update privileges on the target Folder. Links between a Folder and an Element with the ownership flag set to true indicate the Owning Folder link. Note that you cannot create a short cut for a Folder, only for individual Elements. Also note that a short cut applies to all versions of the element it is created for. Creating a short cut from Folder HRM/PUBLIC to Table Definition HSD_DEPARTMENTS means: linking every single version of HSD_DEPARTMENTS to HRM/PUBLIC.
In the context of a Folder, you will see all its owned Elements as well as its short cuts. That means that you can see and reference elements without having to search and navigate through the entire repository. Furthermore, if you click on the little hand icon or press F12, you will navigate directly to the source of the shortcut. New (compared to shares in Oracle Designer 6.0) is the ability to edit-in-situ: if you have update privileges on the Folder that owns the Element, you can directly update the Element short cut without having to navigate to the owning Folder. Another step forward is the ability to copy a short cut. That means: you can drag & drop a short cut to a Folder, thus creating a short cut to the same Element the original short cut links to.
You should realize that you can still use Oracle Designer 6i as you always have before, i.e. use Oracle Designer 6i as your repository for non-versioned structured elements only. In time you may consider the storage of files as well and finally enable the versioning of both element types. This chapter will provide you with an insight on how to use Oracle Designer 6i, and it provides an overview of the relevant chapters of Part 2 "Migrating the repository" for each Oracle Designer 6i mode.
If you do not want to version your elements - the reasoning on which to base your decision will be provided soon - you simply should not enable the version option in the Repository Administration Utility just after a fresh Oracle Designer 6i installation. As long as the version option is not enabled you can only store "one version" of each element, just like in previous Oracle Designer releases. In fact the version properties of each element will not be populated, because you will never be able to check in an object. You will only commit your changes. Each participant will use the GLOBAL_SHARED_WORKAREA.
In addition you will instruct your participants not to store any file in the repository. Note that there is no system repository option available that can stop you from populating the repository with files.
You will typically use Oracle Designer 6i in this specific mode in the following circumstances:
The following chapters of Part 2 "Migrating the repository" are relevant:
Obviously you may skip all sections in the above chapters that handle the versioning of data.
If you do not want to enter the versioned world, but you do want to store files in addition to structured elements, you also simply should not enable the version option in the Repository Administration Utility.
In addition you should provide your participants with guidelines on how to store files and folders in the repository. More specifically you should set up a folder hierarchy with appropriate access rights. See also Chapter 7 and Chapter 8 of Part 2.
You will typically use Oracle Designer 6i in this specific mode - thus including the storage of non-versioned files - in the following circumstances:
The following chapters of Part 2 "Migrating the repository" are relevant:
Obviously you may skip all sections of the above chapters concerned with the versioning of data.
If you would like to enter the vesioned world, you simply enable the version option in the Repository Administration Utility just after a fresh installation and you provide at least some users with the container access right "version". See also Part 2, Chapter 7 "Migrate users and assign access rights".
You would like to enter the versioned world for at least the following reasons:
Your migration efforts are more substantial. The following chapters of Part 2 "Migrating the repository" are relevant:
|
|
|
