Oracle9i Designer Migration Guide Part 5. Migrating generated Web/PLSQL applications to Oracle9i Designer |
Contents

# Chapter 1 Introduction

This migration guide provides the information necessary for upgrading Web/PLSQL Applications that were designed and generated using earlier releases of Designer to Oracle9i Designer.

The document discusses migration from the following earlier releases:

- 1.3.2
- 2.1.2
- 6.0

This document assumes that you have already installed Oracle9i Designer and migrated your repository. (See instructions in Part 2 of this Migration Guide.) The document then explains steps you have to take so that you can:

- generate your application from Oracle9i Designer and achieve the same generated results you had from earlier releases, and

- take advantage of new features that have been added to Designer since your previous release.

Throughout the document, special mention is made of any migration issues known at the time of publication of this document.

There are a number of migration scenarios that are possible in bringing your Designer-generated Web PL/SQL application forward into Oracle9i Designer.

## Scenario 1. Migrate, Regenerate All, No Redesign

In this scenario, you will regenerate all of your Web/PLSQL application from Oracle9i Designer.

The goal of this scenario is to be able to generate your Web/PLSQL application out of Oracle9i Designer and achieve the same results you got when generating out of your previous Designer release. No attempt is made to redesign your existing Web/PLSQL application to make use of new features available in Oracle9i Designer.

This scenario has the following characteristics:

- If you have minimal post-generation changes, scenario 1 is fast and requires minimal changes in the Web/PLSQL application definition in the Oracle Designer repository.
- Scenario 1 uses your existing module definitions and any custom framesets or templates without changes.
- Scenario 1 does not take advantage of many new Web/PLSQL features in Oracle9i Designer. It is merely a 'technical' upgrade. Some new features will be implemented as part of this upgrade.

This scenario is appropriate when:

- Your application is already in production.
- Your application is stable, no major functional modifications are expected.
- Maintenance is limited to simple bug fixing.
- Your application is 100% generated, or post-generation modifications are minor.

## Scenario 2. Migrate, Regenerate All, With Redesign

In this scenario, you will regenerate your entire Web/PLSQL application from Oracle9i Designer. As you regenerate each Web/PLSQL module, you will make use of new features as appropriate.

The goal of this scenario is to take advantage of the new Web/PLSQL features available in Oracle9i Designer. As with Scenario 1, you want to be able to generate your Web/PLSQL application and get the same user interface you got from your previous release of Designer. However, many new Web/PLSQL features have been added to Designer to make achieving the desired result easier. Many features that were difficult or impossible to generate with earlier releases of Designer are now supported. Thus, in one pass, you can eliminate post generation modifications and difficult constructs that were used only to work around limitations of earlier releases of Designer.

This scenario has the following characteristics:

- Scenario 2 requires a review of security implementation.
- Scenario 2 requires modifications in many module definitions, and is therefore more time-consuming.
- Scenario 2 fully leverages the new Web/PLSQL features in Oracle9i Designer.

This scenario is appropriate when:

- Your application is still in development.
- Your application is in production, but major functional modifications are to be made, or expected.
- Your application requires modifications (e.g. security) which can only be implemented using new functionality in Designer.
- Your application has been heavily modified post-generation, but the majority of the modifications are no longer needed due to the new Web/PLSQL functionality in Designer.

## Scenario 3. Migrate, Regenerate Incrementally

This is the most complex scenario. In this scenario, you will migrate your application a little at a time, rather than all at once. You will begin by migrating your application to a 8i Database in a schema specific way, or create a database link and appropriate synonyms to your new database schema. You will then make the changes required to run the application generated from your previous release of Designer alongside Web/PLSQL applications generated from Oracle9i Designer. Finally, over some arbitrarily long period of time, you will regenerate all of your modules out of Oracle9i Designer.

The goal of this scenario is to allow you to regenerate your whole application, taking into account new features, but in such a way that you do not have to migrate your entire application in one go. This means you will be able to move the deployed application to the new tool stack before you have completely migrated every module. Thus, you can continue with bug fixes and new development in parallel with the continuing migration effort.

This scenario has the following characteristics:

- Scenario 3 allows you to perform a phased migration. You can take advantage of the new Designer features right away, without the need to regenerate all your modules at once.

This scenario is appropriate when:

- Your application is in production, but major functional modifications are to be made, or expected.
- Your application requires modifications (e.g. security) which can only be implemented using new functionality in Designer.
- Your application is too large to migrate in one ‘big-bang’.

## Scenario 4. Database Migration Only

The first three scenarios all eventually require you to regenerate your application. Any post-generation modifications will be lost. If you heavily modified your application post-generation, and the characteristics of Scenario 1 apply to your situation, you might consider only upgrading the database environment to 9i, and not upgrading to Oracle9i Designer. This implies that all future maintenance has to be done manually in PL/SQL.

This migration guide does not cover 9i database migration. It will, however, discuss modifications that will allow you to continue to run your generated Web/PLSQL modules alongside other applications. For information on migrating to a 9i database, see Part 3 of this migration guide.

Note that, even though you may choose not to use Oracle9i Designer for continued module generation, you may still use Oracle9i Designer to maintain your database definitions. You may also choose to use the Software Configuration Management features of Oracle9i Designer to manage your application source code. In that case you could bring in the previously generated and adapted packages as files in the repository and maintain these files for future enhancements and/or fixes. Note that in addition you can parse these packages - stored as files - for dependencies with the Dependency Manager for impact analysis.

For information on Software Configuration Management with Oracle9i Designer, see the Oracle Technology Network at http://otn.oracle.com/products/repository.

Note that all scenarios result in an actual usage of Oracle9i and Oracle9i Designer and therefore you will be optimally serviced by Oracle Support on your Oracle tool stack, i.e., you do not need to implement costly workarounds, you can simply profit from regularly released patches.

# Chapter 2 Oracle9i Designer New Features

Depending on which Designer release you are coming from, many Web/PLSQL features of Oracle9i Designer may be new to you.

This chapter presents a brief overview of new features that are of particular interest when migrating a generated Web/PLSQL application. It is by no means an exhaustive list of all new features, and it does not try to explain each new feature in detail. Rather, it introduces the relevant features, and points you to where you can find more information in the Oracle9i Designer online help. These new features may be referenced in the appropriate migration steps of the following chapters.

This chapter is organized by Designer release. You should begin reading at the section for your "from" Designer release, and then continue reading the sections for any later releases. For example, if you are migrating from Designer 1.3.2, you need to read all four sections below. If you are migrating from Designer 2.1.2, you may skip the section on Designer 1.3.2 and read the sections for Designer 2.1.2 and 6.0.

## Migrating from Designer 1.3.2

### Design Editor

See Part 4, Chapter 3 of this migration guide for a general overview of these new features.

### Module Components

See Part 4, Chapter 3 of this migration guide for a general overview of these new features.

### Preferences

Oracle9i Designer has added many new preferences. These preferences allow for greater flexibility in layout and provide for new methods of security.

### TAPI/Triggers

Designer 1.3.2 introduced the concept of a Table API (TAPI) specifically for the WebServer Generator. The WebSever Generator used the TAPI to do any inserts, updates or deletes (and some selects) against a table. The TAPI auto-generated primary keys associated with sequences and audit columns, and allowed you to place your own specific code within the TAPI. The TAPI was not used with any other Designer generator. Beginning with Designer 2.1.2, the TAPIs became an integral part with other generators and were associated with table triggers, causing the TAPI code to be run during any insert, update or delete. Oracle9i Designer has additional custom code placement options within the TAPI and auto-generates more functionality, including enforcing arcs, etc.

## Migrating from Designer 2.1.2/6.0

This section describes migrating from Designer 2.1.2 or 6.0.

### LOV components

Oracle9i Designer departs from the use of lookup table usages to drive LOVs. LOVs can now be created as specific, reusable components and attached to an element. This provides for more flexibility and the ability to drive the LOV from a custom query. This is particularly helpful in the WebServer Generator in that it allows you to better define the look of Poplist type LOVs.

### All_domains Table

Before Oracle Designer 6i, the CG_REF_CODES table provided the only structured reusable table for multiple lookup types. This limited its usefulness to only lookups that fit within the column structure of CG_REF_CODES. The All Domains table feature extends this type of functionality to a table that can be custom designed to meet the needs of your application. Coupled with Reusable LOV components this becomes a very powerful new feature.

