Highlighted
Absent Member.
Absent Member.
960 views

Eventout Reporting and Sending two notifications for one

I have a Interaction notification that is going out twice. I tested the notifications by falsing out others and I isolated it to being one particular line of a notification. For "SM Close" there is a notification that goes as follows and reports two e-mails in eventouts and sends both to the customer:

not null(contact.name in $L.file) and (callback.type in $L.file="Telephone" or callback.type in $L.file="E-mail") and rtecall("rinit", $L.rc, $L.tmp.screlation, "screlation") and rtecall("select", $L.rc, $L.tmp.screlation, "source=\""+incident.id in $L.file+"\" and source.filename=\"incidents\" and depend.filename=\"problem\"") and not null(contents($L.tmp.screlation))

 

If there is a related incident send a notification an e-mail to contact.name in $L.file, any suggestions?

0 Likes
6 Replies
Highlighted
Absent Member.
Absent Member.

Are the contents in eventout queue is exactly same?
Check you macros and master FC too.
____________________________________
Assign Kudo, if found post useful and mark it accepted if solves the issue.
0 Likes
Highlighted
Absent Member.
Absent Member.

Yes the Eventout is an exact copy of each record. It was occuring in all environments. As of yesterday it stopped without any changes outside the original test case of falsing it and then returning it to its normal condition to see if in the change it did or did not send e-mails.

It is working today, odd that it was happening in all 3 of our environments, dev, test, prod.

0 Likes
Highlighted
Absent Member.
Absent Member.

so all the notification are going twice or a particular one?
If later one then check the condition on which it is triggering and look for macro/FC of concerned table.
Also check the RAD trace to see what applications are executing when saving the record which is triggering the mail.


hth,
____________________________________
Assign Kudo, if found post useful and mark it accepted if solves the issue.
0 Likes
Highlighted
Absent Member.
Absent Member.

Access the SM Close notification record and add another entry which matches the isolated line. Use the following for the Condition column:

 

$L.void=rtecall("log", $L.code, "DEBUG JustinN")

 

Enable tracing (RTM:3 and debugdbquery:999) and replicate the issue.

 

If the log file contains two "DEBUG JustinN" entries, then that means the notification record is processed twice. The RTM:3 parameter (RAD work-flow) should identify why/where us.notify is running a second time.

 

If the log file only contains one "DEBUG JustinN" entry, then the second email is coming from somewhere else.

Highlighted
Absent Member.
Absent Member.

I know it's been awhile since i posted this but here is an update. The system seems to close the change twice. I added the debug to the notifications. The line is entered into the log twice along with the closing of the service desk Interaction. Any idea why that might be happening?

 

 

  1524(  3284) 01/09/2012 11:42:05  RAD I Interaction SD00301582 has been closed.
  1524(  3284) 01/09/2012 11:42:05  RAD I DEBUG Contact Line
  1524(  3284) 01/09/2012 11:42:05  RAD I Interactions record closed.
  1524(  3284) 01/09/2012 11:42:05  RAD I Interaction SD00301582 has been closed.
  1524(  3284) 01/09/2012 11:42:05  RAD I DEBUG Contact Line

0 Likes
Highlighted
Absent Member.
Absent Member.

Tracing the scenario with RTM:3 and debugdbquery:999 is an appropriate next step. The trace will identify whether the record is updated twice or if only the notification is processed twice.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.