Setting webcontainer custom properties in WAS

1. In the administrative console, click "Servers" and under Servers click "Server Types" and under Server Types click "WebSphere application servers"
2. Click on the server to which the custom property is to be applied
3. Under "Configuration" and "Container settings" click "Web Container Settings" and under Web Container Settings click "Web container"
4. Under "Configuration" and "Additional Properties" click "Custom Properties"
5. In the Custom Properties page, click "New"
6. In the settings page, enter the name of the custom property to be added in the "Name" field and the value to be set for the custom property in the "Value" field. Note that some properties are case sensitive.
7. Click "Apply" or "OK"
8. Click "Save" in the "Messages" box that appears
9. Restart the server for the custom property to take effect

Forgot password and cannot access WAS administrative console

There are 2 possible methods for disabling security

By way of wsadmin command: Server must be stoped

Method : 1

1. <WAS_INSTALL_DIR>/bin/> wsadmin -conntype NONE
2. wsadmin> securityoff
3. wsadmin> exit
4. Restart the servers.
5. Enable the security from administrative console.
6. Restart the servers.
Method : 2

By way of manual edit of security.xml file: /opt/IBM/WebSphere/AppServer/profiles/profile_name/config/cells/cell/security.xml

1. Create a copy for security.xml file, in case you need to roll back.
2. Disable the security from the security.xml file (change the very first occurrence of... enabled="true" to enabled="false")
3. Restart the servers.
4. Enable the security from administrative console.
5. Restart the servers.

How to find enabled WebSphere Commerce features

You can list the features that have been enabled on WebSphere Commerce.

1. Navigate to the following directory
    
    WCSDIR/bin

2. Run the check enablement status script
    
   checkEnablementStatus.bat


3. Confirm the feature enablement status from the following location.

   WCSDIR/logs\enableFeature.log



Sample Screen

How WCS selects the correct price from OFFER table?

Offers for catalog entries are stored in the OFFER table. When setting pricing for catalog entries, WC uses specific criteria to find valid offers from the OFFER table and then select the correct price.

To set the price for a catalog entry, WC must first determine all the valid offers for each applicable price list. To be valid, the offer must meet the following criteria according to data in the OFFER table: 

1. The offer must be published, that is, the PUBLISHED value must be 1.
2. The quantity of the catalog entry being purchased must be within the MINIMUMQUANTITY and MAXIMUMQUANTITY values for the offer.
3. The purchase date must be within the defined STARDATE and ENDDATE values for the offer.

If you load pricing data into WC using the data loader utility or SQL statements, it is possible to have more than one valid offer for a catalog entry. If there is more than one valid offer, WC sets the price using the offer with the highest value in the PRECEDENCE column of the OFFER table. If multiple offers exist with that same highest precedence value, the offer with the lowest price is used.

Price rules and offer price selection

If your store uses price rules for storefront pricing, the price rule also retrieves offers from the OFFER table, but then the price rule might perform additional calculations on the offer price.

In this price rule, the Get Price from Price List action retrieves the offer from the OFFER table and then performs the mark down and rounding on the offer price. To evaluate and select the correct offer to retrieve from the OFFER table, WC uses the same criteria described earlier in this topic.

Solr concept and Architecture

Conceptually, the Solr can be divided into four blocks:

    Mode (schema.xml)
    Configuration (the solrconfig.xml)
    Index
    Search

A Document contains one or more Field, A Field by name, content, and content approach of metadata. Analysis of the content to be searched. Analysis is completed by a Tokenizer and zero or more TokenFilter link to the Tokenizer to the input stream split into words (tags) TokenFilter can change (for example, stem) or remove the tag . Solr schema can easily configure the code analysis process. It also provides a more powerful type of feature that allows you to Field specific designated as String, int, float, or other type of original or custom.

Solr schema for the index is defined in schema.xml. it contains field type definitions within  the <types> element and the index's fields within <fields> elements. you may also notice <copyField> element, which copy an input field as provided to another field.

1. Schema design decisions in which you map your source data to document limited structure.
2. The structure of the schema.XML file where the schema definition is defined. Within this file are both the definition of field types and the fields of those types that store your data.
3. Text analysis—the configuration of how text is processed (tokenized and so on) for indexing. This configuration affects whether or not a particular search is going to match a particular document.

In the configuration, the solrconfig.xml file specified not only Solr how to deal with the index, highlight, classify, search, and other requests, and also specifies the properties used to specify the cache approach, and used to specify the method of the Lucene index properties . Configuration depends on the model, but the pattern does not depend on the configuration.

Solr's solrconfig.xml file contains lots of parameters that can be tweaked. At the moment, we're just going to take a peak at the request handlers, which are defined with <requestHandler> elements. They make up about half of the file. In our first query, we didn't specify any request handler.

