IBM Support

JR46230: SPLIT ACCESS CONTROL POLICY KEYS BETWEEN STAGING AND PRODUCTION ENVIRONMENT.

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Key collisions for access control policy tables during
    StagingProp propagation phase may occur if staging triggers for
    these tables are turned on and customers make access control
    policy changes directly in the production server. In
    V7, access control policy tables are not staged.  However,
    there are 2 situations in which these tables become staged: 1)
    customers may decide to customize them and make these tables
    staged; and 2) starting in V7 fix pack 6, publishing a store
    will temporary enable the staging triggers for the access
    control policy tables and disable them at the end of the process
    so that when StagingProp is run, it will propagate those access
    control policy changes together with the published stores data.
    
    Because the access control policy tables' primary keys are not
    split, updating the access control policy directly in
    production server may cause new records to be created with the
    same primary keys that are already used in the staging server by
    other records with different unique index.
    
    In order to avoid this issue, the keys for the access control
    policy tables should be split.
    

Local fix

  • Apply this APAR immediately and manually run the corresponding
    SQL to both Staging and Production databases to split the keys
    for the access control policy tables.
    After this APAR is installed,  2 SQL files will be created:
    
    1. <WCS>/schema/common/apar/wcs.acp.keys.lowrange.production.sql
    2. <WCS>/schema/common/apar/wcs.acp.keys.midrange.staging.sql
    
    Manually run wcs.acp.keys.lowrange.production.sql into the
    production database, and manually run
    wcs.acp.keys.midrange.staging.sql for staging database.  This
    will split the key for the access control policy tables.  For
    production databases, the keys will be in the lower range; for
    staging database,  the keys will be in the mid range.
    
    It is important to apply this APAR and run the SQLs before
    publishing a store in the staging server and before making any
    changes in the access control policies in production server.
    Once a key collision occurs,  it will be very difficult to
    correct.
    

Problem summary

  • USERS AFFECTED:
    
    WebSphere Commerce users on V7 fixpack 6 or fixpack 7 with both
    staging and production environments who plans to publish stores
    in staging  server and update access control policy in
    production server should apply this APAR
    
    
    PROBLEM ABSTRACT:
    Key collisions for access control policy tables may occur during
    the StagingProp utility's propagation phase if staging triggers
    for these tables are turned on and access control policy changes
    are made directly in the production server.
    
    
    BUSINESS IMPACT:
    
    Without applying this APAR, business users who publish stores
    and who update access control policies directly in production
    server may run into key collisions.
    
    RECOMMENDATION:
    
    All Commerce V7 customers on staging and production setup who
    may update access control policy directly in production should
    apply this APAR and run the SQLs to avoid key collision during
    StagingProp propagation.
    

Problem conclusion

  • Different key ranges should be used between the staging and
    production environments in order to avoid key collisions during
    staging propagation.
    
    This ifix splits the keys for the access control policy tables.
    The SQLs provided will split the out-of-the-box keys for these
    tables into their corresponding ranges so that any new records
    created will obtain a correct primary key in the right range and
    keys will not collide during StagingProp propagation.  The SQLs
    check the lowerbound and upperbound of their KEYS records so
    that only unmodified out-of-the-box access control policy tables
    keys are split.
    
    It is highly recommended all Commerce customer should apply this
    APAR.
    
    -------------------------------------------------------------
    The latest available maintenance information can be obtained
    from the Recommended Fixes for WebSphere Commerce technote:
    http://www.ibm.com/support/docview.wss?rs=3046&uid=swg21261296
    

Temporary fix

Comments

APAR Information

  • APAR number

    JR46230

  • Reported component name

    WC BUS EDITION

  • Reported component ID

    5724I3800

  • Reported release

    700

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    YesSpecatt / Pervasive

  • Submitted date

    2013-04-03

  • Closed date

    2013-05-31

  • Last modified date

    2015-05-01

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    WC BUS EDITION

  • Fixed component ID

    5724I3800

Applicable component levels

  • R700 PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSYSYL","label":"WebSphere Commerce Enterprise"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
01 May 2015