I am starting to build a new Survey 123 Connect that will be used to document what vehicles a GPS tracking device will be installed in. The Primary Key to the resulting Feature Layer needs to be the IMEI of the Device, the Secondary Key will be the Vehicle ID. I plan to use Connect so I can scan the Bar Code IMEI on each device.
Since I want this to be a collection tool I do not plan to use the inbox. But how do I control the issue of a potential duplicate primary key if a unit is moved from vehicle one to vehicle two and rescanned/inputted twice into the system?
TIA - -
Solved! Go to Solution.
Just a quick update --
I went with the Webhook approach and maintained the Feature layer and a separate PostgreSQL table.
---
There are a ton of ways you could handle this, but hard to say what is best for your business case. How will you be ingesting this data? I assume there are more steps to this process beyond getting the data into Esri?
We have a brand new fleet that will need a similar system soon. These were the top two things that came to my mind when i was thinking of this same thing:
Thank you for the reply --
Yes, there are a ton of different ways to handle this, but for this new install/fleet of trackers, I have 66 devices so the inbox is just much too cumbersome. If this was a Web Page I would get the IMEI (Primary Key here), do a look on the DB, and if it's already present populate the form and treat the submit as an update instead of an insert. That's what I would like to do here, treat any submit with an existing key as an update.
Instead, right now, I think I will place a Webhook on the submit and then use the rest API to delete any older entries for the same primary key from the target of the Webhook.
Using this data to enrich the transactions coming in through the feed in velocity will be straightforward with a join node using the IMEI as the common key.
Just a quick update --
I went with the Webhook approach and maintained the Feature layer and a separate PostgreSQL table.
---