<requestHandler name="search" class="solr.SearchHandler default="true">
<!-- default values for query parameters can be specified, these will be overridden by parameters in the request -->
   <lst name="defaults">
   <str name="echoParams">explicit</str>
   <int name="rows">10</int>
   </lst>
</requestHandler>

Each HTTP request to Solr, including posting documents and searches, goes through a particular request handler. Handlers can be registered against certain URL paths by naming them with a leading "/".

<requestHandler name="/update" class="solr.XmlUpdateRequestHandler" />

Resetting the Cloudscape database to contain only bootstrap data

The initial installation of WebSphere Commerce Developer contains pre-published starter stores using IBM Cloudscape (derby) as the development database.

1. Navigate to the WCDE_installdir\bin directory.

2. Run the resetdb.bat script. This script will reset your Cloudscape database to its bootstrap configuration. When prompted you must confirm that you want the database to be reset by typing YES.

3. Run the resetstores.bat script. This script will reset the Stores Web module in your workspace to its bootstrap configuration so there will be no starter store resources in the Stores Web module.

4. If you run the resetdb.bat command after you have applied a WebSphere Commerce fix pack, you must run the updatedb.bat command to bring that database back to the appropriate level.

5. Use the Administration Console to publish only those starter stores that are of interest to you.

Default contract

A default contract defines the default customer entitlement for a store or a group of stores. The default contract applies to all customers shopping at a store who do not have any other contract with the store, for example, guest customers.

A typical default contract for a store specifies the following information:

• Customers can purchase all products available in the master catalog for the store at standard prices set in the master catalog (no discounts or mark-ups).
• Any shipping charges are paid to the seller (store).
• Payment is specified during order processing. The customer can use any payment method accepted by the store.
• The customer can select any shipping provider supported by the store to ship an order.
• The ship-to address for an order is specified by the customer during order processing.
• Customers can return purchases without penalty charges within a certain number of days.
• Customers can receive refunds using the same payment method used for the original purchase.

In order to create a default contract, you must define the contract, the contract owner, the contract description, the contract participants, and the terms and conditions of the contracts. Contract information is stored in four tables: CONTRACT, PARTICIPNT, TRADING, and TERMCOND.
About this task

The default contract is associated with a store using the STOREDEF database table. For WebSphere Commerce Enterprise users, contracts other than the default contract are associated with a store using the STORECNTR database table.

You can create a default contract in XML, based on one of two formats: XSD or DTD.

Generate usefull WCS password

Resetting the wcsadmin user password (Runtime)

Steps:

1. Enter the following SQL statement:

select salt from userreg where logonid='wcsadmin';

2. Run the following command line script from the WC_installdir/bin directory:

$ wcs_password <password> <salt> <merchant key>;

For example:

$ wcs_password password hsdbacehyoyn 0123456789abcdef

3. Enter the following SQL statement:

update userreg set logonpassword=<hex encrypted version of password output from the wcs_password script> where logonid = 'wcsadmin';

For example:

update userreg set logonpassword=x'74434f61354f51593862415655304d5268424e54723865685653356151374a2b353163 where logonid = 'wcsadmin';

Generate WebSphere Commerce encrypted password (wcs_password)

The wcs_password utility is used for encrypting user passwords to be stored in the WebSphere Commerce database.

Passwords are encrypted with a merchant key. The value of the merchant key could be specified through command line arguments or retrieved from calling out to the Key Locator Framework using the "-k" parameter.

Example 1

Encrypt password when merchant key is not retrieved from the Key Locator Framework: wcs_password pass1word rfKtuve 1234567890abcdef

Example 2

Encrypt password when merchant key is retrieved from the Key Locator Framework:

wcs_password pass1word rfKtuve -k WC_installdir\instances\xml\CustomKeys.xml


Changing the Configuration Manager password

You can change the password to access the Configuration Manager client. Two methods are available to change the password.

1. Change to the following directory
     WC_installdir/bin
2. Issue the following command
     ./wcs_encrypt.sh new_password

Two encrypted versions of the new password will be generated:

    ASCII encrypted string
    HEX encrypted string
 
3. Open the PwdMgr.xml file in a text editor
    WC_installdir/instances
4. Modify LoginPassword in the PwdMgr.xml file with the ASCII encrypted password from step 2 and save your changes.


Generating WebSphere Commerce encrypted passwords

You can generate encrypted passwords in order to manually reset the password of a user from a command line. There are other tools (such as the ResetPassword command) that accomplish the same task. To manually reset the password, the administrator would take the encrypted password that is output by the utilities and update the LOGONPASSWORD field of the USERREG table. The administrator would also update the SALT field of the USERREG table with the chosen salt.


1. Change to the following directory
     WC_installdir/bin
2. Run the wcs_password to generate the encrypted password.

