IllegalStateException | Command Caching

Any command that extends CacheableCommand can be cached; in other words, both the TaskCommand and ControllerCommand can be cached.

IllegalStateException is thrown when a cached command cannot be serialized. This can happen if any of the variables/objects (class level) are not serializable.

sample command definition:
public class LearnerTestCmdImpl extends ControllerCommandImpl implements
        LearnerTestCmd {
   
    String name;

    MyBean bean;
         .................................
         .................................   

sample bean definition:
         public class MyBean {

 Let's say the command LearnerTestCmdImpl is cached but throws IllegalStateException while it is executed.

This can be resolved in two ways:
1. Make the object (Eg: MyBean Object in above sample) serializable
    i.e;
         public class MyBean implements Serializable {

2. Make the MyBean object transient variable in the command. But any variable/object defined as transient will not be a part of the cache content.
i.e;
public class LearnerTestCmdImpl extends ControllerCommandImpl implements
        LearnerTestCmd {
 
         String name;

         transient MyBean bean;
         .................................
         .................................  

ECException & isRetriable() | WCS Commands

All the exceptions that occur in commands are wrapped into ECException and thrown back. This is of two types :
1. ECApplication Exception : Exception due to any application parameters.
2. ECSystem Exception : Exception due to any system issues.

isRetriable() method of a Command

The isRetriable method returns a Boolean value which specifies whether the command can be retried on a transaction rollback exception. The isRetriable method of the new controller command's superclass returns a value of false. You should override this method and return a value of true, if your command can be retried on a transaction rollback exception.

WCS Users | Overriding isGeneric() Method | Controller Command

Default value returned by the method isGeneric () is false.

If a controller command can be executed by a generic user, this method needs to be overriden to return true.
When the value returned by isGeneric () is false, a generic user will not be able to execute it, instead a new Guest user id would be created and the command execution would complete successfully.

Importance of overriding this method :
To have the application perform better, it is always recommended to override this method to return false for all the commands that are not user specific/dependant.
Else (if not overriden), a new user is always created during the command execution, which may result in the larger DB size, in addition to an extra overhead of populating user bean objects for the command context.


Additional Info:

In the standard WebSphere Commerce implementation there are multiple types of users. These include generic, guest, and registered users. Within the grouping of registered users there are customers and administrators.

The generic user has a common user ID (-1002) that is used across the entire system. This common user ID supports general browsing on the site in a manner that minimizes system resource usage. It is more efficient to use this common user ID for general browsing, since the Web controller does not need to retrieve a user object for commands that can be invoked by the generic user.

Simple Steps to create a controller Command

Steps:

a. Create an interface (MyNewControllerCmd) extending com.ibm.commerce.command.ControllerCommand.

b. Create the class (MyNewControllerCmdImpl) extending com.ibm.commerce.command.ControllerCommandImpl and implementing the interface MyNewControllerCmd.

c. Create a CMDREG entry.

Eg:

insert into CMDREG (STOREENT_ID, INTERFACENAME, DESCRIPTION, CLASSNAME, TARGET)
values (storeent_ID,'com.ibm.commerce.sample.commands.MyNewControllerCmd', 
'This is a new controller command for the business logic tutorial.', 
'com.ibm.commerce.sample.commands.MyNewControllerCmdImpl','Local');

d.  Make the struts entry for the command.

Eg: 

com.ibm.commerce.sample.commands.MyNewControllerCmd" path="/MyNewCmd" type="com.ibm.commerce.struts.BaseAction"/> 

e.  Create the access control policy

Eg:

  CommandName="Execute">
  
 
   ResourceBeanClass="com.ibm.commerce.sample.commands.MyNewControllerCmd">
 
  
 

f. Stop server and load access control policies into database using acpload.bat file.

g.  Basic methods to be implemented in the implementation class

     i. setRequestProperties () - Method to set the request parameters.

     ii  validateParameters () - Method to perform validations of request parameters.

     iii  performExecute () - Method holds the business logic. 

h. The command can now be executed with the following url

http:///webapp/wcs/stores/servlet/MyNewCmd?storeId=

Controller Command (vs) Task Command

WCS Commands

Any business logic that should be executed on server is written in the form of commands in WCS.

Basic command types:

1. Controller Command

2. Task Command

Controller Command	Task Command
Holds the complete business logic for an action.	Holds a part of logic involved in an action i.e; to execute a specific task.
Can be executed as an independent request.	Cannot be executed as an independent request but should be invoked from another command.
Needs resource level access control policies to be defined and executed.	Does not need access control as this is executed from a controller command which already has the policies defined.
Can be defined specific to a store.	Can be defined specific to a store.
Can be cached	Can be cached
Example: UserRegistrationAddCmd is used to Register a user.	Example: UpdateCredentialsCmd is invoked from UserRegistrationAddCmd to encrypt and update the credentials of the user.