Oracle Designer SCM Guide

Oracle Designer SCM Guide
Oracle Designer SCM Guide




   Ministry of Community Services

Ministry of Tourism, Sport and the Arts

               (CS/TSA)
Oracle Designer SCM Guide
Table of Contents
1     Version Control ......................................................................................... 4
2     INTRODUCTION ........................................................................................ 5
2.1   Audience......................................................................................................................... 5
2.2   Purpose .......................................................................................................................... 5
2.3   Assumptions ................................................................................................................... 6
2.4   SCM Vendor meeting prior to project commencement ................................................... 6
2.5   Other Documents............................................................................................................ 6
3     Configuration Management - background.............................................. 6
3.1   What is Configuration Management................................................................................ 6
3.2   Software Configuration Management (SCM) .................................................................. 7
4     DEFINITION OF TERMS ............................................................................ 7
4.1   Element........................................................................................................................... 7
4.2   Version tree .................................................................................................................... 7
4.3   Container ........................................................................................................................ 8
4.4   File Folder Structures...................................................................................................... 8
      4.4.1    Database files (DDL/DML) Scripting Standards.............................................................................10
4.5   Workarea ...................................................................................................................... 11
4.6   Configuration ................................................................................................................ 11
4.7   Promotion model........................................................................................................... 11
5     Repository–wide policies....................................................................... 12
5.1   Versioning policies ........................................................................................................ 12
      5.1.1    Automatic branching ......................................................................................................................12
      5.1.2    Automatic version labeling .............................................................................................................14
      5.1.3    Strict locking...................................................................................................................................14
5.2   Names of files and folders ............................................................................................ 14
      5.2.1    Case sensitive uniqueness checking .............................................................................................14
5.3   Dependencies............................................................................................................... 14
      5.3.1    Copy on versioning ........................................................................................................................15
      5.3.2    Copy on copying ............................................................................................................................15

6     Security.................................................................................................... 15
6.1   Database ...................................................................................................................... 15
6.2   Repository..................................................................................................................... 15
6.3   Roles............................................................................................................................. 17
6.4   Workareas .................................................................................................................... 17
6.5   Containers .................................................................................................................... 18
6.6   Configurations............................................................................................................... 19
7     Seeding of applications with Enterprise standards ............................ 19
7.1   What gets seeded ......................................................................................................... 19
7.2   Seeding workarea ......................................................................................................... 20
7.3   The seeding process..................................................................................................... 20
      7.3.1    Seeding an empty container ..........................................................................................................21
      7.3.2    Seeding an existing container for the first time ..............................................................................23
      7.3.3    Adding new seed domains to a previously seeded container........................................................25
      7.3.4    Upgrading previously seeded domains..........................................................................................28
      7.3.5    Copying seed domains...................................................................................................................30
Oracle Designer SCM Guide
7.4   Verifying updates to seeded elements .......................................................................... 32
8     PROMOTION MODELS ........................................................................... 33
8.1   Development Promotion model..................................................................................... 33
8.2   Parallel maintenance promotion model......................................................................... 35
8.3   Emergency fix promotion model ................................................................................... 37
8.4   Promotion management procedures............................................................................. 39
      8.4.1    Overview ........................................................................................................................................40
      8.4.2    Delivery ..........................................................................................................................................41
      8.4.3    Release Build and Promotion.........................................................................................................53
      8.4.4    Pre-Configuration QA Checks........................................................................................................75
      8.4.5    Post-Configuration QA Checks (WA_DELIVERY_) ...........................................................78
      8.4.6    Promotion from WA_TEST_QA to WA_PRODUCTION ................................................................80
      8.4.7    Demotion ........................................................................................................................................82
      8.4.8    Non-release-based (exception) configurations ..............................................................................82
      8.4.9    Transfer of Application Version ......................................................................................................83
      8.4.10   Transfer of Entire Application.........................................................................................................84
      8.4.11   Archive of Application Version .......................................................................................................84
      8.4.12   Archive of Entire Application ..........................................................................................................84
8.5   Workarea Rules used during Delivery........................................................................... 85
      8.5.1    Inclusion Rules...............................................................................................................................85
      8.5.2    Exclusion rules (optional) ...............................................................................................................85
8.6   Workarea rules used for parallel maintenance.............................................................. 86
8.7   Workarea rules used for emergency fixes..................................................................... 86
8.8   Merging......................................................................................................................... 86
      8.8.1    General (read this first) ..................................................................................................................86
      8.8.2    Container merges...........................................................................................................................88
      8.8.3    Element merges .............................................................................................................................94

9     RELEASE MANAGEMENT...................................................................... 98
9.1   Versioning of base release or patch configuration ........................................................ 98
10    ADDITIONAL REPOSITORY ENVIRONMENTS ..................................... 98
11    CONCLUSION.......................................................................................... 98
Oracle Designer SCM Guide
Ministry of Community Services



1 Version Control
Ver.                                Description                                       Date          Author      Org.
0.1    First Draft                                                               2003-NOV-10 Scott Petersen SBD
0.2    Revised based on feedback                                                 2002-DEC-18 Scott Petersen SBD
1.0    Bea’s feedback                                                            2003-JAN-14     Gary Wong      SBD
1.1    Revised Promotion Model                                                   2004-MAR-12 Gary Wong          SBD
1.2    Added Configuration QA Checks (6.2.7, 6.2.8) and WA_TEST_QA to
       WA_PRODUCTION promotion (6.2.9)                                           2004-APR-22     Gary Wong      SBD