3. To change the encrypted password for customers, use the chgwcspwd.sh command.

    Navigate to the following directory: WC_installdir/bin
    Run the following script: chgwcspwd.sh (The usage parameters will be displayed.)
    Run the command again using the appropriate parameters.

Custom promotions loader for WCS

WCS does not support promotion data load.

The promotions loader essentially has to put entries and XML into the following tables.

PX_PROMOTION
PX_GROUP
CLCDPROMO
CALCODE
CALCODEDSC
CATENCALCD --product promotions
CATGPCALCD--category promotions

WebSphere Commerce Transactions

Throughout the execution of a controller command, data is often created or updated. In many cases, the database must be updated with the new information at the end of the transaction. The transaction is managed by the Web controller.

The Web controller marks the beginning of the transaction before calling the controller command. When the execution of the controller command is complete,
the controller command returns a view name to the Web controller.

The Web controller is responsible for marking the end of the transaction. The actual point at which the transaction ends (before or after invoking the view) depends upon the type of view used (forward view command).

The Web controller determines the view command to be used for the view by looking up the view name in the struts config file. If the entry in the struts config file specifies the use of the ForwardViewCommand, then the Web controller forwards the results of the controller command to the corresponding
ForwardViewCommand implementation class. The view command executes within the context of the current transaction. In this case, the database commit or rollback does not occur until the view command completes.

In the cases where the view command executes under the same transaction scope as the controller command, an error in the view command causes a rollback of the entire transaction. This may or may not be the desired outcome, depending upon your business logic.

WebSphere HTTP Request Flow

The flow between components in response to a request from an internet browser.

1. An HTTP request is directed to the Servlet Engine by the WebSphere Application Server plug-in.
2. The request is executed in its own thread. The Servlet Engine dispatches the request to the HTTP Request Servlet.
3. The HTTP Request Servlet passes the request to the HTTP Adapter Manager.
4. The HTTP Adapter Manager determines that the request originated from an Internet browser. Therefore, it passes the request to the HTTP Browser Adapter.
5. The HTTP Browser Adapter passes the request to the Web controller.
6. The Web controller determines which command to invoke by querying the command registry.
7. Assuming that the request requires the use of a controller command, the Web controller invokes the appropriate controller command (the other option to invoke a view command). The controller command may access the database, using one or more entity beans.
8. After a controller command begins execution, there are a few possible paths:
    – The controller command may access the database using access beans and their corresponding entity beans.
    – The controller command may invoke one or more task commands.
    – The task commands may access the database, using access beans and their corresponding entity beans.
9. Upon completion, the controller command returns the name of a view command to the Web controller.
10.The Web controller looks up the view name struts config file. It invokes the view command implementation that is registered for the device type of the requester.
11.The view command forwards the request to a display template.
12.Within the JSP template, a data bean is required to retrieve dynamic information from the database. The data bean manager activates the data bean.
13.The data bean manager invokes a data bean command, if required.
14.The access bean from which the data bean is extended accesses the database using its corresponding entity bean. 

Websphere Commerce run-time architecture

Servelt Engine

The servlet engine is part of the WAS runtime environment that acts as a request dispatcher for inbound Uniform Resource Locator(URL) requests. The servelt engine manages a pool of threads to handle requests.  each inbound request is executed on a separate thread.

Protocal listeners

Can invoke WC commands from various different devices.

1. Internet Browsers

2. Mobile phones using an Internet Browsers

3. B2B application sending XML messages using MQ

4. The WCS scheduler that executes commands and background jobs.

Protocal listener is a WAS rum-time component that receives inbound request from transports and then dispatches the requests to the appropriates adapters, based on the protocol used (request servlet, MQseries listener).

Adapters

WebSphere Commerce adapters are device-specific components that perform processing functions before passing a request to a controller.

1. Instructing the Web controller to process the request in a manner specific to the type of device. For example, a pervasive computing (PvC) device adapter can instruct the Web controller to ignore secure HTTP (HTTPS) checking in the original request.

2. Transforming the message format of the inbound request into a set of properties that WebSphere Commerce commands can understand.

3. Providing device-specific session persistence.

Web controller

A WC web controller is an application container that follows a design pattern similar to that of an EJB container. These containers simplify the role of commands, by providing such services as session management (based on the session persistence established by the adapter), transaction control, access control, and authentication.

The web controller also plays a role in enforcing the programming model for the commerce applicaion. ex: the programming model defines the types of commands that an application should write. each type of commands serves a specific purpose. Business logic must be implemented in controller commands.

Commands

WC commands are java beans that contains the programming logic associated with handling a particular request.

only Foward view command supported
 
Entity Beans

WC entity beans are the persistent, transactional commerce objects provided by WebSphere Commerce. These beans represent WebSphere Commerce data in an intuitive way. That is, rather than understanding the
database schema, you can access data from an entity bean that more closely models concepts and objects in the commerce domain. You may extend or replace existing entity beans.

Data Beans and Data bean commands

