Managing Transaction Type Configurations

This topic describes the considerations and steps related to migrating transaction type definitions, such as permits, planning and zoning applications, and code enforcement, from your test environment to your production environment.

Transaction Type Lifecycle Overview

Any implementation of Oracle Applications Cloud usually requires migrating setup data from one environment to another at various points in the subscription lifecycle.

For example, you set up your initial configuration of the Oracle Permitting and Licensing offerings in the test environment, which is your source system. Then, after thorough testing and verification, you move the setup and configuration data from your test environment to the target environment, which is your production system.

You use the Fusion Applications Functional Setup Manager to perform these migration tasks.

This example illustrates that you use Functional Setup Manager to migrate data between your test and your production environment.

This example illustrates Functional Setup Manager in relation to a test and production environment. Details are in the surrounding text.

Use Functional Setup Manager to migrate data between test and production environments.

You access Functional Setup Manager by selecting Navigator > Setup and Maintenance or by clicking the Setup and Maintenance tile on the springboard. To access Functional Setup Manager, you need to have the System Administrator role associated with your user account.

The functional areas in Functional Setup Manager that apply to your transaction type definitions and application form definitions are:

Offering

Functional Area

Public Sector Permits

Permit Types

Public Sector Planning and Zoning

Planning Application Types

Public Sector Code Enforcement

Incident and Case Types

Like using Functional Setup Manager to setup your configuration, when migrating data, you use a top-down approach. That is, if you are not exporting the entire configured offering, and you are exporting by functional area, you need to export the functional areas in the order they appear.

For more information on using Functional Setup Manager, see Using Functional Setup Manager.

Note: All configuration changes should be completed and tested in your test environment and then migrated to the production environment. Changes made directly to the production environment might be overridden during subsequent test-to-production migration activity.

For additional information related to migrating configuration data from your test environment to your production environment for the Public Sector Compliance and Regulation offerings, see Oracle Permitting and Licensing: Test to Production (Doc ID 2551940.1) on My Oracle Support.

Set the Target Instance URL

On the source system (your test environment), you need to define the URL target system (your production environment) so that setup data and configuration data can be sent to the target.

To set the target instance URL:

  1. Sign on to the test environment.

  2. Click the Setup and Maintenance tile on the springboard to access Functional Setup Manager.

  3. On the right side of the Functional Manager Setup interface, click the Tasks tab to open the Tasks drawer.

  4. Click Search, and search for Manage Configuration Set Migration Target Security Policy.

  5. On the Manage Configuration Set Migration Target Security Policy page, enter the URL for your target environment, and the appropriate security credentials for the System Administrator role.

    Note: It is recommended to include the port number when you specify the URL value. For example:https://server.example.com:443You can get the target port value by accessing the Manage Configuration Set Migration Target Security Policy page on your production system (your target).
  6. Save.

Managing Unified Sandboxes on the Source and Target System

Oracle Permitting and Licensing requires the Unified Sandboxes feature to be enabled on your test environment, where you are actively designing and configuring your implementation. It is recommended that you disable the Unified Sandboxes feature on your production system.

For migrating transaction types from your test system to your production system, especially, make sure to disable the Unified Sandboxes feature on your target, production system. Because you should be completing all configuration tasks on your source test system, sandboxes shouldn’t be required on the production system. Having the Unified Sandboxes enabled on the production system can cause the Configuration Set Migration utility not to render or function properly.

To disable Unified Sandboxes:

  1. Sign on to your target, production system.

  2. Navigate to Functional Setup Manager.

  3. Select your solution, such as Public Sector Permits, Public Sector Planning and Zoning, or Public Sector Code Enforcement.

    Note: Disable Unified Sandboxes in all solutions you have licensed for Public Sector Compliance and Regulation.
  4. Click the Change Feature Opt In link.

  5. Locate the Application Extensions feature, and click the pencil icon in the Features column.

  6. Make sure the Unified Sandboxes feature is disabled.

    Note: If there are any open sandboxes, they need to be deleted or published before you can disable this feature.
  7. Click Done.

Migrating Transaction Type Foundational Metadata

Before you use Functional Setup Manager to export transaction type configuration data, you need to create and migrate a configuration set, which includes the underlying metadata required to be in place as a prerequisite prior to migrating other transaction type setup data.

Because the Public Sector Licensing and Permitting solutions are metadata-driven, you need to migrate the metadata that is the foundation of the transaction definitions. This is the data stored in the Oracle Metadata Services (MDS) layer. You do this by creating a configuration migration set. Once that is complete, you can then begin using Functional Setup Manager export and import features to transfer the rest of required definitions between test and production systems.

Note: Before you migrate transaction type metadata from your test system, ensure that the transaction type definitions and associated intake forms are complete, tested, and published.
Caution: These steps must be completed before you use the Functional Setup Manager export and import options.
Note: Prior to running the configuration set migration process, ensure that all transaction types are published and there is no development and design of intake forms underway. Creating transaction types and intake forms is not supported while the configuration set migration process is running. Once the configuration set migration process has completed successfully, you may resume development and design of intake forms.

To migrate transaction type metadata:

  1. Sign on to the test system, which is the source system.

  2. Click the Setup and Maintenance tile on the springboard to access Functional Setup Manager.

  3. Select the appropriate offering (Permits, Planning and Zoning, or Code Enforcement).

  4. Expand the Permit Types, Planning Application Types, or the Incident and Case Types functional area (depending on your offering).

    Note: These steps for creating a migration set apply only to the Permit Types, the Planning Application Types, and the Incident and Case Types functional areas.
  5. Click the configuration you want (depending on your offering). For example for permits, click the Manage Permit Configuration link.

    Note: This link takes you to the Manage Configuration Set Migration Target Security Policy. You can also access this page in Fusion Application by selecting Navigator > Configuration > Migration.
  6. If you have not already specified your target instance URL, you must do that prior to the next step.

    See the previous section for more information.

  7. Select the Outgoing tile and create an outgoing migration set to export to your production environment.

    When creating a configuration set, the utility compares differences between source and target, and determines the metadata that needs to be exported to the target system. When the process is complete, the resulting migration set is downloaded in the form of a downloadable jar file.

  8. After finishing the creation and migration of the outgoing migration set, sign on to the production system (the target system), and complete the steps for applying the incoming migration set.

This example illustrates an incoming configuration set.

Incoming configuration set during migration

For more information on these steps, refer to Oracle Applications Cloud documentation: Overview of Migration in Configuring and Extending Applications.

Exporting and Importing Remaining Transaction Type Data

After you have completed migrating the configuration set on the source system, you then export the remaining transaction type data using the Functional Setup Manager options for the functional area or the entire offering.

Note: You can export and import at the functional area-level by selecting the Actions button for the functional area or at the entire offering level by selecting the Actions button at the top right.

This example illustrates using the functional area export options.

Using FSM functional area export features.

After exporting from the test system, you then sign on to the production system and import the corresponding business object data.

When you export business object data, you have the option to select only those business objects that you utilize. For example, if you are not using application groups, you could deselect Manage Application Groups from the Business Objects list.

The objects you export will be in the form of a downloadable jar file.

For more information on these Functional Setup Manager export and import features, see Oracle Applications Cloud documentation, Using Functional Setup Manager:

Export and Import of CSV File Packages

Setup Data Export and Import Using an Offering or a Functional Area