I am trying to store a delivery property via the ootb map:recipient target mapping. The goal is to store a delivery level attribute within the nms:broadLogRcp at the time of delivery. Is it possible to access these delivery level properties within this context? How would this be referenced?
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @cavallo714 ,
Another solution that I can suggest is to have a workflow that runs once in the midnight, at a time of low activity, reads the attribute information from delivery and then updates the delivery broadLogs with the information.
Reason I'm suggesting to run in the night is that, if you run it every hour, it will cause unnecessary locks.
Regards,
Vipul
Anyone happen to know if this is possible? I know that you can reference delivery attributes within the context of the delivery content, so I believe it should be available to store in the broadLog via the target mapping.
Views
Replies
Total Likes
Hi cavallo714 ,
Each delivery log is already associated with the delivery schema. Can you please elaborate more on why will you like to duplicate the data in two places.
For your future data consumption, you can select the broadLogRcp of choice and then traverse through the linked Delivery schema to get the relevant details.
The screenshot you have shown here is to store targetData into the broadLogRcp table.
If this delivery parameter is known to you in advance, please use an Enrichment on the workflow to add targetData element and feed it there.
Hope this helps.
Regards,
Vipul
Views
Replies
Total Likes
Hi Vipul,
We are storing delivery level data in the broadLog because we are running a sysFilter on the marketing history data based on a custom attribute set at the delivery level. We do not want to have to run the filter on the delivery attribute through the join, because of performance reasons (The broadLog contains a lot of data Especially with this clients requirment to store for many years). Also, i believe the retention of broadLog data is different than that of delivery data, which is another reason why we wanted to duplicate the data in the broadLog, so We wouldn’t not be reliant on the delivery data.
I was afraid that the only way would be by adding it to the workflow targeting data, as I have done something similar in the past of storing a workflow set segmentCode in the broadLog
Views
Replies
Total Likes
Hi @cavallo714 ,
Another solution that I can suggest is to have a workflow that runs once in the midnight, at a time of low activity, reads the attribute information from delivery and then updates the delivery broadLogs with the information.
Reason I'm suggesting to run in the night is that, if you run it every hour, it will cause unnecessary locks.
Regards,
Vipul
Views
Likes
Replies
Views
Likes
Replies