Data beans represent containers of properties (or data) that are primarily used by page designers. Most commonly, they provide a simple representation of a WebSphere Commerce entity.

A page designer can place these beans on a JSP template, allowing dynamic information to be populated on the page at display time. This person only needs to understand what data the bean can provide and what data the bean requires as input. In keeping with the theme of separating display from business logic, there is no need for the page designer to understand how the bean works.

To know what features-fixpack level are enabled?

Query the database table SITE and you can find the list of features enabled in your WCS V.
You can also find out the fix pack level.

  You can find out the fix pack level and installed feature pack details using the versionInfo.bat

Catalog assets and merchandising associations - Part-4

Catalog groups and catalog entries are related by merchandising associations.

Here are some examples:

Cross-sell: 

                 For example, “If you liked this book, you may like these other books in the same genre.”
Up-sell: 

              For example, “If you like this computer, here is a slightly more expensive model with these extra   features.”
Accessory: 

               For example, “If you order this camera, you may be interested in these batteries, cases, and tripods”.

For each association, additional semantics can be used to refine the relationship.

Here are some examples.

Required: 

               For example, “You must have this game program in order to use this game expansion accessory.” 

Comes with: 

           For example, “This case is included with this laptop package and you can follow this link to see a detailed display.”
Optional: 

              For example, “This power supply is an optional accessory for this battery-powered MP3 player.”

It is important to note that the business objects used to represent the merchandising associations do not include language-dependent text suitable for building a shopper's view. The assumption is that a store developer, while adding logic to the Java server pages used to build the shopper's view, searches for a particular type of association. Since the association is precisely chosen, the store developer can easily pull descriptive text from the store's language-dependent properties file if a matching association is found.

The following tables includes catalog assets and merchandising associations.

• Merchandising association (MASSOC)
• Merchandising association type (MASSOCTYPE)
• Related catalog group (MASSOCGPGP)
• Related catalog entry (MASSOCCECE)

Merchandising association (MASSOC)

The merchandising association object defines a value used to refine the meaning of a type of merchandising association. Default values include REQUIRED, COMES_WITH, and TEMP. Note that the description field in this object is not language dependent and should not be used when building a shopper's view.

Merchandising association type (MASSOCTYPE)

The merchandising association type object defines a value used to associate different catalog groups or different catalog entries. Default values include X-SELL, UPSELL, and ACCESSORY. Note that the description field in this object is not language dependent and should not be used when building a shopper's
view.

Related catalog group (MASSOCGPGP)

The related catalog group, held in the MASSOCGPGP table, contains the merchandising associations that exist between CatalogGroups.

Related catalog entry (MASSOCCECE)

The related catalog entry, held in the MASSOCCECE table, contains the merchandising associations that exist between catalog entries.

Catalog assets and Store assets- Part-3

A catalog may be used by multiple stores, but a store is not required to sell every item or display every group in the catalog. Neither are stores required to display each item identically. These relationships allow store developers to customize how a catalog is used by a store without changing the catalog assets and, therefore, without affecting other stores that use the same catalog.

The following tables includes on catalog assets and store assets:

• Store catalog (STORECAT)
• Store catalog group (STORECGRP)
• Store catalog entry (STOREENT)
• Display catalog group relation (DISPCGPREL)
• Display catalog entry relation (DISPENTREL)

Store catalog (STORECAT)

A store catalog object is used to link catalog objects to a store. Collectively, the set of all objects that contain the same storeent_id value are used to find the catalogs supported by the store.

Remember, a single store may use more than one catalog. For example, in addition to a master catalog, there
may be sales catalogs that organize the products differently, each optimized for a different type of shopper. The storeent_id is used to find the appropriate set of catalogs to display. For each object found, the catalog_id is used to find the appropriate catalog object. sales catalog proceeds as shoppers choose the catalog they would like to view.

Store catalog group (STORECGRP)

A store catalog group object is used to link catalog group objects to a store. Collectively, the set of all objects that contain the same storeent_id value are used to find the catalog groups supported by the store.

 

Store catalog entry (STOREENT)

A store catalog entry object is used to link catalog entry objects to a store. Collectively, the set of all objects that contain the same storeent_id value are used to find the catalog entries supported by the store.

The storeent_id is used to find the set of supported catalog entries. Given a list of catalog entries in the
catalog, the catalog entry is displayed only if it is also in the set of supported catalog entries.

Display catalog group relation (DISPCGPREL)

The display catalog group relation object is used to link a JSP name to a catalog group. Usually, a default page is provided for an entire site and, when necessary, an override is provided when the default page is inadequate. Overrides can be selected based on store, member group, device type, catalog group, language or any combination of these properties. A weighted best-fit technique is used when more than one relation satisfies the selection criteria.

Display catalog entry relation (DISPENTREL)