1.3    Renamed WA_DELIVERY to WA_DELIVERY_ conventions                      2004-MAY-14 Gary Wong          SBD
1.4    Added section 6.3 (Workarea Rules)                                        2004-MAY-18 Gary Wong          SBD
1.5    Updated Section 6.2.2 to exclude UDS PAC element from UDS
       membership                                                                2004-JUNE-1     Rob Gretchen   CS
1.6    Included sections on creating a configuration, use of the staging workarea,
       further explanation on choice of folder version when using
       INCLUDE_FOLDER_VERSION. Also added QA check on Delivery
       procedure for container and contents check-in state and use of
       INCLUDE_FOLDER rule when creating a full release                            2004-JULY-19 Bia Stratton    BSC
1.7    Added WA_DELIVERY__STAGE descriptions and renamed
       document to “Oracle Designer SCM Guide”                                   2004-JULY-30 Rob Gretchen      CAWS
1.8    Changes relative to allowing concurrent development (emergency fixes and
       parallel maintenance). Included section on branches, policies, new
       workareas and merging                                                    2004-AUG-24 Bia Stratton        BSC
1.9    Changes based on last review meeting on parallel development and
       emergency fix environments.                                               2004-SEP-30     Bia Stratton   BSC
1.10 Added mention of meeting prior to project start, for SCM discussion.
       Added section on inclusion of entire folder hierarchy when creating
       configuration from workarea spec.                                         2004-NOV-12 Bia Stratton       BSC
1.11 Added section on seeding of application containers from Enterprise model
     standards.
       Added section on new workarea rule for parent folder inclusion for all files
       in UDS.                                                                      2004-DEC-6   Bia Stratton   BSC
1.11 New workarea for prevention of check-outs of seeded elements.
       Few changes to seeding process to account for usage of this workarea      2005-MAR-15 Bia Stratton       BSC
1.12 Removed usage of INCLUDE_FOLDER during release deliveries                   2005-MAR-21 Bia Stratton       BSC
1.13 Make use of delivery staging workarea mandatory and use this workarea
     for configuration build. Also, added new post-configuration QA check.       2005-MAY-26 Bia Stratton       BSC
1.14 Update to reflect change to Ministry name(s) and update wording to reflect                  Rob Gretchen /
     upgrade from Oracle Designer 6i to 10g.                                    2006-FEB-03      Maureen Bird CS
1.15 Update to reflect inconsistencies in “Configuration” creation processes and
     to focus on only using WA_DELIVERY rules for configurations (Section
     8.4.3). Also updates for scripting standards for database deliveries in
     SQL*Plus (Section 4.4.1)                                                    2006-JUL-26     Rob Gretchen   CS



Oracle Designer SCM Guide
Thu, Aug 10, 2006                                             Version 1.14                                      Page: 4
Oracle Designer SCM Guide
Ministry of Community Services




2 INTRODUCTION
This document details the methods of using the Designer 10g repository for version control of software
and metadata. This version control, also called Software Configuration Management (SCM) and is a
vitally important component of the application development lifecycle. It allows for the structured
assembly of application database artifacts (objects) within a configuration management discipline, thus
ensuring accuracy and traceability of application releases.

2.1 Audience
The intended audience for this document includes:
   •       Repository managers who administer the ministry repository
   •       Vendors engaging in systems development and maintenance projects with the ministry
   •      Application support staff involved in installation of applications, evaluation of bugs and
       enhancement requests
   •      In-house data administration analysts who define standard constructs that are (re-)used by
       application systems
   •       Business analysts who develop preliminary application models and provide guidance to
       their clients regarding application development projects


