RFC-13 App migration webhook in Connect Descriptor

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Summary of Project:

“App migration web hook in Connect Descriptor” will enable marketplace partners to register app migration webhook for their app data migration to all cloud sites on which their app is installed, by declaring an entry in Connect descriptor once.

  • Publish: 11 May 2023
  • Discuss: 25 May 2023
  • Resolve: 08 Jun 2023

Problem

App migrations failing due to cloud apps not having an app migration webhook registered for the destination cloud site, is one of the major failure points for customers performing server to cloud app migrations using cloud migration assistants. Today , marketplace partners register their webhook (absolute URL) specific to a cloud site. This means they need to register their webhook for each cloud site on which their cloud app is installed. Customers running an app migration to a cloud site for which that cloud app missed to register webhook will often see a long running app migration with no progress updates until that app migration eventually expires and fails. This problem gives an unpleasant experience to customers and customers end up reaching out to Atlassian support or marketplace partner support or both and losing considerable amount of time in getting this issue fixed.

Who are we solving for?

For marketplace partners : “App migration web hook in Connect Descriptor” aims to provide a declarative way for marketplace partners to register their app migration webhook by adding an entry on their connect descriptor once and thus registering their app migration webhook for all cloud sites at once.

For customers : “App migration web hook in Connect Descriptor” aims to reduce the number of customer app migrations failing due to cloud apps not registering app migration webhook on their cloud sites.

Proposed Solution

“App migration webhook in Connect Descriptor” will allow the marketplace partners to add a new entry cloudAppMigration to the connect descriptor as shown below,

{
  // Existing field for base URL
  "baseUrl": "https://your.sample.app.com"
  ...
  ...
  // Existing field for data residency purposes
  // https://developer.atlassian.com/cloud/confluence/data-residency/#enable-data-residency
  "regionBaseUrls": {
    "US": "https://us.your.sample.app.com",
    "EU": "https://eu.your.sample.app.com",
    "AU": "https://au.your.sample.app.com",
    "DE": "https://de.your.sample.app.com"
  }
  ...
  // New field for registering app migration webhooks
  "cloudAppMigration": {
    "migrationWebhookPath" : "<relative-url-to-migration-notification-endpoint>"
  }
  ...
}

App migration platform will form the webhook URL to notify app migration events as follows,

  • For apps NOT supporting data residency, webhook URL will be formed as baseUrl + cloudAppMigration.migrationWebhookPath
  • For apps supporting data residency, webhook URL will be formed as corresponding regionBaseUrl + cloudAppMigration.migrationWebhookPath

Precedence of webhooks :

App migration platform will use the following precedence to decide which type of webhook should be used to notify app migration events,

  1. If your cloud app has app migration webhook defined on the Connect descriptor, App migration platform will use the app migration webhook URL formed from the fields of Connect descriptor
  2. If your cloud app have registered app migration webhook using the REST API, App migration platform will use the webhook URL registered for the specific cloud site
  3. If you have registered a default app migration webhook for your app with App migration platform, App migration platform will use the default webhook URL

Note :

  • Precedence defined above is to help marketplace partners to onboard to this new solution without worrying about off-boarding their existing app migration webhooks.
  • Default app migration webhook is not publicly available or a self-serve feature. We have reached out to a few marketplace partners to onboard their default app migration webhook to App migration platform. So, #3 in the above precedence is not applicable for all the marketplace partners.

Possible extension to this project :

Support for cloudAppMigration.migrationWebhookPath as connect module for Connect On Forge apps is out of scope for this RFC, but App migration platform can add that support if Connect On Forge becomes widely adopted and marketplace partners require that feature.

Other options considered :

We have considered allowing marketplace partners to add absolute URL on the connect descriptor for app migration webhook, but this option won’t enable App migration platform to notify migration events to the cloud app on the region based URLs based on the product realm (related to data residency support).

Actions

While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:

  • Do you have any blocking use case that will stop you from using the proposed solution to declare a relative path to App migration webhook endpoint on Connect descriptor ? If yes, could you please share such use cases ?
  • Do you have any concerns in the App migration platform snapshotting the webhook URL to be used for an app migration at the start of that app migration ? (Note : This will help in avoiding App migration platform delivering the events related to single app migration using different webhook URLs, if the webhook changed during an active app migration)
  • Do you plan to move your Connect app to Forge app using the Option B explained on this page ? If yes, does adding the support to cloudAppMigration.migrationWebhookPath as a Connect module on your Forge manifest be helpful ?
  • If your app supports data residency or planning to support data residency, would you like to get your server to cloud app migration events on the region based URL based on the realm location of the cloud product ?