### Reusable Modules

Reusable Modules allow you to define a module with base table usages, associated lookups, etc., and to reuse this definition in multiple generated modules. This provides enhanced standardization.

### Preferences

Oracle9i Designer adds substantially to the preferences available for WebServer Generator modules. These preferences provide better control over layout and provide the ability to maintain “context” between modules. Because the web is stateless, information that may have been available in a previous module in the hierarchy may not be available in the current module. The Master Context section of the generator preferences provides a way to ensure context is available to subsequent modules. Please see the Oracle9i Designer online help for more information on new preferences.

### Multi-Row Screens

Oracle9i Designer will generate multi-row screens to provide inserts, updates and deletes across multiple rows. This is determined at the module level.

## Oracle Portal portlets generation

You are now able to generate more functional Oracle Portal portlets. Please see the Oracle9i Designer online help for more information on this feature.

# Chapter 3 General Migration Issues

This section will review issues that may arise with migrating from any previous release of Designer to Oracle9i Designer. The following sections will deal with specifics of each release. For completeness, you may wish to read the sections regarding earlier releases than your own.

There are a number of actions you must take regardless of which migration scenario you choose.

This chapter is organized by Designer release. You should begin reading at the section for your "from" Designer release, and then continue reading the sections for any later releases. For example, if you are migrating from Designer 1.3.2, you need to read all sections below. If you are migrating from Designer 2.1.2, you may skip the section on Designer 1.3.2 and read the sections for Designer 2.1.2 and 6.0.

## Migrating from 1.3.2, 2.1.x, 6.0

This section covers general migration issues when migrating from Designer Release 1.3.2, 2.1.x and 6.0.

### Perform a backup of your database schema that captures the Web-PL/SQL components

In all cases perform a complete backup of your database and export of any affected schemas.

### Web PL/SQL Generator Libraries

You will need to upgrade the associated libraries for the Web PL/SQL generator (wsgl, wsglm, cg$errors, etc.). Because you will be regenerating all components, there is no need to run the existing version of these packages alongside the new versions. In other scenarios you will be required to maintain both sets of packages.

WSGLM is often modified to provide messages tuned to your applications. Any changes to your existing WSGLM will need to be re-applied to the Oracle9i Designer WSGLM package.

Occasionally changes might have been made to other library packages. Some of these changes may need to be reapplied, where others may not be needed due to new functionality within the product. For example, Designer 1.3.2 matched case on queries. The dynamic build_where_clause could be modified to overcome this. In Oracle9i Designer there is an option to perform case insensitive queries (the default is case insensitive).

Depending upon the number of existing applications, you might have multiple copies of the WSGL libraries. By default, Oracle9i Designer will install these libraries in one location (schema). If the schema has sufficient privileges, the installation will grant execute on these libraries to public and create public synonyms. In some cases you may prefer to have multiple copies of the libraries for use by different application systems. This can be done by installing the copies in separate schemas and pointing the application schemas to the appropriate library schema by use of private synonyms.

### Security

Designer 1.3.2 and 2.1.2/6.0 were typically run using either the Oracle Application Server PL/SQL cartridge or the WebDB listener. In both cases you had two methods of configuring the database login to run the generated PL/SQL components:

1. single user login, and
2. database authentication (provide a basic authentication login screen and login to the database with the supplied username and password).

In Oracle9i Designer, there are new security features that should be considered. In Scenario 1 we assume that you will use your existing access and security methods. The new features are discussed in Chapter 5 "Migrate, Regenerate All with Redesign".

Regardless of which scenario you adopt, you will need a good understanding of your existing access and security mechanism. At a minimum you should determine your DAD settings and note any schemas and roles that are associated with securing your existing PL/SQL packages that comprise Web PL/SQL modules.

Web PL/SQL Generator uses a checksum routine to secure access to specific records. Regardless or the version of Designer, it is a good idea to change the function WSGL.CHECKSUM slightly so that your checksum is different than the default shipped. The easiest method is to change the mod number in the function, WSGL.CHECKSUM, from 4294967296 to some other large number. As you will be installing a new version of the libraries, specifically WSGL, previous changes to WSGL.CHECKSUM must be reapplied.

