SendOrderConfirmationEmail questions

I've been experimenting with legacy code here recently and have some questions about order confirmations.

When sent from the client, order emails are logged in T_LOG_ORDER_EMAIL, so that they can be referenced in the Connections tab on the constituent. Orders sent via the API do not record here.

We currently have a SQL Job that, every 10 minutes, sends emails for all orders in that span, whether they are made through the client or web, however, since we also use TNMP, those order emails are never logged, and need to be excluded from the job by channel and/or MOS. 

This creates a bit of a mess, especially as I'd love to be able to wrap the email confirmations into either a single SQL job or even better, send from the web.

The API call also lacks any granularity for sending to owners vs initiators etc which seems like a missing piece in that piece of functionality.

Is the intended behavior from the Network that we must continue this customized behavior in order to have accurate information in the Contact Log?

Am I missing something?

Chris, New42

  • Hey Chris,

    I'm pretty sure you're not missing anything. I've raised this as a TNEW defect in the past, and the way that ticket was resolved was for the TNEW team, I believe, to submit an enhancement request to the API team for that logging functionality. I think it's a pretty obvious defect, but as we know, the SOAP api is in a strict maintenance state -- so the best we may be able to hope for is that the when the REST API gains coverage of this feature, it will finally have this functionality.

    Just a thought, but if you have enough information to exclude the TNMP orders from your SQL job, maybe you have enough information to reconstruct the T_LOG_ORDER_EMAIL rows that _would have_ been created by TNMP if it was able to? Not that it makes your database scripts any cleaner, but at least then your contact log would show all of the emails being sent.

  • That's the general direction I was leaning, Nick. I'm basically on the fence between rewriting the SQL job logic and writing a local procedure to replace the job completely, but that still leave TNEW / TNMP on the outside.

    The biggest issue with that cleanup, is that there's no way to actually see if the TNEW orders sent the confirmation successfully.