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.

Issue: Results of importing a ZIP archive depend on the order of Data- classes in the Product form

Updated on November 29, 2005

Symptom

A developer asks:

We imported a product ZIP archive that includes data table instances intended to end up in a custom table (as mapped by a Data-Admin-DB-Table instance that is included in the ZIP archive). 

But some of the data instances end up in database table pc_other and some in the correct table. We suspect that this is caused by an ordering issue during the import.   Should the import of the ZIP archive process the Data-Admin-DB-Table instance before it processes other items in the archive?

Update: This issue is resolved in V4.2SP5 and later. (B-16717)

Solution

Explanation

Investigation shows that there are two ways to cause the above problem of loss of data:

  • A Rule-Admin-Product ZIP archive that contains only Data instances, including a Data-Admin-DB-Table instance.

Why? Process Commander recognizes a Class to Database mapping only if, during import, Data-Admin-DB-Table instances are saved and committed to the database . The Import Archive tool uses a transaction model that commits to the database only after every 100 records are processed and saved.

  • Defining Data-Admin-DB-Table and Data-Admin-DB-Name instances in the QUERY DATA INSTANCES TO INCLUDE section of the Product form..

Why? The ZIP archive processing expects Data-Admin-DB-* instances to be specified in the DATA INSTANCES TO INCLUDE section, not in the QUERY DATA INSTANCES TO INCLUDE section. When Data-Admin-DB-* instances are defined in the former section, the zip file is built such that these records are loaded first when a Product ZIP archive is imported into a target system. But when they are defined in the QUERY DATA INSTANCES TO INCLUDE section, then there is no guarantee of when they are loaded, which could lead to a loss of data as you experienced.

Workaround

Use either of these two workarounds:

  • Use two product rules. In the first product rule, includes the Data-Admin-DB-* instances. In the second product rule, include the rest of the data and rule instances. When importing the two ZIP archives, load the Data-Admin-DB-* instances first.
  • If the product definition includes any rules, define Data-Admin-DB-* records in the DATA INSTANCES TO INCLUDE section and use When rules to limit the list of instances that get exported.  This approach takes advantage of the fact that, during import, any Rule-RuleSet-Name and RuleSet-Version rules encountered force an immediate Commit to the PegaRULES database. Since Data-Admin-DB-* instances are imported before RuleSet-Name and RuleSet-Version rules, the Data-Admin-DB-* instances will be available when the import processing tries to look for a class mapping.

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.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us