In the past, there have been a few incoming problem records (PMRs) about messaging, such as why emails are not being sent, and why messages are being lost.  So, I would like to spend some time talking about these common questions that I hear about messaging.

Messaging is not new in WebSphere Commerce.  However, it has been evolved, from the XML message integration to later "simple" inbound web service.  Essentially, debugging requires you to understand how the underlying process works and how to interpret tracing.

First of all, you have to understand if you are dealing with an inbound or an outbound message.  An inbound messages refers to a message that feeds into WebSphere Commerce.  An outbound message is the one that is sent out from WebSphere Commerce.

If you are dealing with an outbound message issue, a common question is: "Why are messages not being sent?"

Ask yourself, how are the messages created?  Is the message generated by a customized command or an out-of-the-box (OOTB) command?  If this is an OOTB command, enable WC_SERVER tracing (if it is a production environment, enable tracing during a non-peak hour) to see if the command is being run.  It may also be helpful to enable component-specific tracing (such as WC_USER if this is a registration type email).

Since most messages are being sent by an OOTB command asynchronously by sendMsgCmd.sendTransacted(), you can do a quick check on the MSGSTORE table.  If no such message is persisted on that table, it is highly likely that the command is not being run or a transaction rollback occurred.  If MSGSTORE contains the message, it's time to find out why messages are not being processed.  Check the SendTransactedMsgCmd scheduler job.  WebSphere Commerce relies on this scheduler job to scan through all messages (entries) in the MSGSTORE table and process them.  Since each entry contains a java persisted version of the Message class, processing involves un-persisting the Message class, extracting the method of sending the message, and then the actual transmission can occur.  I often see cases where the user forget to schedule the job, or sometimes the job is not being run even though it is scheduled.  The latter case usually happens if the job is configured to run on a specific host (it's possible but not trivial to get it working).  Even if the scheduler job seems to be running, you may want to check the log for errors since a misconfiguration (such as the wrong hostname for the SMTP server) could prevent the message from being sent.

Another problem I see on occasion is that the same message is sent multiple times.  One possibility for this is when these two conditions are met:

1. The batch size of the sendTransactedMsg scheduler is set to a number higher than 1 (which is normally the case for performance).
2. There is a message that failed to be sent.

When these conditions happen, all messages that have successfully been sent (for example entries before the problematic entry) will be processed again during the next attempt when the job runs again, thus causing the same messages to be sent.

In this blog post, I have shared my thoughts on performing some problem determination for an outbound message issue.  In a subsequent posts, I plan to discuss more about my experience with inbound messages and some general observations of messaging in WebSphere Commerce.  In the near future, I also plan to discuss other areas in WebSphere Commerce, such as the catalog and component service.

Tags:  inbound sendtransactedmsgcmd commerce websphere msgstore messaging ootb outbound