The following table outlines the specific “focus” areas of this document for the varying audience
involved with developing applications using the CS SCM processes. This table only provides
references for those roles which have “hands-on” requirements for interacting with the SCM process
through Designer:


 ROLE                         MANDATORY SECTIONS                   RECOMMENDED SECTIONS
 Repository Manager           ALL                                  ALL
 Developer (Programmer)       Section 8.4                          Sections 2-6
 Developer (Application       Section 8.4, 8.5 (                   Sections 2-6
 Configuration Manager)



2.2 Purpose
The purpose of this document is to inform the reader about the structure of work environments within
the Designer 10g repository, and how application systems releases are managed, within this set of
environments.

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                   Version 1.14                                  Page: 5
Oracle Designer SCM Guide
Ministry of Community Services

2.3 Assumptions
   •       Versioning of the repository is enabled
   •      The Ministry will be responsible for all backups of the container; at any time, Ministry staff
       can see the work in progress
   •       Labeling of the releases shall be via Configurations; the container ‘version’ will not be used
       to identify releases
   •       Non-Oracle code (e.g. .java class files.) will not be included in the repository but will be
       included in the Ministry VSS implementation or on the Ministry network.
   •       Documentation in the form of Word Documents etc. will be included in the repository.
   •       Repository users that have read or write access will connect to the repository via named
       individual accounts (e.g. case_jsmith )
   •       Individual accounts will have only the minimum access rights and privileges to do their job
       (e.g. see only the applications and workareas for which they’re responsible)
   •      Throughout the remainder of the document, the Ministry of Community Services and the
       Ministry of Tourism, Sport and the Arts shall be referred to as “the Ministry”.

2.4 SCM Vendor meeting prior to project commencement
It is important that the project team and business analysts meet with the Ministry repository manager
prior to project start, to discuss how the use of software configuration management practices will affect
the project activities and schedule.
Project teams should be familiar with SCM standards and their responsibilities in the area of version
control and release management and delivery. This introductory meeting will provide an overview of
Ministry SCM practices, expectations and services provided.

2.5 Other Documents
   •       Oracle Designer 10g Standards and Guidelines


3 Configuration Management - background

3.1 What is Configuration Management
Configuration Management is the discipline of organizing and managing products and their
individually existing component parts. The right components need to be assembled in the right way to
produce the appropriate end product.
Components can be altered slightly or recombined to create a slightly different version of the end
product (or a different product altogether). One of the goals of Configuration Management (CM) is to
manage the processes by which new component versions are created and their variations documented.

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                   Page: 6
Oracle Designer SCM Guide
Ministry of Community Services

It also addresses the recording and creation of new end products, particularly which component
versions are involved in assembling the product.

3.2 Software Configuration Management (SCM)
Configuration management applies to software engineering since the software products are usually
made of a selection of components.
An individual program, or a database table, is usually a component of a specific application. An
application requires a specific combination of versions of these components in order to function as a
whole. In addition, a suite of applications or the applications that combined make up the enterprise
environment also needs to be ‘version aware’ of each other.
While historically the information systems industry has done reasonably well in managing elements at
the file level and database level, it is only recently that the IT professionals have been faced with the
need to manage meta-layer elements. With the use of CASE (Computer Aided Systems Engineering)
tools, a new level of complexity was added to the CM discipline. The analysis and design definitions,
which originate an application’s physical components, also need to be configuration managed.


4 DEFINITION OF TERMS

4.1 Element
At the lowest level of granularity, the Repository is filled with elements (also referred to as objects; the
two terms are interchangeable). All elements are classified as either Structured or Unstructured.
   •       structured element - 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 Elements at this moment are the
       Oracle Designer element types (Entity, Business Function, Table Definition etc.)
   •       unstructured element - An element that has a structure that is unknown to the Repository
       infrastructure is, somewhat strongly, labeled Unstructured Element. 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.

4.2 Version tree
Configuration Management makes use of tree structures to maintain the evolution of elements into their
various versions. Maintaining snapshots would be of little use if the sequence of their occurrence were
unknown. Versions are nodes in a tree, and the linkage between a version and its predecessor is known
information.
Version trees have a main branch and any number of branches. Branches can stem from the main
branch or from another branch, and can also be combined or merged together into a single branch. The
figure below illustrates a typical element version tree.


Oracle Designer SCM Guide
Thu, Aug 10, 2006                                     Version 1.14                                    Page: 7
Oracle Designer SCM Guide
Ministry of Community Services

        PARALLEL       MAIN          EMERGENCY
        MAINTENANCE                  FIX
                         1.0




                         1.1




                         1.2
                         1.1        1.0.3.1
                                    1.1.1.0




            1.0.2.2
            1.2.1.0      1.3
                         1.1        1.0.3.2
                                    1.1.1.1




                            merge




4.3 Container
A container is an object that groups elements within the repository. Containers have the version
dimension built-in. In other words, containers hold all versions of every element they own. The same
container always owns all versions of a repository element.
Containers can contain other containers in a hierarchical fashion.
Containers can be of two types:
   •       Folder - a container that holds unstructured elements
   •       Application System - a container that holds structured and possibly unstructured elements

4.4 File Folder Structures
   The Ministry standard folder structure for non-generated items, such as DDL/DML scripts, release
      documents which are created outside of Designer but need to be included in release
      management activities is:
       CM_non_generated
       CM_non_generated\admin
       CM_non_generated\dataconv
       CM_non_generated\db_objects
       CM_non_generated\doc
       CM_non_generated\install
       CM_non_generated\non_db_source
       CM_non_generated\www
       CM_non_generated\db_objects\schema folders
       CM_non_generated\db_objects\schema_app folders
       CM_non_generated\db_objects\schema_case folders
       CM_non_generated\db_objects\schema folders\Indexes
       CM_non_generated\db_objects\schema folders\Sequences
       CM_non_generated\db_objects\schema folders\Synonyms

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                               Page: 8
Oracle Designer SCM Guide
Ministry of Community Services

       CM_non_generated\db_objects\schema folders\Tables
       CM_non_generated\db_objects\schema folders\Triggers
       CM_non_generated\db_objects\schema folders\Views
       CM_non_generated\db_objects\schema_app folders\Functions
       CM_non_generated\db_objects\schema_app folders\Javascripts
       CM_non_generated\db_objects\schema_app folders\Package bodies
       CM_non_generated\db_objects\schema_app folders\Packages
       CM_non_generated\db_objects\schema_app folders\Procedures
       CM_non_generated\db_objects\schema_app folders\Type bodies
       CM_non_generated\db_objects\schema_app folders\Types
       CM_non_generated\db_objects\schema_case folders\Functions
       CM_non_generated\db_objects\schema_case folders\Javascripts
       CM_non_generated\db_objects\schema_case folders\Package bodies
       CM_non_generated\db_objects\schema_case folders\Packages
       CM_non_generated\db_objects\schema_case folders\Procedures
       CM_non_generated\db_objects\schema_case folders\Type bodies
       CM_non_generated\db_objects\schema_case folders\Types
       CM_non_generated\non_db_source\forms
       CM_non_generated\non_db_source\icon
       CM_non_generated\non_db_source\java
       CM_non_generated\non_db_source\other
       CM_non_generated\non_db_source\reports
       CM_non_generated\non_db_source\sql
       CM_non_generated\www\html
       CM_non_generated\www\icon
       CM_non_generated\www\img

   The Ministry standard folder structure for project deliverables is:
       CM_project_deliv
       CM_project_deliv\AppDev
       CM_project_deliv\BusReqDefn
       CM_project_deliv\ConfMgmt
       CM_project_deliv\CtrlRep
       CM_project_deliv\DataConv
       CM_project_deliv\DBDsgnBld
       CM_project_deliv\Doc
       CM_project_deliv\ExSysExam
       CM_project_deliv\ProjMgmt
       CM_project_deliv\QualMgmt
       CM_project_deliv\ResMgmt
       CM_project_deliv\Support
       CM_project_deliv\TechArch
       CM_project_deliv\Testing
       CM_project_deliv\Training
       CM_project_deliv\Transition
       CM_project_deliv\WorkMgmt


Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14        Page: 9
Oracle Designer SCM Guide
Ministry of Community Services



Before you can version files in the repository, you have to upload them into the appropriate sub-folder
within the application you're working on.
Every application has at least one mandatory sub-folder: "CM_non_generated" and optionally
CM_project_deliv", for holding non-generated application components and CDM project
deliverables, respectively.
The "CM_non_generated" folder has a number of sub-folders to cater for the typical types of files that
applications require. Additional sub-folders can be created by the repository manager if required.
The "CM_project_deliv" folders have a number of sub-folders which correspond to Oracle CDM
processes. Project deliverables should be placed in the appropriate folder prior to versioning.
File upload and download are done in the Repository Object Navigator (RON).



 To upload a file     Navigate to the folder you want the file to be in, and select the file if it already
                      exists. Then select "Upload Files and Folders" (either from the Utilities menu,
                      or from the right-mouse-click menu).
                      Note: If you're uploading a modified version of a file that is already under
                      version control in the repository, the file should be in check-out state, and you
                      should select the "overwrite changed files" option on upload

 To download a        Select the file. Then select "Download Files and Folders" (either from the
 file                 Utilities menu, or from the right-mouse-click menu). If you intend to make
                      changes to the file, you should check-out the file as well, to indicate to others
                      that the file is being worked on.

It is possible to upload and download multiple files at a time, by applying the same functions to a group
of selected files.

Note: The Ministry standard delivery folder structure may be extended if deemed necessary by the
Ministry project team in consultation with the developer.

4.4.1 Database files (DDL/DML) Scripting Standards
It is expected that any files uploaded into Designer that execute DDL/DML statements be properly
formatted and tested prior to delivery (upload) to the ministry’s Designer repository. All DDL/DML
files should conform to the following specification:


   1) All DDL/DML files MUST be properly formatted and tested to execute in SQL*Plus (10g
      client version). Those files which do not conform will be immediately returned to the
      developer.

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                    Page: 10
Ministry of Community Services



   2) Multiple DDL/DML files that execute as a sequenced set must be invoked from a driver (.sql)
      file.
   3) Output from all DDL/DML files must be logged to the appropriate log file. The log file should
      have the same name as the SQL file which creates it, except should have the “.lst” extension.
   4) The DDL/DML scripts should have some comments at the beginning stating the name of the
      script file itself, who the author is, what database connection (userid) is required to run the
      script, and what the body of the script generally does (purpose).
   5) DDL and DML statements generally should run independent of each other in their own script
      files.
   6) Any DDL statements which build PL/SQL objects (eg. Package, Package Body, Procedure,
      Function, Trigger) should include a “SHOW ERROR” command after the DDL statement that
      creates the object. This will ease troubleshooting when DDL commands abend due to errors,
      although the expectation is that the scripts have been thoroughly tested by the developer.

