Oracle9i Designer Migration Guide
Appendix B. Quick reference information
|
Oracle9i Designer Migration Guide |
A type of Container that groups Structured Elements with a logical affinity to each other. This affinity may be data related (that is, all data elements for <App System Cluster>) or function related. An Application may container Folders to hold related File Elements and Documents (that is, ins and ddl).
A type of Configuration Item that is the direct source for an application executable element (that is, Module Definition, Report Source File). These generate out as Developer, PL/SQL, etc. source or are extracted “as is”.
A group of application systems that are strongly interrelated. For example a set of entities and tables from application system CORE is referenced by the application systems SALES and STOCK. You would typically group these application systems in a single workarea.
A base line configuration - or base line release - represents a full set of object definitions for a specific system. For example base line configuration <App System> 3 represents release 3 of system <App System> and contains all elements within <App System> that should be deployed for release 3.
Branches are sequences of object versions that have their starting point at a particular version in an existing branch, but evolve independently. All the versions together create a version tree. A version tree always has a MAIN branch, and may also have sub-branches. Branching enables you to develop multiple versions of a product simultaneously (parallel development) using the same set of source files.
When you check in an object for the first time, it is always added to the default MAIN branch. If the repository policy specifies an alternative branch to check in to for the first time, two versions are created, one on MAIN and the other on the specified alternative branch.
The checkin option versions an uploaded file/folder or a saved structured element. For example, the file or folder is already stored in the repository and in addition it will be enhanced with version information and you will be able to view the file/folder/structured element in another workarea. Note that another version of an element can only be created via a checkin operation.
Repository elements can be manipulated only when they are checked out (or unversioned). You therefore first have to check out a checked in element before you can apply changes. The checkout action starts with the creation of a duplicate of the element. This allows you to perform an undo checkout operation. As a result you will fall back on the original, checked in element version.
A configuration is another means to isolate only one version of one or more repository elements. The content of a configuration is fully static, in contrast to workareas. Like any other element you can version configuration. This version capability of configurations can be used to associate configurations with a workarea or, to put it differently, to base a workarea on one or more configurations. Another application of the configuration version capability is the storage of an original element set in the “first” version of the configuration. Within the next version all corresponding derived elements (ddl files) are stored.
The product of a task, or a deliverable for the project, which is placed under Configuration Management.
A grouping of items for the purpose of usage, access, or extraction. Within the Oracle Repository containers can be Applications (for example, DMO, Headstart) or Folders (for example, ins, ddl). Containers should not be confused with Workareas (see below). Workareas are a means of presenting containers and their contents.
A type of Configuration Item that is the direct source for the initiation of a database schema element (that is, seed data script). These are extracted “as is” for use.
A type of Configuration Item that is the direct source for the restructuring, conversion, or initiation of a database schema element (that is, restructure table script). These are extracted “as is” for use.
A type of Configuration Item that is the direct source for a database schema element or a database schema logic element (that is, Table or View Definition). These generate out as DDL scripts.
A database schema is a user in the database. Each database element like a table or view (expect a role) is owned by a database schema.
Database Synchronization refers to the state of database definitions in the repository versus its mapped database objects in the database within a database schema. There can be a mismatch between these two, since there are (within the context of a workarea) two database representations, one in the repository and one in the database. The database synchronization status can be checked with the CheckRelease Form (see CheckRelease QRC).
See database schema. Note that each database user can access its own database objects - obviously. In addition a database user can access database elements of other users - or schema’s - via a mechanism of grants and synonyms.
Any type of Configuration Item which is part of the supporting description an application system’s architecture, environment, usage, or its general definition.
The download option allows you to publish files and/or folders from the repository to a specific folder path on the operating system - either based on the default folder mapping or session specific value. The download will prompt you if the file already exists on the file system.
The content of a workarea is primarily determined by workarea rules (see above). You need a specific workarea access right (Update Spec) to change the workarea rules for a workarea. This Update Spec policy is given only to a PCM. This Update Spec right must be distributed in combination with the Refresh or Compile right (see below).
Any type of Configuration Item (see above), intermediate item (not under configuration control), executable item (for deployment), or other component which is associated with the development and deployment of the application system that is being constructed or maintained. An element can be either structured or unstructured (file).
A specific set of elements drawn from across each of the technology layers. An environment is identified as being for a particular promotion state or purpose, such as application development or application deployment. An environment will include a specific Baseline Configuration, a directory structure containing source and executable programs, a specific database schema containing data structures and data content, and an accessible toolset.
A type of Application Element which may or may not have been originally sourced from Designer, but whose current source is the file system representation, (for example, a report with post-generation changes, or data conversion scripts written by hand).
File Synchronization (not to be confused with the synchronization option, see above) refers to the state of files in the repository versus its mapped files on the file system. There can be a mismatch between these two, since there are (within the context of a workarea) two file representations, one in the repository and one on the file system. The file synchronization status can be checked with the CheckRelease Form (see CheckRelease QRC).
A type of Container that groups File Elements with a logical affinity to each other. They may be related by usage, project phase focus, or other criteria. Top level Folders are usually created as children of Applications and may contain other Folders in turn. A standard set of Folders has been identified for general use in all Applications (that is, ins and ddl).
Folders - containers for files - in the repository can be mapped against directories on the file system via the folder mapping option (available for root containers only). This mapping - stored locally in the registry - is reused while downloading and uploading files (see below).
See Configuration Item.
The classification of an Item based on its definition, characteristics, or use (see below).
A storage system which contains a copy of all the items under Configuration Management control, and also contains the information that relates those items to each other and to project deliverables. This facility is provided by the Oracle Repository, which is implemented as a specific database schema, that underlies the Oracle Designer toolset. The CM repository contains for example all <App System> entities, tables, views and files and subsequent versions.
A root container (application system or folder) is the starting point of a container structure like a root directory on the file system.
A partial configuration contains only a limited set of object definitions for a specific release. A partial configuration can be associated with a single registered enhancement request (“Change Request”) or with a bundle of registered enhancement requests. For example partial configuration <App System>_20013011 represents enhancement request <App System>_20013011 for system <App System> and contains only objects that are associated with this enhancement request.
The refresh or compile option of a workarea (another specific workarea access right) reevaluates the content of a workarea based upon the workarea rules, without changing the workarea rules themselves. The end-result (pointers) is stored in the workarea table.
The requery does not reevaluate the workarea rules, but takes the persistent workarea table content as a given and requeries all primary and secondary elements, associations and properties.
A sandbox - or playground - workarea can be used for the preparation of releases or to experiment with workarea rules. The use of a separate workarea during the preparation of a release circumvents the interference with ongoing development and testing activities.
The following operations can be executed against a workarea:
A type of Application Element that is defined wholly within the Designer toolset and is then generated out from there for use in the application system (that is, Entity, Table Definitions, View Definitions)
The synchronization option (files only) compares the repository content with the underlying file system, for a specific directory tree. Subsequently it will suggest uploads and downloads for file mismatches. This option will however be rarely used because files are downloaded or uploaded on a individual basis during checkin and checkout procedures (see Checkin and Checkout QRC).
The target or destination file system is the environment on the file system level that will receive the files for a specific system (DMO) captured in a specific release.
The target or destination database schema is the schema in the database (in the specific target database instance) that captures the database objects of one or more systems (for example, <App System>, OHL) of a specific release (or configuration).
The target or destination workarea is the environment in the repository that will receive the release, captured in a configuration. The target or destination workarea, given the (D)TAP model, could be Test (for example, <App System>_TST_REL<release nr>), Acceptance test (for example, <App System>_ACC) or Production workarea (<App System>_PRD).
The latest object version of a branch.
The upload option allows you to store files and/or folders in the repository from a specific file system path, either based on the default folder mapping or session specific value. Note that an upload does not check in the element. That is, no version properties are added and you cannot view a stored file/folder in another workarea.
The CheckRelease Form reports about the synchronization status of repository elements versus its file representatives on the file system and its database representatives in the database (see also CheckRelease QRC).
The rendering of an item which incorporates all of its revised content starting from a given point (that is, from a previous version).
A workarea serves as an access vehicle or environment to the repository content. Within a workarea you can see (and manipulate with appropriate access rights) only one version of one or more objects, grouped in a container structure. A workarea therefore provides a version resolved access mechanism to the repository elements. A workarea only contains pointers to the full definition of the element - it does not capture the full element definition.
The content of a workarea can change over time, for example via checkin and checkout actions. That is, a workarea content is dynamic. Almost all Oracle SCM and Oracle Designer tools (except the repository object navigator) - allow you to access the repository elements only in the context of a workarea. That is, you cannot access the Design Editor in the context of a configuration.
Note that there is, luckily, no need to version a workarea. You cannot therefore version a workarea.
The content of a workarea is primarily determined by workarea rules. A workarea can contain multiple workarea rules (for example, LATEST(MAIN), INCLUDE_FOLDER(<App System>)) that are evaluated one by one (from top to bottom). The evaluation result (pointers to the full element definition) is subsequently stored in a persistent way (in a workarea table).
The RON or Repository Object Navigator provides a tree-navigational interface to the repository elements (structured elements and files). Subsequently the RON hosts all configuration management functionality like the manipulation of workareas, configurations and branches, file manipulation, and merge utilities.
The DE or Design Editor also provides a tree-navigational interface and a graphical interface to the structured design repository elements like tables, views and sequences. In addition, it hosts the DDL generators. Note that these generators are no longer available in the RON.
The Version History Viewer displays a graphical interface of all versions of a specific element. You can launch the VHV from the RON or DE.
The Version Event Viewer displays a character-based interface of all versions' history information (for example, checkin/checkout notes, the owner of the changes, when changes took place) of a specific element. You can launch the VEV from the RON or DE.
The element compare tool displays a detailed overview of the differences between two element versions. You can launch the element compare tool either from the RON or DE.
The element set compare tool displays an overview of the element set differences, differences in version numbers, for example the differences in element set memberships of two workareas or configurations.
You can launch the element set compare tool only from the RON.
The element merge tool merges differences between two object versions on different branches on a conflict by conflict basis. For example you can merge object version 1.2.1.1 into MAIN branch label 1.4 resulting in version 1.5.
You can launch the merge tool from the VHV.
The merge wizard allows you to perform a merge for a set of elements.
For example you can merge all elements checked in on a specific branch (for example, <App System>_REL1) into the corresponding elements in the workarea that captures the MAIN branch (for example, <App System Cluster>_DEV).
You can launch the merge wizard from the RON.
For example, 10.
The format of a release nr is indicated with x where x represents the major component. A release can contain all objects of an application system (baseline release) or it can contain only the changed and added objects introduced in a specific release (increment). Note that releases are implemented by configurations and that you could have multiple versions of configurations (see below).
For example, 1.1
The format of the version number of a single object is indicated with 1.y where y represents any major or minor change.
For example, 1.1.1.1
The format of a branch version number of a single object is indicated with 1.y.1.z where ‘y’ and ‘z’ represent any major or minor change.
Workarea that captures the latest versions of all objects of one or more strongly interrelated application systems, for example MARKETING_DEV. The default checkin branch is equal to MAIN.
Workarea to prepare a specific release or to try out different workarea rules with a stack of configurations. SB stands for sand box (play ground). There is no default checkin branch and there are no database schemas associated with this workarea.
Workarea that captures one or more application systems of a specific release and/or application system patches that has reached the acceptance test status. There is no default checkin branch (by definition).
Workarea that captures one or more application systems of a specific release (and/or application system patches) that has reached the production status. There is no default checkin branch (by definition).
Workarea that fixes incidents on one or more <App System> release that has reached the production status. The default checkin branch is equal to <App System>_REL_<release nr>.
Branch label for the MAIN branch
Branch label that captures the latest version of a specific <App System > release (for example <App System Cluster>_REL10).
Branch label that captures the latest version of all production fixes of a specific <App System > release (for example <App System >_PRDFIX_REL10).
Base line configuration for <App System> that contains a full set of all database elements or all changed and introduced elements (increment) (for example <App System>_REL10).
Note that you have to create a new baseline release if you remove elements from the <App System>.
Patch configuration for <App System> that contains all elements that are solved for one or more fixes in the context of a specific release (for example <App System >_REL10FIX1).
Baseline DDL scripts belonging to a specific release of an application (for example <App System>REL10.sql, <App System>REL10.tab).
For a list of possible values of the <ext> see below.
Overall DDL script, derived from the generated baseline scripts for a specific application system. The <release> part stands for the target release.
Seed data script for a specific table within a specific application system.
Overall DDL script, derived from the generated delta script(s), for a specific fix (or fixes) in the context of a specific release. <App System>REL10FIX1.sql
Specific database schema that captures the database objects of a specific application system.
Sub-Folder that captures the database install (DDL) scripts.
Sub-Folder that captures the packages stored as files (for example *.pck) and the overall release delta script that is transferred to Application Services.
System Identifier (SID) of the Oracle database.
Note that the above operations cannot be enforced by Oracle9i Designer. Every developer is able to execute each of the listed actions, since every developer has the version right and they all share the same workarea.
The repository supports the following revision keywords:
Note that you should not use the string ‘||’ on the specific location. This string is added here to circumvent the expansion when this specific QRC document is checked in to the repository.
You should always add the “revision” keyword string, on a specific location/property, into new design elements and files. Use the following overview for the specific location:
Note that you can copy/paste an existing revision keyword string for the exact syntax from existing tables/views/files. The version string is automatically updated after the checkin operation.
Workarea: [Basic]
Branch Label : [Version]
Checked In By: [Version]
Check State: “Checked in” [Version].
Note that you may find too many merge candidates, since you do not need to merge if the tip of the branch is already merged into the MAIN branch. The latter can be visualized via the ROB Version History Viewer. You could also try to narrow down the search result by translating the “merge of the tip version into the MAIN branch” condition into an “additional where clause” field on the [Advanced] search TAB.
The merge steps for containers are more or less equal to the merge guidelines of structured elements and files.
However, you will only be confronted with differences of folder memberships (see step 6 of the "Merge guidelines
for structured elements and files").
|
|
|
