Explore topic-wise InterviewSolutions in .

To MAP VIEWS to CORRESPONDING JSP PAGES .

To map views to corresponding JSP pages .

commitCopyHelper():INSTEAD of using the remote interface, CopyHelper Access Beans exist that contain getters and setters for CMP fields that do not exist on the remote interface. The methods within the CopyHelper Access Beans write data to a hash table that in TURN updates the database when commitCopyHelper() is called. The hash table can RECORD multiple database changes then update the database in one transaction, unlike the remote methods which REQUIRE one transaction per change.

RefreshCopyHelper():which does the REVERSE function of commitCopyHelper(). The method refreshCopyHelper() writes to the hash table from the database.

commitCopyHelper():Instead of using the remote interface, CopyHelper Access Beans exist that contain getters and setters for CMP fields that do not exist on the remote interface. The methods within the CopyHelper Access Beans write data to a hash table that in turn updates the database when commitCopyHelper() is called. The hash table can record multiple database changes then update the database in one transaction, unlike the remote methods which require one transaction per change.

RefreshCopyHelper():which does the reverse function of commitCopyHelper(). The method refreshCopyHelper() writes to the hash table from the database.

MAPPINGS from EJB bean ATTRIBUTE definitions to DATABASE table SCHEMA column definitions .

Mappings from EJB bean attribute definitions to database table schema column definitions .

The DIFFERENT BUSINESS models of wcs are:

1. B2C 
2. B2B 
3. DEMAND chain 
4. Supply chain
5. Value chain and
6. Extended sites.

The different business models of wcs are:

ECApplicationException : This EXCEPTION is thrown if the error is related to user input and will always fail. For example, when a user enters an invalid parameter, an ECApplicationException is thrown. When this exception is thrown, the solution controller does not retry the COMMAND, even if it is specified as a retriable command.

ECSystemException : This exception is thrown if a RUNTIME exception or a WEBSPHERE Commerce configuration error is detected. Examples of this type of exception include create exceptions, REMOTE exceptions, and other EJB exceptions. When this type of exception is thrown, the solution controller retries the command if the command is retriable and the exception was caused by either a database deadlock or database rollback. 

ECApplicationException : This exception is thrown if the error is related to user input and will always fail. For example, when a user enters an invalid parameter, an ECApplicationException is thrown. When this exception is thrown, the solution controller does not retry the command, even if it is specified as a retriable command.

ECSystemException : This exception is thrown if a runtime exception or a WebSphere Commerce configuration error is detected. Examples of this type of exception include create exceptions, remote exceptions, and other EJB exceptions. When this type of exception is thrown, the solution controller retries the command if the command is retriable and the exception was caused by either a database deadlock or database rollback. 

ECSystemException.

ECSystemException.

A retriable command is a controller command that can re-execute itself after encountering a system-level exception during the command execution.

To MAKE an existing controller command retriable, must perform one of the following steps:

Set the retriable PROPERTIES in the PROPERTIES column of the CMDREG database table, where PROPERTIES is the default properties associated with this command. The properties are in the property1=value1&property2=value2 form, where propertyn is the name of the property and valuen is the value corresponding to the property.

Set an instance property <CommandRegistryRetriableProperty defaultValue="1" /> in the wc-server.xml FILE.

Functional architecture and Runtime architecture of WCS 6.0/WCS 7.0.

A retriable command is a controller command that can re-execute itself after encountering a system-level exception during the command execution.

To make an existing controller command retriable, must perform one of the following steps:

Set the retriable properties in the PROPERTIES column of the CMDREG database table, where PROPERTIES is the default properties associated with this command. The properties are in the property1=value1&property2=value2 form, where propertyn is the name of the property and valuen is the value corresponding to the property.

Set an instance property <CommandRegistryRetriableProperty defaultValue="1" /> in the wc-server.xml file.

Functional architecture and Runtime architecture of WCS 6.0/WCS 7.0.