### Application Server Choice

Designer 1.3.2, and 2.1.2/6.0 WebServer Generator applications were typically run with the OAS PL/SQL Cartridge or the WebDB Listener.

Although you can continue to use your existing Application Server, Oracle9i Designer applications are likely to be run with Oracle 9i Application Server using MODPLSQL. In general, the configuration of web pl/sql modules is very similar.

The DAD configuration information can be found in the file $ORACLE_HOME/Apache/modplsql/cfg/wdbsvr.app. Beginning with Oracle 9iAS
1.0.2.2 the DAD password is encrypted within this file. The browser interface to configure this file is found at
http://yourmachine:port/pls/admin_/gateway.htm where your machine is the machine name where Oracle 9iAS is installed.

After installing Oracle 9iAS, make a copy of the file $ORACLE_HOME/Apache/Apache/conf/httpd.conf

Modify this file and change the line

defaultType text/ascii

to

defaultType text/html

The application server will then treat unknown content type as html. On rare occasions, with defaultType set to text/ascii, the html code generated by Designer WebServer Generator will be displayed as ascii text rather than an html page.

# Chapter 4 Scenario 1: Migrate, Regenerate All, No Redesign

In this scenario, you regenerate your entire application from Oracle9i Designer, including all Web/PLSQL, libraries, menus and reports.

The goal of this scenario is to be able to generate your application out of Oracle9i Designer and achieve the same results you got when generating out of your previous Designer release. No attempt is made to redesign your existing application to make use of new features available in Oracle9i Designer.

This chapter is organized by Designer release. You should begin reading at the section for your "from" Designer release, and then continue reading the sections for any later releases. For example, if you are migrating from Designer 1.3.2, you need to read all sections below. If you are migrating from Designer 2.1.2, you may skip the section on Designer 1.3.2 and read the sections for Designer 2.1.2 and 6.0.

This chapter assumes that you have performed all the actions described in Chapter 3, General Migration Scenarios.

## Migrating from 1.3.2

In most cases, migrating your 1.3.2 application to 9i will go smoothly. There are four specific areas that may cause difficulty: module level security (z_chk), using calls to underlying values, return links and Table APIs.

### Module Level Security

Designer WebServer Generator modules use “Query, List, Detail”. A user is first presented with a Query Screen, then a list of items that match the criteria, and ultimately a detail screen that typically allows update. In many cases, the list screen will always be limited by a fixed where clause in the module. Releases of Designer 2.1.2 onwards implement a security check to ensure that users do not access the detail screen directly by changing the URL. Designer uses a checksum value (Z_CHK) to enforce this. Every link on the list screen has Z_CHK=#####. The detail page checks to see that this checksum value is correct.

If you have defined your own method of calling a component based upon the URL, you will need to modify these calls to implement Z_CHK or turn off Z_CHK. You can turn off Z_CHK by setting the preference SECECS (Enforce URL Checksums) to No. Please see the Oracle9i Designer online help for specific information about how to call wsgl.checksum to implement Z_CHK from your own code.

Note: It is a good idea to change the function WSGL.CHECKSUM slightly so that your checksum differs from the default shipped. The easiest method is to change the mod number in the package (4294967296) to some other large number.

### Using Calls to Underlying Values

In all releases of Designer you could reference values from routines placed in the user text area. This was not explicitly stated in release 1.3.2 and there were no APIs or standards given for doing so. Hence, calls made to these underlying values, by use of form_val.field_name, etc., will likely fail in the migrated application. Oracle9i Designer specifies the use of these values. Please see the Oracle9i Designer online help for more information on accessing these values.

### Return Links

Designer 2.1.2 onwards provides return links to allow the user to select a link to return to previous modules in the hierarchy. Because this was not available in earlier releases, the existing application may have coded return links in the user text area. You can turn off return links with the preference MODBRL (Build Return Hyperlinks).

### Table APIs

