Access control policies
Problem: New extended site store was created / published on staging environment but the out of the box store policies did not propagate through to the production.
Resolution: The default access control policies have to be manually loaded to the production environment. The steps below describe how to load the ACP.
- Extract the accesscontrol.xml file from the store archive file that you want the policies to be loaded for. For example, if you have published Madisions.sar under the ExtendedSites, then extract the accesscontrol.xml from the path in the SAR
/WEB-INF/stores/StoreAssetsDir/data/accesscontrol.xml
- Edit the accesscontrol.xml file extracted in the above step to make it a valid XML file. Add the following at the top of the file (as first three lines)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE import SYSTEM "../../../schema/xml/wcs.dtd">
<import>
And then close the import tag at the end of the file
</import>
- In the XML, replace all the references of "&STORE_IDENTIFIER_RPS; with the name of your store. For example, Madisons (ie. refer to the STOREENT.IDENTIFIER field in the database for this value).
For example, replace "&STORE_IDENTIFIER_RPS;” with MadisonStorefrontAssetStore
<acpolgrp acpolgrp_id="@acpolgrp_id_1" name="&STORE_IDENTIFIER_RPS; PolicyGroup" member_id="@profile_mbr_id"/>
<acpolgrp acpolgrp_id="@acpolgrp_id_1" name="MadisonStorefrontAssetStore PolicyGroup" member_id="@profile_mbr_id"/>
- Replace all occurrences of "@profile_mbr_id" with the member id who owns the store (please check storeent.member_id for details)
<acpolgrp acpolgrp_id="@acpolgrp_id_1" name="&STORE_IDENTIFIER_RPS; PolicyGroup" member_id="@profile_mbr_id"/>
Replace with
<acpolgrp acpolgrp_id="@acpolgrp_id_1" name="&STORE_IDENTIFIER_RPS; PolicyGroup" member_id="7000000000000000001"/>
- Replace all occurrences of @profile_orgentity_id with the same value as above
<acpolgrp acpolgrp_id="@acpolgrp_id_1" name="MadisonsStorefrontAssetStore PolicyGroup" member_id="@profile_orgentity_id"/>
<acpolgrp acpolgrp_id="@acpolgrp_id_1" name="MadisonsStorefrontAssetStore PolicyGroup" member_id="7000000000000000001"/>
- Once the changes to the xml are completed, copy the xml to the following folder location on the target environment where policies have to be loaded.
<<WC_Install_Dir>>/xml/policies/xml
- Run the idresgen command to resolve ID’s. Ensure that you run the idresgen on the target database (production in this case). The syntax of the idresgen is as below
idresgen.cmd -dbname <<name>> -dbuser <<user>> -dbpwd <<pwd>> -infile <<infilepath>> -outfile <<outfilepath>> -method mixed -schemaname <<schemaname>>
replace
<<name>> with database name,
<<user>> with the websphere commerce database user
<<pwd>> with the database password
<<infilepath>> is the file path. For example, E:\IBM\Commerce\xml\policies\xml\accesscontrol.xml
<<outfilepath>> is the output file path. This is the output file that is generated after running the idresgen command
<<schemaname>> is the database schema name which if left out will default to the –dbuser parameter.
- The idresgen command above will generate a XML file by resolving the primary keys for the entities in the input xml. To keep the production database exactly same as the staging one, we need to modify the xml output of the idresgen utility and replace all ID’s with that of the staging environment.
- After the above step is complete, run the massload utility to actually load the access control policies for the new store.
massload.cmd -dbname <<nameofdb>> -dbuser <<user>> -dbpwd <<passwd>> -infile <<resolvedxmlFilePath>> -method sqlimport -commitcount 200 -schemaname <<schemaname>>
nameofdb – Name of the Database
user – Database user
passwd – database password
resolvedxmlFilePath – complete path to the resolved XML File
This resolved the access control issue on production environment for default out of the box store policies.
