Stagingprop utility fails when propagating access control policy data

When you run the stagingprop utility to publish a store from the staging instance to the production instance, the utility fails when propagating access control policy data.

Problem

The problem occurs if you created a staging instance on the following versions of WebSphere Commerce:
  • WebSphere Commerce Version 8 Fix Pack 8 (8.0.0.8) or earlier
  • WebSphere Commerce Version 8 Mod Pack 1 (8.0.1.0)
WebSphere Commerce's instance creation splits the keys for the access control policy tables based on the type of instance:
  • For staging instances, the generated keys are restricted to the middle and upper range of values
  • For production instances, the generated keys are restricted to the lower range of values
This key splitting causes the bootstrap access control policy data to have different primary keys in the staging instance than in the production instance. During store publish, new access control policy data is created but these store access control policies have references to the bootstrap access control policies from instance creation. When the stagingprop utility is run, the utility fails because the store's access control policies are pointing to the parent bootstrap access control policies which have different primary keys in production than in staging.

This issue was reported in APAR JR55762.

Solution

  1. Run the following SQL statements on your staging database and production database to verify whether the primary keys for some access control policies are synchronized.
    select min(acpolicy_id), max(acpolicy_id) from acpolicy;
select policyname from acpolicy where acpolicy_id in (select min(acpolicy_id) from acpolicy);
select policyname from acpolicy where acpolicy_id in (select max(acpolicy_id) from acpolicy);

select min(acaction_id), max(acaction_id) from acaction;
select action from acaction where acaction_id in (select min(acaction_id ) from acaction );
select action from acaction where acaction_id in (select max(acaction_id ) from acaction );
  2. Compare the results. If the results are in completely different ranges, then you need run the following script fixes to replace the access control policy data that is on the production instance with the data from the staging instance. You need to complete this step only once. Future executions of the stagingprop utility will not generate propagation errors.
    Note: This procedure overwrites any custom access control policies that you might have on your production instance. If needed, back up your custom policies and then reload the custom policies after you run the script fixes.
    1. Install one of the following maintenance packages:
      • Version 8 Fix Pack 9 or later (8.0.0.9+)
      • Version 8 Mod Pack 1 Fix Pack 1 or later (8.0.1.1+) or any later mod pack.
      To download a maintenance package, see List of available maintenance packages.
    2. On the staging instance, run the stagingprop utility with the 'actionOnError' parameter set to 1. For example,
      stagingprop.bat -actionOnError 1 -sourcedb staging_db_name 
-destdb production_db_name -dbtype db2 -sourcedb_user user
-sourcedb_passwd password -destdb_user user 
-destdb_passwd password
      For more information about how to run the stagingprop utility, see stagingprop utility.
    3. Export the access control policy data from the staging instance by completing the following steps. (A new acpExport utility is included in 8.0.0.9+ and 8.0.1.1+).
      1. Go to the WC_installdir/bin directory.
      2. Open the acpExport utility in a text editor.
        • DB2WindowsacpExport.db2.bat
        • WindowsOracleacpExport.oracle.bat
        • LinuxAIXDB2For IBM i OS operating systemacpExport.db2.sh
        • LinuxAIXOracleacpExport.oracle.sh
      3. Edit the values to reflect your database credentials.
      4. Save and close the file.
      5. Run the acpExport utility to generate the export files.
        • DB2WindowsacpExport.db2.bat <dbpassword>
        • WindowsOracleacpExport.oracle.bat <dbpassword>
        • LinuxAIXDB2For IBM i OS operating system./acpExport.db2.sh <dbpassword>
        • LinuxAIXOracle./acpExport.oracle.sh <dbpassword>
    4. On the production instance, replace the current access control policies data with the exported policies (A new acpImport utility is included in 8.0.0.9+ and 8.0.1.1+).
      1. Open the acpImport utility in a text editor.
        • DB2WindowsacpImport.db2.bat
        • WindowsOracleacpImport.oracle.bat
        • LinuxAIXDB2For IBM i OS operating systemacpImport.db2.sh
        • LinuxAIXOracleacpImport.oracle.sh
      2. Edit the values to reflect your database credentials.
      3. Save and close the file.
      4. Run the acpImport utility to replace the access control policy data that is on your production environment with the data from the staging environment.
        Note: This utility deletes the access control policy data that is currently on your production environment.
        • DB2WindowsacpImport.db2.bat <dbpassword>
        • WindowsOracleacpImport.oracle.bat <dbpassword>
        • LinuxAIXDB2For IBM i OS operating system./acpImport.db2.sh <dbpassword>
        • LinuxAIXOracle./acpImport.oracle.sh <dbpassword>
        Note: If you are using a remote database, then manually copy the exported files to your production environment.
      5. Reload any custom access control policies. That is, rerun the acpload, acpnlsload, or acugload utilities for your custom policies as needed.
    5. Continue with the store publish process.