4.5 Workarea
A workarea is an environment that provides a ‘version-resolved’ view of specific repository elements
for a specific group of users / user role. That is, it shows one version of each of the objects defined in
the workarea. These objects may be the latest version of all objects in a container or specific versions
based on a configuration.
Access rights are established for work areas. Work areas are usually based on containers and / or
configurations, which may have further access rights defined. Thus, the contents of a workarea may
vary from user to user, due to their varying access rights to the underlying components.

4.6 Configuration
A fixed set of element versions. Configurations provide the basis for Release Management. They
specify the element versions that together make up a product release or patch.
Configurations themselves can also be versioned.

4.7 Promotion model
A promotion model is the specific set of environments and technology levels that elements go through
during their development or maintenance process, as well as the allowed environment transitions.
   •      Promotion level - the development levels that an element goes through. These levels
       generally follow the adopted systems development life cycle, with some additional levels. An
       example of a set of promotion levels is:
       ƒ   Development
       ƒ   Delivery


Oracle Designer SCM Guide
Thu, Aug 10, 2006                                     Version 1.14                                  Page: 11
Ministry of Community Services

       ƒ   Test_QA
       ƒ   Production
   •       Promotion environment - a physical environment where elements reside during their
       existence in a promotion level. Each technology layer requires a promotion environment for
       each promotion level. The designer repository is an example of a Promotion environment.
   •      Promotion - an allowed state transition between promotion levels (e.g. Promotion from
       Test_QA to Production)
   •      Demotion - an allowed state transition ‘rollback’ between promotion levels (e.g. Demotion
       from Delivery back to Development)


5 Repository–wide policies
Repository-wide policies dictate repository behaviour when certain tasks are executed by the user. The
figure below shows the repository policies currently in use at the Ministry.




5.1 Versioning policies
Versioning policies control tool behaviour on check-in and check-out operations.

5.1.1 Automatic branching
When selected, each workarea must have a default check-in branch. This default branch is provided to
users in the check-in pop-up window. (Note that users are still able to change the check-in branch. This
is not recommended though. It is a shortcoming of the tool)

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                   Version 1.14                                 Page: 12
Ministry of Community Services

Branches supported by the repository are used by the Ministry promotion models for parallel
maintenance and emergency fix. These branches are called PARALLEL MAINTENANCE and
EMERGENCY FIX respectively.
An additional branch called ENTERPRISE SEED is used to store the seeded elements (that were
placed in a application container through the seeding process). These seeded elements originate from
an Enterprise model.
To verify what elements have branched versions, use the Version Æ Edit branch labels… window.
Select the desired branch and click Used by. All elements using the branch will be shown ordered by
their owning container, as shown in the two figures below.




