Expand my Community achievements bar.

SOLVED

"Event not covered" for transactional message

Avatar

Level 1

I am trying to test transactional messaging (sending an email by SOAP request) to no avail.

What i did:

- created a template, type (called "t3") according to the steps in the documentation file "message-center-v6.1-en.pdf".

- Created the event "t3"

- published the template

- sending a proof worked perfectly

Then i created send SOAP message to the server with "Boomerang SOAP & REST client". This worked after using the content of a cookie "__sessiontoken" as "sessionToken".

Request looks like this.

l got back a response with HTTP code 200 (success) with this content:

In the event history of the message center i see the event (see screenshot), but it is marked as "Event not covered" and no email is sent.

Screen Shot 2016-07-26 at 13.29.41.png

I do not see any entry in any logfile i searched on the server for this event.

Apparently the server cannot associate the request (type="t3") with the template for some reason. Event type of the template is "t3", as you see in this screenshot:

Screen Shot 2016-07-26 at 13.34.23.png

Server works OK for workflows, but just not for transactional messages via SOAP (proof sending works also). We are using a linux machine for the server.

Additional info

in the Audit log of the Workflow "Processing real time events" i see "[Routing] 1 message(s) with errors" (see screenshot).

But i cannot find out what the actual error was. How is this done?

Screen Shot 2016-07-28 at 15.39.17.png

Does anybody know what's (not) going on here? Is there any place on the server where i can see what is going on?

any help appreciated

Hermann

1 Accepted Solution

Avatar

Correct answer by
Level 1

Hi Linda,

Both "Transactional Message Control" and "Transactional Message Execution" Packages are installed on one instance. Template was successfully published. So i assume that both Control and Execution instances are set up correctly, see also the screenshots above.

I will do a fresh server install of Campaign 6.1 soon (on Redhat 7 w PostgreSQL). Which Packages are the absolute minimum to get transactional messages working? Do they have to be installed on the same instance or is it necessary to set up separate instances with each contains one of these packages?

Hermann

View solution in original post

14 Replies

Avatar

Employee

Hi Hermann,

You are correct that the Event not covered error means that no Template is being found that matches the event type specified in your SOAP call. Do you have separate Control and Execution instances? Did you successfully publish your Template?

Linda

Avatar

Correct answer by
Level 1

Hi Linda,

Both "Transactional Message Control" and "Transactional Message Execution" Packages are installed on one instance. Template was successfully published. So i assume that both Control and Execution instances are set up correctly, see also the screenshots above.

I will do a fresh server install of Campaign 6.1 soon (on Redhat 7 w PostgreSQL). Which Packages are the absolute minimum to get transactional messages working? Do they have to be installed on the same instance or is it necessary to set up separate instances with each contains one of these packages?

Hermann

Avatar

Employee

You do not have to install them on separate instances; Message Center can work either way. From what you have shown me, it appears that things are configured correctly. If you would like to request office hours, we could look around your instance and I can see if anything looks unusual. You might want to try making the API call with the minimum set of rtEvent attributes. I think only email and type are needed. Just in case the API call is trying to match on any other information that you are including. But I am not aware that it does this.

Linda

Avatar

Level 1

Hi Linda,

thanks for your help: i will use just the minimum required attributes ona freshly installed server and see what happens.

Hermann

Avatar

Level 1

Hi,

I do have same issue. Can you please elaborate how this issue got fixed?

Thanks,

Jrs

Avatar

Level 1

Hi,

did you find root problem, why this is happening? It seems that I have the same problem.
So, could you help me with solving this issue?

BR,
Aga

Avatar

Employee

Hi Hermann,

Please share the root cause/solution for this problem. I am also facing the same issue in my local instance.

Thanks

George

Avatar

Level 2

Hi,

Kindly check the event type when you passed in the SOAP Call. The event type should match the event type internal name(administration->Platform->Enumerations->eventType->t3). This would help for Event not covered problem.

Thanks,

Malarrajan Sundarraj.

Avatar

Employee

Hi Malarrajan,

Thanks for the reply. Yes i already made sure the eventType internal name is used correctly in the soap call.  But still the error is coming from my v6.

Avatar

Community Advisor

For future searchers, I fixed same error by moving the published templates folder so it's under /Administration/Production/Message Center/Default

The messageCenter.js code is looking at these fields:

[triggerMessage/@eventType]

[@messageType]

[folder/@fullName]

[triggerMessage/@publicationStatus]

[@isModel]

[mapping/@name]

Where [folder/@fullName] was testing "LIKE ('/Administration/Production/Message Center/Default/'+ '%')" instead of the ootb path.

Avatar

Employee

Hi Jonathon,

That is interesting. Do you think it is a bug in that build or misconfiguration in the training environment?

Linda

Avatar

Community Advisor

Happened in a fresh 8853 install. A better fix might be to change the mc operator's home folder (under access rights), as that's where that path comes from.

Avatar

Employee

I too faced similar issue but later figured out that when we don't login as the message center agent and issue the soap request, then i got this "Event Not covered error". Once i changed the login to the message center agent and changed the appropriate session and security token and then issued the soap call, the transactional message did went through.

Avatar

Employee

If you are using a user other than the mc user provisioned for the RT instance, this issue could happen due to lack of folder access as well. The new user should match mc user Folder access levels.