There are two types of catalogs in a WebSphere Commerce system: master and sales. While a master catalog is the CENTRAL location to manage all your store's merchandise and services, a sales catalog is a subset of the merchandise and services found in the master catalog.

Every store in the WebSphere Commerce system must have a master catalog. Only one master catalog can exist at a time, and multiple STORES can share a master catalog. However, you can CREATE one or more sales catalogs for CUSTOMER display purposes. A sales catalog has a flexible display STRUCTURE that allows you to associate products to more than one category, to suit the requirements of your store. 

There are two types of catalogs in a WebSphere Commerce system: master and sales. While a master catalog is the central location to manage all your store's merchandise and services, a sales catalog is a subset of the merchandise and services found in the master catalog.

Every store in the WebSphere Commerce system must have a master catalog. Only one master catalog can exist at a time, and multiple stores can share a master catalog. However, you can create one or more sales catalogs for customer display purposes. A sales catalog has a flexible display structure that allows you to associate products to more than one category, to suit the requirements of your store. 

Every product has a UNIQUE IDENTIFICATION number when it is MANUFACTURED i.e.,PartNumber.SKU is a store keeping unit which is a number when a PRODUCTS are orderable.

Every product has a unique identification number when it is Manufactured i.e.,PartNumber.SKU is a store keeping unit which is a number when a products are orderable.

PRODUCT MANAGEMENT TOOL.

Product Management Tool.

Products: A product acts as template for a group of items(or SKUS) that exhibits the same ATTRIBUTES.

Items: An item is a tangible UNIT of merchandise that has a specific name, PART number and price.

Products: A product acts as template for a group of items(or SKUs) that exhibits the same attributes.

Items: An item is a tangible unit of merchandise that has a specific name, part number and price.

An attribute dictionary is a SET of common attributes and attribute values that can be reused by MULTIPLE products. The attribute management TOOL in Management Center provides business USERS the ability to CREATE,update, assign, and manage product attributes.

An attribute dictionary is a set of common attributes and attribute values that can be reused by multiple products. The attribute management tool in Management Center provides business users the ability to create,update, assign, and manage product attributes.

Packages: A package is an atomic collection of catalog entries. It is that all the items in a package can sold together but individual SELLING of items in a package is not allowed.

Static Kits:

1. A static KIT is a group of products that are ordered as a unit.
2. A static kit will back order if any of its COMPONENTS are unavailable.
3. A static kit is FIRST created as a package then configured by an administrator.

Packages: A package is an atomic collection of catalog entries. It is that all the items in a package can sold together but individual selling of items in a package is not allowed.

Static Kits:

Calculation usage consists of TYPES of taxes that can be attached to an order item.
By default we have 7 types of taxes like SHIPPING, discount, shipping TAX, etc.
All those can be found in CALUSAGE database table.

Calculation usage consists of types of taxes that can be attached to an order item.
By default we have 7 types of taxes like shipping, discount, shipping tax, etc.
All those can be found in CALUSAGE database table.

There are 7 TYPES of charges, those are:

• discount
• shipping
• sales TAX
• shipping tax
• COUPON
• SURCHARGE
• shipping adjustment

There are 7 types of charges, those are:

While attachment is defined outside of a calculation code, the following properties are defined as part of a calculation code:

• A calculation usage. This specifies the calculation type for which a calculation code can be used. Calculation usages are COVERED in Calculation usages.
• Calculation methods that are used to qualify, calculate, and apply the calculation code.
• A flag indicating if a calculation code must be qualified or not.
• A flag indicating if the calculation code is active, inactive, or marked for deletion.
• The method of grouping ORDER ITEMS for calculations.
• A sequence number that is used to determine the order of calculations when MULTIPLE calculation codes of the same calculation usage apply to an order item.
• A time RANGE during which the calculation code is in effect.
• These properties are defined in the CALCODE database table. 

