EAS客户现场开发经验总结

研发中心EAS开发部 杨中科

简介：这篇文章介绍了我在进行EAS客户现场开发时积累的一些经验，主要涉及到了现场开发调试环境的搭建、构建系统的建立等，还有现场开发的一些技术性问题。

一、 开发调试环境的搭建

1、代码查看

代码属于研发受控资源，因此除了小部分业务系统代码之外，大部分的框架代码和业务代码是无法带到开发现场的，这样在客户现场很难参考他人以及框架的代码，使得开发速度降低。不过客户开发现场的jar包基本没有混淆，所以可以通过反编译的方式查看源码。Java反编译的工具有很多，比如DJ Java Decompiler、jadclipse、Jode等等。我个人推荐大家使用Jode，因为它有一个eclipse的插件，可以在eclipse中直接反编译.class文件，十分方便，而且其反编译质量也非常高，基本接近于源码。

2、调试

使用反编译工具可以查看框架和业务系统的源码，但是反编译以后的代码只能查看，因为java的调试是以代码行号为标识进行的，而反编译以后的代码行号与源码是不一致的，所以就无法在反编译以后的代码上直接打断点调试。可以通过如下方式解决此问题：

（1） 在eclipse工程下建立一个新的源文件夹，比如命名为decompilesrc。

（2） 打开eclipse工程“Java构建路径”的“排序和导出”页签，将

decompilesrc文件夹移到boslib,easlib之前。

（3） 将您要调试的.class文件反编译，然后以java源文件的形式保存到

decompilesrc源文件夹下。

这样就可以正常的对代码进行调试了。但是有一些源码反编译以后是无法正确编译的，因为jode的反编译的时候将一些编译结果用JVM指令表示，例如将return语句反编译成Push、pop，将创建一个对象的new操作翻译成Push、push、swap、pop、pop，因此需要进行少量调整才能正确编译。

二、开发测试构建环境的建立

对于比较大的客户现场开发项目一般都会建立比较标准的开发测试流程，也就是与研发中心类似的流程：开发提交代码、构建人员构建打包部署到测试服务器、测试人员测试反馈。

（一）bug管理系统

为了便于bug的规范化管理，bug管理系统的使用是很必要的。网上有很多免费的或者开源的bug管理系统，比如Bugzila、BugFree(国人开发的系统)、URTrack等等。

（二）构建系统

EAS系统的构建包括如下几个主要步骤：发布元数据、编译代码、打包元数据、打包二进制代码、签名代码包，部署到服务器。

手动进行元数据打包、代码打包签名是十分机械性的重复工作，而且很容易

出错。如果采用批处理的方式则会大大加快构建的速度。最简单的方式可以写bat批处理文件，或者使用ant,python之类的工具。我这里以ant为例为大家介绍一下，其他方式也都与此类似。

这个ant脚本是我在湖南烟草永州现场写的一个构建脚本（经过了简化）： <?xml version="1.0" encoding="GB2312" ?>

<project name="tobacco" default="init">

<property name="class.root" value="W:\workspace\eas\classes\"/>

<property name="meta.root" value="W:\eas\Server\server\deploy\metas\"/>

<property name="juanyanclass.src.dir" value="com\kingdee\eas\scm\hntobacco\" /> <property name="metadata.src.dir" value="com\kingdee\eas\scm\hntobacco\" />

<property name="juanyaclassjar.dest.dir" value="c:\tobacco.jar" />

<property name="metajar.dest.dir" value="c:\metas.jar" />

<property name="juanyaclassjarsign.dest.dir" value="c:\tobacco_signed.jar" />

<taskdef name="kingdeesignjar" classname="com.kingdee.bos.bim.ant.task.KingdeeSignTask"

classpath="bimant.jar"/>

<target name="init">

<echo>清除原有构建文件</echo>

<delete file="${juanyaclassjar.dest.dir}"/>

<delete file="${juanyaclassjarsign.dest.dir}"/>

<delete file="${metajar.dest.dir}"/>

<echo>开始打包代码</echo>

