Thanks a lot for the hints! Sorry for replying late, I was busy actually using your answer
- Yes, our listener is working, we’ve been using the Spring Scanner 2 thing.
- Thanks for reminding me about the dev mode, I had forgotten to enable it. With it I could indeed trigger app migrations and do a big part of the migration code (Still having some trouble with some mappings, but that’s for another question.)
- All the dev work we did until here was with forked versions of both the client and server apps. I’m not sure
getCloudAppKey() actually do anything, or if they do I have no idea what. I couldn’t get anything to work until they were both identical, matching the forks’ key.
The reward for a job well done is traditionally a harder job, so since you’ve helped a bunch I’ll ask some more on the same subject.
- We’d like to be able to test the Assess and Prepare steps of the migrations, without clients being able to see our partial progress until we’re ready. This would help make sure that we understand all that the clients will see.
- It would be very convenient during development to be able to migrate from the real server app (with the already-existing key) to a dev-only cloud app (the forked one, with a different key). We have a lot of testing data that is tied to the production app that would be pretty hard to migrate to a dev-only fork.
I couldn’t figure out a way of doing either of these using the
DiscoverableListener API. I’m wondering if the Marketplace Migration API (MMAPI) would help.
What I would like to do is to send to the MMAPI for our public app’s key a set of
AppMigrationInformation that uses the development fork of the cloud app as the
cloudAddonKey and sets
PRIVATE. (I’m not exactly sure what the other properties do, but they look like they should be mostly optional.)
I would hope that this should allow us to:
- do the Assess & Prepare steps while dev mode is enabled, without actually showing anything to any customers that are testing migrations;
- migrate from the “public” server key to the “private” cloud key;
- change the
cloudAddonKey to the “public” app key when we’re ready to update the cloud app, without making it visible to clients;
- then change the
PUBLIC when we finished testing and published the new server version, to make everything visible to clients.
The problem here is that most of that is guessing based on property names and imagining how I’d do an API, I’m worried that I might guess wrong and somehow get stuck with an app that claims to clients it can do migrations but doesn’t, and being unable to convince Marketplace to change its mind.
Could you maybe confirm/disconfirm if/what of my “hopes” above are correct? Anything I got even a tiny bit wrong?
(Also, this feels like too much to ask, but would it be plausible to get some really pedantly detailed documentation of what each property in the MMAPI’s
AppMigrationInformation object does, how it interacts with the presence/absence of the listener in the server app, and who can see what and when?)