Designer 1.3.2 required Table APIs (TAPIs) only for WebServer Generator applications. With Oracle9i Designer the default is to have all transactions run the logic present within a TAPI. Hence, any code that is currently in the TAPIs will be run for all transactions regardless of the application. This is implemented through the use of table level triggers. You can disable this feature by deselecting the Generate Table API Triggers checkbox in the Generate Table API Definitions dialog box during generation. Other types of applications, however, may wish to make use of the TAPIs, hence it is a better practice to move any code specific to Web PL/SQL modules out of the TAPIs and into the modules themselves. Oracle9i Designer has many new trigger points within the module to accept this code.

## Migrating from 2.1.2/6.0

In most cases, migrating your 2.1.2/6.0 application to Oracle9i Designer will go smoothly. There are two specific areas that may cause difficulty: using calls to underlying values, and table APIs.

### Using Calls to Underlying Values

In all releases of Designer you could reference values from routines placed in the user text area. In many cases the format of calls or local access to these underlying values may have changed; calls made to these underlying values, by use of form_val.field_name, etc., will likely fail in the migrated application. Oracle9i Designer specifies the use of these values. Please see the Oracle9i Designer online help for more information about accessing these values.

Additionally, Oracle9i Designer provides a preference for bringing master level information into detail blocks of a module. These preferences can be found in the Master Context area of the Web PL/SQL Generator preferences.

### Table APIs

Designer 2.1.2/6.0 virtually insisted that you install triggers that implemented the TAPIs for all transactions. Oracle9i Designer allows you to bypass generation of these triggers. In general it will not affect your Web PL/SQL applications if you do not generate these triggers. It may, however, allow the data to become inconsistent with what is expected from your application. Before deselecting the Table API Triggers checkbox in the Generate Table API Definitions dialog box during generation, consider carefully the affect of not having the TAPIs fire for all transactions .

# Chapter 5 Scenario 2: Migrate, Regenerate All, with Redesign

In this scenario, you regenerate your entire application from Oracle9i Designer, including all Web/PLSQL, libraries, menus and reports. As you regenerate each module, you make use of new features as appropriate.

The goal of this scenario is to take advantage of the new features available in Oracle9i Designer. As with Scenario 1, you want to be able to generate your application and get the same user interface you got from your previous release of Designer. However, many new features have been added to Designer to make achieving the desired result easier. Many features that were difficult or impossible to generate with earlier releases of Designer are now supported. Thus, in one pass, you can eliminate post generation modifications and difficult constructs that were used only to work around limitations of earlier releases of Designer.

This chapter assumes that you have already performed all the actions described in Chapter 3 "General Migration Issues" and that you have evaluated the steps in the previous chapter, "Scenario 1 Migrate, Regenerate All, No Redesign".

This chapter is organized by Designer release. You should begin reading at the section for your "from" Designer release, and then continue reading the sections for any later releases. For example, if you are migrating from Designer 1.3.2, you need to read all the sections below. If you are migrating from Designer 2.1.2, you may skip the section on Designer 1.3.2 and read the sections for Designer 2.1.2 and 6.0.

## Migrating from 1.3.2

Please review Chapter 4 "Scenario 1: Migrate, Regenerate All, No Redesign", because this also applies to this section.

### Security

This section is an extension of the security section in Chapter 3 "General migration issues".

Designer 1.3.2 and 2.1.2/6.0 were typically run using either the Oracle Application Server PL/SQL cartridge or the WebDB listener. In both cases you had two methods of configuring the database login to run the generated PL/SQL components:

1. single user login, and
2. database authentication (provide a basic authentication login screen and login in to the database with the supplied username and password).

The first scenario, single user login, may have been extended to have multiple Database Access Descriptors (DADs) that pointed to specific database schemas.

The second scenario, database authentication, allowed the user to log in to the database as a specific database user. Grants to specific PL/SQL components could then be made to a role, which would in turn be granted to the database users.

In Oracle9i Designer, there is a new security feature that should be considered. The preference SECPKG (Security Package Name) allows you to specify a PL/SQL package that will determine the users' ability to use a component. (Please see the Oracle9i Designer online help for details of SECPKG.) By using SECPKG you can simplify your deployment architecture to that shown below.