<jar basedir="${class.root}"

jarfile="${juanyaclassjar.dest.dir}" includes="${juanyanclass.src.dir}\**\*"/>

<echo>开始打包元数据</echo>

<jar basedir="${meta.root}" jarfile="${metajar.dest.dir}" includes="**\*"/> <echo>打包元数据完毕！</echo>

<copyfile src="${juanyaclassjar.dest.dir}" dest="${juanyaclassjarsign.dest.dir}"/>

<echo>开始签名</echo>

<kingdeesignjar jar="${juanyaclassjarsign.dest.dir}"/>

<input>打包完毕，回车退出...</input>

</target>

</project>

这个脚本的运行步骤就是：首先删除上次打包的内容，然后将eclipse编译后的class文件打包，将发布后的元数据打包成metas.jar，将打包后的class复制一份，然后对复制后的jar包签名（portal客户端使用，如果客户现场没有采用portal

方式登陆，则无需这一步）。

部署人员只要从cvs上同步代码（需要eclipse编译代码）、元数据，然后发布元数据（只发布客户化开发部分即可），运行此构建脚本，停止服务器，然后将构建出来的包部署到服务器相应目录下，然后重启服务器即可（第一次部署需要重新部署应用服务器）。

当然从cvs上同步代码、元数据，编译代码，发布元数据，停止服务器，部署包，重启服务器等操作都是可以写在脚本中的（发布元数据、启停服务器等操作可以使用bimant.jar中提供的Task来完成），对ant熟悉的同事可以将此脚本写的更自动化，这样部署人员只要运行一下脚本，所有的构建部署工作就会自动完成。

客户现场开发和在研发中心开发的一个重要不同之处就是必须考虑如何将客户化开发的部分构建到标准产品包中。代码jar包可以通过分包的方式解决，但是由于所有的元数据都放在metas.jar中，所以将客户化开发的内容融合到标准产品的metas.jar中就成了大问题。因为不仅要把客户化开发的元数据打包到metas.jar中，而且还要在entity_pkmapping.properties、facade_pkmapping.properties、com_kingdee_eas_base_botp.mdbview、com_kingdee_eas_base_codingrule.mdbview等文件中增加客户化开发的内容，这样如果手动去修改这些文件的话不仅难度大，而且很容易出错。而且一旦新的标准产品包到达现场以后又要重新修改这些文件。

我们可以借助BOSStudio的元数据发布功能解决此问题，借助BOSStudio的元数据发布功能会自动去更新这些文件。我们只要把metas.jar解压到一个路径下，然后把BOSStudio的元数据发布路径也指向这个路径。这样我们只要发布客户化开发部分，然后将构建脚本的打包元数据的路径指向此路径即可。当有标准产品新的metas.jar到现场后，只要将metas.jar重新解压到此路径，重新发布客户化开发部分即可。

（三）开发测试流程优化

在项目开发的前期，由于功能性、中断性bug比较多，如果在这个阶段测试要采用打包部署测试的方式会使得bug验证修改周期变长、测试服务器频繁重启、影响其他测试人员的测试，从而导致项目整体开发效率降低。因此在这个阶段我建议采用更高效的方式：如果测试人员的机器配置较好，可以在测试人员机器上安装开发环境，这样测试人员就可以立即验证开发人员修改的bug，甚至在需要的时候开发人员可以直接在测试人员机器上进行调试，加快bug的修改速度；如果测试人员的机器无法运行开发环境，那么可以采用PT方式登陆开发人员的机器，甚至对于验证耗时较短的bug可以直接在到开发人员的机器上去验证。

当然到了功能性、中断性bug明显减少的阶段，测试人员还是要回到测试服务器上去验证，这样不仅会做到开发、测试工作相对独立并行进行，而且也有助于发现更多用前一种方式无法发现的问题。

三、技术问题

（一）执行特定数据库方言sql的问题

