Increase Accelerator / Org Admin Console Inactivity Timeout

This change is to prevent frequent login timeouts and loss of work for the admin users in old style WC tools (Accelerator, Org Admin Console etc). In wc-server.xml, find and adjust the LoginTimeout value (in milliseconds). The following snippet has a timeout value of 90 days: 

<LoginTimeout enabled="true" name="Login Timeout">

      <Timeout display="false" value="7776000000"/>

</LoginTimeout>

To make the change for a runtime server environment:

1. Update the LoginTimeout field in your <instance>.xml file <WC_installdir>/instances/<instance_name>/xml/<instance>.xml

2. Propagate changes to your Commerce Configuration File 

<WC_installdir>/bin/config_ant.sh -DinstanceName=instance_name UpdateEAR

Sample locations from an iSeries box:

/QIBM/UserData/CommerceServer60/instances/[InstanceName]/xml/[InstanceName].xml

/QIBM/ProdData/CommerceServer60/bin/config_ant.sh -DinstanceName=[InstanceName] UpdateEAR

DB2 Backup And Restore

Backup

CONNECT TO WCDB USER user_name USING passwd
QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS
CONNECT RESET
BACKUP DATABASE WCDB USER user_name USING passwd TO "C:\backup\db" WITH 2 BUFFERS BUFFER 1024 PARALLELISM 1 WITHOUT PROMPTING
CONNECT TO WCDB USER user_name USING passwd
UNQUIESCE DATABASE
CONNECT RESET


Restore

CONNECT TO WCDB USER user_name USING passwd
QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS
CONNECT RESET
RESTORE DATABASE WCDB USER user_name SING passwd ROM "C:\backup\db" TAKEN AT 20121219113159 WITH 2 BUFFERS BUFFER 1024 PARALLELISM 1 WITHOUT PROMPTING
CONNECT TO WCDB USER user_nameUSING passwd
UNQUIESCE DATABASE
CONNECT RESET

Sample Troubleshooting Sequence From getData Tag To Search Profile

-- In ProductDescription_Data.jsp

<wcf:getData 
type="com.ibm.commerce.catalog.facade.datatypes.CatalogNavigationViewType"
var="catalogNavigationView"
expressionBuilder="getCatalogEntryViewAllWithoutAttachmentsByID"
varShowVerb="showCatalogNavigationView"
maxItems="1"
recordSetStartNumber="0">

<wcf:param name="UniqueID" value="${productId}"/>
<wcf:contextData name="storeId" data="${WCParam.storeId}" />
<wcf:contextData name="catalogId" data="${WCParam.catalogId}" />
</wcf:getData>

-- In get-data-config.xml this expression builder uses access profile IBM_Store_All

<expression-builder>
<name>getCatalogEntryViewAllWithoutAttachmentsByID</name>
<data-type-name>CatalogNavigationView</data-type-name>
<class>com.ibm.commerce.foundation.internal.client.taglib.util.UniqueIDsExpressionBuilder</class>
<method>formatExpression</method>
<param>
<name>template</name>
<value>/CatalogNavigationView[CatalogEntryView[(UniqueID=)]]</value>
</param>
<param>
<name>searchProfile</name>
<value>IBM_findCatalogEntryDetailsWithComponents</value>
</param>
<param>
<name>accessProfile</name>
<value>IBM_Store_All</value>
</param>
</expression-builder> 

-- In wc-component.xml this access profile is mapped to search profile IBM_findCatalogEntryAll (based on the logs this seems to be the search profile used, not IBM_findCatalogEntryDetailsWithComponents)

<_config:configgrouping name="AccessProfileToSearchProfileMapping">
<_config:property name="IBM_Store_Summary" value="IBM_findCatalogEntrySummary"/>
<_config:property name="IBM_Store_Details" value="IBM_findCatalogEntryDetails"/>
<_config:property name="IBM_Store_CatalogEntryAttachments" value="IBM_findCatalogEntryAttachments"/>
<_config:property name="IBM_Store_CatalogEntryDetailsWithAttachments" value="IBM_findCatalogEntryDetailsWithAttachments"/>
<_config:property name="IBM_Store_CatalogEntryDetailsWithComponentsAndAttachments" value="IBM_findCatalogEntryDetailsWithComponentsAndAttachments"/>
<_config:property name="IBM_Store_CatalogEntryDetailsWithMerchandisingAssociations" value="IBM_findCatalogEntryDetailsWithMerchandisingAssocDetails"/>
<_config:property name="IBM_Store_All" value="IBM_findCatalogEntryAll"/>
<_config:property name="IBM_Store_CatalogEntryPrice" value="IBM_findCatalogEntryPrice"/>
<_config:property name="IBM_Store_CatalogEntryPriceWithAttributes" value="IBM_findCatalogEntryPriceWithAttributes"/>
</_config:configgrouping>

-- In wc-search.xml this search profile is defined

<_config:profile extends="IBM_findCatalogEntryDetailsWithComponentsAndAttachments" name="IBM_findCatalogEntryAll">
<!--  The search profile used to fetch the details of associated catalog entries. -->
<_config:param name="catalogEntrySearchProfile" value="IBM_fetchRelatedCatalogEntryDetailedInfo"/>
<_config:result inherits="true">
<_config:filter classname="com.ibm.commerce.catalog.facade.server.services.search.metadata.SearchCatalogEntryMerchandisingAssocResultFilter"/>
</_config:result>
</_config:profile>

To use custom attribute usages customize:
com.ibm.commerce.catalog.facade.server.services.search.metadata.SearchCatalogEntryViewAttributesResultFilter

