; ODTUG – Unchained Migrations
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

ODTUG – Unchained Migrations

VIEWS: 35 PAGES: 12

  • pg 1
									UNCHAINED MIGRATION TO DESIGNER 9I: STEP BY
STEP, REPEATEDLY AND BI-DIRECTIONAL
Lucas Jellema, AMIS Services BV
Migration from Designer 6.0 (or 2.1) to Designer 6i or 9i can be thought of to consist of several dimensions. Getting your
developers acquainted with Designer 9i, new concepts such as Versions, Workareas and Configurations and the new
functionality for generating Forms, Server DDL and Web PL/SQL Modules certainly defines one dimension. Designer 9i – or
rather the underlying Oracle Software Configuration Manager – suggests, no almost demands the introduction of a proper
Software Configuration Management process. A third dimension is definitely made up of the actual migration of the existing
Designer 1.3.2/2.1 or 6.0 Repository. This paper focuses on this third dimension.
Note: Designer 9i and Designer 6i are equivalent on the Server (Repository) side. Any reference in this paper to Designer 9i
also applies to Designer 6i. By the way – the main and really the only reason for continuing to use Designer 6i is the fact that
Designer 6i generates for Forms 6i which can be deployed as Client/Server as well as WebForms, whereas Designer 9i
generates Forms 9i which can only be deployed as WebForms.

What happens during migration?
The server side migration process will populate the Designer 9i Repository with data taken from an existing Designer 2.1.2 or
6.0 Repository. In the past (1.3.2 to 2.1.x and 2.1.x to 6.0), migrations of Oracle Designer typically entailed an in-situ
transformation of the existing repository into the new one. After migration was completed, the original lower-version-
repository did not exist anymore, it had been turned into the new-release-repository. That of course meant all of the
repository has to be migrated at once. With Designer 9i, the migration is different. The source Repository will continue to
exist after the migration and it will be separate from the target Repository, the one implementing the Designer 9i
environment. It is possible to migrate only part of the source 6.0 repository. It is also possible to migrate several 6.0
Repositories into a single 9i Repository.
The migration itself does not just copy data. It also caters for the changes in the meta-model by adding/modifying/filtering
out attributes and even by creating new Designer 9i elements such as Lists of Values from existing 6.0 (Module) definitions.




                                  Figure 1. Situation just prior to starting the migration

Detailed Migration steps
   1. Create a database link from the 9i Repository Owner’s schema to the 6.0 Repository Owner.
   2. Cleanse source repository: remove invalid data and corruptions from the 6.0 Repository




www.odtug.com                                                                                                    ODTUG 2003
Unchained Migrations to Designer 9i                                                                                   Jellema




   3.    Populate several upgrade tables to support the creation of new 9i elements that not directly correspond to 6.0
        Repository Objects, such as List of Values and Navigation Items

   4.    Populate the JR_ID_MAPS table with one record for every 6.0 Repository Object to be migrated as well as every




        row in the upgrade tables introduced in step three. In every record in JR_ID_MAPS, include the “old” Designer 6.0
        ID and the new 9i IRID en IVID.
   5.    Load data into the 9i Repository tables (I$_SDD_OBJECT_VERSIONS, I$SDD_ENT, I$SDD_TAB etc.) from
        both the 6.0 Repository tables (SDD_ELEMENTS, SDD_STRUCTURE_ELEMENTS), the upgrade tables and the




        JR_ID_MAPS table. The latter table is not only used for values in IRID and IVID columns of the 9i Repository table
        but also the (IRID) value in all referencing columns.


Limitations in the standard migration functionality in the Designer product
Here we list a number of shortcomings and limitations of the migration facility as it is shipped with Oracle 9i Designer.
        You cannot migrate into a workarea of your choice. In a Versioned Repository, you have to migrate into a brand
         new workarea that is created by the migration process.



www.odtug.com                                                                                                   ODTUG 2003
Unchained Migrations to Designer 9i                                                                                    Jellema


        You cannot migrate the same source application system twice or at least when you do so, you get two application
         systems in your Designer 9i environment that are totally unrelated. It is not possible to continue work on an
         application system in Designer 6.0 after it has been migrated to Designer 9i and then migrate it again, hoping to
         somehow update the migration result of the first migration.
        There is no way in which the migration facility makes use of the fact that a source application system has been
         defined as the new version of another application system (in Designer 6.0 you can have multiple versions of an
         application system; the migration utility does not recognize that fact).
          Application systems can only be migrated at the same time as all application systems that contain elements on which
           they have a dependency. If Application System X has references to elements owned by Application System Y then
           Y is automatically migrated along with X, even if Y had been migrated before. The migration tool does not link the
           previously migrated Y with the currently migrated X; instead it migrates Y again.