Oracle Designer SCM Guide
Thu, Aug 10, 2006                                  Version 1.14                                Page: 13
Ministry of Community Services




5.1.2 Automatic version labeling
When selected, each new object version is automatically assigned a version label on check-in.
Automatically calculated version labels follow this convention:
   1. For versions on the MAIN branch, labels are in the format 1., where  is a number
      starting in 0 and incremented by 1 at every check-in.
   2. For versions on a branch, labels are in the format .1., where
      .is the version label of the element that provides the source for
      the new branch, and  is a number starting in 0 and incremented at every check-in

5.1.3 Strict locking
When selected, ensures that only one version can be in check-out state per branch.

5.2 Names of files and folders

5.2.1 Case sensitive uniqueness checking
When selected, activates case sensitivity checking for the names of new file system files and their
containers when these are created in the repository. (Note that there are issues with the enforcement of
this policy. The repository appears to be case-sensitive regardless of the setting of the policy.)

5.3 Dependencies
The following options control the default setting for what happens to dependencies for certain
operations on repository objects. In either case the default can be overridden at the time of the

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                     Version 1.14                                  Page: 14
Ministry of Community Services

operation. Dependencies, in this context, refer to calculated element dependencies available in the
dependency Manager tool. These are impact analysis dependencies (as opposed to metadata
associations such as entity relationships etc).

5.3.1 Copy on versioning
When selected, causes object dependencies to be copied by default when a new version of an object is
created.

5.3.2 Copy on copying
When selected, causes object dependencies to be copied by default when an object is copied.


6 Security
Security in the Designer 10g Repository is controlled at multiple levels. A user must have the
appropriate permissions at each of the levels before they are able to use an element in the repository.
For example, user “Steve Smith” has an Oracle userid, has been granted permission to use the
repository and has the “Select” permission on the LGIS application container. However he does not
have any permissions on any of the workareas so is unable to view or interact with the LGIS
application. When he is granted, at the very least, “Select” on a workarea of which LGIS is a part, he
will be able to interact with the application.

6.1 Database
Each user that accesses the repository must have an Oracle userid with the connect privilege. There are
currently two distinct classes of users that will use the repository. These classes and the naming
convention for each are as follows:
   1. Repository owner (which also defaults to application owner for all containers)

   2. Named users (anyone who needs read or write access to the repository)
      CASE_
      e.g. CASE_SSMITH

6.2 Repository
The repository manager must grant all users permission to use the repository. This is done using the
Repository Administration Utility. In order for the repository manager to grant these permissions, the
Oracle userid must already exist.
In order to grant permissions on the repository to the user perform the following steps:
   1. Connect to target repository using the Repository Administration Utility
   2. Click the Maintain Users button
   3. Select “Users”

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                 Page: 15
Ministry of Community Services

        4. Click the green plus (+) button to add a new user.
        5. Select the Oracle userid from the drop list labeled “Oracle User Name”
6.          Set the permissions as shown in the following screen shot for regular users




        7. Set the permissions as shown in the following screen for those users who are filling the role of
           the application configuration manager. This role is responsible for assembling and testing the
           application release content before delivery to the repository manager for actual release creation.




     Oracle Designer SCM Guide
     Thu, Aug 10, 2006                                   Version 1.14                                 Page: 16
Ministry of Community Services




   8. Click OK

6.3 Roles
There is one available role in the repository called PUBLIC. Unfortunately, this role is hard-coded in
Designer and can’t be altered. As well additional roles cannot be added. However, this role is great for
granting permissions to ALL users. The permissions on the different work areas are granted using the
PUBLIC role.
In order to grant permissions to public on an object, use the steps in Section 6.4and 6.5

6.4 Workareas
The next level of access control is the workarea. In order for a user to see or manipulate the objects that
are part of a work area they need to have permissions to do so. All users, except for application owners
and the repository manager, get permissions for workareas in the Ministry repository from the PUBLIC

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                     Version 1.14                                 Page: 17
Ministry of Community Services

role and do not need to be changed for an individual user. The following table outlines the permissions
granted on work areas:
       Workarea name               Application         REPOSITORY                     Public Role
                                  Configuration         MANAGER
                                    Manager
 WA_DEVELOPMENT                                      ALL                    Select, Insert, Update, Delete,
                                                                            Version
 WA_DELIVERY_                Update Spec,       ALL                    Select
                                  Compile
 WA_DELIVERY__STAGE          Update Spec,       ALL                    Select
                                  Compile
 WA_TEST_QA                                          ALL                    Select
 WA_PRODUCTION                                       ALL                    Select
 WA_PARALLEL_MAINTENANC                              ALL                    Select, Update, Version
 E                                                                          Note: access to this workarea is
                                                                            enabled on request, and disabled
                                                                            after parallel maintenance
                                                                            changes have been merged back
                                                                            into the MAIN branch.
 WA_EMERGENCY_FIX                                    ALL                    Select, Insert, Update, Delete,
                                                                            Version
 WA_ARCHIVE                                          ALL                    Select
 WA_ON_HOLD                                          ALL                    Select
 WA_GENERAL_RM_TASKS                                 ALL
 WA_ENTERPRISE_SEEDING                               ALL
 WA_BLOCK_SEEDED_CHECKO                              ALL
 UTS

