Thursday, 24 July 2014

Identify Fix Pack\Feature Pack \ APARs in Websphere Commerce 7

Determining what APARs are installed on WebSphere Commerce

WebSphere Commerce keeps a history of installed APARs in the following locations: 


Check the NIFStack.xml file to see which APARs are currently installed.

Logs files for APAR  can be found in the following directories:

The group of APARs installed during a fix pack installation are shown in the "apars" section.
Another option is to use the historyInfo command. The historyInfo command shows fix pack and APAR history including installation and uninstallation for the WebSphere Commerce product. The historyInfo command is located in the WC_installdir/bin directory

Identify Fix Pack\Feature Pack in WCS 7

1)Fix Pack and feature pack level can be found using versioninfo.bat

Go to C:\IBM\WCDE_ENT70_New\bin folder and type  versioninfo.bat

2)Feature Pack\fix Pack details at component level is stored in SITE table.

This table is not one that Commerce itself uses a lot, but it does store the version and FixPack and Feature Pack information, so can be very useful if you somehow have a mismatch between the Commerce application and the Commerce database, or if you need to verify Commerce versions at the database level. It is not one you will generally update.

Column Name
Column Type
Reserved for IBM internal use.
Reserved for IBM internal use.
Reserved for IBM internal use.

Stagingprop utility in Websphere Commerce

The stagingprop utility propagates staged data and managed files from the production-ready data to the production server. It consolidates the changed data from the production-ready database, and then it propagates the necessary changed data into the production database if the connection is available.

The stagingprop utility retrieves all the unprocessed  records from STAGLOG table and processes them. An unprocessed STAGLOG is a record in the Staging database table where the column STGPROCESSED value is 0. Successful stagingprop updates these STAGLOG records in the STGPROCESSED column from unprocessed (0) to processed (1). The stagingprop utility has two stages: consolidation and a propagation. During consolidation, stageprop examines STAGLOG table and determines which STAGLOG records can be marked as processed without propagation.Processed STAGLOG records are then propagated to the production database.

For example If there is an INSERT Statement  followed by a DELETE and an INSERT then stage consolidation will eliminate the first two records and mark them as processed and propagation phase will propagate the final INSERT statement.

You can run stagingprop consolidation without propagation by omitting the following parameters: -destdb, -destdb_user, and -dest_passwd. If some of the parameters are supplied, or if the stagingprop utility cannot establish a connection to the production database with the parameters, the utility does not run successfully.

Tables Involved

This is the heart of stagingprop. In a basic discussion, the most important columns to be aware of are:

1.STGRFNBR – unique generated key for the table
2.STGSTMP –    the time stamp of the operation
3.STGOP –         the operation type (I=Insert, U=Update, D=Delete)
4.STGOKEY1, STGOKEY2, STGOKEY3, STGOKEY4, STGOKEY5 – the old value(s) of the primary key column(s)
5.STGNKEY1, STGNKEY2, STGNKEY3, STGNKEY4, STGNKEY5 - the new value(s) of the primary key column(s)
6.STGPROCESSED – flag indicating whether the row has been processed or not. 0=not processed, 1=processed

Staging Data can be divided in three types

STGSITETAB    - This table contains  the Site level Changes. E.g. Taxes or currencies.
STGMERTAB    - This table contains the store level(Merchant Level ) Changes.E.g.STORE and CATENTRY.
STGMRSTTAB -This table contains both Store and Site changes E.g. MEMBER table uses MEMBER_ID to decide if the record is SITE or Store.

For tables which contain both site and merchant data, insert into STGSITETAB, STGMERTAB, and STGMRSTTAB.

In all these tables (STGSITETAB, STGMERTAB, and STGMRSTTAB) there is a TABNBR Column which is the reference number of the table. The parent table must have a lower reference number than any child table.
Staging Triggers

For each table that is a part of staging prop, there are three triggers on that table. All are AFTER triggers. One each for INSERT, UPDATE, and DELETE. When one of those operations happens on the table, these triggers insert a row into the STAGLOG table for every affected row. The row inserted into the stag log table includes the table name, and the values and columns of the primary key of the row affected, along with the operation type (I, U, D).

Executing Stage Prop by running  the below utility

WC_installdir/bin/ <parameters and values>

Overview of staging Prop
As changes are made to the staging database, triggers on the tables being changed.The changes noted include the timestamp,the table being changed, the type of change, and the primary key of the row.
When is executed, it reads STAGLOG,STGMERTAB,STGSITETAB and STGMRSTTAB tables and based on those tables queries the staging database for the full data and inserts/updates/deletes data on production.Most staging prop tables are exactly identical on staging and production.

To stage custom tables, you should
Step 1: Add the custom table to the relevant table (STGSITETAB, STGMERTAB, and STGMRSTTAB) based on the scope.
Step 2: Create database triggers to record changes of custom tables to the STAGLOG table.
Create three triggers for the custom database table in the wcs.stage.trigger.sql file.
INSERT trigger to capture inserts operations on the custom table.
UPDATE trigger to capture update operation on the custom table.
DELETE trigger to capture deletes operations on the custom table.

Staging Server Utilities

The staging server has three utilities:
Staging Copy
Copies configuration data from the production database to the production-ready data on a staging server.
Staging Prop
Retrieves all the unprocessed STAGLOG records and propagates them to the production server.
File Prop
Propagates all changed files to the production server.

Buyable Flag \Published Flag for a Catalog Entry in Websphere Commerce

Buyable Flag is available in CATENTRY table   BUYABLE column. This flag indicates whether this Catalogentry can be purchased individually or not. I.e. whether we can add to cart this Catalog Entry or not.1=yes and 0=no

Published Flag  is available with  CATENTDESC table PUBLISHED column. Published flag means whether this Catalog Entry should be displayed for the language ID .0= Catalog Entry should not be displayed, 1= Catalog Entry should be displayed.