These limitations basically make it very difficult for organizations to do anything else than migrate all application systems at
the same time. However, this can be a very poor strategy for several reasons. The total number of application systems and
therefore the sheer size of the migration can become very big. This makes it more difficult to manage, requires a lot of system
resources to succeed and will take a very long time to run. Besides, it is quite rare to find a timeframe for the migration that
suits all project teams. It would be much more convenient to tackle one or several teams and applications at a time, rather
than the whole enterprise at once. Furthermore, it forces any external parties working in their local repositories on sections of
the to-be-migrated repository to also upgrade to Designer 9i (in fact, they would have to merge all their work into the central
6.0 Repository, set up an empty Designer 9i Repository and wait for the migration result to be sent their way before
continuing work).
In order to make your life a lot simpler, we are going to stretch the limitations Designer has set on the migration process. We
will do so by ever so slightly amending the scripts used by Designer for performing a migration. Strictly speaking, we enter a
shady area with regards to Oracle product support. Therefore, it is adamant that you test your migration in an environment
that you can afford to mess up. However, all migrations described in this paper were tested and have proven themselves.

Choose your own workarea
A very simple first step overcomes the requirement to migrate into a new workarea. If you do not intend to check in the
results of the migration and you want to group several (migrated) application systems in a certain workarea, you have to
make two small changes to a simple script. Without those changes, every migration will create a new workarea. Elements not
checked in could never be moved to a different workarea and clustering application systems into workareas is severely
hampered.




            Figure 2. Error displayed when you provide a target workarea name that already exists


www.odtug.com                                                                                                    ODTUG 2003
Unchained Migrations to Designer 9i                                                                                     Jellema


The internal, unnecessary cause for the limitation is the following: the first thing done by the RAU Migration Utility after
you have typed in the name of the designated workarea is check whether a workarea with that name already exists. (note that
this check is case sensitive). Strangely enough, even though all other migration code is prepared for dealing with an existing
workarea, in the RAU it turns out that if the workarea already exists, the user entry is rejected. That means that at this stage
we cannot enter an existing workarea name.
The workaround for this limitation is the following: Ensure that the name of the intended target workarea contains at least
one uppercase character. If we type in the name of an existing workarea in lower case only (while the actual name of the
workarea contains at least one upper case character) this initial check in the RAU will not recognize the fact that the workarea
already exists. By making some minute changes in the ckwkarea.sql script, help the script to recognize the right workarea and
to ensure that the migration is really being done into the intended workarea.
The first change involves adding the function lower() to the where clause in the following statement:
           select irid
           into wkarea_irid
           from i$sdd_workareas
           where lower(name) = wkarea_name;
Here wkarea_name is the workarea name entered by the user in the RAU Migration Wizard.
The second change at the end of the script is to set the name of the workarea to the (lowercase) name as it was typed in by the
user to allow the RAU Migration utility to recognize this workarea later on – this means that after the migration the workarea
will have an all lower-case name.:

         jr_workarea.rename_workarea(workarea_id => wkarea_irid, new_name => wkarea_name);




