Some Maximo implementations massively rely on email communications to notify users about important events like new tickets or assigned tasks. Sometimes outbound emails are also used to implement integration or notify external parties about relevant events. In such environments, it is important to avoid that a planner or unplanned email server downtime results in a bunch of emails not being sent.
Maximo relies on Communication Templates to send emails. There is an important field in the Communication Templates application called Track Failed Messages. This flag allows to specify if failed email messages should be logged in the COMMLOG table.
Unfortunately, Maximo does not retry to send failed emails automatically but this can be easily achieved with few configuration steps. I will show you to configure an escalation to automatically retry failed emails for the WORKORDER object.
When the Track Failed Messages option is selected on the Communication Template, a row is saved in the COMMLOG table with the ISSENDFAIL field set to 1. This can be used to create an escalation that will look for such records and trigger the built-in SEND_FAILED action that will try to send failed messages. Lets see how to do it.
- Escalation: SEND_FAILED
- Description: Send failed messages tracked in COMMLOG
- Applies To: WORKORDER
- Condition: workorderid in (select ownerid from commlog where issendfail=1 and ownertable=’WORKORDER’) and changedate>sysdate-10
- Schedule: Every hour
- Escalation Point
- Repeat: Yes
- Action: SEND_FAILED
A short note is worth to explain the where clause and the schedule configurations. There may be reasons for a failed emails that are not related to technical problems with the SMTP server. For example, there could be a communication with an empty recipient list. In such cases the escalation will keep retrying forever. I have tried to minimize such problem in two ways.
- Setting the schedule of the escalation with a lower frequency. I think 1 or 2 hours are a good tradeoff.
- Forgetting record updated many days before. I my example the where clause is selected work orders updated in the last 10 days.
One last consideration. The SEND_FAILED action will resend only failed messages but you should be careful when activating this escalation in any environment (development, test or production). If you have a lot of unsent messages in your COMMLOG table it can spam users with a lot of emails. Before activating the escalation, you should run the where clause in an SQL client with a query like this.
select * from workorder where workorderid in (select ownerid from commlog where issendfail=1 and ownertable='WORKORDER') and changedate>sysdate-10;
Hi Bruno,
the last SQL command can be changed to the more efficient one:
select * from workorder where exists (select 1 from commlog where ownerid = workorderid and ownertable = woclass)
Hi Bruno,
Very nice. Is the SEND_FAILED a java funciton that could be called in script? If so I assume you could create a script to run on a cron task to search for all COMMLOG records that are failed with any desired where clause and then loop over them with an “mbo.getOwner().sendFailed()”
Dave S
The SEND_FAILED is a built-in action that just runs the psdi.common.commlog.CommLogSendMessage Java action class.
Here is what it does.
public void applyCustomAction(MboRemote mbo, Object[] params) throws MXException, RemoteException
{
MboSetRemote commlogset = mbo.getMboSet(“COMMLOG”);
if (commlogset != null)
{
CommLogRemote commlog = (CommLogRemote)commlogset.fetchNext() ;
while (commlog != null)
{
if (commlog.getBoolean(“issendfail”))
{
try
{
commlog.sendMessage();
commlog.setValue(“issendfail”, false,MboConstants.NOACCESSCHECK);
} catch (MXException e)
{
commlog.setValue(“issendfail”, true, MboConstants.NOACCESSCHECK);
}
}
commlog = (CommLogRemote)commlogset.fetchNext();
}
}
}