Q2 Customer Support

The issue happen can be happen due database server issue (down, slowness, etc) meanwhile IFM detection still can be done without database connection since it done internally in AIS using synchronous mode, and the data will be stored in internal queue (broker) to be distributed to database using asynchronous mode using below steps.
a. Internal Queue data inserted into DB_QUEUE table (raw data of alert)
b. alertQueueListener service take data from DB_QUEUE table to distributed as alert to RCM.

This no alert condition could be happen due one or all of above points a and b weren't executed successfully.
This can be confirmed by running below query:
select * from IFM_APP.dbo.DB_QUEUE

If you can find the data in that table coming from today having NUM_TRIES=10, means point a above was executed successfully and you can try to update the NUM_TRIES=0 so alertQueueListener can grab the data and distribute the alert to RCM. But, if you cannot find the data from today's date, what we can do is to manually unhold using application we've sent earlier (if there is transaction in hold status).

You might verify from server.log and find for the timing that match with the transaction datetime being questioned:

From explanation before, data insertion to DB_QUEUE table failed to be performed due connectivity issue hence no alert distributed even the transaction was eligible for alert. Unfortunately we have no way to generate an alert again for the missing transaction inserted to DB_QUEUE table.