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.