有几种可能的方法;您选择的将取决于您的情况。
使用已为新域授予的另一个测试应用程序的密钥。如果您已经为仅限于您的新 DEV2 LE 的应用程序授予了 App ID/Key,那么您可以尝试暂时使用该应用程序的凭据。这将需要使用新凭据重建或重新配置您的客户端应用程序。我们不推荐这种方法,因为为了进行有效的测试,您肯定希望跟踪哪个应用程序正在对 LE 进行哪些调用;但是,如果您已经拥有一组用于狭窄部署的测试应用程序的应用程序凭据,例如,您可以切换到共享这些凭据。
在 DEV2 LE 上使用来自 DEV1 LE 的 LMSID/Key 凭据. 应用于应用程序密钥的“域限制”对应于在部署时分配给 LE 实例的 LMSID/密钥凭据。如果您的 DEV2 实例仅在升级场景中被浮动以测试集成,并且这些集成已经(以它们的测试形式)都针对您的 DEV1 实例工作,那么您的 DEV2 LE 可能使用相同的 LMSID/Key 凭证作为您的 DEV1 LE。这意味着 DEV2 LE 从 D2L 的密钥工具服务中获取其已知的应用程序凭据列表,它将获得与提供给 DEV1 LE 完全相同的凭据列表。这是最激进的建议,需要 D2L 的支持台参与,并且绝对需要 DEV2 LE 的批准支持联系人的指导——这种部署可以对于某些非常特定类型的测试 LMS 实例是有意义的,但它是一个非常大的锤子,因此它可能不是正确的选择。
请注意,如果您无权更改应用程序的代码/配置本身(应用程序凭据已烘焙到应用程序中),则此解决方案是唯一可行的解决方案 - 如果您要测试的应用程序必须针对 LE运行就像它是 DEV1 实例一样,那么这可能是唯一可能的解决方案,在这种情况下,您可能必须等到升级的 LE 部署在 DEV1 上才能测试您的应用程序。我完全不相信可以将一组授予的应用程序凭据“重新指向”到新的域限制。
申请新的应用程序 ID/密钥对,并努力加快请求。授予应用程序 ID/密钥和部署它们的主要延迟在于让相关目标 LMS 域的合作伙伴和/或客户经理批准请求:如果您将您的合作伙伴和/或客户经理与您的情况和/或客户经理联系起来,并且要求他们引导请求,这种延迟可以降低。这将是理想的选择,因为它以预期使用的方式将“适当的渠道”与现有的业务关系一起使用。
为您的新 DEV2 域中的测试应用程序获取一组新的应用程序凭据应该不会花费很长时间,特别是如果您已经建立了现有关系,该关系已通过合作伙伴和/或客户经理获得应用程序凭据。此解决方案仍需要您更改/重新配置您的应用程序。
如果可能的话,你应该走最后一条路。