Failure Reasons and Import Workflow

[#1]

Hi,

Basically, I had two questions, since I am integrating my MTA server with adobe, upon delivery I need to trace back the stats back to adobe for reporting.

1. With resp to failure reasons, like mail box full, not connected, refused, unreachable, what table should I refer to insert the values? Would it be directly 'nmsdeliverylogstats'? Any other tables I need to take care?
Because the delivery success / failures I am inserting in 'nmsbroadlogrcp' table and they auto populate in 'nmsdeliverylogstats'.

2. Is it possible to import / create work-flow in a way to insert the entries in above 2-3 tables at the same time? Currently, my work-flow just inserts entries into 'nmsbroadlogrcp'. Any reference for example?

[rohanpat · Accepted solution]

Hi @rohanpat ,

You need to update the failure reasons in the nms:broadLogMsg schema, linked to the nms:broadLogRcp schema with msg-id field. Below screenshot should help.

 For your second question, the answer is yes. How exactly are you receiving the response from the custom MTA? API, files, or something else. Based on that you can build a mechanism to update all tables with proper linked items.

Cheers.

[rohanpat · Accepted solution]

Hi @isahore, Thanks, will check out the first solution with resp to table. For import, the custom MTA is dumping the data in text files, which I map to corresponding fields in adobe for insertion in broadlogrcp table. But I didn't find a way or option to have import / insertions in multiple table at the same time. Could you please let me know the steps or attach a snap pic for better understanding.

[rohanpat · Accepted solution]

Hi @isahore, I inserted values into nmsbroadlogmsg table with resp to failures, but don't see them getting updated in nmsdeliverylogstats table. As a result nothing's available on UI reporting with resp to unreachable, mailbox full, etc and corresponding hard / soft bounces.

[isahore · Accepted solution]

Hi @rohanpat,

If you are able to insert records into the nms:broadLogRcp and nms:broadLogMsg schemas correctly, then the last thing you need to do is execute the RecomputeStats method of the nms:delivery schema.

Specifically for updating the error stats, below is the syntax

nms.delivery.RecomputeStats(73061911,2); // first parameter is the delivery Id, second parameter is the integer (enum) value for the type of stats to update.

Details on this page: https://docs.adobe.com/content/help/en/campaign-classic/technicalresources/api/sm-delivery-Recompute...

For updating both tables in one workflow, you need to first insert records with relevant fields in the nms:broadLogMsg schema first, and then using the primary key returned in the targetSchema from this step, insert records into the nms:broadLogRcp schema with the remaining relevant fields. See the flow below. This might help.

Cheers,

Ishan

[rohanpat · Accepted solution]

Thanks @Ishan. To this, how could brodlogmsg table be useful since it just has the operator level info. Like say, I have 7 email domains in my delivery and 2 of them fail, how this could be differentiated in broadlogmsg table, we we just have operator who has scheduled delivery info with msgid been common for all associated deliveries by operator. Further, could we use nmsaddress table? Correct me here, As per my understanding there's no direct way to insert hard / soft bounce stats. Both hard / soft bounces total / percent is auto calculated by Adobe system based on the failure reasons. For example - softBounce = @unreachable + @mailBoxFull + @invalidDomain + @disabled + @notconnected + @refused The flow might be : 1. Upon delivery, entries go into nmsaddress table where we have a column (saddress) consisting of email address associated with a particular deliveryID. The column 'iquarantinereason' could indicate the different failure reasons. This table might have daily clean-up activity since I could only see data for following deliveryID in QA while its empty in prod. 2. After step 1, in the background Adobe system might have a job running that dumps data into nmsdeliverylogstats table. Here we have all the failure columns associated with domains (sdomain). Say our email delieries were to rohan@gmail.com, rohan@yahoo.in. 'nmsdeliverylogstats' table will get the associated domains from 'nmsaddress' table and dump into 'sdomain' column as gmail.com and yahoo.in. In case unknown user failure was recorded for rohan@gmail.com, gmail domain would have that count against other domains. 3. There are other tables like 'nmsdelivery' and 'nmsbroadlogmsg' of which we aren't that sure now. 'nmsbroadlogmsg' table does have failure reason and failure type columns but its associated to single operator based on msgID. Adding / updating this table doesn't look correct if rohan@gmail is failure while all others are success. Also here issue is most of our deliveries are associated with same msgID (operator base). Not sure how to filter.

[isahore · Accepted solution]

Hi @rohanpat,

nms:broadLogMsg table is used to store further information related to delivery send-outs. By default it does not contain much information about success deliveries, since the @status column in nms:broadLogRcp table tells us that the message was successfully sent. It does contain further information about the error deliveries. If you see carefully, these two tables are linked on the @msgId field (primary key of nms:broadLogMsg). There can be multiple messages which failed but due to same reason (mailbox full, invalid domain, etc.). Only one entry in this table can be linked to multiple records in the nms:broadLogRcp table to tell us more about the reason of failure.

In your case, you can use this table to store more information about failure (or even successful) deliveries. The choice is yours.

However, the table nms:address only contains information about email addresses which are either quarantined or blacklisted due to x,y,z reason. This table is checked by the typology rules to filter out any recipients from the delivery target which are either quarantined or blacklisted. This table does not contain any delivery level information per recipient. Moreover, entries into this table would also be made automatically based on the error qualification for a particular email address in the nms:broadLogMsg table (not 100% sure though).

Delivery success or failure stats are calculated by the RecomputeStats method run on every delivery automatically at one or several points in time. But if you want your custom MTA feedback to reflect correctly you need to execute this method on your own (not sure if the automatic job that recomputes these stats for every delivery will take your MTA feedback into consideration, better be safe and do it yourself).

Let me know in case of further doubts, will try my best.

Thanks,

Ishan

[rohanpat · Accepted solution]

Thanks @Ishan for the explanation. I did follow your steps but no luck. Instead of going via import work-flow route, I manually inserted new entry in nmsbroadlogmsg table with mailbox full error against soft bounce event code, based on msgId, inserted similar kind of record in nmsbroadlogrcp with other details like success / failure and deliveryID. Now my expectation was in the background Adobe's job would insert the related entries in nmsdeliverylogstats but that wasn't the case, as a result UI didn't had the related reporting. Could you please suggest where am I going wrong and my understanding with the flow is correct? I did vice versa as well... like inserting first in nmsbroadlogrcp followed by nmsbroadlogmsg, but didn't succeed.