Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

Write quaratine to Message Center Execution instance

Avatar

Avatar
Validate 1
Level 1
PLundmark
Level 1

Likes

0 likes

Total Posts

11 posts

Correct Reply

0 solutions
Top badges earned
Validate 1
View profile

Avatar
Validate 1
Level 1
PLundmark
Level 1

Likes

0 likes

Total Posts

11 posts

Correct Reply

0 solutions
Top badges earned
Validate 1
View profile
PLundmark
Level 1

20-05-2021

I need to write to the address schema (quarantines) on the Message Center execution instance due to spam trap hits. I will in practice write quarantines present on the marketing instance to the message center instance since there is no sync out of the box.

 

I've tried to run the below code in a workflow but get error: INT-150012 The HTTP query returned a 'Forbidden' type error (403)


I use the same connection information to query for current quarantines in message center in another workflow.

 

How can I make this work to write to nms:address in execution instance?
Is it just a matter of getting credentials to a login with admin (write) permission on the execution server.

NOTE: Code and error example updated after adding try catch and changing from NlElement to string as input param.

 

//--ACCOUNT AND LOGON DATA
var extAccount = instance.vars.extAccountId;
var rtCell = NL.ExecutionInstance.getExtAccount(extAccount, NL.ExecutionInstance.MESSAGECENTER_TYPE);
if( !NL.XTK.parseBoolean(rtCell.@active) ) { logError("account disabled");}
vars.login = String(rtCell.@account);
vars.password = String(rtCell.@password);
vars.url = String(rtCell.@server);

//-----INIT CONNECTION----
document.cnx = new HttpSoapConnection(vars.url + '/nl/jsp/soaprouter.jsp', 'utf-8', 0)
document.soapSrv = new SoapService(cnx, 'urn:xtk:session')
document.soapSrv.addMethod('Write', 'xtk:session#Write',['object','string'],[])
var tokens = NL.ExecutionInstance.logonRemote(vars.url, vars.login, vars.password);
document.cnx.addTokens(tokens["sessionToken"], tokens["securityToken"]);

//WRITE ADDRESS
var newAddress = "<address type='0' status='4' address='peter@example.com' quarantineReason='2' xtkschema='nms:address' _operation='insertOrUpdate'/>";
//xtk.session.Write(newAddress); //Test if object can be saved in marketing instance
try{
document.soapSrv.Write(newAddress);
}
catch( e )
{
if( e.soapFault ) logInfo("A SOAP Fault occured : " + e.soapFault.toXMLString());
else logInfo("An error occured : " + e);
}

//--------END------------
document.soapSrv.dispose();
document.cnx.dispose();

Accepted Solutions (0)

Answers (1)

Answers (1)

Avatar

Avatar
Boost 10
Level 3
CedricRey
Level 3

Likes

24 likes

Total Posts

62 posts

Correct Reply

11 solutions
Top badges earned
Boost 10
Applaud 5
Boost 5
Affirm 5
Give Back
View profile

Avatar
Boost 10
Level 3
CedricRey
Level 3

Likes

24 likes

Total Posts

62 posts

Correct Reply

11 solutions
Top badges earned
Boost 10
Applaud 5
Boost 5
Affirm 5
Give Back
View profile
CedricRey
Level 3

25-05-2021

Hello PLundmark,

 

I'm very interested with your question : it could be relevant to do what you intempt ! Specialy with spam trap.

And what I see with your code is good to me, you seem to do it right.

But I'm affraid that is not possible : I'm not surprised to see that you don't have the right to write datas from mkt instance, for evident security reasons.

 

One thing to know : the quarantine / nms:address are handle by the Message Center instances. So if someone attemps to send real time messages to them, it will be quickly stoped (usually after 1 attempt) and then reject by the MC instance.

Also, the quarantines are synchronised with you marketing instance (via the mcSync workflow)

 

But I agree : why if the quarantines are synchronised in one way, it's not the case on the other way? And if the marketing instance is aware of spam trap adresses, it could be relevant for the delivrability to share this information with MC instances.

 

If the message center instance is managed by yourself, you could try to synchronise the quarantine from the MC instance (by reading and writing the nmsAdresses from it, instead of writing from the mkt instance) with a local account ?

 

Sorry to not giving more help...

Cedric

PLundmark
Thanks for your reply Cedric.
PLundmark

Thanks for your reply Cedric!

There are proven spam traps quarantined in the marketing instance and the message center will most probably send to these addresses. This is why it is important, at least as a one time migration, to get the quarantines from the marketing instance into the message center instance.

 

Adobe is hosting - hence the issue. I have asked Adobe to perform the import but they refuse.

If I had direct access to the execution instance it would be a very easy operation to just insert these into the database. 

 

/Peter

LaurentLam

I would even say that Message Center has never been designed for handeling correctly the quarantine functionnality:

Marketing instance

Message Center 1 (RT1)

Message Center 2 (RT2)

I know that kind of configuration is quite old today but always used for lots of customers

 

RT1 have "badEmail@homail.com" in its quarantine table
RT2 have "wrongEmail@gmal.com" in its quarantine table

 

It means that if your API call with "badEmail@homail.com" lands on RT2 (due to load balancing): the email sending will proceed

Now, as you know, both of these addresses are consolidated on marketing instance... But then, it will only helps your standard "batch" sendings

 

It means that the only way to address the issue is to build a custom API that will query the nmsAddress schema from your marketing instance with a queryDef (don't forget to check the correct status in your "where" clause) to check if the email address in parameter exists... And that will proceed the pushEvent method to the Message Center load balancer

 

Problem of this kind of integration is that it implies a robust architecture: I would suggest to deploy a dedicated webserver process for soaprouter.jsp: too many connections could lead to make web process failing in memory...

Or you could even imagine to execute directly a stored proc on nmsAddress table directly from your API... But take really care about possible deadlocks


For that kind of tricky issue... Adobe addressed it by promoting the "one RT message center instance": no more synchronization issue about nmsAddress ^^

In the end, if you have a deliverability consulting package with Adobe... I'm quite sure that they will be happy to integrate your CSV file on RT instance(s)...