Introduction

Approval rules are rarely configured only once.

In most Oracle Fusion implementations, approval rules are initially configured and tested in a development or TEST instance. Once testing is completed, the same configuration must be moved to another instance, such as UAT or Production.

Recreating every approval rule manually can be time-consuming, especially when the rules include multiple conditions, management hierarchies, approval groups, application roles and sequential or parallel approvers.

Oracle SOA Composer provides an export and import option that helps migrate approval-rule changes from one instance to another. In this blog, we will cover the complete migration process and an additional scenario where only a specific approval process needs to be migrated.

A Common Business Challenge

Imagine that your project has completed the configuration of approval rules for:

• Absence
• Promotions
• Transfers
• Change Assignment
• Work Location Changes

The configuration has been tested successfully in the TEST instance and must now be moved to UAT. Rebuilding all these rules manually would require considerable effort. There is also a risk of missing a condition, changing the approval sequence or selecting the wrong approver type.

Instead, the approval changes can be exported from the source instance and imported into the target instance using SOA Composer.

What Does SOA Composer Export?

SOA Composer creates an archive containing the SOA runtime changes available in the source instance. These changes can include modified approval tasks and approval rules.

It is important to understand that this is not a complete export of every unchanged seeded approval rule. The archive contains the approval-related runtime changes made in the source instance.

When the complete archive is imported, all approval composites included in that archive are processed in the target instance.

Prerequisites

1. The source and target instances must be on the same patch level.
2. The source and target must use the same release version of the approval composites.
3. The user performing the migration must have the BPMProcessAdmin role.
4. The approval rules must be reviewed and tested in the source instance.
5. Referenced approval groups, roles and hierarchies must be available in the target instance.
6. The export must be reviewed for unwanted or unfinished approval changes.

Oracle states that the import can fail when the source and target composite versions do not match.

Step-by-Step Approval Migration

Step 1: Review the Approval Rules in the Source Instance

Before exporting the changes, confirm that the required rules are available, their conditions and approval sequences are correct, and no unfinished configuration is included unintentionally.

Source Instance

Step 2: Review the Target Instance Before Migration

Open the same approval processes in the target instance and capture their current configuration. This provides a clear baseline for comparison after migration.

Target Instance

Step 3: Open SOA Composer in the Source Instance

Add /soa/composer to the source Oracle Fusion URL:

https://<source-instance-host>/soa/composer

1. Sign in using an account with the required BPM administration access.
2. Click Export/Import.
3. Select Export SOA Changes.

Step 4: Export the Approval Changes

1. Click Export.
2. Wait for SOA Composer to create the export archive.
3. Confirm that the archive is ready.
4. Click Download and save the JAR file.

The export may contain multiple approval composites, depending on the changes available in the source instance. Keep an untouched copy of the downloaded file.

Step 5: Open SOA Composer in the Target Instance

Open the target instance using:

https://<target-instance-host>/soa/composer

1. Confirm that you are connected to the correct target instance.
2. Click Export/Import.
3. Select Import SOA Changes.

Step 6: Select the Exported Archive

1. Click Choose File.
2. Select the JAR file downloaded from the source instance.
3. Confirm that the correct archive is selected.
4. Click Import.

When migrating all approval changes contained in the archive, no modification to the exported JAR is required.

Step 7: Monitor the Import

SOA Composer decompresses the archive, validates its contents and processes each approval composite. Wait until the Import succeeded message appears.

Step 8: Verify the Migrated Approval Rules

An import-success message confirms that the archive was processed, but functional validation is still required. Verify the rule names, conditions, sequence, approver types, management hierarchies, application roles, approval groups and exception routing.

Step 9: Perform Transaction Testing

Submit sample transactions in the target instance and confirm that:

• The correct approval rule is selected.
• The transaction reaches the expected approvers.
• The approval sequence is correct.
• Positive and negative conditions behave as expected.
• Notifications are generated correctly.
• Referenced approval groups and roles work correctly.

Additional Scenario: Migrating Only a Specific Approval Process

Sometimes the source instance contains changes for several approval processes, but only one or two are ready for migration.

Open a copy of the exported JAR using an appropriate archive utility. The archive normally contains a META-INF folder, multiple approval composite JAR files and CS_SOA_ExportList.txt.

[Screenshot Placeholder 11: Exported JAR containing multiple approval composite files. Keep the META-INF folder and composite filenames visible. Mask the local folder path.]

To prepare a selective migration:

1. Retain only the required composite JAR files.
2. Open META-INF/CS_SOA_ExportList.txt.
3. Retain only the entries matching the required composites.
4. Remove the unwanted composite entries.
5. Save the file and update it inside the archive.
6. Import the modified JAR into the target instance.

Important: This filtering works at the composite level. It cannot select one individual approval rule from within the same composite.

Common Mistakes to Avoid

• Importing between instances on different patch levels
• Exporting without reviewing unfinished approval changes
• Selecting the wrong source or target instance
• Assuming import success means functional testing is complete
• Assuming approval groups or security roles are automatically created
• Modifying the JAR filename or internal folder structure
• Forgetting to keep an untouched copy of the original export
• Attempting to isolate one rule when multiple rules belong to the same composite

Conclusion

SOA Composer provides a straightforward way to migrate Oracle Fusion approval-rule changes between instances.

For a complete migration, export the SOA changes from the source instance and import the same archive into the target instance. When only selected approval processes are required, filter the archive by retaining the required composites and their corresponding entries in CS_SOA_ExportList.txt.

Regardless of the approach, always confirm instance compatibility, review the export scope and perform transaction-level testing after the import.