Thanks for your feedback!

7 Likes

Thanks a lot for working on this, it’s much appreciated and will allow us to drop quite a bit of code and workarounds.

  • Do you have any concerns in the App migration platform snapshotting the webhook URL to be used for an app migration at the start of that app migration ?

This absolutely makes sense in our case. I assume that it will not be possible to for customers to switch DARE realms and perform server-to-cloud migrations at the same time? Please don’t support that :slight_smile:

  • If your app supports data residency or planning to support data residency, would you like to get your server to cloud app migration events on the region based URL based on the realm location of the cloud product ?

Yes please, our data residency realms are completely standalone, so we absolutely need to receive the server-to-cloud migration events in the app’s realm used for that particular cloud site.

Some additional questions:

  • How do we migrate away from the current webhook registration model once this is available? Are we supposed to declare the descriptor field and then de-register the webhook via API call in the enabled lifecycle event?
  • We’re also using the default webhook mechanism. Are we supposed to reach out to you so you can remove that default value for our apps?

Thanks,
Jens

1 Like

We are currently in the process to close some of our feature gaps between DC ↔ Cloud by building using “Connect On Forge apps”.
On DC we have a CustomField and CustomFieldType we want to migrate using forge as it’s currently only possible in forge (as far as I know) to implement our use case.
We have yet to work on the migration process, but this RFC sounds like something good to have. As we currently don’t have an existing migrationWebhook and our intermediate solution is a mix of forge / connect, this may be out of scope for this RFC but something for you to know about.

To explain our use case in a short way:
Connect Plugin where Forge will allow us to implement missing feature parity. We need a reliable way to register cloudAppMigration Webhooks. DC CustomFields / CustomFieldTypes will be migrated to Force CustomField / CustomFieldTypes

1 Like

Thanks @jens for your great feedback and clarifying questions !

This absolutely makes sense in our case. I assume that it will not be possible to for customers to switch DARE realms and perform server-to-cloud migrations at the same time? Please don’t support that :slight_smile:

Yes :slight_smile: , you’re right, I’d assume the same as I understand the product will be offline during the data residency REALM movements. Atlassian may need to surface this information in a pre-migration checklist OR user interfaces of DARE migrations and server-to-cloud migrations, so that customers don’t accidentally end up doing both at same time.

Yes please, our data residency realms are completely standalone, so we absolutely need to receive the server-to-cloud migration events in the app’s realm used for that particular cloud site.

Thanks heaps for sharing this. Noted.

How do we migrate away from the current webhook registration model once this is available? Are we supposed to declare the descriptor field and then de-register the webhook via API call in the enabled lifecycle event?

We’re also using the default webhook mechanism. Are we supposed to reach out to you so you can remove that default value for our apps?

Good news is that we are proposing to treat app migration webhooks registered in Connect descriptor with highest precedence as stated here, so that marketplace partners don’t need to worry about off-boarding their existing webhooks.

During the initial stages of your app onboarding to this solution, shall we suggest to maintain all your existing web hooks and App migration platform will choose the webhook registered on Connect descriptor, if it’s available (following the precedence stated here). This can help App migration platform to use the lesser precedence webhook URLs (site specific webhook URL or default webhook URL), if there are any issues in getting the webhook from Connect descriptor.

Once Atlassian observe that this new solution is stable and App migration platform always uses the webhook registered on Connect descriptor for the onboarded apps, Atlassian can send out a recommendation notice on when and how to offboard the other existing webhooks.

May I ask a follow up question on this ? Would you like to have site specific webhook URL or default webhook URL as a fall back webhook, in cases where App migration platform faced issues in fetching webhook from Connect descriptor ?

Thanks again for this great question :+1: . I’ve added a note under the precedence defined in the RFC. I’ll update the RFC again, once I get your thoughts on the follow up question.

1 Like

Thanks @m.herrmann for your feedback.

We have yet to work on the migration process, but this RFC sounds like something good to have. As we currently don’t have an existing migrationWebhook and our intermediate solution is a mix of forge / connect, this may be out of scope for this RFC but something for you to know about.

Thanks heaps for sharing this. Noted. I’ll take this back to our team to check whether we need any follow ups on how we can help you here.

Good news is that we are proposing to treat app migration webhooks registered in Connect descriptor with highest precedence as stated here, so that marketplace partners don’t need to worry about off-boarding their existing webhooks.

I should have payed more attention … I didn’t realize this list represented a precedence. But this makes sense and will simplify the migration for us :+1:
We would then just keep registering webhooks on the enabled lifecycle event until you tell us to stop it :slight_smile:

