第八章 金蝶EAS元数据升级冲突解决办法.pdfVIP

受限修改下的 客户版元数据升级冲突解决办法 1.概述 以下所有描述假定发生在如下场景中： 1）在EASv5.1（假定）正式发布后，客户A 利用BOS 业务建模或设计开发工具在EASv5.1 （简称为原始版，下同）基础上进行二次开发并形式客户版EASv5.1.1 （简称为客户版，下 同），EAS 开发部也在EASv5.1 基础上进行新功能开发并形成标准版的EASv5.1.1 （简称为 升级版，下同）。现需根据升级版对客户版进行升级，形成客户升级版，该客户升级版的功 能涵盖了客户版中客户自定义的功能与升级版中EAS 开发人员开发的新功能。 2 ）EAS 二次开发人员已全部意识到：所有的BOS 元数据都是以UTF-8 文件格式保存。 3 ）受限修改：二次开发人员对于 EAS 出厂元数据的修改必须受一定的约束，详见 《EASv5.2_BOS 架构_设计开发工具_客户版允许修改出厂元数据范围.xls》。因违背该约束 的修改行为而导致的元数据冲突，不是本文的职责。 2. 命名空间冲突 系统约束：客户二次开发人员不能删除或修改EAS 出厂元数据的命名空间 可能场景：在客户版中新建了命名空间，如 com.kingdee.eas.scm.crm 。 在升级版中也新利 用了该命名空间，此时需区分两种情况： 1）在此命名空间中，所有客户版的元数据（含所有子孙空间的所有元数据）与升级版 的元数据没有冲突，即没有重名情况。 2 ）在此命名空间中，所有客户版的元数据（含所有子孙空间的所有元数据）与升级版 的元数据有冲突，即有重名情况。 解决方案： 1）对上述场景1，仅需指定命名空间本身（Package 元数据）的合并策略（即指定以客户版 或升级版的命名空间为准），元数据升级引擎可自动合并。 2 ）对上述场景2 ，解决方案有： A ）修改客户版的命名空间，并重新发布此空间下的所有元数据（含代码生成），此方 案涉及面甚广，不建议采用。 B ）修改此空间中，重名的客户版元数据，具体内容详见大粒度元数据对象一节。 3. 大粒度元数据对象（元数据文件）冲突 系统约束：客户二次开发人员不能删除或重命名EAS 出厂元数据的大粒度元数据对象（元 数据文件） 3.1 新建元数据文件冲突 可能场景：在com.kingdee.eas.scm.im.inv.app 命名空间中，客户版新建了一个Facade 元数据 InventoryFacade.facade （库存管理功能），升级版也在此空间中新建了InvertoryFacade.facade 元数据，此时需区分两种情况： 1）此客户版与升级版中的两个InvertoryFacade.facade 元数据从语法、语义完全相同。 此情况可能发生在：受时间因素制约，客户二次开发人员将升级版中未正式发布的标准元数 据移植到客户版。此情景的发生几率很小。 2 ）此两个版本中两个元数据命名相同，但从语法结构或语义上都有明显不相同之处。 解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2 ）对上述场景2 ，第一步：利用BOS 设计开发工具中重命名功能，将客户版的此元数据重 新命名（并保证所有引用此元数据的其它元数据均已更新）；第二步：对于BOS 发布引擎不 会覆盖的 java 文件（包括：发布 entity 对应的 xxxInfo.java 、xxxControllerBean.java 、 xxxControllerBeanEx.java ， 发 布 façade 对 应 的 xxxControllerBean.java 、 xxxControllerBeanEx.java ，发布UI 对应的xxx.java ），利用Eclipse 提供的重命名功能，根据 元数据的新名称，对此些 java 文件修改类名（并保证相关的引用均已修改）；第三步：在 BOS 设计开发工具中，重新发布此元数据（包括代码与元数据自身）；第四步：利用 BOS 业务建模工具提供的测试与布署功能，测试重命名过的元数据是否正常，并正确布署；经以 上四个步骤后，再进行元数据合并，从而保证了元数据文件没有冲突。 3.2 修改/删除元数据文件冲突