The display catalog entry relation object is used to link a JSP name to a catalog entry. Usually, a default page is provided for an entire site and, when necessary, an override is provided when the default page is inadequate. Overrides can be selected based on store, member group, device type, catalog entry type, catalog entry, language or any combination of these properties. A weighted best-fit technique is used when more than one relation satisfies the selection criteria.

Catalog assets (tables) and Description (usefull info)-Part-1

• Catalog (CATALOG)
• Catalog description (CATALOGDSC)
• Catalog group (CATGROUP)
• Catalog group attribute (CATGRPATTR)
• Catalog group description (CATGRPDESC)
• Catalog catalog group relation (CATTOGRP)
• Catalog group relation (CATGRPREL)
• Catalog entry (CATENTRY)
• Catalog entry attribute (CATENTATTR)
• Catalog entry description (CATENTDESC)
• Attribute (ATTRIBUTE)
• Attribute value (ATTRVALUE)
• Catalog entry relation (CATENTREL)
• Catalog group catalog entry relation (CATGPENREL)

Catalog (CATALOG)

A catalog object is the root of each catalog, whether it is a master catalog or a sales catalog. The catalog contains all of the hierarchical and navigational information for the catalog. The primary key catalog_id is used in all the business objects that define the relationship of catalog groups or catalog entries.The description in this object is only for administrative purposes.

Catalog description (CATALOGDSC)

A catalog description object contains language-dependent information and an image suitable for viewing by a shopper. if store support more than one catalog, the information from the CATALOGDSC object is used to describe the shopper's choices.

Catalog group (CATGROUP)

The catalog group object is used to organize a catalog and help the shopper navigate to the products they wish to view. A category group may contain other category groups. Alternatively, a category group may contain catalog entries.

 The relationships are not kept in this object.

• The catalog catalog group relation object, which links the foremost catalog groups to a catalog.
• The catalog group relation object, which links child category groups with their parent group.
• The catalog group catalog entry relation object, which links catalog entries with their parent catalog group.

When creating catalog groups, you must first arrange your catalog in a hierarchy. The root category branches out into increasingly specific subcategories. For example, Accessories is a grouping of the Men’s Fashions category, while the catalog groups wallets and hats are found nested within the Men’s Fashions
Accessories group.

Catalog group attribute (CATGRPATTR)

The catalog group attribute object contains descriptive attributes for catalog groups. Although the WebSphere Commerce sample stores do not use these objects, they are useful objects when a catalog group needs structured information to be included in its description. Unlike the catalog group description object, each descriptive attribute has both a name and a sequence property, necessary properties for building structured descriptions or comparison tables.

Typically, developer will use descriptive attributes when they wish to present a view that the shopper uses to compare similar catalog groups. The view would include a table with a row for each attribute name and a column for each catalog group to be compared. The sequence value is used to order the attribute names. The description from each catalog group attribute object would be displayed in the appropriate cell under the column assigned to its catalog group. The result is a side-by-side comparison table that the shopper can use to determine which catalog group they wish to view.

Sizes, styles, and other product features or functions can easily be used to organize the catalog into different groups. The name of the feature or function can then be used as attribute names. The values used to delimit the group can be used as attribute descriptions. Color could be defined to be an attribute; blue might be the assigned attribute value of a specific item.

Catalog group description (CATGRPDESC)

A catalog group description object contains language-dependent information and an image suitable for viewing by a shopper.

Typically, a developer will use the information in this object to produce a view that describes the catalog group for a commerce site. When the shopper navigates to a catalog group that contains other catalog groups, the information from this object is used to describe the shopper's choices for each child. The
shopper's preferred language or the current browser language are converted into the proper identifier together with the catgroup_id, to find the appropriate object.

Catalog catalog group relation (CATTOGRP)

The catalog catalog group relation object is used to link a catalog group to a catalog. Collectively, the set of objects that contain the same catalog_id value are used to find the root categories.

Typically, a developer will use the information in this object to select the catalog groups to be displayed initially. The catalog_id is used to find the appropriate set of objects to display.

Catalog group relation (CATGRPREL)

The catalog group relation object is used to link a child catalog group to its parent catalog group. Note that the relationship is qualified by a catalog_id. This gives the store developer the freedom to build different relationships for different catalogs, usually to optimize the navigation.

Typically, the store developer will use the information in this object to select the next set of catalog groups to display when the shopper selects a parent catalog group. The catalog_id and the parent's catgroup_id are used to find the appropriate set of objects to display. For each object in the set, the catgroup_id_child is used to find the appropriate catalog group object. Catalog navigation proceeds as shoppers choose the next catalog group to view.

Catalog entry (CATENTRY)

 The catalog entry object represents merchandise that can be ordered from the catalog. There are four different types of catalog entries, which can be identified by the value of the catenttype_id found in the CATENTRY element.

• Item
• Product
• Package
• Bundle

Item