Migrate in stages
When you select an application system to migrate, Designer 9i forces you to migrate all application systems that “hang
together”. This means: if your application system A has references to elements owned by application system B – i.e. A has
shared objects from B – the migration tool will automatically select B for migration along with A. Of course if B has
references to C, then C is also included automatically in the set to migrate. However, if you already migrated B and C in a
previous migration run, you still have to migrate them again. The migration tool does not recognize the fact that your target
Designer 9i Repository already contains migrated application systems B and C that you in this current migration run want to
hook into.
Luckily, this limitation is quite unnecessary and relatively easy to overcome. In order to see why that is so, you need to
understand just a little bit of what goes on during the migration.
After the source repository has been cleansed of corruptions, the migration proceeds with a few scripts that populate the
JR_ID_MAPS table. This table contains entries for every element in the source repository (every record in the tables
SDD_ELEMENTS, SDD_STRUCTURE_ELEMENTS, CK_APPLICATION_LOGIC, SDD_DIAGRAM_SEGMENTS)
that is a member of one of the application systems in the migration set. JR_ID_MAPS contains the old id for each of these
elements (the primary key value in the Designer 6.0 Repository) as well as new id values (irid and ivid) that are generated at
this point. When this step is complete, JR_ID_MAPS completely describes using the current (old) as well as the future (new)
identification for all elements that will be migrated.
The actual migration is done per element type. Basically a migration consists of an insert into the target repository of a select
from the source repository of all instances of a certain element type that are owned by one of the application systems in the
migration set. The target IRID and IVID are retrieved from JR_ID_MAPS. The same is done for all columns that contain
references to other repository elements: the source column contains a value that corresponds with an old id (in the source
repository). From JR_ID_MAPS, the utility retrieves the corresponding IRID value in the target repository, and sets the
column value in the target Designer 9i Repository to that IRID value.
In pseudo-code a typical migration statement looks like this:
   insert into i$sdd_att
   ( irid, ivid, name, entity_ref, domain_ref,….)
   select get_irid(id,0)
   ,         get_ivid(id,0)
   ,         name



www.odtug.com                                                                                                     ODTUG 2003
Unchained Migrations to Designer 9i                                                                                     Jellema


   ,         get_unique_id( entity_reference)
   ,         get_unique_id( domain_reference)
   from ci_attributes@r212
   where application_system_owned_by in ( select id from upg_app)


The functions get_irid, get_ivid and get_unique_id all access the table JR_ID_MAPS.
The key to hooking into previously migrated application systems is in this JR_ID_MAPS table. If we make sure that this
table, just prior to the second stage in the migration where the actual inserts into the Designer 9i Repository take place, does
not contain freshly generated IRID values but instead the IRID values assigned during the previous migration, then after the
second stage the newly migrated elements have references to the previously migrated elements. Of course we must also make
sure that in the second stage the previously migrated elements are not migrated again.
We have to go through the following steps to make it work as planned:
        Back up the contents of the JR_ID_MAPS table after each migration for future reference. The JR_ID_MAPS
         archive we build up holds a full record of how elements in the source Designer 6.0 Repository (-ies) map to
         elements in the Designer 9i Repositoy.

         We create two tables: MIGRATED_APPS that holds a single record for every application system in the source
         repository that is migrated and ID_MAP_ARCH that is populated with all rows in JR_ID_MAPS. The script
         ckmigtyp.sql (in ORAHOME\repadm61\cnv) is slightly changed: after the JR_ID_MAPS table is completely
         populated, its contents is archived into the two tables we created. At this point, every migration will have its ID-
         mappings between source and target repository archived in the MIGRATED_APPS en ID_MAP_ARCH tables.

        At the start of a migration, indicate which previously migrated application systems should be reused – or: can be
         hooked into. The table MIGRATED_APPS contains a column called REUSE (varchar2(1)); this column should
         contain either of the values Y or N. Any application system in MIGRATED_APPS that has the column REUSE set
         to Y will be hooked into instead of being migrated again. Note: setting REUSE to Y has no effect for application
         systems are not in the migration set.

        Modify the migration scripts to not migrate elements in the REUSED application systems. Elements in Application
         Systems that are to be reused should not be migrated in this migration run. The script ckmigtyp.sql is extended with
         this statement that removes from the temporary tables upg_app the application systems that are in the migration set
         but should not be migrated because they are reused:


         delete upg_app ua
         where exists
                  ( select     'x'
                    from       migrated_apps ma
                    where      ua.id = ma.app_id
                    and        ma.reuse = 'Y'
            )
            ;

         The script ckfolmem.sql is also modified, to not create Folder Members for the elements that are not migrated again
         but instead reused. The statement
         and    owning_app_id in ( SELECT ID FROM UPG_APP)

         is added to the where-clause in the insert-statement this script. A number of such statements are added to the
         statements in the script ckmigdat.sql, again to ensure that reused elements are not migrated again.
        Modify the migration scripts to update JR_ID_MAPS for all reused elements with the IRID assigned in previous
         migration runs. In the second stage of the migration, the migration tool will derive the values in all referencing
         columns (columns that implement referencing properties such as Foreign Table Reference in Foreign Key
         Constrains or Domain Reference in Attributes) from the JR_ID_MAPS table. It will check the value for the
         referencing column in the source (6.0) repository and retrieve from JR_ID_MAPS the IRID value that was assigned




