More about the Import and Export gadgets

To access these tools, select

• > Application > Import & Export > Export — To copy rules and data instances from the PegaRULES database to create a Zip archive file on the server. BYRNB 2/25/10
• > System > Tools > Migrate Product — To create a product rule that packages work objects. BYRNB 2/25/10
• > Application > Import & Export > Import — To upload rules and data instances in a previously exported ZIP file into the PegaRULES database of the destination Process Commander system. BYRNB 2/25/10

See A checklist for product migration.

Select this option on a source Process Commander system, the one that contains the rules to be extracted. Use the Export Rules link to create a ZIP file containing all the rules in a RuleSet.

See Help — Export gadget.

Don't create a ZIP archive when any of the rules designated for the archive are checked out. An error is reported identifying the checked-out rule or rules. Neither the original version nor the checked-out version of the rule is included in the ZIP archive. C-1118

Use this option to import rules and data instances from ZIP file into a destination Process Commander system.

If you import rules in a RuleSet version that some users already can access, they may begin executing them immediately, possibly before other rules in the same ZIP archive are present. This may be desirable and intended, or not intended. Similarly, declarative rules begin executing for such users immediately; declarative rules may fail if not all the elements or properties they reference are uploaded yet. CLINIC 3/05 also B-12115.

By default, you can't upload a ZIP file larger than 25MB to the server from your desktop with the Import gadget. This is a limitation on the upload operation, not on the import itself. Use FTP or another means to place the ZIP archive into the ServiceExport directory on the server, or change the limit through a prconfig.xml file setting. See Limits and maximums.

The property @baseclass.pxMoveImportDateTime records the date and time that a rule (or other instance) was imported from a ZIP archive. CLINIC 9/27/07 You can report on this property (for one rule type such as properties or flows) on when the rules moved into a system.

See Help — Import gadget

You can use these tools to copy a product or RuleSet from one Process Commander system to another. (Also called migrating or moving, this procedure doesn't alter or delete the source rules.)

For example, you can move a product from a smaller development or test Process Commander system into a production Process Commander system. The source and destination systems may have different servers, operating systems, database vendors, Web server software vendors and so on. Information inside the ZIP file consists entirely of XML documents in Unicode characters.

1. Confirm that you have a working Operator ID with a PegaRULES:SysAdm4 access role on both the source system and destination system.
2. Confirm that the Process Commander version number of the destination system is not less than the version number of the source system. Don't attempt to move a RuleSet created in version 05-01-06 into a system based on version 04-02-01.
3. Review the RuleSets version rules to be included. Note the prerequisite RuleSets and versions they reference. If moving more than one RuleSet, note whether and how they are interdependent.
4. On the destination system, access the Rules Explorer. Confirm that the destination system includes all the prerequisite RuleSets and versions needed.
5. On the source system, create a product rule or product patch rule.
6. On the source system, examine the checked out rules display. Confirm that none of the rules to be migrated is checked out. Select >Application > Development > Checked Out Rules.
7. On the source system, use Rules per RuleSet, Version, report to estimate a count of rules to be included in the ZIP archive. The reports show only up to 10,000 rules. The ZIP archive may contain more than 10,000 instances. Select > Process and Rules > Tools > Find Rules > Rules by RuleSet, Version...
8. Export the ZIP archive.
9. Copy the ZIP archive to the destination system.
10. On the destination system, import the ZIP archive.
11. Adjust your access group as necessary to provide access to the uploaded RuleSets and versions.
12. Log off, then log in with the updated access group, and review the uploaded results. If they are satisfactory, this may be a good moment to lock the imported RuleSets and versions.
13. Consider whether a new class group and work type structure is appropriate for deployment of the application. See How to replicate a class group and class structure.
14. In a multinode system, the lookup list cache (and in some cases the compiled libraries) may be stale on nodes other than the node on which you run the Import gadget. As a good practice, recompile the libraries and delete the lookup list cache on each of the other nodes. CLINIC 2/24/07

As it runs, the Export gadget stores information about its operation as instances of the Log-PegaRULESMove class. The tool logs errors as instances of the Log-PegaRULESMove-Error class. Use the Class Explorer or the standard LookupList list view rule to review the instances of these two classes.

You must hold the @baseclass.zipMoveExport privilege to use the Export gadget. BUG-25879 You must hold the @baseclass.zipMoveImport privilege to use the Import gadget.

A ZIP archive contains JAR files. The ZIP archives are endian-independent and platform-independent.

When you create a ZIP archive containing a RuleSet version, any blocked rules associated with that RuleSet Version are included in the archive (and remain blocked when uploaded into on a destination system). CLINIC 7/2/07 On a destination system, a blocked rule can in some cases block a different set of other rules than it blocked on the source system.

In releases before V5.3, the Import archive operation prevented import of rules belong to a RuleSet Version that was locked on the destination system. This restriction is removed.