6.5 Containers
The next level of access control is the container. Each user must have permissions on the container
before they can perform actions on that container.
In order to grant permissions to users for a container perform the following steps:
   1. Connect to the repository using the Repository Object Navigator as the REPOSITORY
      MANAGER.
   2. Open the Repository object. (You will need to go up a level to be able to select “Repository”)
   3. Navigate to the container
   4. Right click on any container and select “Grant Access Rights”
   5. Click the name of the user in the “Users” column




Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                     Page: 18
Ministry of Community Services

   6. Check the needed options in the “To Grant” column.
      Note: Do not grant “Update Spec”, “Compile” or “Administrate” even if they are available
      Note: Generic users should get SELECT access ONLY.
   7. Check the “Recurse Sub-Containers” option
   8. Click the “Grant” button”
   9. Click “OK”

6.6 Configurations
The final level of access control is the configuration. Configurations that represent application releases
must be made visible in read-only mode to application configuration managers (who require them for
context during delivery workarea setup).
In order to grant permission on the configuration perform the following steps:
   1. Connect to the repository using the Repository Object Navigator as the REPOSITORY
      MANAGER
   2. Open the Repository object. (You will need to go up a level to be able to select “Repository”)
   3. Expand the Configurations node.
   4. Select the configuration you want to grant access to and expand it. You should see the versions
      that have currently been created for that configuration.
   5. Select any version. Right-click and select “Grant Access Rights”.
   6. Proceed as usual to grant “Select” only to the designated application configuration manager
      account.


7 Seeding of applications with Enterprise standards

7.1 What gets seeded
The Ministry maintains a set of standard domain definitions for the most commonly used data types.
This set of domains (or a subset of it) provides a starting point for data modelers during system analysis
and design.
When new application development projects start, the repository manager and data administrators will
establish the set of domains that provides a good starting point to the application. This set of domains is
then seeded into the application container.
IMPORTANT NOTE: Seeded elements are not meant to be altered in the application system.
Application delivery will fail quality assurance and will not be promoted to production if changes
are detected in seeded elements.




Oracle Designer SCM Guide
Thu, Aug 10, 2006                                     Version 1.14                                 Page: 19
Ministry of Community Services

Seeding affects the element’s version tree as shown in the figure below. The seed element provides
version 1.0 on the MAIN branch, and also version 1.0.1.0 on the ENTERPRISE SEED branch. This
branch provides a frozen view of what was originally seeded.




Seeded elements are delivered to the application in checked-in state.

7.2 Seeding workarea
The workareas used during the seeding process are:


              Workarea name                                             Description
 WA_ENTERPRISE_SEEDING                          Volatile contents.
                                                This workarea is populated with the Enterprise
                                                configuration and is used to create and seed the new
                                                application container.
                                                The default check-in branch for this workarea is
                                                ENTERPRISE SEED.
 WA_BLOCK_SEEDED_CHECKOUTS                      This workarea contains configurations containing the
                                                seeded elements on the MAIN branch, for all seeded
                                                containers. It is used to perform a “dummy” check-
                                                out of the seeded elements in order to prevent check-
                                                out by a developer.

7.3 The seeding process
NOTE: An application undergoing seeding should not be changed by developers during the
seeding process. If changes are made by a developer, they may be lost in the event of a rollback of
the container to a pre-seeded state.

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                  Page: 20
Ministry of Community Services

To seed an application container, follow the steps in the appropriate scenario below:

7.3.1 Seeding an empty container
In this scenario, a new application development project is starting, and you want to seed the application
container with a “starter set” of domains from the Enterprise standards.
   1. Go to the WA_ENTERPRISE_SEEDING workarea. Ensure that the workarea contains the
      LATEST(Enterprise Seed) rule followed by the configuration representing the latest version of
      the “Enterprise domain standards” container. The workarea rules should contain the
      INCLUDE_CONFIG rule for this configuration.




   2. Take note of the configuration name and version as you will need it later in this process.
   3. Create the new container
   4. Follow the instructions in the ‘Copying seed domains’ section later in this document.
   5. Select the application container and all domains and perform a check-in.
           a. In the check-in notes, specify the configuration (and its version) that you used to create
              the elements. For example, your notes could say ‘Seeded from configuration
              ‘ENTERPRISE DOMAINS release 1.00.00’ version 1.0’.
           b. Notice that the result of this check-in is a version tree with version 1.0 on MAIN and
              1.0.1.0 on ENTERPRISE SEED. These two versions are identical. Also note that the
              folder itself is also versioned in the ENTEPRISE SEED branch. The branched folder



Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                  Page: 21
Ministry of Community Services

               version will indicate the seed additions over time whereas the folder version on MAIN
               will indicate the application element additions.
   6. Create a baseline configuration representing the contents of the application after seeding.
           a. Name the configuration ‘ seed baseline on MAIN’
           b. Use the INCLUDE_FOLDER rule with the new application as the folder, on MAIN.
              NOTE: you have to go to the ‘All Containers’ node to select the container version on
              MAIN.




           c. Check-in the configuration
   7. Create another configuration representing the contents of the application on the Enterprise Seed
      branch.
           a. Name the configuration ‘ seeded elements on Enterprise Seed’.
           b. Use the LATEST_CONFIG_CONTENTS rule, with the configuration created in the
              previous step, and the Enterprise seed branch.




Oracle Designer SCM Guide
Thu, Aug 10, 2006                                   Version 1.14                                    Page: 22
Ministry of Community Services




   8. In the WA_BLOCK_SEEDED_CHECKOUTS workarea, edit the workarea to include the
      ‘ seed baseline on MAIN’ configuration.
   9. Check-out all the elements you’ve just seeded (but don’t check-out the container). This is a
      “dummy” check-out that will prevent unwanted check-outs of seeded elements by application
      developers.
           a. In the check-out notes add “Temporary check-out to prevent further check-out of this
              version by developers. Check-out will be un-done if this seed version is superseded by a
              revised version or if the Repository Manager deems necessary for another reason.”
   10. Refresh the development workarea to include the new application version.