在标准产品的开发中是严格禁止使用只有一种或部分数据库系统支持的特性的，但是客户化开发中使用的数据库系统通常是固定的。在一些情况下使用某些数据库的特性则可以大大加快项目进度。幸好KSQL为我们提供了一个很小但是很有用的功能：执行数据库方言。我们只要在sql语句前加注/*dialect*/，这

样KSQL就不会对此SQL进行翻译，而直接将此sql转交给数据库执行。这样就达到了我们想要达到的效果。

（二）在客户端直接执行sql的问题

由于现在机构数据的EAS技术体系的开发人员基本处于空白，所以对于如果项目开发中有机构的开发人员则可以采取一些变通措施来最大限度的发挥这些同事的作用。比如很多机构的同事以前都是习惯使用VB、Delphi等RAD工具进行开发或者是只熟悉Java+DAO这样的开发方式，他们习惯了直接在客户端写sql语句操纵数据库的方式，他们刚接触EAS这种分布式开发方式的时候会比较不适应，要他们在短期改变开发方式也是不实际的。我们可以建立一个facade，在这个facade中公布executeQuery（执行查询语句）,executeSQL（执行无返回值的sql语句）这两个方法，这样开发人员就不需要ORM、EJB等这些知识就可以使用原有方式进行开发了。

当然这种方式必须要保证事务性并考虑并发操作等问题。

（三）开发数据库的选择

由于EAS是支持多数据库的，系统在数据库之间切换的代价非常小。所以对于比较大的客户现场开发项目我个人建议采用MS SQLServer进行开发，开发测试完成以后再切换到客户要求的数据库。

理由如下：

1、熟悉MS SQLServer的开发测试人员比熟悉其他数据库系统的人多，可以参考的参考资料也比较多，有利于提高开发速度。

2、MS SQLServer集成的开发用工具比较多，比如事件监听器、企业管理器、查询分析器等，而且易用性比较好。

3、MS SQLServer返回的错误信息也比较清晰易懂，有利于快速排错。

由于我参与过的客户化开发项目还比较少，因此上边说的有可能有疏漏与错误，希望各位前辈多多指教。

第二篇：Uasb调试经验总结

Uasb调试经验总结

1. 种泥的选择，个人比较认同书上写的污水处理厂厌氧消化污泥。接种量可以按厌氧容积的10%计算。污泥浓度60~70g（干污泥）/l,按80%的含水率计算，300~350kg/m3。有些书上写的30%的接种量，100g/l的污泥浓度。

2. 启动过程，低浓度有利于颗粒污泥的形成。Cod浓度至少在1000mg/l，不高于20xx/l启动初期间歇进水，在容积负荷0.5~2kgcod/m3.d期间，刚开始最好以略高于0.2kgcod/m3.d运行，HRT大于24小时，待cod去除率达到80%，再考虑增加负荷，按20%-30%的增幅增长，还是采用间歇进水，HRT保持不变，一直等到负荷到达2kgcod/m3.d，此后开始在此负荷下延长进水时间，直到24小时运行。上升流速低于0.5m/h。

3. 加入微量元素肥料，提供惰性载体如活性炭，璜化煤，膨润土和有机高分子絮凝剂有助于颗粒污泥的形成。

4. 在运行过程中，需要准备好纯碱或者小苏打，以防厌氧内碱度不足，水体酸化。

5. 对于VFA的测定，由于设备有限，需要仔细观察ph,尽量让ph维持在7.0左右，或者略高于7.0. 根据经验，ph很难维持在7，一般在6.2左右就很好了。

6. 有几个问题，对于低负荷运行时，究竟选择大流量短时间还是小流量长时间对颗粒污泥的形成有利需要探讨。

7. 在设计时，需对调节池采取“特殊”对待，既能满足一般调节池作用，又能在后期时采取临时措施，起到水解酸化池作用，换句话说采用 “水解酸化工艺+UASB”工艺，其实质时两段法的变相应用。水解酸化池的污泥来自好氧系统产生的剩余活性污泥，前提是变性。

8. UASB随着负荷的增加会出现轻质污泥的洗出，这种现象与污泥膨胀有关联。