一种替换EAI与Siebel商用适配器的方法

一种替换EAI与Siebel商用适配器的方法章沁芳（浙江大学计算机科学与技术学院 杭州 310027）摘要 商用EAI与Siebel CRM 7.7的适配器iWay在实际应用过程中经常出现不明原因的错误，对业务影响比较大。为了解决这个问题，采用了Java Servlet(HTTP)方式来替代iWay，通过一系列的性能测试和业务测试，证实了该方法可以有效解决该问题。关键词企业应用集成；Siebel；iWay；Java ；九七系统；客户关系管理1引言中国电信“九七系统”工程的建设将中国电信的业务系统推到了一个新起点，但由于市场的变化与电信业的重组，2002年以来电信行业竞争日益激烈，原“九七系统”已支持不了多变的市场营销的要求，2005年中国电信集团推出CTGMBOSS1.0规范1后对系统建设要求也更高，各省电信开展了新的基于客户理念的客户关系管理（CRM）系统的建设，国外成熟的套装软件如Siebel CRM、Comverse Kenan BP等也纷纷登陆中国电信业，成为各省业务系统建设的选用软件之一，同时EAI（enterprise application integration）2的概念也进入了企业的系统架构中，Web Logic8平台成为搭建EAI系统一个通用选择。在实际的应用中发现了国外厂商iWay开发的EAI连接Siebel应用的商用适配器3（iWay application systems adapter for Siebel，下文简称iWay）的一些问题，如无法建立Cluster，在电信级的业务流程中无法满足大容量大并发的需求，多次发生iWay不稳定导致挂起以致Siebel CRM无法下单，这些问题对业务的影响范围较大。目前恢复的手段主要是EAI server重启，再重启iWay，恢复所需的时间在30 min左右，这将大大影响服务质量与性能。本文为了解决iWay的错误对业务的影响，设计了一种基于Java Servlet(HTTP)的技术来实现CRM与EAI之间的消息通信，以此代替iWay。2商用适配器的问题分析适配器是将两个不同的平台间的应用数据转换成平台可以识别的标准协议信息，iWay Siebel适配器就是将Siebel XML消息经过转换后传送到EAI系统，在EAI内部是通过JMS来通信的。它本身是一个程序包，对于开发人员来说是个黑匣子，厂商提供的资料也很少。通过研究它的功能和数据流信息4，可以判断它本身所做的工作并不是很复杂，主要就是将Siebel的用户信息和订单数据转换成JMS格式并有一个错误控制机制以保证转换正确，它是一个双向的转换，其系统架构如图1所示，Siebel数据库与集成对象形成Siebel用户接口，并通过集成对象与适配器相互通信，Siebel内部的适配器进行XML的转换后提供给iWay，同时也提供Java API调用给iWay，iWay接收了之后将HTTP格式转换成BEA EAI的协议格式并传送给其他系统，所以iWay适配器(iWay Adapter)是很重要的一个环节，其与Siebel系统及EAI系统连接的iWay Adapter架构如图2所示。从图1与图2可以看出，iWay适配器的主要功能通过“侦听”或“触发“的方式与Siebel应用相连，并接收Siebel系统业务事件处理的结果，其一侧用HTTP方式连接，另一侧连接BEA Web Logic8。由于适配器是黑匣子，一旦出了性能问题或根本性的故障，将会导致订单流转不稳定以致系统中断。这些问题无法根本解决，只能通过重启适配器，而重启适配器必须重启EAI server，由此带来了巨大的性能影响。本文将自主研发一个适配器来取代iWay，以此实现iWay相同的功能与接口。本文在架构上采用了类似iWay的方式以保证原有的流程不改变，以减少因改动而带来的风险。该适配器提供的转换及调用的功能尽量模拟原来的适配器iWay。3Java适配器的架构及方案通过上文的分析，可以确定替代用的适配器功能主要如下：得到Siebel请求有效的XML schema格式；发出Siebel请求给EAI分布式JMS队列；响应成功或失败的消息返回给Siebel。本文采用基于HTTP协议的Java Servlet 技术5，对于不同的请求（账户、订单、语音通道等）用不同的HTTP URL来对应以便更好地提供服务。由于这个方法是完全架构在Java基础部署EAI WebLogic，解决了原来的iWay适配器无法建立Cluster的不足（WebLogic支持Cluster），可以更好更多地容纳大并发，架构的采用如图3所示，与旧架构相比变动的主要是在EAI侧建立几个HTTP入口来应对Siebel的服务调用，并建立一个Java类来执行。其中时序控制上采用如图4所示，当接收到CRM发的消息，返回一个验证确定消息，经过中间的转换后发送消息给EAI的消息队列，成功完成事务发回适配器，然后由适配器发送确认消息给CRM。使用Java开发时可以定义一个类，如图5所示，其中HTTPAdapter主要功能是接收Siebel XML消息,验证格式,并发送到分布式消息中，父类定义为HTTPServlet，主要属性定义如表1。4测试方法及结果为了测试新开发的适配器是否能满足需求以替换原来的适配器，必须经过严格的性能测试和业务测试。本文搭建了一套测试环境，主要以吞吐量或每秒话单数来衡量应用性能，采样了包括CPU、内存和磁盘输入输出的数据进行统计分析。测试环境架构如图6所示。首先用测试程序发送数据到F5负载均衡器，然后自动分配到不同的适配器处，通过EAI平台传送数据到其他系统，测试主要是侧重于EAI平台中的传送性能，其他外系统不在测试范围。本文测试硬件配置如表2所示。本文挑选的用例涉及到了典型的日常操作，具体如表3所示。测试设计了8个场景，主要是针对不同的并发量（60/120/240/480）及不同的时间（30 min和12 h）来进行加压测试。分别用每秒3个、4个、5个或6个事务的频率向新适配器加压，用来测试该接口的吞吐率是否达到要求，另外也在较长时间（12 h、40 h）不间断地对新适配器进行加压，观察系统的资源使用情况和事务的响应时间，以确定系统的可靠性和稳定性。由于本次测试的目的就是为了检验 新适配器的性能是否能够满足生产系统的要求，故只经过EAI中某些流程，而非全部的流程，步骤如下。 由测试程序模拟发起新建账户,新建订单和IVR（语音）； 消息经过F5负载均衡发到2台EAI（省级）的服务器上，由新适配器接收； 新适配器将消息分别发送到EAI 的Account/Order/IVR队列中； EAI（省级）将Siebel消息进行拆单，转换成CDM并存入数据库； EAI（省级）将消息发送到EAI（地市级），存到“九七系统”接口表。测试的目标是要求最大吞吐量不能超过6.06 T/s（事务数/秒）及最大并发数达到480，测试结果记录了不同并发量情况下的吞吐量及CPU、内存占用情况，由于篇幅有限只给出60、120、240、480并发情况的吞吐量（见表47）。通过4种并发的吞吐量比较可以认为吞吐量没有超过预期，符合生产的要求，同时从内存及CPU的使用情况来看，没有发生内存泄漏及CPU异常占用的情况，可以达到生产的要求，相对原来的iWay适配器性能上有所提升，最重要的是没有出现内存泄漏及连接异常占用不释放的情况，系统能够保持长时间的稳定。参考文献1中国电信集团公司.CTG-MBOSS规范1.0,20052娄丽军. EAI技术和概念解析， http:/www-900. ibm. com/developerworks/cn/wsdd/lirary/techarticles/loulijun/0412/eai.shtml3iWaySoftware.iWay application system adapters技术白皮书4BEA.iWay universal adapter framework for BEA WebLogic技术白皮书5李绪成. Java EE 5实用教程基于WebLogic和Eclipse. 北京：电子工业出版社，2007