May I ask a follow up question on this ? Would you like to have site specific webhook URL or default webhook URL as a fall back webhook, in cases where App migration platform faced issues in fetching webhook from Connect descriptor ?

I can only speak for our apps of course, but we don’t need site-specific webhooks for this (as long as they are invoked in the correct DARE realm). Also declaring the URL in the descriptor seems very simple and straight forward, so I personally don’t really see the need for any other fallbacks in the long term.

Maybe one thing to consider is that the new descriptors including the migrationWebhookPath field might not get rolled out to all instances for various reasons (admin approval required for an even older version, manual descriptor uploaded to the instance, …). For these it might be good to have a realm-specific fallback, but I guess you can do some research on your end to check what fraction of sites this would affect.

1 Like

I should have payed more attention … I didn’t realize this list represented a precedence. But this makes sense and will simplify the migration for us :+1:
We would then just keep registering webhooks on the enabled lifecycle event until you tell us to stop it :slight_smile:

No worries, thanks :slight_smile: , :+1: .

Maybe one thing to consider is that the new descriptors including the migrationWebhookPath field might not get rolled out to all instances for various reasons (admin approval required for an even older version, manual descriptor uploaded to the instance, …). For these it might be good to have a realm-specific fallback, but I guess you can do some research on your end to check what fraction of sites this would affect.

Thanks for bringing up this point. Noted. I’ll take this back to the team and update the decision taken when resolving this RFC.

1 Like

This approach makes sense, it is a welcome improvement.

If your app supports data residency or planning to support data residency, would you like to get your server to cloud app migration events on the region based URL based on the realm location of the cloud product ?

Yes, this will be the preferred option.

In the meantime, to mitigate the problem of missed webhooks, could you add better error reporting or up-front validation to reflect that a selected addon does not have a webhook registered for the selected cloud instance? Customers can then contact the add-on support.

1 Like

Thanks @NikolaNedoklanov for sharing your preference and comments.

In the meantime, to mitigate the problem of missed webhooks, could you add better error reporting or up-front validation to reflect that a selected addon does not have a webhook registered for the selected cloud instance? Customers can then contact the add-on support.

Good news ! We have released a pre-migration check that notifies the customers when a selected cloud app have not registered an app migration webhook for the destination cloud site. Please refer #6 in this list. This pre-migration check is available from JCMA v1.9.0 and CCMA v3.4.3.

1 Like

wow, that was fast :smiley: Thanks!

1 Like

Sounds like a good approach. We don’t support data residency yet, but being able to have specific endpoints for regions makes sense.

1 Like

Thank you so much for all your participance, feedback, questions on this RFC !

We have received lot of positive signals for the approach stated on this RFC, comments upvoting our thought process on extending this solution for Connect On Forge apps as well (which is out of scope for this RFC), additional scenarios that we should be aware of (customers staying in the old version of Connect app and not moving to the version with this feature) and some good questions.

We are closing this RFC for discussion. Please stay tuned for resolution on or before 08 Jun 2023.

1 Like

Thanks a lot again for all your participance and valuable feedback !!!

What did we hear ?

  • Favouring comments for the relative URL approach proposed in this RFC and mentions about,
    • this approach can be helpful when marketplace partners starts supporting data residency
    • this approach seems to be very simple and straight forward
    • extending this solution to Connect On Forge apps can be useful
  • Questions about how to migrate away from existing site specific web hook registration mechanisms and default web hooks registered with Atlassian.
  • Realm specific fall back app migration web hook may be needed, if there are considerable amount of customers who chose to stay with old version of Connect apps that have not implemented the solution proposed in this RFC.

What is coming next ?

  • Atlassian started implementing this solution and having a good progress so far. Please watch MIG-673 and App migration platform change log for further updates.
  • We expect to release this feature in June 2023 , along with the documentation on how marketplace partners can onboard to this new feature and guidelines on maintaining the existing site specific web hook registration mechanisms and default web hooks registered with Atlassian.
  • After the release of this feature, Atlassian will monitor how many of the customers were not able to get the benefits of this feature, even after a marketplace partner onboarded to this solution, just because the customers chose to stay on the older versions of Connect app. If this issue turns out to be major, Atlassian will explore and send another RFC for realm specific fallback app migration web hook.
  • App migration platform won’t snapshot the webhook URL to be used for an app migration at the start of that app migration, in the initial release of this feature. (Can be driven via another RFC, if Atlassian decides to implement this webhook URL snapshot feature in future).
  • Extending this solution for Connect On Forge apps is out of scope for this RFC and will be considered in future.
3 Likes