Configuration Management With Oracle Designer
Configuration Management Features and Capabilities of Oracle Designer
Oracle Designer offers substantial new configuration management capabilities utilizing the Oracle Repository. This article will provide an overview of the new configuration management functionality and how it can best be utilized to provide a robust application development environment.
One of the primary benefits of using Oracle Designer is the ability to share existing knowledge between applications. However when new functionality needs to be added to the repository and existing applications have already been defined serious configuration management issues can arise. What used to work may suddenly exhibit new and unintended features. A well planned configuration management plan coupled with the new features of Designer can help to alleviate most of the problems associated with revisions and derivations of applications.
Configuration Management coordinates the resolution of software development issues by identifying and controlling the problems that confront software development teams. Maintaining multiple incremental releases of software inevitably causes them to diverge from each other meaning that even with the best of intentions a seemingly identical change made to two versions of an application many times result in two different results. Over time the discrepancy between versions grows wider as new features are introduced that may not be included in the original version. Without control over existing releases with their bug fixes and new release that introduce added functionality the ability to rebuild prior versions becomes difficult or impossible. Manually maintaining the identification and maintenance of existing versions becomes increasingly difficult as new versions are released. As additional versions are introduced it is increasingly likely that a modification will not be propagated or retrofitted which may introduce bugs or result in a loss of functionality.
Sharing data and information between Designer applications presents many benefits. The ability to maintain information in one place reduces overhead and eliminates having to determine which information is correct or the most up to date. For example if the length or type of a field needs to be changed many applications, modules and databases may be affected. In traditional development environments manually ide
https://redzone.labette.edu/ICS/Campus_Life/Campus_Groups/Radiography_Club/Discussion.jnz?portlet=Forums&screen=PostView&screenType=change&id=d183786f-e349-41d4-82e2-4a3c679f89c1 https://redzone.labette.edu/ICS/Campus_Life/Campus_Groups/Radiography_Club/Discussion.jnz?portlet=Forums&screen=PostView&screenType=change&id=f037e5b4-1bc9-47e6-b285-42154b9a1af8 https://redzone.labette.edu/ICS/Campus_Life/Campus_Groups/Radiography_Club/Discussion.jnz?portlet=Forums&screen=PostView&screenType=change&id=88e66a35-9994-41a3-9f6a-388647ebaa6e https://redzone.labette.edu/ICS/Campus_Life/Campus_Groups/Radiography_Club/Discussion.jnz?portlet=Forums&screen=PostView&screenType=change&id=ef971f26-0463-4deb-b79f-8f19e652e315 https://redzone.labette.edu/ICS/Campus_Life/Campus_Groups/Radiography_Club/Discussion.jnz?portlet=Forums&screen=PostView&screenType=change&id=f7fab051-bb3d-4d1c-9e46-5dc54864675e
ntifying where the required changes need to be made is a daunting task, ensuring the modification is made everywhere it is needed is even more difficult. The ability to automatically perform impact analysis to determine the scope of a change quickly and accurately benefits management and designers when they need to estimate the resources required to implement a change and developers who may have to grope through a variety of systems to locate all occurrences that need modification.
Simultaneous updates are another problem that offer many pitfalls. If Sally is modifying a module and Frank needs to fix a bug in the same module the likelihood of Franks bug fix being overwritten by Sally's enhancement is high. Without a configuration management procedure in place the communication needed to keep everyone informed with all modifications being made is nearly impossible.
Through this paper and the accompanying presentation examples will be shown and solutions described illustrating how Oracle Designer and the Oracle Repository provide many of the requirements of a sound configuration management system. Using this information you will be better equipped to develop a configuration management framework to control objects within the Oracle Repository.
Communication issues
Consider that a three person team only has three communication paths. However adding a fourth team member doesn't just add one more communication path it raises the number of communication paths to six. Imagine adding a fifth developer! Frequent team meetings somewhat alleviate this problem, however it is all too often true that the meetings are not frequent enough, don't cover all of the necessary issues or may be impossible due to teams being separated geographically.
The Oracle Repository and Designer introduce many new terms and concepts; Containers, Configurations, Workareas, Merge, a new check in/check out mechanism, synchronization with file systems just to name a the most common associated with Configuration Management. In the past there were only two kinds of element types used to store information about Applications in the Repository, Primary Access Controlled elements (PAC) and Secondary Access Controlled elements (SAC). The following descriptions will provide a framework of knowledge about the new terminology and their function.
Containers
With the new functionality of being able to version and work with many objects at the same time for different purposes, a means of organizing these objects into a manageable size was needed. A new versionable and transferable construct called a Container was created for this purpose. Containers are similar to directories in a file system they provide a way to organizing repository objects in a logical fashion.
Containers can be of two types depending on how the repository is utilized, folders and application systems. If the repository is used only as a source control system Folders are available. If Designer is used for application development then Application Containers and Folders can be used. Application Containers are very similar and have the same appearance of an "Application" in prior releases of Designer. Folders on the other hand are totally new in this release and provide a means to upload and version external files and documents. It appears though that technically they are identical under the covers since typical application objects (modules, entities...) can exist in folders and external documents (word, excel) can exist in application containers. New versions of containers are created when objects are added or removed from it, or if changes are made to the properties of the Container. Containers can contain totally different objects or exactly the same objects as another container only diverging when a modification is made.
Configurations
A group of versioned objects are specified to exist in a configuration. An object can exist only once in a configuration but it may exist in many different configurations. This graphic from Designers Help depicts two different configurations and show that a configuration can itself be versioned and tracked as an object.
A configuration provides a method of tracking releases of a set of objects at a specific time (or state). An object version included in a configuration is considered a member of that configuration. They can be added, modified or removed to create new versions of the configuration. A Configuration can also be created and defined via one of the following rules: include/exclude folders or objects, latest, latest before and between, another configuration.
Workareas
Development shops typically have more than a single developer. These developers certainly find, on occasion, that they need to modify or enhance part of an application that another developer is also modifying. Separate Workareas provide a means for concurrent access to objects that can later be merged into a configuration or serve as a basis for a new configuration. Additionally in the case of large applications with thousands of modules a developer probably doesn't need or want to have every one of those modules in their development area. A Workarea provides a mechanism of organizing the objects that the developer is currently interested in thereby removing the clutter of the other unneeded objects. Workareas are non-versionable objects that serve as a context for all work performed until a sessions ends or the user decides to change work areas. By specifying access control on the work area they can be configured to be private for a specific developer or testing team or open for access to everyone.