Mega Menu

Friday, November 22, 2013

Store and Archive Messages in WCS

Any email or sms or content in any form sent from Websphere Commerce (WCS) using the Out of the Box (OOB) messaging framework through any transported can be stored and also archived.

Eg: Order Transfer to External systems, Sending Emails, etc..

Pre-conditions :


1. While creating the message type, make sure the below option is selected





This selection updates the column PROFILE.ARCHIVEMSG to 1

2. Configure the message transmission as async in the wc-component-client.xml configuration file.


Eg:

<_config:invocationservice>
    <_config:invocationbinding bindingimpl="com.ibm.commerce.foundation.internal.client.services.invocation.impl.JCAInvocationBindingImpl">
     
    <_config:action asynchronous="true" name="MyMessageAction">
     
  (OR)

If you are directly using Messaging class to send messages, invoke

Messaging.sendTransacted ()

which sends a message asynchronously.


 Additional Info:
Messages that are sent to any external system can either be synchronous or asynchronous. In WCS messages can be sent using the task command SendMsgCmd which internally makes use of Messaging class to compose, load config and send messages through the specified transports.

If a message is marked as asynchronous, SendMsgCmd invokes the sendTransacted method of Messaging class which just saves the composed Message as a BLOB object into table MSGSTORE

 The scheduler command SendTransactedMsg, when kicked in scans through the table MSGSTORE and then sends the valid messages (leaving the expired messages) accordingly.
The scheduler in addition checks for the flag PROFILE.ARCHIVEMSG and accordingly arhives/not the message. If this flag value is 1, the message will be sent to an archive table MSGARCHIVE after successful transfer. 







Tuesday, January 15, 2013

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.