7.3.2 Seeding an existing container for the first time
In this scenario, the application already exists, and you want to add standard domains to the application
container. The application has never been seeded.
   1. Ensure that none of the domains you are seeding already exist in the target container. This is a
      visual check using the RON and version history viewer.
           a. If matching domains exist (they were created by the development team):
                   i. if you want to overwrite these with enterprise domains, the application domains
                      should be renamed first. Then you may proceed with the seeding process. After
                      seeding, the development team may re-direct the usages of the old domain to the
                      new one.


Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                 Page: 23
Ministry of Community Services

                  ii. If by comparing the domains (using the compare tool) with the corresponding
                      domain in the Enterprise container you determine that they are identical and you
                      want to “make them a seed domain”:
                            1. Carry out steps 2 through 4 to populate the seeding workarea,
                            2. check-out the domains you want to set as seeded.
           b. If no matching domains exist: proceed with the seeding process.
   2. Ensure that the entire container and contents are checked-in in WA_DEVELOPMENT.
   3. Create a savepoint configuration with the entire container contents (using INCLUDE_FOLDER
      rule), as a rollback position .
   4. Edit the WA_ENTEPRISE_SEEDING workarea:
           a. Ensure that the WA_ENTERPRISE_SEEDING workarea contains the configuration
              representing the latest version of the “Enterprise domain standards” container. The
              workarea rules should contain the INCLUDE_CONFIG rule for this configuration.
           b. Take note of the configuration name and version as you will need it later in this process.
           c. Use the INCLUDE_FOLDER rule to include the target container in the workarea.
   5. Check-out the target container.
   6. Follow steps in the ‘Copying seed domains’ section later in this document.
   7. Select the application container and all domains you’ve created or checked-out and perform a
      check-in.
           a. In the check-in notes, specify the configuration (and its version) that you used to create
              the elements. For example, your notes could say ‘Seeded from configuration
              ‘ENTERPRISE DOMAINS release 1.00.00’ version 1.0’.
           b. Notice that the result of this check-in is a version tree with version X.Y on MAIN and
              X.Y.1.0 on ENTERPRISE SEED for all domains that existed in the application and
              became part of the seeded set. These two versions are identical. Also note that the folder
              itself is also versioned in the ENTEPRISE SEED branch. The branched folder version
              will indicate the seed additions over time whereas the folder version on MAIN will
              indicate the application element additions.
   8. Create a configuration representing the contents of the application after seeding, on enterprise
      seed.
           a. Name the configuration ‘ seeded elements on Enterprise Seed’
           b. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on branch
              Enterprise seed.
           c. Check-in the configuration




Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                 Page: 24
Ministry of Community Services

   9. Use the merge tool to bring in the new domains to the container version on MAIN. Follow the
      container merge instructions in this document using the MAIN branch as the target version and
      the ENTEPRISE SEED branch as the source version.
   10. Create a configuration representing the contents of the application after seeding, on the MAIN
       branch. Name it ‘ seed baseline on MAIN’.
           a. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on MAIN.
                   i. NOTE: you have to go to the ‘All Containers’ node to select the container
                      version on MAIN.
           b. Check-in the configuration.
   11. In the WA_BLOCK_SEEDED_CHECKOUTS workarea, edit the workarea to include the
       ‘ seed baseline on MAIN’ configuration created in the previous step.
   12. Check-out all the elements you’ve just seeded (but don’t check-out the container). This is a
       “dummy” check-out that will prevent unwanted check-outs of seeded elements by application
       developers.
           a. In the check-out notes add “Temporary check-out to prevent further check-out of this
              version by developers. Check-out will be un-done if this seed version is superseded by a
              revised version or if the Repository Manager deems necessary for another reason.”
   13. Refresh the development workarea to include the new application version.

7.3.3 Adding new seed domains to a previously seeded container
In this scenario, the application has already undergone seeding, but you want to bring in additional seed
domains.
There is no “domain collision” in this scenario. The new seed domains have no matching domains in
the application container (addressed in scenarios 7.3.2 and 7.3.4).
   1. Ensure that the entire application container and contents are checked-in in the
      WA_DEVELOPMENT workarea.
   2. Create a savepoint configuration with the entire contents of the application to be seeded, on the
      MAIN branch.
           a. Use the INCLUDE_FOLDER rule and select the latest container version on MAIN.
   3. Edit the WA_ENTEPRISE_SEEDING workarea:
           a. Ensure that the WA_ENTERPRISE_SEEDING workarea contains the configuration
              representing the latest version of the “Enterprise domain standards” container. The
              workarea rules should contain the INCLUDE_CONFIG rule for this configuration.
           b. Take note of the configuration name and version as you will need it later in this process.
           c. Use the INCLUDE_CONFIG rule to include the configuration created in the latest
              seeding of the container. This configuration is the one with container version and
              previously seeded domains on branch (as opposed to the baselines on MAIN).

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                Page: 25
Ministry of Community Services




   4. Check out the target container
   5. Follow steps in the ‘Copying seed domains’ section later in this document.
   6. Select the application container and all domains you’ve created and perform a check-in.
           a. In the check-in notes, specify the configuration (and its version) that you used to create
              the elements. For example, your notes could say ‘Seeded from configuration
              ‘ENTERPRISE DOMAINS release 1.00.00’ version 1.0’.
           b. Notice that the result of this check-in is a version tree with version 1.0 on MAIN and
              1.0.1.0 on ENTERPRISE SEED. These two versions are identical. Also note that the
              folder itself is also versioned in the ENTEPRISE SEED branch. The branched folder
              version will indicate the seed additions over time whereas the folder version on MAIN
              will indicate the application element additions.
   7. Update the configuration representing the contents of the application after seeding.
           a. Check-out the latest version of the ‘ seeded elements on Enterprise
              seed’




Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                 Page: 26
Ministry of Community Services




           b. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on branch
              Enterprise seed.
                   i. NOTE: you have to go to the ‘All Containers’ node to select the container
                      version on MAIN.
           c. Check-in the configuration
   8. Use the merge tool to bring in the new domains to the container version on MAIN. Follow the
      container merge instructions in this document using the MAIN branch as the target version and
      the ENTEPRISE SEED branch as the source version.
   9. Create a configuration representing the contents of the application after seeding, on the MAIN
      branch. Name it ‘ seed baseline on MAIN’.
           a. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on MAIN.
                   i. NOTE: you have to go to the ‘All Containers’ node to select the container
                      version on MAIN.
           b. Check-in the configuration.
   10. In the WA_BLOCK_SEEDED_CHECKOUTS, un-do the check-outs of all elements check-
       out for the seeded container. Workarea.
   11. Edit the workarea to include the ‘ seed baseline on MAIN’ configuration
       created earlier.