Log BOD XML For Troubleshooting

Enable logging for:
com.ibm.commerce.foundation.server.command.bod.BusinessObjectDocumentProcessor

Display/Retrieve store relationships involving a particular store

DB Query

select s1.identifier as store, s2.identifier as relatedstore, sr.name
from storeent s1, storeent s2, storerel s1_s2, streltyp sr
where s1.storeent_id=s1_s2.store_id
    and s2.storeent_id=s1_s2.relatedstore_id
    and (s1_s2.store_id=STORE_ID or s1_s2.relatedstore_id=STORE_ID)
    and store_id<>relatedstore_id
    and sr.streltyp_id=s1_s2.streltyp_id
;

WebSphere Commerce v7 SOLR Configuration Files

Configuration Files Used for Creating the SOLR Index

wc-dataimport-preprocess-aaa.xml

This file contains the create statement for the particular preprocess table, and a query for populating the data for this table.

Typically on the WC server. Sample location:
[IBM]/WebSphere/CommerceServer70/instances/myInstance/search/pre-processConfig/MC_10001/DB2/

wc-data-config.xml

This file contains queries for getting data from preprocess tables (and regular WC tables if necessary) to populate the index. The query results are mapped to SOLR fields in this file. 

Typically on the SOLR server. Sample location:

C:\WCSearch\search\searchInstance\search\solr\home\MC_10001\en_US\CatalogEntry\conf\

schema.xml

This file defines the SOLR field settings. Searchable, sortable SOLR fields are defined here. 

Typically on the SOLR server. Sample location:

C:\WCSearch\search\searchInstance\search\solr\home\MC_10001\en_US\CatalogEntry\conf\

solrconfig.xml

This is the main SOLR configuration file. 

Typically on the SOLR server. Sample location:

C:\WCSearch\search\searchInstance\search\solr\home\MC_10001\en_US\CatalogEntry\conf\

Configuration Files Used by WC to Interpret Index Data

wc-search.xml

This file contains the search profiles. Fields to sort by are defined here. 

Typically on the WC Server. Sample location: 

[SOLR EAR]/xml/config/com.ibm.commerce.catalog-ext/

Highlights

• Facet configuration including facet sort (index vs count), facet count upper and lower limits, facet data converters.
• Config profiles (IBM_findCatalogEntryByNameAndShortDescription), fields that are searched (name, shortDescription, defaultSearch), expression providers (SolrSearchByKeywordExpressionProvider).

wc-business-object-mediator.xml

This file has the mapping from SOLR fields to WC fields (usually user data fields are used). 

Typically on the WC Server. Sample location: 

[SOLR EAR]/xml/config/com.ibm.commerce.catalog-ext/

Additional Reference Information

Sample SOLR log location (on the SOLR server)

[IBM]/WebSphere/AppServer/profiles/myProfile_solr/logs/solrServer/

Sample preprocessing command (run on the WC server)

[IBM]/WebSphere/CommerceServer70/bin/di-preprocess.sh [IBM]/WebSphere/CommerceServer70/instances/myInstance/search/pre-processConfig/MC_10001/DB2 -instance myInstance -dbuser dbUserName -dbuserpwd dbPassword -localename en_US -onelevel false -fullbuild true -multithread true

Sample indexing command (run on the WC server)

[IBM]/WebSphere/CommerceServer70/bin/di-buildindex.sh -instance myInstance -masterCatalogId 10001 -indextype CatalogEntry -dbuser dbUserName -dbuserpwd dbPassword -fullbuild true -localename en_US

Resetting the Password of wcsadmin

A frequent problem I encounter working with WC projects is that I get a new virtual machine for a project and the password for user wcsadmin is set to a value that I don't know. It is often easier to just reset the password then find someone who actually knows the password. Plus, the password reset methods can be used in different situations where you want to change the password of any user to a value you know.

1. Use the wcs_password script
If you know the merchant key of the environment where you are changing the password, you can simply pick the password you want, a random salt value and call the wcs_password script to find the encrypted password:
wcs_password new_password new_salt merchant_key

for example:
wcs_password passw0rd qwertyasdfgh 1a1a1a1a1a1a1a1a

Once you get the encrypted value you need to update the userreg entry for your user with these password and salt values.

If the account you are changing password is already locked, you will also need to unlock it by updating the following values:
USERREG.STATUS=1
USERREG.PASSWORDEXPIRED=0
USERREG.TIMEOUT=-1
USERREG.PASSWORDRETRIES=0
USERREG.PASSWORDINVALID=null

This is also detailed in the following IBM infocenter page:
http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=/com.ibm.commerce.admin.doc/tasks/tseresetwcsadminaccountruntime.htm

2. Reset the password to wcsadmin if you are using the default merchant key
This will work only if you are using the default merchant key. Use the queries for your DB type in the following IBM infocenter page to reset your password to wcsadmin:
http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=/com.ibm.commerce.admin.doc/tasks/tseresetwcsadminaccount.htm

3. If your environment is not using the default merchant key and if you don't know the merchant key in use, you cannot use the above methods. One workaround in this case is to have a user user2 whose password you know, and copy user2's password to the problem user user1.

If there is no user whose password in the environment, you can go to the storefront and register a new user. Store customers and admin users have their passwords encrypted the same way.

Query to do this update between problem user (user1) and user whose password you know (user2) is below:

update USERREG set LOGONPASSWORD=(select LOGONPASSWORD from USERREG where LOGONID='user2'), SALT=(select SALT from USERREG where LOGONID='user2') WHERE LOGONID='user1';

After this update, you can sign in as user1 using user2's password.