www.odtug.com                                                                                                     ODTUG 2003
Unchained Migrations to Designer 9i                                                                                  Jellema


        to that 6.0 Repository Id. In the ckmigtyp.sql script, a single update statement is included to update the IRID column
        with the IRID value held in the ID_MAP_ARCH table from previous migrations.
        update jr_id_maps idm
        set    (irid, ivid) =
                 ( select irid
                   ,      ivid
                   from   ID_MAP_ARCH idma
                   ,      migrated_apps ma
                   where idma.old_id = idm.old_id
                   and    idma.owning_app_id = idm.owning_app_id
                   and    idma.owning_app_id = ma.app_id
                   and    idma.migration_run_id = ma.migration_run_id
                   and    ma.reuse           = 'Y'
                 )
              where exists
                 ( select 'x'
                   from   migrated_apps ma
                   where idm.owning_app_id = ma.app_id
                   and    ma.reuse = 'Y'
                  )




                            Figure 3. Override the newly derived irid-values for elements in C with
                                      previously derived values kept in ID_MAP_ARCH
       Run the Migration. With all scripts adopted to the staged migration approach all we need to do is set the proper
        records in MIGRATED_APPS to REUSE=’Y’ and proceed normally with the migration. When the migration is
        done, we will find the following:
            New records have been added to MIGRATED_APPS and ID_MAP_ARCHS
            The application systems in the migration set have been migrated insofar they were not listed in
             MIGRATED_APPS to be reused. Their references to elements in application systems that were to be reused are
             now to previously migrated application systems that already existed in the Designer 9i Repository.


TWO VERY IMPORTANT WARNINGS
If you have added elements to the Designer 6.0 Repository after the previous migration of the reused application systems,
those new elements are not in the Designer 9i Repository after the migration, since no elements in the reused application
systems are migrated. If you want to reuse the application system but also migrate the new elements, the workaround would
be to create a temporary application system in the Designer 6.0 Repository, transfer the new elements to this application
system that will automatically be included in the migration set, transfer them back after the migration is complete and also
transfer them in the Designer 9i environment to the counterpart of the application system. If you do not migrate these new
elements, and references exist to those elements from the migrated application systems, than the migrated elements will have
invalid references. This will also happen if you have deleted elements from the Designer 9i Repository.



www.odtug.com                                                                                                  ODTUG 2003
Unchained Migrations to Designer 9i                                                                                    Jellema


There is one serious danger as a result of updating the JR_ID_MAPS table: if the migration for whatever reason (e.g.
database outage, tablespace limits reached, Client shutdown) is aborted, a incomplete result is left in the target Repository. To
clean up this mess, the repository proposes to Purge Previous Abort. This is a good thing to do. However: if you have reused
application systems, there is a step you must take before proceeding with the Purge. The Purge will assume that all objects in
JR_ID_MAPS are the product of the aborted migration run. It therefore intends to remove all objects in the target repository
with an IRID that exists in JR_ID_MAPS. However, all objects in JR_ID_MAPS that are owned by reused (previouslys
migrated) application systems, are perfectly valid repository 9i objects, and should definitely not be deleted. So before you
allow Purge to do its job, delete from JR_ID_MAPS all records with an IRID value that is derived from ID_MAP_ARCH. If
you do not, valid Repository objects will be removed from the Designer 9i Repository!!