An item represents a tangible unit of merchandise that can be purchased by a shopper. Viewed another way, an item represents anything that can be shipped to a shopper.

Product

A product represents a collection of items that have identical attributes but can be distinguished by their attribute values. For example, a catalog may contain a shirt that comes in different sizes and colors. Each unique combination of size and color values must be defined in an item, but, collectively, they can be displayed as a single product with a single price, description, and image as long as a shopper is given an opportunity to select the size and color values necessary to resolve the selection to a single item.

Package

A package is a collection of items that must be purchased as a single atomic unit. Even if its items can be ordered separately, a package has its own attributes, even its own price and part number, and cannot be  decomposed into individual items during navigation or after its placed in the shopping cart.

Bundle

A bundle is a collection of items that can be added to the shopping cart with a single selection. It is typically just a convenience for the shopper, a way to order a collection of items without navigating to each item individually. Unlike a package, each item in the collection is placed in the shopping cart and the shopper can modify (for example, change the quantity) or remove each item.

Catalog entry attribute (CATENTATTR)

The catalog entry attribute object contains descriptive attributes for catalog entries. Although the WebSphere Commerce sample stores do not use these objects, they are useful objects when a catalog entry needs structured information to be included in its description. Unlike the catalog entry description object, each descriptive attribute has both a name and a sequence property, which are necessary properties for building structured descriptions or comparison tables. The sequence value is used to order the attribute names.

Catalog entry description (CATENTDESC)

A catalog entry description object contains language-dependent information and an image suitable for viewing by a shopper.

Typically, regardless of the type of catalog entry, the developer will use the information in this object to produce a view that describes the catalog entry. When the shopper navigates to a catalog group that contains catalog entries, the information from this object is used to describe the shopper's choices for each child. The shopper's preferred language or the current browser language are converted into the proper identifier together with the catentry_id, to find the appropriate object.

Attribute (ATTRIBUTE)

The attribute object defines the name, qualified by language, of each attribute used to resolve a product catalog entry into an item that can be added to the shopping cart. Notice that its catentry_id is a reference back to a product catalog entry. Compare that to an attribute value object where the catentry_id refers back
to the item catalog entry that is identified with that value.

The product's catentry_id together with the shoppers preferred language (or the browser's current language converted into an identifier) is used to select all the attributes that are used to resolve the product to a particular item. The value of sequence is used to order the attributes on the view. If the selection criteria are not obvious from the attribute name, the values from description and description2 can be used to provide additional information to aid the shopper.

The attrtype_id can be used to dynamically choose the correct structure for the shopper's selection. The choices in each selection structure will be taken from the matching attribute value objects.

Attribute value (ATTRVALUE)

The attribute value object defines the value, qualified by language, of each attribute used to resolve a product catalog entry into an item that can be added to the shopping cart. Notice that its catentry_id is a reference back to an item catalog entry. Compare that to an attribute object where the catentry_id refers back to the product catalog entry that is identified with that value.

Catalog entry relation (CATENTREL)

The catalog entry relation object is used to link a catalog entry to its parent. To date, only three relationships are possible

• PRODUCT_ITEM: An item can be linked to its product.
• PACKAGE_COMPONENT: A catalog entry of any type can be linked to a package.
• BUNDLE_COMPONENT: A catalog entry of any type can be linked to a bundle.

Notice that, unlike catalog groups, these relations are not qualified by catalog_id. These relations are the same no matter which catalog includes the catalog entry.

Typically, the developer will use the information in this object to determine what collection of merchandise is represented by a catalog entry collection, either to provide a more granular display or to determine what merchandise is to be added to the shopping cart. Once a collection is selected, the related objects are found by finding the objects where the catentry_id_parent value matches the collection's catentry_id value. For each catalog entry relation found, the catentry_id_child is used to find the appropriate catalog entry object to display or to include in the shopping cart. The value of sequence can be used to order the children in the view.

Special care must be exercised when a package or bundle contains a product. If this combination exists, the store developer must also include the means to resolve the product to a single item.

Catalog group catalog entry relation (CATGPENREL)

The catalog group catalog entry relation object is used to link a catalog entry to a catalog group. Note that the relationship is qualified by a catalog_id. This gives the store developer the freedom to build different relationships for different catalogs, usually to optimize the navigation.

Typically, the developer will use the information in this object to select the set of catalog entries to display when the shopper selects a parent catalog group. The catalog_id and the selected catgroup_id are used to find the appropriate set of objects to display. For each object in the set, the catentry_id is used to find the
appropriate catalog entry object. Catalog navigation proceeds as the shopper chooses a catalog entry to view, optionally adding the merchandise to the shopping cart in the process.

Catalog and offering assets (price) Part-2

Every catalog entry object must have a base price (commonly called a default price) there may be any number of prices associated with a given item.

Example:

1. There may be a price for each supported currency.
2. There may be a special discounted price for senior citizens or for employees.
3. There may be special business customer contracts with terms and conditions (minimum quantity, maximum quantity, shipping restrictions, and so on) that justify special prices.

This following tables includes catalog and offering assets.

• Trading position container (TRADEPOSCN)
• Catalog group trading position relation (CATGRPTPC)
• Offer (OFFER)
• Offer description (OFFERDESC)
• Offer price (OFFERPRICE)

Trading position container (TRADEPOSCN)

A trading position container object organizes, by reference, a group of offers. The reference identifier tradeposcn_id value is used in all the offers in the container.

Typically, a developer begins by creating a single trade position container to contain the base prices for the entire catalog. In this container, the productset_id property is set to NULL and the type property is set to indicate that it represents the standard prices. When special prices need to be offered, the store developer creates additional trading position containers, one for each collection of related prices.

Catalog group trading position relation (CATGRPTPC)

The catalog group trading position relation is used to link a catalog or a catalog group to a trading position. If the catgroup_id property is set to 0, the relation applies to the entire catalog. Otherwise, the relation applies to the specified catalog group.

Offer (OFFER)

The offer object is used as a relation to link a particular catalog entry object and its related prices to a trading position container. It may also contain properties that qualify the applicability of the specified prices. Once a trading position container has been chosen, its reference identifier plus the reference identifier of the catalog entry can be used to find the appropriate offer object.

By convention, every catalog entry, regardless of type, has an offer in the base price list. You could argue that items could inherit their price from the related product, or all the item prices in a bundle could be summed to provide the price for the bundle. However, for convenience and performance while building a view, an invoice, or an order, each catalog entry is given its own offer, even when information appears to be redundant.

Offer description (OFFERDESC)

An offer description object contains language-dependent information about an offer. Although this object is not used in the sample stores, it can be used to add descriptive text about the price for viewing by a shopper. For example, it may say “For a limited time, only”, “While supplies last”, or “Special price because you are
an eligible Senior Citizen”.

Note the granularity of these descriptions, one per offer object. In most cases, all the offers in the same trading position container are there for the same reason. To have this information recorded for each offer can be very redundant. You may be tempted to use the description in the trading position container instead, but
that description is not language dependent and is therefore unsuitable for stores that support more than one language.

Offer price (OFFERPRICE)

The offer price object links a currency-dependent price to an offer. Once an offer has been chosen, its reference identifier and the desired currency identifier can be used to find the price to be displayed. Optionally, this object may contain a comparison price, in the same currency. When special prices need to be added to the site, additional offer price objects are created for each offer in the new trading position container.

How to implement access control in customized code?

Enterprise beans and data beans are resources that may need to protect. However, not all Enterprise bean and data beans should be protected.

Typically, the question of what to protect comes into play when you create new Enterprise beans and data beans.

Decide which resource to protect depends on your application.

If a command returns an Enterprise bean in the getResources method, then the Enterprise bean must be protected because the ACP manager will call the getOwner() method on the enterprise ban. The fulfills() method will also be called if a relationship is specified in the corresponding resource-level ACP.

if we implements the protectable interface for all of enterprise bean and data bean ( in number of policy increase) performance may degrade.

Primary resources should be protected, but dependent resources often do not require protection. if user allowed to access a primary resource, it makes sense that, by default, the user should also be allowed to access its dependent resource.

Understanding Access Control Policy

Access control in WCS is composed of the following elements:

1. Users - Users are the people that use the System. so users must be grouped into relevent access group.

2. Actions - Actions are the activities that users can perform on the resource. so action must also be grouped into relevent action groups.

3. Resources - Resources are the entities that are protected. Ex: if the action is a view, the resource to be protected is the command that invoked the view.

4. relationships - are the relationship between the user and the resource.

There are two level/type ACP.

1. Command-level ACP - The first level of ACP is performed by the WAS. In this respect, WC uses WAS to protect Enterprise beans and servlets.

2. Resource-level ACP - The Second level ACP is the fine-grained access control system of WCS.

Note: A command-level ACP alwasy has the ExecuteCommandActionGroup as the action group for Controller command. for views, the resource group is always ViewCommandResourceGroup. (ACPOLICY, MBRGRP, MBRGRPCOND, ACACTGRP, ACRESGRP)

ACP are enforced by the access control policy manager. when a user attempts to access a protected resource, ACP manager determines what ACP are applicable for that protected resource, and based upon the applicable ACP, it determines if the user is allowed to access the requested resources.

An ACP is a 4-element that is stored in the ACPOLICY table. Each access control policy takes the following form:

AccessControlPolicy [UserGroup, ActionGroup, ResourceGroup, Relationship]

The above elements say, a user belonging to a specific user group is permitted to perfrom action in the specified ActionGroup on resource belonging to the specified ResourceGroup, as long as the user satisfies the conditions specified in the Relationship or relationship group, with respect to the resource in question.

