Handling concurrent updates to Qualtrics IDP | XM Community
Skip to main content
Solved

Handling concurrent updates to Qualtrics IDP

  • August 29, 2024
  • 2 replies
  • 68 views
M
Forum|alt.badge.img+1

I am storing a history of messages (think of a chat app) in a Qualtrics Imported Data Project record. Since there’s no relational data support, I am storing the conversation as a stringified JSON array.

 

When someone adds a new message, it triggers a Qualtrics workflow, which:

  1. Fetches the conversation history
  2. Adds the new message
  3. Stores the new conversation history

 

A problem arises when two messages are sent at the same time. The second update overrides the first update. Any solution?

Best answer by chackbusch

@Mitchell Sokol Interesting topic… I would actually see this kind of queuing on sender side to achieve some synchronous processing. But I get that this does not solve your issue. 

When I think about it, I always end up at a dead end. For example, I have considered whether it would be possible to block an entry until processing is complete, for example by setting a flag on the entry. However, if two requests are processed asynchronously, checking the flag doesn't help much…

Creating one entry in the imported data project for each message (all having the same ID for the same chat to group them) with exact timestamps (millisecond level) will also not be possible in your setup I guess? This would avoid overwriting, based on the chat ID you could group and based on the timestamps you could sort. However, you would lose the concatenated chat protocol. 

Let me sleep a night over it. 

2 replies

chackbusch
QPN Level 5 ●●●●●
Forum|alt.badge.img+22
  • chackbusch
  • QPN Level 5 ●●●●●
  • Answer
  • August 29, 2024

@Mitchell Sokol Interesting topic… I would actually see this kind of queuing on sender side to achieve some synchronous processing. But I get that this does not solve your issue. 

When I think about it, I always end up at a dead end. For example, I have considered whether it would be possible to block an entry until processing is complete, for example by setting a flag on the entry. However, if two requests are processed asynchronously, checking the flag doesn't help much…

Creating one entry in the imported data project for each message (all having the same ID for the same chat to group them) with exact timestamps (millisecond level) will also not be possible in your setup I guess? This would avoid overwriting, based on the chat ID you could group and based on the timestamps you could sort. However, you would lose the concatenated chat protocol. 

Let me sleep a night over it. 

Driving Qualtrics @ MHP – A Porsche Company 🚀
M
Forum|alt.badge.img+1

@Mitchell Sokol Interesting topic… I would actually see this kind of queuing on sender side to achieve some synchronous processing. But I get that this does not solve your issue. 

When I think about it, I always end up at a dead end. For example, I have considered whether it would be possible to block an entry until processing is complete, for example by setting a flag on the entry. However, if two requests are processed asynchronously, checking the flag doesn't help much…

Creating one entry in the imported data project for each message (all having the same ID for the same chat to group them) with exact timestamps (millisecond level) will also not be possible in your setup I guess? This would avoid overwriting, based on the chat ID you could group and based on the timestamps you could sort. However, you would lose the concatenated chat protocol. 

Let me sleep a night over it. 


Thanks for thinking about this. I may end up creating my own API to manage updating the Qualtrics IDP. Probably I can implement some locking mechanism in my .NET API.

Terms & ConditionsAccessibility statement