Architecture Dynamics AX 2009：：互斥GLS层的含义

据我所知，AX 2009的构建方式使巴西、中国和/或印度不能与俄罗斯和/或波兰处于同一AX实例上，因为它们具有相互排斥的GLS层。我们正接近这场冲突的阶段，因此正在研究如何处理这场冲突

有人能给我指出关于这个问题的任何文档/博客吗？我希望了解更多关于功能和技术方面的影响以及可能的解决方案。我知道AX 2012没有这个问题，但在做出这个决定之前，我想看看我们在2009年有哪些选择

提前感谢,

JB

如果您想了解更多关于我正在调查的内容，请参阅以下内容：

• 功能影响是什么（因此我们可以决定GLS层引入的功能是否与我们的需求相关/如果我们的需求不受此影响，我们可以实施一些没有GLS层的国家/地区）
• 是否可以为两个实例维护一个自定义代码库（即在VAR层中），但在每个实例中使用不同的GLS层
• 如果上述情况并不简单，那么是否可以在VAR层中添加更多代码，将两个GLS层的功能映射到一个公共层（即，其行为就像两个GLS层中的类实现了相同的接口），然后使用VAP层进行自定义代码，使用USR层进行修补（因为所有代码都将由我们的合作伙伴开发，所以我们不需要为自己的目的使用此层）
• 有关于多个GLS层的代码管理的信息吗
• 是否有关于此问题存在原因的描述（从技术角度），以便我更好地了解此问题的确切原因（即，架构中的哪一部分导致多个国家发生冲突/MS在AX 2009中为何无法解决此问题）
• 功能影响是什么（因此我们可以决定GLS层引入的功能是否与我们的需求相关/如果我们的需求不受此影响，我们可以实施一些没有GLS层的国家/地区）
你基本上是在问，“每个国家的自定义GLS层中有什么？”我不知道这个答案，但获得答案的一种方法是在一个清晰的环境中，你可以启用每个GLS层，通过（工具>开发工具>版本更新>比较层）创建一个层比较项目在GLS层上，然后将GLS层项目仅导出到一个XPO，并对两个XPO使用WinDiff。这是我能想到的所有方法，可以快速找出差异。在这个问题上，可能值得与Microsoft开一张罚单，在实际层上工作的工程师可以为您提供更好的答案
• 是否可以为两个实例维护一个自定义代码库（即在VAR层中），但在每个实例中使用不同的GLS层
不。例如，如果您有两个AO，每个AO具有不同的GLS层，它们与同一个数据库通信，则基本上是两个独立的代码基。根据发布环境的不同，某些内容可能会发布不同的内容。这将是一条不好的路径
• 如果上述情况并不简单，那么是否可以在VAR层中添加更多代码，将两个GLS层的功能映射到一个公共层（即，其行为就像两个GLS层中的类实现了相同的接口），然后使用VAP层进行自定义代码，使用USR层进行修补（因为所有代码都将由我们的合作伙伴开发，所以我们不需要为自己的目的使用此层）
我认为在这种情况下首先需要做的是通过代码比较确定GLS层之间的差异
与您的大部分业务相关的GLS层我们称之为A。另一个次要GLS层我们称之为B
要执行此操作，请使用GLSB创建您的环境，并执行（工具>开发工具>版本更新>比较层）并将项目命名为GLS\U B，选择源GLS层，然后选择sys的引用层，然后单击“确定”。创建专用项目后，将整个项目导出到名为GLS\U B.XPO的XPO
对于这个例子，我们将在VAR层中工作，我将假设您环境的层仅为SYS、SYP、GLS、VAR、VAP、USR
切换到GLSA环境，删除GLS上方的所有层。打开导入XPO工具（从AOT中Ctrl+Shift+I），选择GLS_B.XPO，保留所有默认值，然后选中“显示详细信息”，然后会出现繁琐的工作，但单击每个对象并进行比较。如果有任何差异，请导入该对象。如果没有差异，请不要导入。检查完所有对象后，创建VAR层的另一个比较项目，您将知道要仔细查看的对象。检查每个项目，请参见w代码差异是什么
GLS层对于不同的国家是独立的，这一事实使我认为差异可能是显著的或相互冲突的…因此简单的合并可能无法解决潜在的逻辑差异。这就是您需要确定下一步要做什么的地方。如果更改不那么显著，您可以合并到VAR层，使其成为y我们的合并GLS层，您可以将其单独保留，并在上层进行修改
• 有关于多个GLS层的代码管理的信息吗
不确定。我认为这只是我上面的TFS方法
• 是否有关于该问题存在原因的描述（从技术角度），以便我能更好地了解该问题的确切原因（即，架构中的哪一部分导致多个国家发生冲突/这怎么可能无法由MS解决）