Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Renaming classes or rulesets during an archive import

Updated on April 5, 2022

Use the Refactor on Import wizard to rename classes or rulesets in an archive as it is imported. This allows you to integrate the imported structure into the existing hierarchy on your system. The Refactor on Import wizard supports merging RuleSets developed by Pegasystems or others into your PegaRULES database.

The Refactor on Import wizard displays a listing of the classes in the archive and allows you to specify the names of classes to replace the top-level and Data- classes for rules contained in the archive. On import, the rules contained in the *.jar or *.zip file, are read into memory, renamed with your specified changes, and then copied to the Pega Platform database. The import archive is not modified. Errors are reported on rules that will not validate when saved, but all rules are saved to the database.

  1. In the header of Dev Studio, click ConfigureSystemRefactorRules.
  2. Click Refactor on import.
  3. Select a file to import:
    • If the file already exists in the server ServiceExport directory, click Next.
    • To upload a new file, click Choose file and follow the prompts.
  4. Select the name of the file you want to import, and click Next.
  5. Specify new class names and optional new ruleset names to apply to each class or ruleset as they are imported and then click Next.
    Note: If the archive contains a product rule, the Refactor on Import wizard looks for a previous import of the same Rule-Admin-Product name. If there is a previous import with the same name, the wizard displays the refactor parameters used in the previous import as the default values for the current import.
  6. Verify that the changes are accurate and click Next.
    Click ExportToExcel to create a detailed list of the rules that will be changed. You can use the spreadsheet to evaluate the effects of renaming the class before beginning the processing.
  7. Click Next.
  8. Select additional rules to be changed. If the archive includes rules that the system cannot clearly identify as a class or ruleset name, you see a list of additional rules to be changed. The check box at the top of the column only selects the instances on the current page.
    Note: For example, the name may be embedded in a Java class name, a URL string, or some other property. These may be incidental occurrences of the class name that you do not wish to change. For example, if you had used your organization name for the original class name, you might want to keep the name where it appears in strings displayed in the user interface.
  9. Optional: To review the additional rules outside the wizard, click Export To Excel to create a spreadsheet of the currently displayed page or Export All To Excel to create a spreadsheet of the entire report.
  10. Review the list of all rule instances that you selected to be refactored that could not be changed successfully. Hover over the error message in the Status column for more details on the error. To review the status for all rules outside the wizard, click Export All To Excel.
  11. Click Finish.
Result: Each use of this wizard is recorded in an instance of the Log-Refactor class, with a key identifying the date and time of the use.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us