Cleaning Up WebSphere Commerce Databases




In the IBM Rochester lab, the Business Solutions Test (BST) team has implemented IBM's WebSphere Commerce in several of its customer-like scenarios. While doing so, the BST team discovered the importance of the Clean WCS Database (CLNWCSDB) command. Here, I'll explain how to use the command for both WebSphere Commerce Suite Version 5.1 (WCS V5.1) and WebSphere Commerce Version V5.4.

Cleaning up unnecessary data in a WebSphere Commerce site can improve performance, decrease the amount of storage needed to host the WebSphere Commerce site, and decrease the amount of time required to do future upgrades and migrations. A number of different tables can be cleaned up, and this cleanup can be done on an individual basis, depending on the needs of the site. If rows need to be deleted from a WebSphere Commerce database, it is important to use the CLNWCSDB command in order to properly handle constraints. 

CLNWCSDB works in conjunction with the WebSphere Commerce CLEANCONF table, and this table should be referenced when using the command to ensure proper results. Each entry in the CLEANCONF table refers to a specific table in the WebSphere Commerce database and the criteria in which to clean up that table.

CLNWCSDB has slightly different parameter names between WCS V5.1 and WebSphere Commerce V5.4:
  • DATABASE: The name of the relational database on which the WCS V5.1 data exists (commonly the iSeries system name)
  • COLLNAME (WCS V5.1) or SCHEMA (WebSphere Commerce V5.4): The name of the schema (which is normally the same name as the instance name)
  • PASSWD: The password to the schema
  • DBTABLE (WCS V5.1) or OBJECT (WebSphere Commerce V5.4): The name of the table to clean up. The name must be in single quotes and should be typed in the same case as the column TABNAME in the CLEANCONF table (typically lowercase).
  • TYPE: The type of object that needs to be deleted. Object types can be found in the CLEANCONF table under the column TYPE. The name must be in single quotes and should be typed in the same case as the column TYPE in the CLEANCONF table (typically lowercase).
  • STATUS: The order status of the record that needs to be deleted, in single quotes. The STATUS parameter is only valid if DBTABLE = orders.
  • LOGLEVEL: The level of logging that takes place during the deletion process. A 0 indicates no logging. Level 1 records delete statements for the specified table. Level 2 records delete statements for the specified table and any child tables as well.
  • NAME: The name of the organization to be deleted, in single quotes. A value for NAME is required if MEMBER was indicated for the DBTABLE/OBJECT keyword and ORGANIZATION was indicated for the TYPE keyword.
  • FORCE: The deletion force option. *YES indicates child tables to be cleaned first; *NO allows constraints to cascade delete from child tables.
  • CHECKONLY: The check only option. *YES will check child tables and delete restricts only. *NO will perform the cleanup.
  • DAYS: The minimum age (in days) of the database entry to be deleted. The DAYS parameter is valid only if the DAYSARG column in the CLEANCONF table is set to yes.
  • LOG: The default location for the log file is/QIBM/UserData/CommerceSuite5/instances/DBCLEAN_
    instance_name_YYYY.MM.DD_HH.MM.SS.ZZZ.LOG, where instance_name is the name of the WCS instance. If the log produced should have a different name and location, you can specify it here.

For example, to clean up all obsolete addresses over six months (180 days) old, run CLNWCSDB with these parameters:

For WCS V5.1: CLNWCSDB DATABASE(relational database name) COLLNAME(schema name) PASSWD(schema password) DBTABLE('address') TYPE('obsolete') DAYS(180)

For WebSphere Commerce V5.4: CLNWCSDB DATABASE(relational database name) SCHEMA(schema name) PASSWD(schema password) OBJECT('address') TYPE('obsolete') DAYS(180)

The CLEANCONF table contains information necessary to run the CLNWCSDB command. Each row in the CLEANCONF table contains the following information:
  • TABNAME (WCS V5.1) or OBJECTNAME (WebSphere Commerce V5.4): The name of the table where entries should be deleted
  • TYPE: The identifier of the type of entry to delete
  • CONDITION (WCS V5.1) or STATEMENT (WebSphere Commerce V5.4): The condition under which all qualifying entries will be deleted
  • NAMEARG: Yes indicates a name parameter in CONDITION, and no indicates no such parameter.
  • DAYSARG: Yes indicates a days parameter in CONDITION, and no indicates no such parameter.
  • SEQUENCE (WebSphere Commerce V5.4 only): Sequence number if more than one SQL statement is required to clean the WebSphere Commerce object.

The CLEANCONF table comes with many default entries for database cleanup. However, you can create your own entries in the CLEANCONF table to define new criteria for data to clean up. To define new types of data, enter rows in the CLEANCONF table that follow the previous guidelines.

These examples illustrate how you can create entries in the CLEANCONF table to specify data to delete. These two examples clean up pending orders and payment initiated orders, respectively.