While attachment is defined outside of a calculation code, the following properties are defined as part of a calculation code:

Stores use FULFILLMENT centers as both INVENTORY warehouses and shipping and receiving centers. One STORE can have one or MANY fulfillment centers.

Stores use fulfillment centers as both inventory warehouses and shipping and receiving centers. One store can have one or many fulfillment centers.

CALCULATION methods use the information that is part of calculation USAGES, calculation codes, and calculation scales to determine MONETARY amounts for order ITEMS. Calculation methods are categorized by the task that they perform within the calculation framework and the part of the calculation framework to which the calculation method BELONGS.

Calculation methods use the information that is part of calculation usages, calculation codes, and calculation scales to determine monetary amounts for order items. Calculation methods are categorized by the task that they perform within the calculation framework and the part of the calculation framework to which the calculation method belongs.

TAXES are CALCULATED when we PROCEED to CHECKOUT.

Taxes are calculated when we proceed to checkout.

3 ways calcode can be ATTACHED :

1. Direct attachment: Here, we can ATTACH a calcode to order or orderitem directly
2. Indirect attachment: Here, we attach a calcode to catalog or catalog GROUP. Hence, every item in a PARTICULAR catalog or catalog group is indirectly attached to calcode that is attached to that catalog or catalog group.
3. Default attachment: Here, we implicitly attach a calcode SPECIFYING a calcode to an orderitem in STENCALUSG table.

3 ways calcode can be attached :

WebSphere COMMERCE supports several mechanisms for submitting orders.

A customer or Customer SERVICE Representative can submit an order using any of the following methods:

• Requisition lists 
• Wish lists 
• SHOPPING carts 
• Scheduled orders are RECURRING orders 
• Quick orders 
• Copied orders 
• Sales quotes.

WebSphere Commerce supports several mechanisms for submitting orders.

A customer or Customer Service Representative can submit an order using any of the following methods:

There are 4 TYPES of INVENTORY EXISTS in wcs namely:

1. ATP
2. Non ATP
3. EXTERNAL Inventory
4. No Inventory.

There are 4 types of inventory exists in wcs namely:

By CHECKING in to OrderItems table InventoryStatus COLUMN.If that column has an VALUE as allc then an inventory is allocated for the ORDER.

By checking in to OrderItems table InventoryStatus column.If that column has an value as allc then an inventory is allocated for the order.

There are MAINLY 6 SUBSYSTEMS available in WCS NAMELY:

1. Catalog.
2. Member.
3. ORDER.
4. Marketing. 
5. MERCHANDISING.
6. Trading.

There are mainly 6 subsystems available in WCS namely:

WebSphere Commerce uses an optimistic locking scheme that allows the database transaction isolation LEVEL to be lowered from repeatable read to read committed. Using that scheme, database rows not normally accessed concurrently are not LOCKED with an intent to update when they are read. Instead, when the update is EVENTUALLY made, the row is checked to make sure it has not been updated concurrently since it was read. If it has been updated concurrently, then the transaction is rolled back and the COMMAND may be restarted from the beginning in a NEW transaction, if appropriate. In this scheme, performance is improved when concurrent updates do not normally occur, because the relatively expensive process of obtaining the database locks with intent to update is avoided.

On the other hand, for those operations where concurrent updates are more likely to occur, pessimistic locking, whereby intent to update locks are obtained when the row is read, continues to be used, thus avoiding the more expensive process of rolling back and re-starting from the beginning in a new transaction. 

WebSphere Commerce uses an optimistic locking scheme that allows the database transaction isolation level to be lowered from repeatable read to read committed. Using that scheme, database rows not normally accessed concurrently are not locked with an intent to update when they are read. Instead, when the update is eventually made, the row is checked to make sure it has not been updated concurrently since it was read. If it has been updated concurrently, then the transaction is rolled back and the command may be restarted from the beginning in a new transaction, if appropriate. In this scheme, performance is improved when concurrent updates do not normally occur, because the relatively expensive process of obtaining the database locks with intent to update is avoided.

