Data wrongly mapped in Twoway Sync

1

Hello Robert,

We are working upon a two-way sync connector where the record should sync by Ids, for that we are following below connector flow.

  1. A connector between 360 & DP
  2. We have created a custom field named “inst_id” in 360Alumni to store DP’s record id.
  3. We have created a custom field named “360Alumni Id” in DP to store 360Alumni’s id.
  4. Created record in DP side, DP trigger triggered that record. [Record ID = 1]
  5. 360 Two way action search the record containing inst_id 1 [Inst_Id==1]
  6. If found then retrieve record id and perform the record update process
  7. If not found then create a new record in 360 and return record id [Record Id = 11]
  8. Update record Id [Record ID 11] retrieved from point 7 into DP Record [retrieved into point 4] [Record Id 1]

Pont 4 to 8 will remain the same for the flow to DP to 360Alumni Side.

However, solution architecture image attached here

image
image1366×768 147 KB

While testing above flow, initially it’s working expectedly and mapped correct sync id’s but after few hours we are seeing that same record id’ mapped with
other Record_id’s too. We have tried to analyze this issue and verified the logs of each execution. Can you please help us to understand where could be the root cause?
or is that anything logged into the system for this scenario? like from which execution it got mapped with another id so I can explain to the customer with logs

Account : dhruvit@apiant.com [development]
Automation Uuid : 8522431d8b2a40508a3465b461208dbb
Dump Link : https://dev.apiant.com/appServices/dumpAutomationDatabase?tenant_uuid=&automation_uuid=8522431d8b2a40508a3465b461208dbb
Wrongly Mapped Id:
360Alumni Id = 541424
DP ID = 8446
DP ID = 6

Thank You
Dhruvit

2

Hi Dhruvit,

At a high level, this is the only module that writes a new 2ws mapping into the database:

image
image2352×2098 346 KB

The 2ws mapping is only written into the db when the subassembly does not return an “EXISTING” record. So the presence of multiple mappings would mean something is amiss with the subassembly being executed. The 2ws “add” subass is only executed when the 2ws trigger indicates it is a new record. Otherwise, the system won’t execute the “add” subass when a 2ws mapping exists b/c the system knows both records exist and an “add” can’t possibly be needed.

I see that the 360 2ws trigger is using the deprecated module:

image
image1480×1186 102 KB

I would start by replacing that with the latest version. If the trigger assembly is being used in a production integration, then make a new a copy so you don’t impact production.

Another thing is that your automation logic looks badly wrong to me. A 2ws automation should look like this:

image
image772×2116 159 KB

The condition checks to see which trigger was fired. Then each branch processes 2ws for each app.

I recommend you make the suggested changes and reset the automation to empty out all the mappings to start fresh. Then do your testing step-by-step, checking the database dump after each step to make sure you see the expected 2ws mappings. When you don’t, then you can more easily check the last logs to try to figure out what went wrong.