Oracle Designer SCM Guide
Thu, Aug 10, 2006                                  Version 1.14                               Page: 27
Ministry of Community Services

   12. Check-out all seeded elements (this includes the ones you’ve just seeded and any other seeds
       from previous seedings) (but don’t check-out the container). This is a “dummy” check-out that
       will prevent unwanted check-outs of seeded elements by application developers.
           a. In the check-out notes add “Temporary check-out to prevent further check-out of this
              version by developers. Check-out will be un-done if this seed version is superseded by a
              revised version or if the Repository Manager deems necessary for another reason.”
   13. Refresh the development workarea to include the new application version.

7.3.4 Upgrading previously seeded domains
In this scenario, the data administration group has revised some of the enterprise domains and wishes
to propagate the revisions to the applications that have been seeded with the domains.
   1. Ensure that the entire application container and contents are checked-in in the
      WA_DEVELOPMENT workarea.
   2. Create a savepoint configuration with the entire contents of the application to be seeded, on the
      MAIN branch.
           a. Use the INCLUDE_FOLDER rule and select the latest container version on MAIN.
   3. Edit the WA_ENTEPRISE_SEEDING workarea:
           a. Ensure that the WA_ENTERPRISE_SEEDING workarea contains the configuration
              representing the latest version of the “Enterprise domain standards” container. The
              workarea rules should contain the INCLUDE_CONFIG rule for this configuration.
           b. Take note of the configuration name and version as you will need it later in this process.
           c. Use the INCLUDE_CONFIG rule to include the configuration created in the latest
              seeding of the container. This configuration is the one with container version and
              previously seeded domains on the Enterprise seed branch (as opposed to the baselines
              on MAIN).
   4. Check-out each domain you want to update.
   5. Manually edit each domain you want to update.
   6. Check-in all edited domains
           a. In the check-in notes, specify the configuration (and its version) that you used to create
              the new versions. For example, your notes could say ‘Re-Seeded from configuration
              ‘ENTERPRISE DOMAINS release 1.01.00’ version 1.0’.
           b. Notice that the result of this check-in is a version tree with an updated branch version
              X.Y.1.Z on ENTERPRISE SEED.
   7. Update the configuration representing the contents of the application after seeding.
           a. Check-out the latest version of the ‘ seeded elements on Enterprise
              seed’


Oracle Designer SCM Guide
Thu, Aug 10, 2006                                    Version 1.14                                 Page: 28
Ministry of Community Services




           b. Use the ‘Refresh all existing members with their latest versions’ option. The new
              versions on Enterprise seed branch will be picked up.




           c. Check-in the configuration

Oracle Designer SCM Guide
Thu, Aug 10, 2006                                  Version 1.14                                   Page: 29
Ministry of Community Services



   8. Use the merge tool to bring in the domain changes to the domain version on MAIN. Follow the
      element merge instructions in this document using the MAIN branch as the target version and
      the ENTEPRISE SEED branch as the source version.
           a. Note that this merge can be done by the developer. Developers know best what the
              application needs. For example, for a domain with allowable values, a given application
              may not want all allowable values specified at the enterprise level.
   9. Create a configuration representing the contents of the application after seeding, on the MAIN
      branch. Name it ‘ seed baseline on MAIN’.
           a. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on MAIN.
                   i. NOTE: you have to go to the ‘All Containers’ node to select the container
                      version on MAIN.
           b. Check-in the configuration.
   10. In the WA_BLOCK_SEEDED_CHECKOUTS, un-do the check-outs of all elements check-
       out for the seeded container. Workarea.
   11. Edit the workarea to include the ‘ seed baseline on MAIN’ configuration
       created earlier.
   12. Check-out all seeded elements (this includes the ones you’ve just seeded and any other seeds
       from previous seedings) (but don’t check-out the container). This is a “dummy” check-out that
       will prevent unwanted check-outs of seeded elements by application developers.
           a. In the check-out notes add “Temporary check-out to prevent further check-out of this
              version by developers. Check-out will be un-done if this seed version is superseded by a
              revised version or if the Repository Manager deems necessary for another reason.”
   13. Refresh the development workarea to include the new domain versions.

7.3.5 Copying seed domains
   1. In the Enterprise container, select all the domains you want to use for seeding.
   2. Select Utilities Æ Extended Copy
   3. The follow pop up may appear. (This is faulty behaviour from Designer and may be fixed in
      future releases. Designer assumes that the source container will become the target container.
      Since the source container is checked-in, it asks if you want to check it out.)




Oracle Designer SCM Guide
Thu, Aug 10, 2006                                   Version 1.14                               Page: 30
You can also read
Next part ... Cancel