You can now grant execute on all PL/SQL components to PUBLIC. Your custom developed SECPKG package will return a true if the user is allowed to run the component, based upon your own criteria.

Note: You can continue to run the generated application exactly as you did before, making use of the default SECPKG which always returns true.

If you are using WebServer Generator in the same database instance as Oracle Portal, you can use all of the Portal user and group features. You must run the Portal script PROVSYNS.SQL for the schema that contains your SECPKG package. You can then reference the Portal lightweight user name with a call to the Portal API wwctx_api.get_user. Additional Group and User API information is available within the Portal PDK (http://portalstudio.oracle.com).

In Scenario 1 we discussed four areas of concern: module level security (z_chk), using calls to underlying values, return links and table APIs. While these areas of concern remain, they also provide enhancements that may allow you to reduce the need for post-generation changes or custom code within the user text areas.

### Module Level Security

Oracle Designer Web PL/SQL Generator modules use “Query, List, Detail.” A user is first presented with a Query Screen, then a list of items that match the criteria, and ultimately a detail screen that typically allows update. In many cases, the list screen will always be limited by a fixed where clause in the module. Designer 2.1.2 and forward implement a security check to ensure that users do not access the detail screen directly by changing the URL. Designer uses a checksum value (Z_CHK) to enforce this. Every link on the list screen has Z_CHK=#####. The detail page checks to see that this checksum value is correct.

In the previous scenario we discussed how to turn off this feature to provide the same functionality as your existing application. In this scenario we will discuss how to make use of this feature.

In Designer 1.3.2 you may have “tricked” the generator into using a view instead of a base table, thereby not allowing the user access to the underlying data in the table. With Z_CHK this trick is no longer necessary. By setting the generator preference SECECS (Enforce URL Checksums) to Yes the generated module will ensure that users only have access to the detail screen via the record list. (Please see Scenario 1 for more details.) Additionally, if you wish to access any detail records from other modules you will need to make use of the wsglm.checksum routine. Please see the Oracle9i Designer online help for more information regarding wsglm.checksum.

### Return Links

In Designer 1.3.2 navigation links were largely the responsibility of the developer. Designer 2.1.2 forwards provides links to components higher in the module hierarchy.

### Table APIs

Table APIs were introduced in Designer 1.3.2 specifically for the Web PL/SQL generator. From 2.1.2 forward TAPIs are an integral part of the overall system. TAPIs have been extended to allow additional points of access to add custom code. TAPIs automatically generate code to provide denormalization and enforcement of constraints such as arcs, domain based keys (CG_REF_CODES and ALL_DOMAINS), etc.

## Migrating from 2.1.2/6.0

Please review Scenario 1: Migrate, Regenerate All, No Redesign, because this also applies to this section.

### Module Level Security

Designer 2.1.2 left security largely up to the developer. Security was generally implemented by creating a schema that either owned the pl/sql packages that make up the Web generator module or had specific grants to those packages. Another option was to create roles with grants to pl/sql packages and ultimately grant those roles to users. In either case, the security was left to the DBA to developed and was limited to granting access to pl/sql via database grants.

Oracle9i Designer provides a mechanism to define your own security policy. This policy is still implemented across the whole module, but it allows you to code the decision of access in any way you choose. Every procedure that is callable from a web browser first calls the package defined in the preference SECPKG, passing in the package name. The default SECPKG always returns true. By coding your own SECPKG routine you can base access on anything you like - it is not limited to database grants. Perhaps some modules should only be run after normal business hours, simply return false when called between 8 and 5. Additionally, when SECPKG returns false, nothing is returned to the browser. This allows you to code your own access error screen. You also have the ability to log invalid (or valid) attempts to run a module. Each call to a module component initiates a call to your security routine, giving an access point to log information regarding the module.

When the generator installs the module component, it will call a procedure, add_package_resp, in the package defined in the preference SECPKG, passing in the value of SECRES (Default Responsibilities) and all PLSQL Packages that make up the module. Your procedure, add_package_resp, can then insert these values into a table that will later be used to determine whether a user can run the package.

### Multi-Row Components

Designer Web PL/SQL components in version 1.3.2 were limited to insert, update and delete a single row at a time. Oracle9i Designer now provides the ability to insert, update and delete multiple rows in a single html screen. Forms that were of type List/Form should be reviewed to determine if the new multi-row format will improve the user interface.

## Oracle Portal portlets generation

Oracle9i Designer provides new functionality to integrate with Oracle Portal. Oracle9i Designer will generate the wrappers required to present the screens as portlets within Oracle Portal. Because Oracle Portal and Designer Web PL/SQL generator modules both use Oracle 9i Application Server’s modplsql, great synergy can exist between these technologies.

If you are using WebServer Generator in the same database instance as Oracle Portal, you can use all of the Portal user and group features. You must run the Portal script PROVSYNS.SQL for the schema that contains your SECPKG package. You can then reference the Portal lightweight user name with a call to the Portal API wwctx_api.get_user. Additional Group and User API information is available within the
Portal PDK (http://portalstudio.oracle.com). By using the PDK you can determine what groups a user belongs to and map these groups to Designer Modules.

Oracle Portal provides great flexibility in navigation and presentation. By generating Portlet wrappers, you can place Designer modules on tabbed portal pages. Portal modules can be integrated on the same pages as Oracle Portal components such as menus, reports and charts.

# Chapter 6 Scenario 3: Migrate, Regenerate INCREMENTALLY

This is the most complex scenario. In this scenario, you migrate your application a little at a time, rather than all at once. You begin by upgrading all of your Designer repository to an Oracle9i Designer repository. You then make the changes required to run Web/PLSQL generated from your previous release of Designer alongside Web/PLSQL generated from Oracle9i Designer. Finally, over some arbitrarily long period of time, you regenerate all of your modules out of Oracle9i Designer.

The goal of this scenario is to allow you to regenerate your whole application, taking into account new features, but in such a way that you do not have to migrate your entire application in one go. This means you will be able to move the deployed application to the new tool stack before you have completely migrated every form. Thus, you can continue with bug fixes and new development in parallel with the continuing migration effort.

The basic method that allows you to run multiple versions at the same time is the same regardless of the versions. You should read all of Chapter 3 and Chapter 4 before attempting this solution. You should back up any schemas that hold database objects, wsgl libraries and application components prior to attempting to reconfigure the system to allow multiple versions to run side by side.

The key to this method is segregating the different versions into their own schemas. Typically all of the database objects and the Web PL/SQL components might have resided in a single database schema.

In order to run your existing application alongside the new Oracle9i Designer application components you will need to first migrate your existing application and associated Web PL/SQL generator libraries to a separate schema. In all cases you will need to grant select, insert, update, and delete on all database tables (including CG_REF_CODES) and sequences that are used by your modules. These grants must be granted directly, not via a role. Depending upon the version that you are migrating from, you may need to create synonyms to point to the database objects (Designer 6i introduced the ability to define the database object schema within the generator preferences. Earlier releases require synonyms.)

After moving all existing application components to a new schema as described above, the system should work precisely as it had previously.

Next, you can install the Oracle9i Designer Web PL/SQL generator libraries. This can be done in the object owner schema or in a separate schema. For the purposes of this document we will assume that these libraries are in a separate schema.

Again, the original application should be tested at this point to ensure that it continues to run properly. The table APIs should be installed next. In Oracle9i Designer, TAPIs are intended to be usable by transactions other than Web PL/SQL modules. If you only intend to use TAPIs for Web modules, the TAPIs can be placed in the schema in the diagram above. We will assume that you will use TAPIs throughout and hence will place the TAPIs in the object owner schema. In so doing, you must grant execute on the TAPIs to the schema.

You can now migrate individual components to Oracle9i Designer and install them into the schema. Any logic placed in the TAPIs will be run for all transactions, including transactions from earlier Web PL/SQL modules.

Designer Web PL/SQL modules do not preface calls to the components with the schema name. Hence, depending upon your application server configuration, you will likely need to create public synonyms for all of the packages associated with your applications. This requires that your module names be unique across schemas.

While this configuration is the most complicated, it is based upon sound database techniques and can be accomplished. Many specific scenarios will require a more complex scheme than that described above.

Prev | Next
| Copyright © 2002, Oracle Corporation. All Rights Reserved. |
Contents