On the other hand, for those operations where concurrent updates are more likely to occur, pessimistic locking, whereby intent to update locks are obtained when the row is read, continues to be used, thus avoiding the more expensive process of rolling back and re-starting from the beginning in a new transaction. 

Social COMMERCE SUPPORT,Coshoping provision, rich look and feel,STARTER stores OPTIMIZED for mobile DEVICES. 

Social Commerce Support,Coshoping provision, rich look and feel,starter stores optimized for mobile devices. 

WebSphere Commerce commands interact with access beans rather than directly with entity beans. Access beans provide a simpler interface to clients, caching of the home object, and reduced call traffic to the enterprise bean.Access beans behave LIKE Java beans, and hide all enterprise bean-specific programming INTERFACES from the client, like the JNDI, home and remote interfaces.

Advantage of accessbean:

 At run time the access bean caches the enterprise bean home object because LOOK ups to the home object are expensive, in terms of time and resource usage.

The access bean implements a copyHelper object that reduces the number of calls to the enterprise bean when commands get and set enterprise bean attributes. Only a single call to the enterprise bean is required when reading or writing MULTIPLE enterprise bean attributes. 

WebSphere Commerce commands interact with access beans rather than directly with entity beans. Access beans provide a simpler interface to clients, caching of the home object, and reduced call traffic to the enterprise bean.Access beans behave like Java beans, and hide all enterprise bean-specific programming interfaces from the client, like the JNDI, home and remote interfaces.

Advantage of accessbean:

 At run time the access bean caches the enterprise bean home object because look ups to the home object are expensive, in terms of time and resource usage.

The access bean implements a copyHelper object that reduces the number of calls to the enterprise bean when commands get and set enterprise bean attributes. Only a single call to the enterprise bean is required when reading or writing multiple enterprise bean attributes. 

Different flavours of EJB AVAILABLE in WCS are SESSION BEAN and Entity Bean. 

Different flavours of EJB available in WCS are Session Bean and Entity Bean. 

A data bean is a JAVA bean that is used within a JSP page to provide dynamic content. A data bean normally provides a simple representation of a WebSphere Commerce entity bean.

There are two types of data beans: SMART data beans and command data beans.

 A smart data bean uses a lazy fetch method to retrieve its own data. This type of data bean can provide better performance in situations where not all data from the access bean is required, SINCE it retrieves data only as required. Smart data beans that require access to the database should extend from the access bean for the corresponding entity bean and implement thecom.ibm.commerce.SmartDataBean interface. When database access is not required, the smart data bean should extend the SmartDataBeanImpl class.

A command data bean relies on a command to retrieve its data and is a more lightweight data bean. The command retrieves all attributes for the data bean at once, regardless of whether the JSP page requires them. As a result, for JSP pages that use only a selection of attributes from the data bean, a command data bean may be costly in terms of performance time. Command data beans can also extend from their corresponding access beans and implement thecom.ibm.commerce.CommandDataBean interface.

SmartDataBean is commonly used in wcs.We use command databean only when USING Command databean is impractical.

A data bean is a Java bean that is used within a JSP page to provide dynamic content. A data bean normally provides a simple representation of a WebSphere Commerce entity bean.

There are two types of data beans: smart data beans and command data beans.

 A smart data bean uses a lazy fetch method to retrieve its own data. This type of data bean can provide better performance in situations where not all data from the access bean is required, since it retrieves data only as required. Smart data beans that require access to the database should extend from the access bean for the corresponding entity bean and implement thecom.ibm.commerce.SmartDataBean interface. When database access is not required, the smart data bean should extend the SmartDataBeanImpl class.