Example 1: Delete pending orders that have not been updated within a specified time period
TABNAME (WCS V5.1) or OBJECTNAME (WebSphere Commerce V5.4) = orders
TYPE = pending_order
CONDITION (WCS V5.1) or STATEMENT (WebSphere Commerce V5.4) = where status = 'P' and (days(CURRENT TIMESTAMP) - days(lastupdate)) >= ?
NAMEARG = no
DAYSARG = yes
STATEMENT = null

Example 2: Delete all orders where payment has been initiated and authorization is pending
TABNAME (WCS V5.1) or OBJECTNAME (WebSphere Commerce V5.4) = orders
TYPE = payment_init
CONDITION (In WCS V5.1) or STATEMENT (In WebSphere Commerce V5.4) = where status = 'M'
NAMEARG = no
DAYSARG = no
STATEMENT = null

In the first example, the column STATUS in the ORDERS table is used to specify the criteria to delete entries. Also, the second clause of the condition, (days(CURRENT TIMESTAMP) - days(lastupdate)) >= ?, indicates that the age of the entry in days needs to be specified to delete the entry. Because of this, the DAYSARG is set to yes so a number of days can be specified in the CLNWCSDB command. 

In the second example, again the column STATUS in the ORDERS table is used to specify the condition to delete entries. If compared to example 1, notice the days part of the condition is removed, and DAYSARG is set to no. This indicates that all entries in the orders tables where STATUS = 'M' will be removed, and the days parameter is not used in the CLNWCSDB command.

This is how to use CLNWCSDB with these two examples:

Example 1
WCS V5.1: CLNWCSDB DATABASE(relational database name) COLLNAME(schema name) PASSWD(schema password) DBTABLE('orders') TYPE('pending_order') DAYS(30)

WebSphere Commerce V5.4: CLNWCSDB DATABASE(relational database name) SCHEMA(schema name) PASSWD(schema password) OBJECT('orders') TYPE('pending_order') DAYS(30)

Example 2
WCS V5.1: CLNWCSDB DATABASE(relational database name) COLLNAME(schema name) PASSWD(schema password) DBTABLE('orders') TYPE('payment_init')

WebSphere Commerce V5.4: CLNWCSDB DATABASE(relational database name) SCHEMA(schema name) PASSWD(schema password) OBJECT('orders') TYPE('payment_init')

Comments

Post a Comment

Popular posts from this blog

Dataload Utility In WCS

Data can be loaded into WCS tables using data load utility.   WCS Data Load utility performs the following functions in a single operation: 1.              Reads the data from the input source file. 2.              Transforms the source data to WebSphere Commerce business objects. 3.              Allocates and resolves WebSphere Commerce business objects to physical data. 4.              Loads the physical data into the database. There are three configurations files and a input source file required to complete the data loader setup. WCS supports only CSV File Reader for other input source you have to write your own Reader Class. This means that if you are using OOB CSVReader then your input file must be a CSV file. The three configuration files are listed below. 1.              wc-dataload-env.xml 2.              wc-dataload-loader.xml 3.              wc-dataload.xml wc-dataload-env.xml holds the environment settings such as database name,encrypted password,data
Read more

10 Steps to Configure Email – Websphere Commerce Server

10 Steps to Configure Email – Websphere Commerce Server Websphere Commerce Server – Configure Email Follow 10 steps for configuring email in Websphere Commerce Server Step 1: Create a JSP ( eg:- AbcEmailNotify.jsp) Create a JSP, lets name it AbcEmailNotify.jsp AbcEmailNotify.jsp will be used for displaying contents of email to recipient. Note: Currently keep AbcEmailNotify.jsp as blank (without any code) Step 2: Create View ( eg- AbcEmailNotifyView) Make an Entry in Struts-Config.xml file for AbcEmailNotify.jsp as below < action path=’/AbcEmailNotifyView’ type=’com.ibm.commerce.struts.BaseAction’> < set-property property =’authenticate’ value =’10101:1′/> < set-property property =’https’ value =’10101:1′/> < /action> < forward name=”AbcEmailNotifyView /10101/-3″ path=”/< location of JSP file >/AbcEmailNotify.jsp” className=”com.ibm.commerce.struts.ECActionForward”> < set-property property=”implClassName” value=”com.i
Read more

WebSphere Commerce

Image
1. Explain WCS Archetecture WebSphere Commerce functional architecture Descriptions: Controller layer The conductor of operations for a request. It controls the transaction scope and manages the session related information for the request. The controller first dispatches to a command and then calls the appropriate view processing logic to render the response. Presentation layer The presentation layer displays the result of command execution. The presentation layer can use JSP pages, or other rendering technologies. Business Context Service (BCS) A service that manages contextual information used by business components. The contexts include such information as globalization and entitlement. Business logic facade This generic interface is implemented as a stateless session bean which the controller calls to invoke controller commands. Controller commands A controller command business process logic such as
Read more