Ex: [AllUsers, UpdateDoc, doc, creator] specifies that all users can update a document, if they are the create of the document.

• The user group is a specific type of member group that is defined in the MBRGRP table.
• A user group must be associated with member group type of -2. the value of -2 represent an access group and is defined in the MBRGRPTYPE table.
• Association between the usergroup and membergroup type is stored in the MBRGRPUSG table.

The membership of a user into a particular user group may be stated explicitly or implicitly. An explicit specification occurs if the MBRGRPMBR tables states that user belongs to a particular member group. An implicit specification occurs fi the user satisfies a condition (all users that fulfill the role of Product Manager) that is stated in the MBRGRPCOND table.

Most conditions to include a user in a user group are based upon the user fulfilling a particular role. Ex: there could be ACP that allows all users that fulfill the Product Manager role to perform catalog management operations. in this case, any user that has been assigned the Product Manager role in the MBRROLE table is implicitly included in the user group.

The ActionGroup elements comes from the ACACTGRP table. An action group refers to an explicitly specified group of actions. The list of actions is stored in the ACACTION table and the relationship of each action to its action group(or group) is stored in the ACACTACTGP table.

An example of an action group is the "OrderWriteCommands" action group. this action group includes the following action that are used to update orders

• OrderDeleteCmd
• OrderCancelCmd
• OrderAProfileUpdateCmd
• OrderUnlockCmd
• OrderScheduleCmd
• ScheduledOrderCancelCmd
• ScheduledOrderProcessCmd
• OrderItemAddCmd
• OrderItemDeleteCmd
• OrderItemUpdateCmd
• PayResetPMCmd

The resource group is mechanism to group together particular types of resources. membership of a resource in a ResourceGroup can be specified in one of two ways.

using the conditions column in the ACRESGRP table
using the ACRESGPRES table.

in most case, it is sufficient to use the ACRESGPRES table for associating resources to resource group. using this method, resources are defined in the ACRESCGRY table suing their java class name.

These resources are associated with appropriate resource group(ACRESGRP) using the ACRESGPRES association table. in this case where the java class name alone is not sufficient to define the members a resource group.

The ACP can optionally include either a Relationship or RelationshipGroup element as its fourth element.

if ACP uses a Relationship element, this come from the ACRELATION table. if on other hand, it includes a RelationshipGroup Element, that comes from the ACRELGRP table. A ReletionshipGroup specification from the ACRELGRP table takes precedeence over the Relationship information from the ACRELATION table.

Enabling JDBCAccessBean for Management Center

Use WebSphere Application Server administrative console to trace queries serviced by the data service layer.

a. Set the log level setting to 'all' for the com.ibm.commerce.foundation.server.services.dataaccess* component in the WebSphere Application Server Administrative console.

Note: To trace the UPDATE and INSERT queries, set the log level setting to 'all' for all classes under component com.ibm.ws.sdo.mediator.jdbc (com.ibm.ws.sdo.mediator.jdbc*=all). You must restart the server after enabling this trace.

massextract utility example

Mass extract (massextract) is an OOB utility which can be used to extract data from any tables in IBM WCS. Use the massextract utility to extract selective subsets of data from the WebSphere Commerce database in the form of XML files.
You can extract data on products related to an upcoming holiday, for example, or you can extract information from a consolidated database for use with other systems.

Step-1

Pre-Request for before running this utility

i. Assume that environment variable setting done.
ii. JVM Setting (optional)

iii. (Oracle) Optional: By default, the massextract utility uses the Oracle thick JDBC client. To change the massextract utility to use the Oracle thin JDBC client.

Step-2

Create an extraction filter: An extraction filter is an XML file that defines the data want to extract from the WebSphere Commerce database. Must create an extraction filter before run the massextract utility.

Procedure to extraction filter

1. Develop SQL queries for the data you want to extract from the WebSphere
Commerce database.

Extraction filter format

This tag and its closing tag define the extraction filter. All of the text in the extraction
file must be contained within this tag.

This tag defines the SQL query used to extract data from the database.
Every tag requires one or more tags.

This tag is responsible for the running of the SQL query. In this tag, you can also
specify for any values required for variable parameter defined in the tag.
Multiple tags can be associated with one tag.

Example:

1. Create file called CatentryFilter.xml
2. Add the following content to CatentryFilter.xml




3. Finally execute the below extract utility

./massextract.sh -filter /opt/IBM/WebSphere/CommerceServer60/bin/CatentryFilter.xml -outfile /opt/IBM/WebSphere/CommerceServer60/bin/CatentryFilterExtracted.xml -dbname PPSTGDB -dbuser MIPRODSTA -dbpwd MIPRODSTA -customizer OracleConnectionCustomizer


Note: we can query multiple tables using join conditions.