Refresh Migration
What if migration is not the final word for the Designer 6.0 Repository? What if development on the 6.0 environment
continues? Then it would be nice to migrate those changes at some point in order to refresh the 9i Repository. The changed
elements should not render completely new objects during the migration, isolated from the previously migrated objects.
Instead, they should become new versions of the existing elements. Note that this repeated migration is only supported in a
versioned repository and for versioned objects. Updating existing, non-versioned elements is not possible with the migration
tool.
To get the desired functionality, we need a few small changes in the migration scripts. First of all, we should no longer
disregard elements in previously migrated application systems. These elements will now also be migrated. Furthermore, any
element being migrated that has been migrated before will now get the same IRID as it was assigned in previous migrations,
but a fresh IVID. In normal English this means that the element is incorporated in the version tree (IRID) started in the first
migration, as a new version (IVID).
        In preparation for the migration, we define a Branch that on which we will collect all migration products. Let’s call
         this branch Migration Target. This branch should not be used for normal development work in the 9i Repository but
         solely for migrations. Set up a new workarea, say Migration, with Default Checkin Branch Migration Target. Define
         workarea rules LATEST(Migration Target) and INCLUDE_FOLDER(SYSTEM_FOLDER;1.0). Use this workarea
         as target workarea in the migration.
        Once the migration tool is done, the most complex part of the operation must still be performed. At this point the
         migration utility has created objects that may have the same IRID as pre-existing (previously migrated) objects.
         However, it has not yet restored version trees and there is no link yet between these new objects and their 'ancestors'
         with the same irid. We will now execute a script that will:
            Check in the immediate predecessor of each migrated object on the Migration Target branch (where applicable)
            Create the version tree link (version_association) between the migrated objects and their predecessors
            Check in the migrated object on the Migration Target branch or Undo Checkout a migrated object. Undo
             checkout can be used for migrated objects that are not changed since the last migration; the undo checkout
             removes the migrated object from the 9i Repository.

             We have sometimes used the column SDD_ELEMENTS.EL_USRX19, available for every element type and
             intended to support the 20th User Extended property, to hold a flag indicating whether or not the element had
             changed. This flag was set in the 6.0 Repository based on the date_changed column. On one occasion we used
             the Oracle Echo 6.0 Compare tool (also available in the freely downloadable Oracle Designer Web Assistant
             6.0) to find out which elements had changed. All migrated objects in which the EL_USRX19 column contained
             a flag set to ‘N’ were removed through Undo Checkout after the migration; since they had not been changed
             since the previous migration, no new version needed to be created for these objects. Thus we limited the number
             of new versions created in subsequent migration runs to only the ones that were actually changed in the source
             6.0 Repository, typically less than 5 % of the total number of objects.




www.odtug.com                                                                                                    ODTUG 2003
Unchained Migrations to Designer 9i                                                                                     Jellema




                                                    MAIN            Migration Target
                                          Domain
                                          JOB         1.0

                                                                            2nd
                                                                            1.0
                                                      1.1
                                                                     rge
                                                                  me

                                                      1.2



                                                      1.3



                                                      1.4
                                                      1.2

                                                                            4th
                                                                            1.1
                                                                       e
                                                                  merg
                                                      1.5
                                                      1.3




                           Figure 4. Changes were found in Domain JOB in 6.0 on the 2nd and
                           4th migration to 9i. In those instances, new versions were created on
                             the Migration Target branch. These version are merged with the
                                        versions in use in 9i on the MAIN branch.


            If changes are made to the previously migrated objects in the Designer 9i Repository, these changes have
             resulted in new versions of these objects on the MAIN branch or any other branch – but not the Migration
             Target branch. After the migration has produced new versions of these objects on the Migration Target branch,
             it is probably a good idea to merge these new versions resulting from the migration back to the versions created
             as part of the development activities in the Designer 9i Repository.


So far we have assumed that the migration uses the same source elements as a previous migration. It could also be that the
migration acts on a different set of source objects that are somehow related to a previously processed set. This is the case, for
example, when we migrate an application system that is a new version of a previously migrated application system. It is quite
simple to have the migration script deal with this fact. A simple mapping table is introduced that contains the Id-values of the
Designer 6.0 Elements in the first migrated application systems and the Id-values of the corresponding elements in the
application system now to be migrated. You can decide for yourself how this mapping table is populated. Thus, we can have
the migration tool create version trees from a number of versions of Application Systems in Designer 6.0.

Migrate downwards
It is not unlikely that an application system C and its associated project will be completely migrated to Designer 9i while at
the same time projects and application systems in Designer 6.0 have references to elements in C. Changes made to elements
in C should ideally be channeled back to the Designer 6.0 Repository, so other projects benefit from the most recent
definitions.
Naturally, the standard migration tool does not support such downward migration in any way. The code to perform this action
must be hand-built. However, this turns out to be quite straightforward.




www.odtug.com                                                                                                    ODTUG 2003
Unchained Migrations to Designer 9i                                                                                 Jellema




                      Figure 5. Identify source element in 6.0 using ID_MAP_ARCH and 9i Irid

