1回答
- 新しい順
- 投票が多い順
- コメントが多い順
1
The recommendation here is to have some sort of "translation" table for all your resources referenced in the flow. You can replace all the new instance ARNs as you process the new flows.
回答済み 2年前
関連するコンテンツ
- 質問済み 2ヶ月前
The recommendation here is to have some sort of "translation" table for all your resources referenced in the flow. You can replace all the new instance ARNs as you process the new flows.
I'm not sure what you mean by this, as the ARNs that are within the JSON body of the exported file will have different account numbers, and specific UUIDs in them, i can't see how having a table with these will work if the instances end up being destroyed and having to get redeployed out again.
I know that if you import one from one account instance e.g dev and then import it into a different account instance e.g. prod manually via the GUI it will let you know that it couldn't resolve it by ARN and resolved via the same name instead. Is this not a capability for the API request of CreateContactFlowCommand able to do?
And if i had to have a DB for translating them how would I got about processing the massive JSON files and making sure i don't change the wrong values across the potential hundreds of flows and modules?
How we've done it, which isn't great. You have a translation table of all your Lambdas. We have the naming convention env-LambdaName. When we export a flow, we run it through our translation table and we tell the system where we want to move the script to. We then get a new JSON file with the new ARNs based on the matching names.
david