A command data bean relies on a command to retrieve its data and is a more lightweight data bean. The command retrieves all attributes for the data bean at once, regardless of whether the JSP page requires them. As a result, for JSP pages that use only a selection of attributes from the data bean, a command data bean may be costly in terms of performance time. Command data beans can also extend from their corresponding access beans and implement thecom.ibm.commerce.CommandDataBean interface.

SmartDataBean is commonly used in wcs.We use command databean only when using Command databean is impractical.

There are 2 types of entity BEANS available namely

• BMP-Bean Managed Persistence
• CMP -Container Managed Persistence

CMP is used in commerce to interact with the DATABASE in commerce.

There are 2 types of entity beans available namely

CMP is used in commerce to interact with the database in commerce.

Possible values for TRANSATTRIBUTE are:

NotSupported:Bean cannot be involved in a transaction. If the CLIENT has started a transaction, the EXISTING transaction is suspended until the bean's method has COMPLETED.

Required :Bean MUST always run within a transaction

Supports :If the client has started a transaction, the bean joins the transaction.

RequiresNew:Bean always starts a new transaction.

Mandatory:The client must start a transaction when the bean is invoked.

NEVER :If the client has started a transaction, the bean throws an exception. 

Possible values for TRANSATTRIBUTE are:

NotSupported:Bean cannot be involved in a transaction. If the client has started a transaction, the existing transaction is suspended until the bean's method has completed.

Required :Bean must always run within a transaction

Supports :If the client has started a transaction, the bean joins the transaction.

RequiresNew:Bean always starts a new transaction.

Mandatory:The client must start a transaction when the bean is invoked.

Never :If the client has started a transaction, the bean throws an exception. 

1. Now a days the REQUIREMENT is changed that caching should be implemented for the content that changes frequently.
2. The bright solution for this is DynaCache system which is PROVIDED by IBM Websphere Application SERVER.
3. Dyna Cache is to be configured to catch some objects and LATER based on some matching rules Dyna cache RETRIVE those objects from the cache.
4. Caching rules are specified in Cachespec.xml file.

There are two types of access control, both of which are policy-based: command-level access control and resource-level access control.

Command-level access control determines whether the user is allowed to execute the particular command within the store you have specified. 

Resource-level access control policy could be applied to determine if the user can access the resource in question. 

Access control in a WebSphere Commerce application is composed of the FOLLOWING elements: users, ACTIONS, resources, and relationships.

Users are the people that use the system. For access control purposes, users must be grouped into relevant access groups. 

Actions are the activities that users can perform on the resource. For access control purposes, actions must also be grouped into relevant action groups. For EXAMPLE, a common action used in a store is a view. A view is invoked to display a store page to customers. The views used in your store must be declared as actions and ASSIGNED to an action GROUP before they can be accessed. 

Resources are the entities that are protected. For example, if the action is a view, the resource to be protected is the command that invoked the view, for example com.ibm.commerce.command.ViewCommand. 

Relationships are the relationship between the user and the resource. Access control policies may require that a relationship between the user and the resource be satisfied. For example, users may only be allowed to display the orders that they have created.

There are two types of access control, both of which are policy-based: command-level access control and resource-level access control.

Command-level access control determines whether the user is allowed to execute the particular command within the store you have specified. 

Resource-level access control policy could be applied to determine if the user can access the resource in question. 

Access control in a WebSphere Commerce application is composed of the following elements: users, actions, resources, and relationships.

Users are the people that use the system. For access control purposes, users must be grouped into relevant access groups. 

Actions are the activities that users can perform on the resource. For access control purposes, actions must also be grouped into relevant action groups. For example, a common action used in a store is a view. A view is invoked to display a store page to customers. The views used in your store must be declared as actions and assigned to an action group before they can be accessed. 

Resources are the entities that are protected. For example, if the action is a view, the resource to be protected is the command that invoked the view, for example com.ibm.commerce.command.ViewCommand. 

Relationships are the relationship between the user and the resource. Access control policies may require that a relationship between the user and the resource be satisfied. For example, users may only be allowed to display the orders that they have created.