The basic steps are
        Identify the objects in Designer 9i that have been changed/added and should be propagated to Designer 6.0 – or in a
         versioned environment the latest checked in versions of those objects.
        Map those objects to their counterparts in Designer 6.0 using the ID_MAP_ARCH table (obviously for objects
         newly created in Designer 9i cannot be mapped since they have no counterpart yet in Designer 6.0)
        Call the relevant API-packages on the Designer 6.0 Repository to perform updates and inserts to propagate the
         changes from Designer 9i. For all referencing properties, use the ID_MAP_ARCH table to derive the value to use in
         Designer 6.0 as the ID that is mapped to the (IRID) value found in the 9i referencing property. For new elements
         that are inserted into the 6.0 Repository, create records in ID_MAP_ARCH that map the irid to the new 6.0 id value.


An example
Create a function to derive the 6.0-ID value based on a 9i-IRID value from ID_MAP_ARCH:
   Create function get_id_for_irid( p_irid in number) return number is
   l_id number(38);
   cursor c_idm( b_irid in number) is
     select idm.id from id_map_arch idm where idm.irid = b_irid;
   begin
     open c_idm( b_irid => p_irid);
     fetch c_idm into l_id;
     close c_idm;
     return l_id;
   end;

Loop over the objects to be down-grated. In a versioned application, you should only ever down-grate (the latest) checked in
versions. Typically they can be selected from a workarea, filtering on I$SDD_OBJECT_VERSIONS.state (‘I’ – checked in
or ‘N’ non-versioned) and date_changed (check in date).
For each object, make the required API-calls for the PAC and all its associated SACs and Associations. For example in
pseudo-code the procedure to down-grate an entity, created in the 6.0 Repository Owner’s schema:
   procedure downgrate_entity( p_ivid in number)
   is
   cursor c_ent(b_ivid) is select … from ci_entities@r9i where ivid = b_ivid;

   r_ent c_ent%rowtype;
   l_ent cioentity.data;

   begin
     l_ent.v.id:= get_id_for_irid( r_ent.irid);
     l_ent.v.name := r_ent.name
     l_ent.v.supertype_reference := get_id_for_irid( r_ent.supertype_reference);
     l_ent.v.plural := r_ent.plural;




www.odtug.com                                                                                                 ODTUG 2003
Unchained Migrations to Designer 9i                                                                                   Jellema


   ….. process other properties and set indicators
     if l_ent.v.id is null
     then
       cioentity.ins( null, l_ent);
       -- update ID_MAP_ARCH with this new mapping between IRID, IVID and ID
       insert into ID_MAP_ARCH (id, irid, ivid) values (l_ent.v.id, r_ent.irid, r_ent.ivid);
     else
        cioentity.upd( l_ent.v.id, l_ent);
     end if;
      for r_att in c_att( b_ent_irid => p_irid) loop
       downgrate_attribute( r_att.irid);
     end loop;
      .. the same for relationships, unique identifiers etc.
   end downgrate_entity;


“Round-trip Migration”
At this point we have the ability to migrate over and over again from 6.0 to 9i, each time producing a new version with the
latest changes. We can also down-grate from 9i to 6.0, typically taking the latest checked-in version in 9i.




It is now possible to migrate one project and application while dependent applications stay behind, only to be migrated at a
later moment. Work can continue on the migrated application system, both in 9i as well as 6.0. The changes can either be
migrated upwards or down-grated. Potentially – not ideally though- changes can be made in both Repositories
simultaneously. Migrating the 6.0 changes to 9i, followed by a merge with the changes made in 9i and subsequent down-
gration of the merge-result ensure that all changes are distributed in both environments.

Managing changes to base product code
Oracle SCM is the perfect tool for managing the original scripts shipped with the base product as well as the modified scripts
we prepare for the enhanced migrations we will perform. It is important that you are always able to revert to the scripts as
they were shipped with the base product, if only to deal with situations where the amended scripts do not deliver the goods.
Here is what you should do. And by the way, this is the standard procedure for managing changes to a base component.
        Create a Workarea Designer 9i Base – this workarea will be used to collect the original scripts, shipped with the
         base product or actually the various releases of the base product
        In the workarea, create a Root Folder DESIGNER9i_HOME. Map this Repository Folder to the ORACLE_HOME
         on your local client filesystem that contains the Oracle SCM Client.
        Upload the Folder REPADM61 with child-folder CNV. Upload in CNV all scripts that we will create modified
         versions for: ckworkarea.sql….. Check in all folders and files in Workarea REPADM61. Use the release label for
         the current release of Oracle Designer 9i (for example 9.0.2) as the Version Label – when automatic labeling is
         switched off; otherwise include it in the Check In comment. This is the baseline for the repository migration scripts.
        Create a Branch to hold the modified versions of the base scripts, called something like DES9I MIG.
        Create a Workarea Enhanced Designer 9i Migration. Set the branch created in the previous step as the Default
         Check In branch for this workarea. Include Folder DESIGNER9i_HOME in the workarea, after the
         LATEST(Branch) rule.
        Changes to the base scripts are made in the new workarea Enhanced Designer 9i Migration. Scripts are checked out,
         modified and checked in on the branch. At any moment, you have both the modified script and the originally




