OK, got this working with 5 minutes to spare.
I can create a device using the API and link it to a repository device so that it picks up the repro formatter. And I can grab the info from v2 to transfer over the details.
I tried using the migration tool and added in the repro device’s extra info and run in to some issues with the session information not being correctly formatted which I suspect may be a mis-alignment between the tool & the console or maybe just a bug. It seems odd that the migration tool doesn’t yield a JSON file that can be imported without modification. But having copied over the session info I could then import using the console. It may be unique to the device I happened to have data for.
So there are a number of ways this can be done. I’m working on a GUI tool that drives the migration and the main CLI apps as a general purpose visual migration interface. It’s easy enough to slot in the appropriate device repro once data has been pulled out of v2.
So I guess there are two things:
- Debug the session info issue
- Find out where people are with preferences for a user interface (CLI or basic GUI) and timescales.
All this said, I’m not entirely sure I can see the benefits of having a device migrated & attached to a repro device just to pick up the payload formatter - if you have many of a device, I’d be inclined to putting the formatter code in at application level so you have some control over the formatter. I’ve not yet established what happens if the repro is updated - whether there is any level of change control in the application server. So one other potential is to not link to the device repro entry but grab the formatter and set that up in the application.
I can see the utility of the device repro for new entered-by-hand devices but for bulk entry from a spreadsheet or database it seems a bit moot excepting there is an element of using the CLI to download device info but bizarrely, you can’t use the search function to search by brand or model number.
More in the morning!