Expand my Community achievements bar.

Announcing the launch of new sub-community for Campaign Web UI to cater specifically to the needs of Campaign Web UI users!

issue with delivery logs and indicators in a "One marketing environment for multiple midSourcing environment"

Avatar

Level 1

Hi all,
We have full on premise environment with an old build (8753):
1 prod marketing server linked to 6 midSourcing environement (through FDA external accounts)

In this build, we had to recreate our own defaultMidSourcingLog and defaultMidSourcingDlv workflows because of an issue:
As the reconciliation between midSourcing and marketing for the deliveries are done through the "mdiRemoteId" at nms:delivery level... When you have several times the same id on different midSourcing environments (example deliveryId "100" on midSourcing A & B) it creates an issue
example:
DeliveryId "1000" on marketing environment has been sent through midSourcing environment "A" and have now a midRemoteId "100"

DeliveryId "1001" on marketing environment has been sent through midSourcing environment "B" and have now also a midRemoteId "100"
Delivery indicators will be the same for both of those deliveries unfortunately

Is this issue has been solved in earlier builds (reconciliation with "external account + midRemoteId") or do I still need to use custom workflows?


3 Replies

Avatar

Employee Advisor

Hi LIamour,

 

Do you have an old ticket number by chance?  I could look up whether the issue was addressed if you had that or the R&D reference number that would have been provided if a ticket was opened up with Support.

 

Thanks,

Craig

Avatar

Administrator

Hi @Llamour,

Were you able to resolve this query by logging a support ticket or do you still need help here? Do let us know.

Thanks!



Sukrity Wadhwa

Avatar

Level 1

Hi,
Ticket number has been logged 2 years ago by Isabelle Riche for "Ventes Privees": TK140646
Pascal Hoarau also had the issue and created a ticket.
Both of those customers are using power booster architecture (with FDA technology to communicate with their mids) and tickets have been closed because "this BUG has beeb considered as an enhancement request": in both case, they just followed Adobe Architects team recommandations
This should have never been considered as a WAD because power booster architecture cannot work correctly with OOTB workflows.

So my question is then, is QA team already tested a powerbooster architecture (2 mids environment > 1 marketing instance through FDA connector) or never?

The aim is to use as much OOTB WKF in order to facilitate build upgrades