www.odtug.com                                                                                                   ODTUG 2003
Unchained Migrations to Designer 9i                                                                                     Jellema


         shipped script (in workarea Designer 9i Base) available. Using Compare you can at any moment find out the
         changes you have made with regard to the base script as it was shipped.
        Once a new release of the base product Designer 9i is installed, for example 9.0.4, you will have to get the latest
         versions of the base scripts into the Repository. Open workarea Designer 9i Base, check out all scripts and upload
         the scripts shipped with the new release. Check in all scripts and indicate through the version label and/or the check
         in notes that these versions are part of the new release. Now open the Workarea Enhanced Designer 9i Migration.
         Check in all scripts. Use the Merge Wizard to merge the new scripts on the Main branch to the DES9I MIG branch.
         After this merge operation, the workarea will contain scripts that hold your modifications as well as the changes
         introduced in the new release of the base product. Note: the migration scripts have changed very little from the very
         first release of Designer 6i and the latest 9.0.4 release; therefore the merge operation to be performed after a new


                                                    MAIN                DES9i MIG
                                 File
                                                     9.0.2
                                                      1.0
                                 ckmigdat.sql
                                                                            2.1
                                                                            1.0


                                                                            4.2
                                                                            1.0
                                                                    e
                                                     9.0.4      merg
                                                                            4.3
                                                                            1.0


                                                                            4.4
                                                                            1.0




                                                                            5.1
                                                                            1.0
                                                                      e
                                                     9.0.5       merg
                                                                            5.2
                                                                            1.0


                      Figure 6. The DES9i MIG branch contains modified versions of standard
                      product scripts. The base versions shipped with release 9.0.4 and 9.0.5 are
                      merged to the modified scripts to ensure that all changes in the standard
                      product code are incorporated.
         release is typically very simple.



Summary
Migration from Designer 2.1/6.0 to 6i/9i in itself is not a difficult process. However, the migration utility in Designer 9i poses
some limitations: no migration into an existing workarea, forced migration of all dependent application systems at the same
time – even when application systems have already been migrated, no option to repeat a migration to capture the latest
changes and no support for downward migration. This paper has demonstrated how small modifications to the migration
scripts allow us to overcome these limitations. It is adamant to test the migration thoroughly, as making changes to core
product components is not strictly in line with support conditions.
AUTHOR’S BACKGROUND
Lucas Jellema works for AMIS Services BV, an independent software provider, based in The Netherlands. AMIS is a
company that has been dedicated to Oracle technology since its very beginning back in 1991. With a staff of over 70, it
provides full services: Business Consultancy, Project Management, Application Development and Maintenance & DBA.
AMIS, a full Oracle partner, has Knowledge Centers around four focus areas: Server Development, Designer & Forms, Web



www.odtug.com                                                                                                     ODTUG 2003
Unchained Migrations to Designer 9i                                                                               Jellema


& Java/J2EE and Business Intelligence, Data Warehouse and Portal. Lucas’ role at AMIS is technical consultant and
expertise manager in the area of application development; he supervises the four knowledge centers mentioned before. Lucas
attends ODTUG conferences since 1997 and is a regular as author and presenter, especially in the areas of Oracle Designer,
Oracle Software Configuration Manager and the Oracle Consulting offerings in the iDevelopment Accelerator’s Suite of
which he is a co-developer. He worked for Oracle Corporation as a member of the global iDevelopment Center of Excellence
until 2002. He can be contacted at jellema@amis.nl. All scripts described in this paper will be available for download from
the AMIS website at http://www.amis.nl/technology.




www.odtug.com                                                                                               ODTUG 2003

								
To top