Oracle Designer SCM Guide

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 .

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 .

Oracle Designer SCM Guide

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 4 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 upgrade from Oracle Designer 6i to 10g.

2006-FEB-03 Rob Gretchen / 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 5 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 Configuration Manager) Section 8.4, 8.5 ( Sections 2-6 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
  • Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 6 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
  • Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 7 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 8 MAIN EMERGENCY FIX 1.0 1.1 1.0.3.1 1.0.3.2 PARALLEL MAINTENANCE 1.0.2.2 MAIN 1.0 1.1 1.1.1.0 1.1.1.1 1.2.1.0 1.1 1.2 1.1 1.3 merge MAIN EMERGENCY FIX 1.0 1.1 1.0.3.1 1.0.3.2 PARALLEL MAINTENANCE 1.0.2.2 MAIN 1.0 1.1 1.1.1.0 1.1.1.1 1.2.1.0 1.1 1.2 1.1 1.3 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 9 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 10 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 file Select the file. Then select "Download Files and Folders" (either from the 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.

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 11 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
  • Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 12 ƒ 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)

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 13 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.

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 14 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 15 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”

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 16 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.

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 17 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 18 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 Configuration Manager REPOSITORY MANAGER Public Role WA_DEVELOPMENT ALL Select, Insert, Update, Delete, Version WA_DELIVERY_ Update Spec, Compile ALL Select WA_DELIVERY__STAGE Update Spec, Compile ALL Select WA_TEST_QA ALL Select WA_PRODUCTION ALL Select WA_PARALLEL_MAINTENANC E ALL Select, Update, Version 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 UTS ALL 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 19 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.

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 20 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” checkout of the seeded elements in order to prevent checkout 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.

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 21 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 22 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.

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 23 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.

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 24 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 25 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).

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 26 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’

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 27 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 checkout for the seeded container. Workarea. 11. Edit the workarea to include the ‘ seed baseline on MAIN’ configuration created earlier.

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 28 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’

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 29 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

Ministry of Community Services Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 30 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 checkout 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.)