金蝶EAS元数据升级冲突解决办法.pdf

受限修改下的 受限修改下的 客户客户版元数据版元数据升级冲突解决办法 升级冲突解决办法 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，发布faade对应的xxxcontrollerbean.java、 xxxcontrollerbeanex.java，发布 ui 对应的 xxx.java） ，利用 eclipse 提供的重命名功能，根据 元数据的新名称，对此些 java 文件修改类名（并保证相关的引用均已修改） ；第三步：在 bos 设计开发工具中，重新发布此元数据（包括代码与元数据自身） ；第四步：利用 bos 业务建模工具提供的测试与布署功能，测试重命名过的元数据是否正常，并正确布署；经以 上四个步骤后，再进行元数据合并，从而保证了元数据文件没有冲突。 3.2 修改修改/删除元数据文件冲突删除元数据文件冲突 可 能 场 景可 能 场 景 ： 在 com.kingdee.eas.fi.gr.cslrpt.app 命 名 空 间 中 ， 客 户 版 修 改 了 元 数 据 exchelimination.entity（内部交易抵销）的内容，升级版将元数据 exchelimination.entity 删 除或重命名为 newexchelimination.entity。 解决方案解决方案：从 eas 标准版约束来看，不可能发生上述场景，即升级版不能删除或重命名原 始版的元数据。 元数据合并引擎根据最大化原则自动处理此问题， 即以修改过的客户版为准， 并忽略升级版的删除/重命名行为。 4. entity 元数据内容的冲突 4.1 修改修改 entity 元数据“别名” 、 “描述”引起的冲突元数据“别名” 、 “描述”引起的冲突 可能场景可能场景：客户版、升级版同时修改了 com.kingdee.eas.basedata.assistant.app.accountbank.entiy 的“别名”/“描述” 解决方案解决方案： 在元数据合并策略文件中指定用客户版或升级版的元数据替代另一个， 元数据合 并引擎将根据此策略进行合并。推荐：用客户版的“别名”/“描述”代替升级版的“别名” /“描述” ，这是元数据合并引擎的默认行为，用户无需指定策略。 4.2 修改修改 entity 元数据的扩展属性的值引起的冲突元数据的扩展属性的值引起的冲突 可能场景可能场景：客户版将原始版 com.kingdee.eas.hr.affair.app.firebill.entity 的扩展属性 orgtype 值由原来的 controlunit 改为 none，而在升级版中将此 orgtype 值改为 company。 解决方案解决方案： 在元数据合并策略文件中指定用客户版或升级版的元数据替代另一个， 元数据合 并引擎将根据此策略进行合并。推荐：用客户版的“扩展属性”的值代替升级版的“扩展属 性”的值，这是元数据合并引擎的默认行为，用户无需指定策略。 4.3 增加增加 entity 元数据的扩展属性而引起的冲突元数据的扩展属性而引起的冲突 可能场景可能场景：客户版在原始版 com.kingdee.eas.hr.affair.app.firebill.entity 上新增扩展属性 orgtype，其值设为 none，而在升级版中也新增扩展属性 orgtype，其值设为 company。 解决方案解决方案： 因元数据结构所限， 元数据合并引擎无法区分此种情景。 元数据合并引擎将按 “修 改 entity 元数据的扩展属性的值引起的冲突”情形进行处理。 4.4 新增新增 entity 的自由属性（的自由属性（ownproperty）或连接属性 （ ）或连接属性 （linkproperty）引起的冲突）引起的冲突 可能场景可能场景：客户版将原始版 com.kingdee.eas.hr.affair.app.enrollbill.entity（入职申请单）中新 增一个连接属性 advisor（入职导师） ，而升级版也在 enrollbill.entity（入职申请单）中新增 一个连接属性 advisor。此时需区分两种情况： 1）此客户版与升级版中的两个 advisor 连接属性在语法、语义完全相同。此情况可能发 生在： 受时间因素制约， 客户二次开发人员将升级版中未正式发布的标准元数据移植到客户 版。此情景的发生几率很小。 2）此两个版本中两个 advisor 连接属性命名相同，但从语法结构或语义上都有明显不相 同之处。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2）对上述场景 2，第一步：用 bos 设计开发工具打开此客户版的 enrollbill.entity，在“属 性” 编辑页面中修改该连接属性的名称， 并保证不会与升级版中 enrollbill.entity 的属性重名； 第二步：利用 bos 设计开发工具，对应修改所有引用该属性的其它元数据，包括 query、 ui；第三步：在 bos 设计开发工具中，重新发布所有修改过的元数据（包括代码与元数据 自身） ；第四步：利用 bos 业务建模工具提供的测试与布署功能，测试重命名过的元数据是 否正常，并正确布署；经以上四个步骤后，再进行元数据合并，从而保证了 entity 元数据文 件中的新增属性没有冲突。 4.5 修改修改 entity 的自由属性（的自由属性（ownproperty）或连接属性 （ ）或连接属性 （linkproperty）的“别名” 、 “描述”的值引起的冲突）的“别名” 、 “描述”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 4.6 修改修改 entity 元数据的元数据的 ownpropertylinkproperty 的 扩展属性而引起的冲突 的 扩展属性而引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据的扩展属性而引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据的扩展属性而引起的冲突”解决方案 4.7 增加增加 entity 元数据的元数据的 ownpropertylinkproperty 的 扩展属性而引起的冲突 的 扩展属性而引起的冲突 可能场景可能场景：类似上述的“增加 entity 元数据的扩展属性而引起的冲突” 解决方案解决方案：类似上述的“增加 entity 元数据的扩展属性而引起的冲突”解决方案 4.8 新增新增 entity 的方法（的方法（ethod）引起的冲突）引起的冲突 可能场景可能场景：客户版将原始版 com.kingdee.eas.hr.affair.app.enrollbill.entity（入职申请单）中新 增一个方法 audit(iobjectpk)，而升级版也在 enrollbill.entity（入职申请单）中新增一个方法 audit(iobjectpk)。此时需区分两种情况： 1）此客户版与升级版中的两个 audit 方法在方法签名、语义完全相同。此情况可能发生 在： 受时间因素制约， 客户二次开发人员将升级版中未正式发布的标准元数据移植到客户版。 此情景的发生几率很小。 2）此两个版本中两个 audit 方法签名相同，但语义不同。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2）对上述场景 2，第一步：用 bos 设计开发工具打开此客户版的 enrollbill.entity，在“方 法”编辑页面中修改该方法的名称，并保证不会与升级版中 enrollbill.entity 的方法重名；第 二步：利用 bos 设计开发工具，对应修改所有引用该方法的其它元数据，包括 entity 的事 件定义；第三步：在 bos 设计开发工具中，重新发布所有修改过的元数据（包括代码与元 数据自身） ；第四步：利用 eclipse 提供的重命名功能，根据此方法的新名称，重构 nrollbillcontrollerbeanex.java 中的方法签名；第五步：利用 bos 业务建模工具提供的测试 与布署功能，测试重命名过的元数据是否正常，并正确布署；经以上五个步骤后，再进行元 数据合并，从而保证了 entity 元数据文件中的新增方法没有冲突。 4.9 修改修改 entity 的方法（的方法（method）的“别名” 、 “描述”的 值引起的冲突 ）的“别名” 、 “描述”的 值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 4.10 新增新增 entity 的事件（的事件（event）引起的冲突）引起的冲突 可能场景可能场景：客户版将原始版 com.kingdee.eas.hr.affair.app.enrollbill.entity（入职申请单）中新 增一个事件 auditevent，而升级版也在 enrollbill.entity（入职申请单）中新增一个方法 auditevent。此时需区分两种情况： 1）此客户版与升级版中的两个 auditevent 事件在语法、语义完全相同。此情况可能发 生在： 受时间因素制约， 客户二次开发人员将升级版中未正式发布的标准元数据移植到客户 版。此情景的发生几率很小。 2）此两个版本中两个 auditevent 事件名称，但语义不同。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2）对上述场景 2，第一步：用 bos 设计开发工具打开此客户版的 enrollbill.entity，在“事 件”编辑页面中修改该事件的名称，并保证不会与升级版中 enrollbill.entity 的事件重名；第 二步：利用 bos 设计开发工具，对应修改所有引用该事件的其它元数据，包括 function 的 定义；第三步：在 bos 设计开发工具中，重新发布所有修改过的元数据（仅发布元数据即 可） ；第四步：利用 bos 业务建模工具提供的测试与布署功能，测试重命名过的元数据是否 正常，并正确布署；经以上四个步骤后，再进行元数据合并，从而保证了 entity 元数据文件 中的新增事件没有冲突。 4.11 修改修改 entity 的事件（的事件（event）的“别名” 、 “描述”的 值引起的冲突 ）的“别名” 、 “描述”的 值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 4.12 修改修改 entity 的逻辑键的“别名” 、 “描述”的值引起的 冲突 的逻辑键的“别名” 、 “描述”的值引起的 冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 5. query 元数据内容的冲突 5.1 修改修改 query 的“别名” 、 “描述” 、 “分组查询” 、 “消除重 复行”的值引起的冲突 的“别名” 、 “描述” 、 “分组查询” 、 “消除重 复行”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 5.2 修改修改 query 元数据的扩展属性而引起的冲突元数据的扩展属性而引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据的扩展属性而引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据的扩展属性而引起的冲突”解决方案 5.3 增加增加 query 元数据的扩展属性而引起的冲突元数据的扩展属性而引起的冲突 可能场景可能场景：类似上述的“增加 entity 元数据的扩展属性而引起的冲突” 解决方案解决方案：类似上述的“增加 entity 元数据的扩展属性而引起的冲突”解决方案 5.4 新增新增 query 的子对象引起的冲突的子对象引起的冲突 可能场景可能场景：客户版将原始版 com.kingdee.eas.hr.affair.app.enrollbillquery.query（入职申请单 查询）中新增一个子对象 creator 以关联到 user 对象，而升级版也在 enrollbillquery.query （入职申请单查询）中新增一个子对象 creator 以关联到 user 对象。此时需区分两种情况： 1）此客户版与升级版中的两个 creator 子对象在连接、语义完全相同。此情况可能发生 在： 受时间因素制约， 客户二次开发人员将升级版中未正式发布的标准元数据移植到客户版。 此情景的发生几率很小。 2）此两个版本中两个 creator 子对象名称，但连接方式、语义不同。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2）对上述场景 2，第一步：用 bos 设计开发工具打开此客户版的 enrollbillquery.query，在 “定义”编辑页面中修改该子对象的名称，并保证不会与升级版中 enrollbillquery.query 的 子对象重名；第二步：利用 bos 设计开发工具，对应修改所有引用该子对象的其它元数据， 包括 query 自身、ui 的定义；第三步：在 bos 设计开发工具中，重新发布所有修改过的元 数据（仅发布元数据即可） ；第四步：利用 bos 业务建模工具提供的测试与布署功能，测试 重命名过的元数据是否正常，并正确布署；经以上四个步骤后，再进行元数据合并，从而保 证了 query 元数据文件中的新增子对象没有冲突。 5.5 新增新增 query 的查询字段（的查询字段（field）引起的冲突）引起的冲突 可能场景可能场景：客户版将原始版 com.kingdee.eas.hr.affair.app.enrollbillquery.query（入职申请单 查询）中新增一个查询字段 bizdate（业务日期） ，而升级版也在 enrollbillquery.query（入 职申请单查询）中新增一个查询字段 bizdate。此时需区分两种情况： 1）此客户版与升级版中的两个 bizdate 查询字段在语义完全相同。此情况可能发生在： 受时间因素制约， 客户二次开发人员将升级版中未正式发布的标准元数据移植到客户版。 此 情景的发生几率很小。 2）此两个版本中两个 bizdate 查询字段名称相同，但所关联到的字段、语义不同。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2）对上述场景 2，第一步：用 bos 设计开发工具打开此客户版的 enrollbillquery.query，在 “字段”编辑页面中修改该子对象的名称，并保证不会与升级版中 enrollbillquery.query 的 字段重名；第二步：利用 bos 设计开发工具，对应修改所有引用该子对象的其它元数据， 包括 ui 的定义；第三步：在 bos 设计开发工具中，重新发布所有修改过的元数据（包括代 码与元数据自身） ；第四步：利用 bos 业务建模工具提供的测试与布署功能，测试重命名过 的元数据是否正常， 并正确布署； 经以上四个步骤后， 再进行元数据合并， 从而保证了 query 元数据文件中的新增字段没有冲突。 5.6 修改修改 query 元数据的查询字段的“显示名称” 、 “可过 滤” 、 “可排序” 、 “可见性”的值引起的冲突 元数据的查询字段的“显示名称” 、 “可过 滤” 、 “可排序” 、 “可见性”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 5.7 修改修改 query 元数据的查询字段（元数据的查询字段（field）的扩展属性而 引起的冲突 ）的扩展属性而 引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据的扩展属性而引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据的扩展属性而引起的冲突”解决方案 5.8 增加增加 query 元数据的查询字段（元数据的查询字段（field）的扩展属性而 引起的冲突 ）的扩展属性而 引起的冲突 可能场景可能场景：类似上述的“增加 entity 元数据的扩展属性而引起的冲突” 解决方案解决方案：类似上述的“增加 entity 元数据的扩展属性而引起的冲突”解决方案 6. table 元数据内容的冲突 6.1 修改修改 table 的“别名” 、 “描述”的值引起的冲突的“别名” 、 “描述”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 6.2 新增新增 table 的“字段” 、 “索引” 、 “外键”引起的冲突的“字段” 、 “索引” 、 “外键”引起的冲突 可能场景可能场景：客户版将原始版 table 元数据上新增一个字段或索引或外键，而升级版也在该 table 元数据新增一个同名的字段或索引或外键。此时需区分两种情况： 1）此客户版与升级版中的两个同名的字段或索引或外键在语义完全相同。此情况可能 发生在： 受时间因素制约， 客户二次开发人员将升级版中未正式发布的标准元数据移植到客 户版。此情景的发生几率很小。 2）此两个版本中两个同名的字段或索引或外键在语义不同。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2）对上述场景 2，第一步：用 bos 设计开发工具打开此客户版的 table 元数据，在“基本 表定义”编辑页面中修改该字 段或索引或外键的名称，并保证不会与升级版中对应的字段 或索引或外键重名；第二步：利用 bos 设计开发工具，对应修改所有引用该字段象的其它 元数据，包括 entity 的自由属性映射；第三步：在 bos 设计开发工具中，重新发布所有修 改过的元数据（仅发布元数据即可） ；第四步：同步修改数据库中对应表的字段或索引或外 键；第五步：利用 bos 业务建模工具提供的测试与布署功能，测试重命名过的元数据是否 正常，并正确布署；经以上五个步骤后，再进行元数据合并，从而保证了 table 元数据文件 中的新增字段或索引或外键没有冲突。 7. relationship 元数据内容的冲突 7.1 修改修改 relationship 的“别名” 、 “描述”的值引起的冲突的“别名” 、 “描述”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 8. facade 元数据内容的冲突 8.1 修改修改 facade 的“别名” 、 “描述”的值引起的冲突的“别名” 、 “描述”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 8.2 新增新增 facade 的方法（的方法（ethod）引起的冲突）引起的冲突 可能场景可能场景：类似上述的“新增 entity 的方法（method）引起的冲突” 解决方案解决方案：类似上述的“新增 entity 的方法（method）引起的冲突”解决方案 8.3 修改修改 facade 的方法（的方法（method）的“别名” 、 “描述”的 值引起的冲突 ）的“别名” 、 “描述”的 值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 9. exception 元数据内容的冲突 9.1 修改修改 exception 的“别名” 、 “描述”的值引起的冲突的“别名” 、 “描述”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 9.2 新增新增 exception 的子异常引起的冲突的子异常引起的冲突 可能场景可能场景：客户版将原始版 com.kingdee.eas.hr.affair. hraffairexception.exception（人事事务 异常）中新增一个子异常 hire_assessresult_positive（考核成绩必须大于 0） ，而升 级版也在 hraffairexception.exception （人事事务异常）中新增一个同名的子异常 hire_assessresult_positive。此时需区分两种情况： 1）此客户版与升级版中的两个子异常的名称、子异常号、描述完全相同。此情况可能 发生在： 受时间因素制约， 客户二次开发人员将升级版中未正式发布的标准元数据移植到客 户版。此情景的发生几率很小。 2）此两个版本中两个子异常的名称相同，但其子异常号、描述不同。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2） 对上述场景2， 第一步： 用bos设计开发工具打开此客户版的hraffairexception.exception， 在 “ 异 常 定 义 ” 编 辑 页 面 中 修 改 该 子 对 象 的 名 称 ， 并 保 证 不 会 与 升 级 版 中 hraffairexception.exception 的子异常重名；第二步：在 bos 设计开发工具中，重新发布所 有修改过的元数据（包括代码与元数据自身） ；第三步：利用 bos 业务建模工具提供的测试 与布署功能，测试重命名过的元数据是否正常，并正确布署；经以上三个步骤后，再进行元 数据合并，从而保证了 exception 元数据文件中的新增子异常没有冲突。 10. enum 元数据内容的冲突 10.1 修改修改 enum 的“别名” 、 “描述”的值引起的冲突的“别名” 、 “描述”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 10.2 新增新增 enum 的“值定义”的冲突的“值定义”的冲突 可能场景可能场景：类似上述的“新增 exception 的子异常引起的冲突” 解决方案解决方案：类似上述的“新增 exception 的子异常引起的冲突”解决方案 11. function 元数据内容的冲突 11.1 修改修改 function 的“别名” 、 “描述”的值引起的冲突的“别名” 、 “描述”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 11.2 新增新增 function 的操作（的操作（operation）引起的冲突）引起的冲突 可能场景可能场景：客户版将原始版 com.kingdee.eas.hr.affair.hraffairbillbizfunc.function（人事单据 功 能 ） 中 新 增 一 个 操 作 setcancelstate （ 设 置 单 据 作 废 状 态 ） ， 而 升 级 版 也 在 hraffairbillbizfunc.function （人事单据功能）中新增一个同名的操作 setcancelstate。此时 需区分两种情况： 1）此客户版与升级版中的两个 setcancelstate 操作在语法、语义完全相同。此情况可能 发生在： 受时间因素制约， 客户二次开发人员将升级版中未正式发布的标准元数据移植到客 户版。此情景的发生几率很小。 2）此两个版本中两个 setcancelstate 操作名称相同，但所引用的实体/界面对象、语义 不同。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2 ） 对 上 述 场 景2 ， 第 一 步 ： 用bos设 计 开 发 工 具 打 开 此 客 户 版 的 hraffairbillbizfunc.function，在“操作定义”编辑页面中修改该操作的名称，并保证不会 与升级版中 hraffairbillbizfunc.function 的操作重名；第二步：在 bos 设计开发工具中， 重新发布所有修改过的元数据（仅发布元数据即可） ；第三步：利用 bos 业务建模工具提供 的测试与布署功能，测试重命名过的元数据是否正常，并正确布署；经以上三个步骤后，再 进行元数据合并，从而保证了 function 元数据文件中的新增操作没有冲突。 11.3 修改修改 function 元数据的操作（元数据的操作（operation）的扩展属 性而引起的冲突 ）的扩展属 性而引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据的扩展属性而引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据的扩展属性而引起的冲突”解决方案 11.4 增加增加 function 元数据的操作（元数据的操作（operation）的扩展属 性而引起的冲突 ）的扩展属 性而引起的冲突 可能场景可能场景：类似上述的“增加 entity 元数据的扩展属性而引起的冲突” 解决方案解决方案：类似上述的“增加 entity 元数据的扩展属性而引起的冲突”解决方案 12. resource 元数据内容的冲突 12.1 修改修改 resource 的“别名” 、 “描述”的值引起的冲突的“别名” 、 “描述”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 12.2 新增新增 resource 的“资源项”的冲突的“资源项”的冲突 可能场景可能场景：类似上述的“新增 exception 的子异常引起的冲突” 解决方案解决方案：类似上述的“新增 exception 的子异常引起的冲突”解决方案 13. bizdatatype 元数据内容的冲突 13.1 修改修改 bizdatatype 的“别名” 、 “描述”的值引起的冲 突 的“别名” 、 “描述”的值引起的冲 突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 14. permission 元数据内容的冲突 14.1 修改修改 permission 的“别名” 、 “描述”的值引起的冲 突 的“别名” 、 “描述”的值引起的冲 突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 14.2 新增新增 permission 的权限项（的权限项（permissionitem）引起 的冲突 ）引起 的冲突 可能场景可能场景：客户版将原始版 hr_affair.permission（人事单据权限文件）中新增一个权限项 enrollbill_update（入职申请单修改） ，而升级版也在 hr_affair.permission（人事单据权限 文件）中新增一个同名的权限项 enrollbill_update。此时需区分两种情况： 1）此客户版与升级版中的两个 enrollbill_update 权限项作在语法、语义完全相同。此 情况可能发生在： 受时间因素制约， 客户二次开发人员将升级版中未正式发布的标准元数据 移植到客户版。此情景的发生几率很小。 2）此两个版本中两个 enrollbill_update 权限项名称相同，但所引用的对象或引用属性、 语义不同。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2） 对上述场景 2， 第一步： 用 bos 设计开发工具打开此客户版的 hr_affair.permission， 在 “权 限项”编辑页面中修改该操作的名称，并保证不会与升级版中 hr_affair.permission 权限项重 名； 第二步： 在 bos 设计开发工具中， 重新发布所有修改过的元数据 （仅发布元数据即可） ； 第三步：利用 bos 业务建模工具提供的测试与布署功能，测试重命名过的元数据是否正常， 并正确布署；经以上三个步骤后，再进行元数据合并，从而保证了 permission 元数据文件中 的新增权限项没有冲突。 14.3 修改修改 permission 元数据的权限项（元数据的权限项（permission）的 扩展属性而引起的冲突 ）的 扩展属性而引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据的扩展属性而引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据的扩展属性而引起的冲突”解决方案 15. log 元数据内容的冲突 15.1 修改修改 log 的“别名” 、 “描述”的值引起的冲突的“别名” 、 “描述”的值引起的冲突 可能场景可能场景：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突” 解决方案解决方案：类似上述的“修改 entity 元数据“别名” 、 “描述”引起的冲突”解决方案 15.2 新增新增 log 的日志项引起的冲突的日志项引起的冲突 可能场景可能场景：类似上述的“新增 permission 的权限项（permissionitem）引起的冲突” 解决方案解决方案：类似上述的“新增 permission 的权限项（permissionitem）引起的冲突”解决方 案 16. ui 元数据内容的冲突 16.1 修改修改 ui 的“别名” 、 “标题” 、 “缺省按钮”的值引起的 冲突 的“别名” 、 “标题” 、 “缺省按钮”的值引起的 冲突 可能场景可能场景：客户版、升级版同时修改了某个 ui 元数据的 “别名”或“标题” 、或“缺省按 钮” 解决方案解决方案： 在元数据合并策略文件中指定用客户版或升级版的元数据替代另一个， 元数据合 并引擎将根据此策略进行合并。推荐：用客户版的“别名”或“标题” 、或“缺省按钮”代 替升级版的“别名”或“标题” 、或“缺省按钮” ，这是元数据合并引擎的默认行为，用户无 需指定策略。 16.2 修改修改 ui 的控件位置（布局信息）引起的冲突的控件位置（布局信息）引起的冲突 可能场景可能场景：客户版、升级版同时修改了某个 ui 元数据中某个（些）控件的位置。 解决方案解决方案： 在元数据合并策略文件中指定用客户版或升级版的元数据替代另一个， 元数据合 并引擎将根据此策略进行合并。 推荐： 用客户版的控件位置信息代替升级版的对应的控件位 置信息，这是元数据合并引擎的默认行为，用户无需指定策略。 16.3 修改修改 ui 的控件属性的值引起的冲突的控件属性的值引起的冲突 可能场景可能场景：客户版、升级版同时修改了某个 ui 元数据中某个（些）控件的属性值。 解决方案解决方案： 在元数据合并策略文件中指定用客户版或升级版的元数据替代另一个， 元数据合 并引擎将根据此策略进行合并。 推荐： 用客户版的控件属性值代替升级版的对应的控件属性 值，这是元数据合并引擎的默认行为，用户无需指定策略。 16.4 新增新增 ui 的控件引起的冲突的控件引起的冲突 可能场景可能场景： 客户版将原始版 com.kingdee.eas.hr.affair.client.hirebilleditui.ui （转正申请单编辑 ui）中新增一个 f7 控件 applierposition（申请人职务） ，而升级版也在 hirebilleditui.ui 中新 增一个同名的控件 applierposition。此时需区分两种情况： 1）此客户版与升级版中的两个 applierposition 控件名称、类型相同，同时在语义完全 相同。此情况可能发生在：受时间因素制约，客户二次开发人员将升级版中未正式发布的标 准元数据移植到客户版。此情景的发生几率很小。 2）此两个版本中两个 applierposition 控件名称相同，但控件的类型不同或语义不同。 解决方案解决方案： 1）对上述场景 1，仅需指定用升级版的元数据替代客户版的元数据，元数据升级引擎可自 动合并；或将客户版的此元数据删除后，再进行合并。 2）对上述场景 2，第一步：用 bos 设计开发工具打开此客户版的 hirebilleditui.ui，在“图 形编辑”编辑页面中选中该 applierposition 控件，然后在“属性”视图中修改该控件的名称 （name） ，并保