通过数据交换消除信息孤岛.ppt

前置机组流程 路由控制——指标模型 指标系统的统一规划 在面对成百上千的需要交换的数据库、数据表，如何通过一套统一的方案进行数据传输控制是一个十分关键的问题。因此需要对这些交换内容进行统一的规划。 将数据库抽象为接入点 将数据表抽象为指标 将字段抽象为指标项 指标系统的实际意义 通过一套统一的指标数据，实现对所有交换数据的约束控制。 路由控制——路由表 在指标的基础上建立路由信息表，对所有接入点的收发数据依据指标订阅情况进行控制 交换中心的接收到数据包后，对数据包中的To节点进行分析，取出其ToItem节点，并发送到与之对应的接收端口，如果存在多个则对数据包依据节点数量依次发送，这需要在BizTalk里实现一个循环操作过程。 交换中心路由流程 BTS群集 在交换中心的BizTalk环境中，我们采用了2个机器组成的BizTalk群集，共同负担路由传输工作。 为了控制并发问题，对注册表中的RenameReceivedFiles的值作了修改，使数据包在被某个机器接收的时候修改其扩展名，以避免其它机器的读取。 BizTalk控制 由于项目中存在多个接入单位，而前置机器分别放置再各部门的机房，为了能更方便的使用同一个入口管理所有的前置程序，我们可对前置机上部署的部分程序通过WMI实现Web管理。 编写一个Windows服务程序，用于控制BizTalk主机启动与否。 使用管道加解密数据包 MIME编码方式的缺陷 全编码方式，在不解码的情况下无法得到一些基本信息。 所开发管道的功能 仅对Body加密 跟踪调试功能 Mime编码： MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-ID: {EAAFB413-7222-41EB-ADC1-42AA6CBFD697} Content-Description: body 编码内容 自定义管道编码： ?xml version=1.0 encoding=utf-8 ? ns0:Root xmlns:ns0=http://PowerSwitch.CenterRouterIn Head BatchNumber0/BatchNumber PackageCode0/PackageCode PackageNum0/PackageNum PackageType0/PackageType PackageTime0/PackageTime PackageFlag0/PackageFlag IsReSend0/IsReSend Discripton0/Discripton From0/From ToToItem0/ToItem/To Check IsCheck0/IsCheck CheckAd0/CheckAd /Check /Head Body编码内容/Body /ns0:Root 日志信息、错误记录、数据跟踪 日志信息 系统日志 交换记录 错误信息 错误捕获 错误归集 异议处理 数据跟踪 发送标记 路由标记 接收标记 数据备份 对所有发送、交换、接收的数据进行备份，并且采用数据库和Xml文件双备份。 这些数据可以通过Web平台检索察看到，并且在Web上支持内容解密、Xml文件内容检索。 可通过备份数据直接实现重发功能。 备份数据异常庞大，需要做好性能足够好的历史数据处理模块。 项目中的问题 在项目中我们碰到过很多问题，其中具有代表性的有下面这些，这些都是曾经困扰过我们的，但最终都寻求到了解决办法，当然，我们的解决办法不可能是最好的，甚至可能背离了BizTalk的设计思维，但仍然很乐意和大家一起分享。 消息架构方面的问题 大量数据顺序处理 对异构数据库的处理 缓冲区程序的生命周期 群集的协同工作 HAT中不可恢复数据的批量处理 消息架构方面的问题 变更消息比较繁琐 在项目开发过程中，当因为某种原因需要变更信息架构的时候，已有程序中已经引用了该消息的地方都会提示错误信息，从而不得不重新设定很多信息。 同一机器上不能部署同样的消息架构 当多个流程中需要使用相同的消息架构时，需要先将这些公用的Schema独立出来，然后再共同引用这些Schema，否则会产生冲突。 大量数据顺序处理 由于BizTalk的始发端口一般采用被动触发模式，当大量的数据同时进入该端口时，容易引发一些异常。特别是WebServices模式下。一般情况下最后使用另外的机制来控制端口流量。 当通过同一端口的数据存在一定的先后顺序，而这些顺序间的关联相对复杂时，难以使用BizTalk 来实现这些关联数据间的联合（简单的可以使用相关集实现）。 对异构数据库的处理 Adapter的局限性 由于Adapter具有一定的适用范围，因此，很难以一种Adapter来同时应对各种类