应用系统整合（共12篇）
应用系统整合 篇1
1 引言
JSF是Sun公司2006年推出的用于构建Java Web应用程序的标准框架, 它提供了一种以组件为中心的用户界面 (UI) 构建方法。像Struts框架一样, JSF定义了一套JSF标签, 能够生成与JavaBean属性绑定在一起的HTML表单元素。从而简化了Web客户端的开发过程, 也减轻了Java服务器端应用程序的开发。
JSF引入了基于组件和事件驱动的开发模式, 使开发人员可以使用类似于处理传统桌面应用程序的方式来开发Web应用程序, 使得行为与表达清晰分离。JSF技术还为管理组件状态提供了一个丰富的体系机构, 可以设置组件的属性值、生命周期等, 使得组件可以在部署时进行配置。
2 设计思路
从上面的描述中, 不难发现JSF有很多优于传统BS开发模式的地方。下面将在此基础上探讨一下构建基于JSF架构的数据库Web应用系统整体思路。
一个面向数据库的BS系统应该包括UI、Action (用于接收客户端传来的请求和参数) 、Service (用于处理业务逻辑) 和DAO (用于处理数据库交互操作) 这几部分。
JSF是针对UI和Action的解决方案, 不同于Structs的是Action对象仅仅是一个POJO, 不需要继承特定的类, 而且UI的事件直接映射到后台处理Bean的方法中。
Services是应用系统的核心, 用于业务逻辑处理, 可能要同时操作多个表, 进行多种资源操作。可见, Services往往是需要进行事务处理的。Spring在事务处理方面的努力一直为Java界所公认, 而且是一种轻量级的解决方案。所以, 本文将以Spring为Services管理容器进行讲解。同时, Spring的IOC、APO等技术是它的灵魂。根据应用系统的实际情况, 将这些技术加以利用, 从而优雅地扩展应用系统功能, 提高系统的解耦能力。
DAO部分已经有了相当成熟的ORM架构, 比如iBatis、Hibernate等, 本文将以Hibernate为例进行描述。
基于JSF架构应用系统的总体思路如图1所示。
3 架构整合
在整合JSF、Spring和Hibernate之前, 先弄清楚JSF的调用过程。JSF是基于Servlet的架构体系, 它接管了来自客户端的JSF请求。通过对画面上所有组件的过滤和整理, 将提交上来的数据传递给相应的后台处理Bean。也是由于这个原因, 需要在后台处理Bean中设置属性的set和get方法, 接收或设置页面提交或展现的数据。
关于JSF, Spring和Hibernate整合, 在网上有很多文章, 下面只对其中的部分要点做简要描述。
在JSF架构中, 后台处理Bean (Backing Bean) 交由JSF容器进行管理。配置文件为faces-config.xml。Bean对象的生命周期可以为null:用时才生成;quest:请求时生成, 请求期间存在;session:session开始时生成, session期间存在;application:整个应用程序运行期间都存在。对于无状态要求后台处理对象的生命周期可以设置为null;对于request期间用到的后台处理对象, 生命周期可以设置为request, 对于需要记录用户状态信息的对象可以设置为session。还有一种后台处理Bean, 也可以设置为session。那就是用户经常用到的工具类对象, 比如数据导出、数据上传、报表图片绘制等。
后台处理Bean可以引用其他对象作为传入参数, 因而在部署时可以配置该后台处理Bean, 也就是反向注入技术的应用。引用的对象可以是JSF管理器中管理的对象, 也可以是由spring管理的对象, 比如service等。若要在JSF管理器中管理的对象中引用spring管理的对象, 需要在JSF中配置spring的EL (Expression Language) 解释器。具体是在faces-config.xml中加入如下信息:
下面的后台处理Bean中引用了有spring管理的generalDAO对象。在初始化mainAction时传入generalDAO对象, 在处理客户端请求时便可使用该DAO对象与数据库进行交互。
应用系统中要进行数据库操作, 需要Service处理包含事务管理能力。通过Spring声明式事务配置, 将Spring管理的Service对象交由transaction对象进行管理。传入到Action对象的Service对象就变为Service的代理对象, 从而Service对象具备了事务处理能力, 而不必在程序中硬编码。
事务处理配置步骤如下:
(1) 数据库连接池:可以使用Apache的对象池或者c3p0, Apache的对象池的已满足。主要是注意初始链接数、最大连接数和最多空闲连接数的设置。
(2) sessionFactory:主要注意Hibernate的几个参数, 包括优化设置、缓存设置和是否显示SQL。
(3) 配置事务管理器。
(4) 事物拦截器:注意事务策略的选择。
(5) 事务代理处理程序:该程序在Spring初始化时自动调用。该处可以配置该类是采用接口编程还是采用原始对象编程。如果选择原始对象则必须设置proxyTargetClass为true, Spring将调用Cglib重写由该代理处理程序代理的类。
JSF和Spring都是对象管理容器, 但侧重点有所不同。JSF侧重于页面后台处理对象的管理;Spring容器侧重于Service层面对象的管理, 并通过反向注入、面向切面编程技术在Service层面上优雅地附加额外处理, 比如自动事务管理、操作审计功能等。利用Spring对象管理容器及其特性, 为应用系统的模块解耦、灵活设置和功能扩展提供基础架构支撑。
以上这些内容涵盖了JSF、Spring、Hibernate三者的结合方式和各自的分工, 但在实际应用的BS系统中还需要解决其他一些问题, 例如:
(1) 客户端表现层的选择。
(2) 认证与授权。
(3) 权限控制 (访问、操作) 。
(4) 图片输出能力。
(5) 文件导出、下载功能。
(6) 页面缓存能力。
(7) 分页功能。
(8) 异常捕获能力。
(9) 日志处理能力。
(10) 消息处理能力。
以上这些问题将在下面逐一进行探讨。
4 客户端表现层选择和应用
基于JSF的客户端有很多种表现层技术可以采用, 在这里推荐使用Facelets技术。Facelets非常适合JSF, 其发挥了JSF的最大特性。
JSF本身是树形结构描述的组件集合, 而Facelets也采用XML这种树形结构作为描述方式, 因而描述更自然。而且Facelets支持多种表现方式, 例如html、wml等xml结构的表现形式。同时, 浏览器在解析严谨规则描述的结构也比那些非严谨结构性描述的html更容易、速度更快。可见, Facelets是一种易扩展、易理解、易编程的表现层描述语言。
为了在系统中使用Facelets, 需要在配置文件faces-config xml中配置Facelets解析工具。具体配置如下所示:
在页面 (xhtml) 中定义页面语言编码、命名空间和所有使用到的标签库。具体如下所示:
在页面中可以使用模板技术, 这是Facelets的优势之一。在模板中定义页面的基本框架和内容的嵌入位置等。在具体表现页面中定义展现的内容, 同时还可向模板传递参数, 比如标题、样式表URL等。使用模板可以保持应用程序总体风格一致, 同时保持页面表现的灵活性和易扩展性。
在页面中声明适用的模板:
页面标签中一般存在两种事件响应设置, 分别是action和actionListener。它们都可以映射到后台处理Bean的某一方法, 但不要将它们的设计目的混淆。action用来执行真正的业务逻辑, 而ActionListener则是作为事件监听器。在后台处理Bean的事件监听方法里可以获取触发事件控件的相关的内容, 也可以获取根据实际需要向后台处理Bean传入自定义参数。调用的顺序也是先调用监听程序再调用事件处理程序。因为目前Sun JSF尚不支持在调用action时直接将参数放置于方法的机制 (Seam架构已经支持这种机制) , 客户端可以利用监听对象传递参数给后台处理Bean。下面是一个实现导出Excel文件功能的页面描述:
此处, 通过ActionListener将参数, 包括文件的类型和数据参数传递给后台处理Bean。处理事件的action方法可以根据此参数获取要处理的数据, 然后组织成Excel文件输出到客户端。
JSF是基于标签UI组件的, 因而Sun公司的JSF核心程序包和标准包提供了很多可用标签。但这些标签往往难以应对应用系统的多种复杂需求, 比如菜单、树形列表、选择标签等特殊UI形式。为此, 在JSF工程中可以方便地引入第三方开发或自开发的标签, 获取更为丰富的功能和表现方式。
在应用实践中, 引入了richfaces和j4fry两个Tag用于功能和表现形式的扩展。其中的richfaces提供了丰富的Tag组件, 包括Menu、Tab、Tree等。J4fry提供了初始化页面的能力, 用于画面数据的准备工作。它们的使用如下所示:
图片数据的动态生成和表现, 典型的应用就是报表图片显示。结合JSF同时在页面上灵活展现报表, 可以采用richface的Paint2D标签。具体使用如下:
后台Bean中对应Paint的处理事件将画面准备时制作的JfreeChart对象按字节流方式输出到Paint2D控件上。细心的读者可以看到, 报表图片数据参数是从Data属性传递过去的。Data属性为应用提供了一种通过页面配置图片输出的可能, 可以根据应用的需要不断扩展, 与上面提到的f:attribute标签具有异曲同工之妙。
5 服务器端问题解决
下面就服务器端开发中可能遇到的问题进行探讨, 给出一些解决办法。
5.1 图片输出功能
前面已经提到, 图片处理采用后台Bean输出字节流到客户端标签的方法, 这需要在页面上配置Graphic2D标签。在标签中指定后台处理Bean的方法以及数据。在后台处理Bean中取得该图形数据, 由JfreeChart对象输出到页面标签中。Pain的方法如下所示:
5.2 文件导出、下载功能
该功能如果采用先由Web服务器输出文件到硬盘, 然后再传输到客户端的方式, 这无疑加重了服务器的负担。因为要判断输出是否结束而且要正确结束, 生成后的文件清理工作也比较复杂。尤其是动态生成的文件更具有频繁性和临时性特点, 比如Excel报表文件。如果处理不得当, 在服务器将存留大量未能正确下载的文件, 日积月累, 难以维护。因此, 文件导出建议也采用向画面输出字节流的方式。
下面是文件导出后台处理Bean的方法:
5.3 分页功能
分页功能是每个应用系统都有可能遇到的实际问题。如何不破坏逻辑处理, 简单、优雅地提供该功能是要考虑的问题。
分页一般有两种方式, 一种在处理类中查询出满足查询条件的所有记录, 一种采用按页码实时获取数据的方式。第一种方式的好处是时间只消耗在第一次查询, 同时也获取到了全部记录数等信息。缺点是对于数据量超大的结果集来说就失去了分页的意义 (查询第一次的时间等于没分页的查询时间) , 而且不能反映数据的实时变化情况。第二种则需要管理页码状态并且在每次查询时都需要统计总记录数等信息, 好处是可以获得更新后的实时数据, 能够及时反映数据变化。
那么JSF如何显示数据分页呢?在页面上采用rich datascroller标签来分页显示数据。该标签可以嵌入到任何继承自DataTable的组件中, 自动计算页数并控制前后页按键的失效和激活。可以说, 该控件在客户端解决了分页功能的所有问题。但不幸的是, 该控件后台Bean使用第一种方式进行数据存储, 即一次性查询所有数据。
基于上面的分析, 不希望在客户端修改代码, 因为那意味着需要管理更多的页面信息。同时希望后台Bean的数据采集能够及时反映数据的变化, 不影响页面控件对页码、总页数的正确显示。
结合以上的考虑, 选择将DataTable的数据集DataMode进行伪装的解决方案。重载其中的getRowData方法, 在该方法中从数据库按页码取得该页数据。并在该类中保存客户状态, 即页码等信息。
5.4 页面级缓存
页面范围缓存, 顾名思义, 就是将用户操作状态绑定到当前页面范围内, 一旦用户跳出当前页面则与该页面相关联的数据就被自动清空。
说到保存用户操作状态信息, 自然会想到Session。在Session中保存用户登录和其他用户状态的信息。如果在Web服务器中, 这种信息过多、数据量过大, 计算机内存的消耗也就越多。如果不能做到及时清理, 很可能导致Out of Memory错误, 最终结果便是Web服务器崩溃。实际上, 很多信息只是临时使用的, 而且与页面的关联度很高。为此, 考虑将数据与页面关联, 一旦用户跳出该页面则与该页面向关联的数据就被清空。对于其他状态信息则依靠Session失效来清空。
首先建立一个页面Object管理类, 用于存储、获取和移除页面关联数据。将该Object管理类注入到JSF容器中, 托管范围为Session。再设置一个PhaseListener用于页面跳转时处理页面关联的Object, 该监听实现了PhaseListener接口。具体处理时机可由读者自己安排, 处理过程如下所示:
5.5 授权与权限认证
解决授权和权限控制是应用系统中常见的问题。授权主要通过角色进行, 权限控制则从多个层次进行控制, 例如页面访问控制和业务操作限制。这两种权限控制都可通过配置文件进行描述。
页面权限检查放在前面提到的PhaseListener监听器中。检查时根据权限配置文件核准要访问的页面ID, 如果没有查看该页面的权限则将页面转到登录画面或其他信息提示页面。
业务操作权限检查放置在NavigationHandler中, 检查时根据权限配置文件, 核准页面ID和Action ID。如果没有执行该动作的权限则将页面转到登录画面或其他信息提示页面。
在JSF容器中注入NavigationHandler监听程序, 以便拦截Action。
配置文件的书写如下:
5.6 异常捕获能力
对于异常处理, 系统考虑将其捕捉地点放在统一的位置, 而且脱离业务处理逻辑。
若想对捕捉到的错误进行修饰, 可以在应用系统自定义的异常对象中加入给最终用户的提示信息, 加入给系统维护人员的详细说明信息。然后再抛出该修饰后的自定义异常。在错误处理页面上显示用户提示信息, 在Log文件中记录异常详细情况。
5.6.1 异常的捕捉
异常的捕捉需要放置在两个地方, 一个是ActionListener, 另一个是Filter。
ActionListener可以拦截Action调用过程中的异常。但此时FacesContext还依然存在, 仍然可以在FacesContext中加入错误提示消息, 然后转向到错误处理页面。
在JSF容器中注入Action监听程序, 拦截Action执行过程中的异常。
ActionListener中异常捕捉和处理部分代码如下:
Filter拦截那些没有被ActionListener拦截并处理过的异常错误。但此时FacesContext已然不存在, 无法在FacesContext中添加错误提示消息, 需要通过HttpServletRequest传递错误提示消息到错误处理页面。
Filter中异常捕捉和处理部分代码如下:
对于其他Web服务器错误, 需要在web.xml中配置错误处理。
5.6.2 错误信息显示
(1) 通过FacesContext显示
(2) 通过ServletRequest显示:
5.7 日志处理能力
日志处理能力可以采用常规的Log4j日志组件, 配置步骤和建议如下:
(1) 添加log4j处理包到lib文件夹中。
(2) 配置Log4j配置文件, 指定log等级、保存位置、日志文件更替频率以及日志书写格式。
(3) 建议日志等级平时设置为error, 输出位置为DAYLO GFILE, 这样日志内容较少 (占用资源少) 、按天查看、检索也比较方便。
(4) 在程序中选择性地输出Debug和Info信息, 以便日后维护时通过调整日志级别获取调试信息, 方便快速定位错误点。
5.8 消息处理能力
在应用系统中, 消息文件作为一种系统资源, 通常作为错误处理的消息显示来源, 也用于国际化时页面Lable的显示。JSF画面上的自动校验 (Validator) 组件也会从消息文件中自动获取提示消息。
在JSF应用系统中, 通过faces-config.xml文件来配置消息文件, 如下所示:
在com.company.package这个文件夹下需要一个命名为messages_zh_CN.properties的文件, 消息文件内容的格式为property=value。具体举例如下:
对于非统一编码 (Unicode-encoded) 或者非拉丁文文字编写的消息文件, 在Java环境中无法正常显示, 需要使用native2ascii工具进行转换。转换命令为native2ascii[options][inputfile[outputfile]]。http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/native2ascii.html。
6 结语
很多开发人员不愿放弃已经掌握得很熟练的Web开发技术, 再投身到一个陌生的开发环境中。所以, 国内JSF技术的应用还不是很广泛。此文的目的也就是向大家提供一个平台, 展示一下在JSF环境中怎样处理Web开发中经常遇到的一些问题。可以看到JSF为Web开发提供了更多的嵌入式接口和丰富的组件选择, 是Web应用快速开发的好帮手。
应用系统整合 篇2
分数应用题是小学应用题教学的重点和难点，由于抽象程度比较高，学生难以理解和掌握。怎样解决好这 一难题，成为众多教师教学研究的热点。
数学应用题的构成要素是：具体内容，名词术语，数量关系和结构特征。这些构成要素不是孤立的，而是 相互联系的，是造成学生解答应用题困难的原因。其中，处于核心地位的是数量关系。确定了数量之间的相互 关系，才能得到解决方法，因此应用题教学应在理解题意的基础上，重点抓住名词术语进行分析，把握数量之 间的等量关系，学生才能真正掌握解题方法。
系统论的整体原理是：整体的功能＝各部分功能之和＋各部分关系功能，这说明整体功能大于各部分功能 之和。分数乘法、除法应用题是一个各部分相互联系的整体，除法应用题可以转化为乘法应用题，把分率改写 成百分率，则分数应用题又成了百分数应用题。
综上所述，我们应该抓住知识的迁移条件，以数量关系为核心，整合教学分数应用题的过程。
教学简单的分数应用题，可以依据结构特点分为“部分与整体相比”与“一个数和另一个数相比”两类， 按互逆关系组合整体教学。
如：教学部分与整体相比的应用题，可这样编题组教学。
例 （1）六年级一班有学生45人，其中男生有25人， 男生人数占全班人数的几分之几？
（2）六年级一班有学生45人，其中男生占5／9，男生有多少人？
（3）六年级一班有男生25人，占全班人数的5／9， 全班人数有多少人？
通过例（1）的教学（具体做法略）， 让学生明白此类题的形成过程及结构特征。男生人数和全班人数是 部分与整体的关系，“几分之几”（分率）是由部分与整体相比产生的，与“倍”的实质是一样的，表示两个 数的倍数关系（扩展了分数的意义）。
通过例（2）的教学使学生懂得一般的解题思路， 首先明确了谁是单位“1”的量（解题关键）， 再根据 分数乘法的意义列出数量间的等量关系式，然后把关系式抽象为算术式或方程式。
在教学例（2）的基础上教学例（3），借助线段图，与例（2 ）对比分析，让学生明白解题思路相同。所 不同的是：例（2）单位“1”的.量是已知的，直接用算术法（乘法）进行计算，例（3）中单位“1”的量是未 知的，用方程法计算，也可根据除法意义直接用算术法（除法）进行计算。
通过例（1）（2）（3）的教学， 让学生明白这是一组部分与整体相比，并且是具有互逆关系的简单分数 乘、除法应用题。教学完（1 ）、（2）、（3）后可以把教材中的两个例题作为尝试练习题进行巩固，然后布 置对应的作业。
教学较复杂的分数应用题，依据结构特点，分为“部分数与部分数相比”、“部分数与整体相比”、和“ 相差数与较小数（或较大数）相比”三类，按发展、互逆关系组合整体教学。
例如，教学“部分与整体相比的较复杂应用题”可以这样编题进行教学。
3
1.出示：“发电厂原有一堆煤，用了─”。首先让学生明确单位“
5
1”的量，并画出线段图：
附图{图}
2.在图上分别补充条件和问题，让学生编写一步计算的具有互逆关系的两道简单应用题，并进行解答，为 知识的迁移、发展作铺垫。
附图{图}
3
发电厂原有一堆煤2500吨，用去─，用去了多少吨？
5
附图{图}
答：（略）
附图{图}
3
发电厂原有一堆煤，用去了─，刚好用去了1500吨，这堆煤原有多
5
少吨？
附图{图}
答：（略）
3.把（1）题中的线段图这么改（如下图），就成了求什么问题，让学生编题，迁移到下题
3
发电厂有一堆煤2500吨，用去了─，还剩下多少吨？与（1）题比
5
较分析数量关系。
附图{图}
3
单位“1”的量相不相同（相同处在于都用去了总重量的─）？原有的
5
数量关系存不存在（存在）问题发生了变化，又滋生了一个什么样的数量关系（部整关系）。
3
总重量×─＝用去的 总重量－用去的＝剩下的
5
3
2500 ×─＝？ 2500－（？）＝？
5
确定解题步骤（先求什么？再求什么？综合算式怎么列？）进行解答检验（略）。
4.把上题中所求的结果作为条件，把总重量（2500吨）作为所求问题（如下图）让学生编题，迁移到下题 。
附图{图}
3
发电厂原有一堆煤，用去了─，还剩1000吨，发电厂原有煤多少吨
5？
比较分析数量关系：单位“1”的量相不相同（相同）， 题中还有哪个数量关系？题中的一个条件和问题 只是发生了互变，题中的部整关系会不会改变（不会）？
附图{图}
这样，两个关系中都有两个不同的问题，一个中间问题，一个最终问题，怎么办呢？能不能将两个不同的 “？”转化为一个“？”（提示：像列综合算式那样，将两个关系式组合成一个含有最终问题的综合关系式） 。
附图{图}
选择解题方法（方程法或算术法），进行解答检验（略）。
5.小结，重点让学生懂得：解答较复杂的分数应用题，首先仍然要明确单位“1”的量，然后列出基本的数 量关系式， 确定解题步骤（先求什么，再求什么），如果列出的关系式两个不同的问题，就将两个关系式组合 成一个含有最终问题的综合关系式，然后选择解题方法（方程法或算术法）进行解答。
资源再构建 系统重整合 篇3
一、区域性数字化校园建设初衷
在数字化校园建设的过程中，我们发现，因为缺少统一的规划，导致各学校的数字化校园系统都是独立的。随着校园网络化、信息化应用的深入，由此而产生的问题也逐渐暴露出来。
1.信息缺乏有效共享。因各校建设数字化校园的步伐不同，学校学科的侧重点也不同，导致在资源建设上的严重不均衡性，甚至有些边缘学科无资源可用，产生了信息孤岛。此外，信息不能有效共享，重复建设现象严重。在使用上，由于信息缺乏整体性和关联性，降低了信息的服务功能，影响了用户对信息的有效使用。
2.数据格式不统一，资源深层次利用受到制约。由于各单位所采用的软件系统不一致、数据标准不统一，并且分布在各个相对独立的服务器中，数据交换难度很大。比如，各学校在数字化校园建设过程中都建立了自己的教师及学生管理的数据库，因各单位使用的软件系统不同，导致区域内师生管理系统的大量重复建设。数据格式的不统一又使得在进行统计分析、数据挖掘时，有些操作无法进行。
3.系统缺乏有效集成，维护成本高。由于缺乏统一的集成设计，各用户都有自己的登录接口、界面以及登录用户名和密码。面对繁多的应用系统，用户难以寻觅所需，人性化程度低。随着校园网应用和资源越来越多，又暴露出缺乏有效的组织和管理的弊端。
鉴于此，在目前的网络环境下，如何加强区域性的数字化校园的建设，如何建立包括学校—地区—县市多级协作组织的信息资源共建共享体系成为扬州市电教馆的一大重点工程。
二、区域性数字化校园建设的理论支撑
建立包括学校—地区—县市多级协作组织的信息资源共建共享体系是指将各学校资源站点连为一体，统一到扬州市教育城域网中，以各区县的城域网为支撑，将现有的各职能部门的信息联系起来，使得同一区域内各个站点之间不再相互孤立，最终形成统一的门户。来访者可以方便地通过一站式服务平台统一获得信息和服务。区域内管理是实现分层次的权限分配、导航和检索，消除“信息黑洞”和“信息孤岛”的基础，以区域为单位统一开发供各学校共享的网站集群的软硬件资源、网站管理系统和互动交流系统。该体系的建设模式遵循“统筹规划、分步实施；统一标准、统一规范；联合共建、互联互通”的指导思想。在具体创建过程中，提出了一个基本公式：区域性数字化校园=数字技术+学校各项工作。我市区域性数字化校园系统结构如下图所示。
扬州区域性数字化校园系统图
三、区域性数字化校园建设的流程
我市的数字化校园建设起步较早。各校、各地区已经建立小范围的数字化校园。教育城域网业已形成；网络物理平台的搭建也已建立；网络集成设计已基本到位。结合学校信息化建设的现状，突出地区特色，我们的主要目标是实现信息共享、实现信息的标准化与数据交换、区域一体化平台的建设、用户综合服务的设计、信息的综合挖掘利用，并考虑与整个教育系统和社会信息对接等。
1.分析区域内各校数字化校园建设现状，建立信息的标准化交换模式，构造一站式服务平台
目前，扬州市区域范围内各学校所采用的数字化校园平台主要有中教育星、维思特、国资源、翰林汇、校际通资源网等。各系统采用的数据标准不一致，数据库结构、系统架构也不同。为此，扬州市区域性数字化校园主要以“华教维思特数字化校园平台”为支撑，将其他单位的数字化校园平台统一进行增删、转换，构建扬州市分布式管理平台。数据交换的标准化模式建设将与相关公司协作，根据信息资源规划（IRP）的需求分析，按照教育部颁发的《教育管理信息化标准》制定规范统一的信息标准，包括建立数据元素标准、信息分类编码标准、用户视图标准、概念数据库标准和逻辑数据库标准等。当然，信息的标准化交换建立不是一项孤立的工作，应伴随整个信息资源规划过程而逐步建立，在其后的数字化校园数据库和应用系统的开发过程中执行并不断充实。依据此数字化校园信息的交换标准，将现有的各校数字化校园平台进行有序增删。
（1）未进行数字化校园建设或建设数字化校园时间不长的学校，抛弃原有的数字化校园平台，直接以扬州市区域性数字化校园平台为基础进行建设。
（2）自建数字化校园平台、系统设计较为繁琐但应用资源比较丰富的学校，抛弃原有的数字化平台，将资源依据扬州市区域性数字化校园标准统一进行数据重建。
（3）原来就采用该数字化校园平台的学校，将现有资源进行重新分类，去除冗余资源。
（4）数字化校园建设及应用比较成熟的学校，鉴于资源量比较丰富、系统较为稳定，建议研究内外数据接口。
2.根据标准的信息化交换模式进行部分数据环境重建，实施现有应用系统的优化及整合
数字化校园的无序建设导致校园网信息资源混乱、信息资源重复建设、信息资源贫乏等问题。要彻底解决该问题，最终形成学校—地区—县市多级协作组织的完整的信息资源共建共享体系，就要按照标准的信息化交换模式建设资源，实施数据环境重建工程。区域性数字化信息资源共建共享体系的数据环境重建不仅要以数据文件、应用数据库为基础进行建设，更要借助主题数据库、信息检索系统来满足学校对信息化的需求，保证高效率、高质量地利用数据资源，在数据集成的基础上实现应用集成，进而达到真正的系统集成。对数据环境重建按以下步骤进行：
（1）重整数据结构。以扬州市教育城域网的数据模型的基本表为标准，逐一衡量已有数据存储的结构，找出差距，确定哪些数据结构可以修改、补全，哪些数据结构不合理，需要抛弃，还要增加哪些新的数据结构。
（2）系统数据转换。对已积累的数据库资源按照新的数据模型基本表的结构标准组织数据转换工作，将原有数据库资源加载到新数据库中。
（3）研制内外数据交换接口。对于应用较为成熟的数字化校园系统，或涉及范围较为广泛的、不可改动的数据结构，为了避免“信息孤岛”效应，只能以数据模型的基本表为标准，研制本单位与外单位数据交换接口表，再利用数据库中间件等技术实现数据的自动交换。
3.根据各校自评的情况及目前资源分布的特点，对资源进行系统整合，由扬州市电教馆重新确定各地区资源建设的侧重点
数字化校园资源的建设是一个繁琐、长期的过程。对于每一个学校而言，建设大而全的资源库是个得不偿失的事情。因此，我们建立区域“中心资源库”和学校“子资源库”，并通过扬州市分布式资源库管理平台连接成一个整体，即形成以区域中心资源库为主体，并分布远程管理各子库的资源管理系统。区域内每一所中小学的教师和学生都可以便捷地访问本地资源、中心资源和其他学校资源。
为有效地进行资源的建设，扬州市电教馆特地进行了“数字化校园应用”的自评调查(http://wwww.yzjy.com.cn/final/szhxy/default.asp)。该调查分為基础环境建设、教学应用水平、管理应用水平、保障工作措施等四个方面。通过分析该调查表及到各学校实地考察的结果，扬州市电教馆在深刻地了解各学校的数字化校园的现状及对资源需求的基础上，最终确定资源建设分为如下几种形式。
（1）整编现有资源，建立初期资源库
多年来，电教馆及各学校积累了大量的专题片、资料片、电子化教学素材、课堂教学实录等资源。按照新课改对资料的要求，我们一方面组织骨干教师审核，另一方面统计素材访问率和图像清晰度等项目。根据数字化校园信息的交换标准和目录分类重新审核入库，作为初期入库资料。在此基础上，电教馆专门组织录制各学科优秀教师每节课的教学，有效地形成了富有扬州特色的“同步课程”视频教学资源。
（2）精选厂商资源，加大资源建设力度
电子化教学素材使用寿命与课程改革息息相关。为了使购买的资源有效、贴切地服务于教育教学，电教馆组织专家在考虑素材是否适用新课改的要求和素材能否简单、有效地被引入到现有的数字化校园平台内的基础上，精选部分厂商的资源，最终购买了部分有价值的资料，作为对现有资源的补充。
（3）学科分工建设，加大资源建设深度
通过对“数字化校园应用”调查的分析发现，目前资源建设处于一个低水平、高重复性的建设阶段，极易产生“薄层问题”及“断层现象”。因此，综合考虑整个区域内各地区、各学校的学科教学成效强弱程度、数字化教学媒体使用频率、现有资源价值程度等诸多方面，最终每学科、每年都能确定3所学科资源建设的重点学校。这样，在一年的时间内，每门学科就可以保质、保量地形成3～4个富有特色的数字化教学素材，将这些素材作为初期教学素材入库，给区域内各教师参考使用。当然，同期各学科还会有诸多数字化教学素材，这些素材经过学科审核员的审核后亦可加入资源库。同一课题形成的资源多达百个之多，一段时间后，按照资源的访问率及质量，清理部分已经不能有效完成课堂教学任务的资源。长期如此，学科资源的建设必将上升一个层次。
4.力求发动全员，各有侧重，依托扬州教育资源网，最终建立包含学校——地区——县市多级协作资源共享体系，服务于教育教学
区域性数字化校园的建设是一个全员性整体推进的工程。为了确保工作顺利、高效地完成，扬州市政府专门在2006年召开会议，向县（市、区）政府及其教育行政部门做出了统一部署，要求全市所有中小学全面开展数字化校园工作。强调数字化校园建设的关键不仅仅在于数字化资源的共享，更着眼于思想的共享，要求各部门能抛开门户之见，统一到学校—地区—县市多级协作资源共享体系中来。创建过程中依据“从理念到任务、从任务到流程、从流程到行为、从行为到习惯、从习惯到常态、从常态到常新”的指导思想，将扬州市教育城域网按不同权限向社会开放，使教师、学生和家长在任何地点，都可以通过互联网访问信息中心资源，从而访问各校资源，最终实现教育资源、环境条件和管理的共享。市及县资源为主要依据，各校在现有平台上增加资源，采取权限限制的方法，使部分资源在区域内共享，使各用户可以访问。对于学校内不便于共享的资源仍处于私密的位置，但总资源的建设则根据区域内专家的评定按学科、分学校建设。要求全员参与，使数字化校园建设渗透到教师的教学方式、学校的管理方式、学生的学习方式中来，有力地服务于教育教学。
2007年，“全国中小学数字化校园建设与应用研讨会”在扬州胜利召开。扬州区域性数字化校园的建设得到了中央电教馆专家的一致肯定。通过两年数字化校园的创建，全市102所中小学建成了数字化校园，形成多达5720个成果，有机地实现了各管理系统之间、学校之间、教育行政部门之间的信息交流，實现了数字化管理。通过数字化校园的创建，教师逐渐步入基于数字化校园平台的教学活动。所有资源均可从该平台获得，有效地避免了资源的“薄层问题”及“断层现象”。数字化的教学模式、教学手段有力提升了教学质量。基于数字化校园的选修课程、研究性学习等越来越丰富，学生可选择其他学校的选修课程，极大地拓展了学生主动与互动学习的空间。家长通过互联网接入到数字化校园平台可以自由查看学生的课堂表现、成绩等在校表现，为家校的互动交流提供了无限可能。
参考文献
[1]http://yzdj.yzjy.com.cn/Article.asp?articleid=376.
异构应用系统用户整合思路探析 篇4
1 需求界定
一般情况下, 异构应用系统使用的数据库类型、用户属性表及业务信息等不同。通过整合用户, 构建总用户中心, 实现各异构系统间用户资源共享。具体需求为: (1) 整合各异构应用系统已注册用户; (2) 新用户能注册; (3) 新老用户能维护个人信息; (4) 用户在总用户中心或某一异构应用系统登录后, 浏览其他被整合的异构应用系统时不需要再次登录, 即所谓的单点登录。最后一个需求是用户整合的目的, 实现方法有多种, 本文不作研究。
2 总体设计
分析界定的用户需求, 异构应用系统用户整合大致要完成两项工作, 一是设计用户系统架构, 构建总用户中心, 对接异构应用系统用户模块, 实现用户资源共建共享;二是将异构应用系统的用户数据迁移到总用户中心。
2.1 用户系统架构设计
用户系统架构设计主要是规划总用户中心与各异构应用系统之间的关系, 降低设计难度和复杂度, 确保全系统用户的唯一性, 可按如图1所示设计, 呈星型关系, 各异构应用系统与总用户中心共享用户资源, 各异构应用系统之间通过总用户中心实现用户资源共享。用户数据传输可依靠数据总线实现, 传输格式可以约定为XML、JSON等。
为了确保异构应用系统的业务独立性, 根据松耦合设计原则, 总用户中心仅管理维护用户基础信息 (如用户账号、口令、手机号、邮箱、姓名、性别以及民族等) 和提供单点登录服务, 各异构应用系统维持原有用户管理运行模式不变, 总用户中心负责产生用户ID (确保唯一性, 也可以为用户唯一识别码, 如居民身份证号、手机号) , 并保存到异构应用系统, 通过用户ID实现总用户中心用户与各异构应用系统用户之间数据同步。
2.2 总用户中心设计
总用户中心主要完成用户注册、单点登录验证、用户信息修改、与各异构应用系统用户信息同步、用户登录日志记录以及多种信息的统计与分析等功能。设计要点如下: (1) 新用户只能通过总用户中心注册; (2) 用户注册后, 第一次到某异构应用系统进行需要用户身份认证的业务操作时, 会自动询问是否开通会员服务, 总用户中心将根据异构应用系统请求推送相应数据; (3) 用户只能在总用户中心修改个人基础信息, 总用户中心将根据各异构应用系统要求推送修改信息, 确保用户基础信息一致; (4) 用户的业务信息 (如稿件系统中存储用户的投稿、发稿以及稿件质量和用稿通知单等信息, 购物系统存储订单、购物评价等信息) 存储在对应异构应用系统中, 但可以从总用户中心调取查看或修改。
考虑到兼容性、跨平台性和安全稳定性, 总用户中心可以基于Java技术构建, 数据库可以采用My SQL, 采用标准中间件实现用户数据共建共享。
3 详细设计
3.1 用户注册
简要用户注册流程如图2所示。考虑到实名制注册要求, 一般用户注册有两种方式, 第一种是居民身份证验证, 可将用户输入的用户姓名和居民身份证号发送到第三方验证机构验证, 如公安户籍管理机构;第二种是手机号验证, 可使用手机短信向用户发送验证码方式确认用户身份。
3.2 开通异构应用系统会员
用户如需开通某异构应用系统的会员, 即具备访问需要身份验证信息的权限, 可按照图3所示流程进行操作。
3.3 用户信息修改
用户信息包括总用户中心的基础信息和异构应用系统的业务信息, 考虑到异构应用系统可能会保存用户部分基础信息, 因此, 用户在总用户中心修改个人基础信息后, 要确保用户基础信息与异构应用系统信息一致, 一般有两种方式:一种是总用户中心可自动更新异构应用系统存储的基础信息;另一种是采取由异构应用系统请求同步方式进行, 一般都支持这两种方式。异构应用系统负责修改对应的业务信息。
3.4 数据迁移
数据迁移是指各异构应用系统的原有用户数据同步到总用户中心, 属于系统部署阶段的工作, 考虑到各异构应用系统用户数据的差异性和用户信息的独立性, 可以编写单独程序, 按照图4所示流程迁移用户数据。
4 结语
异构应用系统的用户整合是信息化建设的一个重要内容, 本文还有许多问题未作深入探讨, 如总用户中心与各异构应用系统之间的数据传输协议与安全保密, 总用户中心运行的可靠性、高效性设计以及各系统间相互信任机制建设, 这些问题都值得进一步研究。
参考文献
[1]王德安, 张松伟, 刘雁南.基于j Query+ASP.NET技术的单点登录模型设计与实现[J].电脑编程技巧与维护, 2014 (11) .
快速整合应用深化数据分析 篇5
济南供电公司是山东电力集团公司所属的全国一流供电企业，资产总额40亿元，担负着济南市10个区、县（市）的供电任务。电网覆盖面积约1万平方公里，拥有直供35千伏以上变电站55座，主变总容量683万千伏安，输电线路2065公里。
随着信息技术飞速发展，济南供电公司信息化建设方面也取得了显著的进步和成就。但其当前的系统也存在着部门自成体系的现象。跨部门应用系统设计成了部门内部系统，完整的信息体系被隔离成一个个独立的“烟囱”，资源共建共享模式没有达成共识，自建自用和自成体系的信息化建设模式明显，潜在的“信息孤岛”风险突出，部门协同能力受到极大牵制，无法对电力行业的高层领导进行宏观决策提供可靠的基础支持。这些严重制约着领导层的决策分析能力和电力行业的信息化建设。
不同系统之间的整合与集成是一项复杂度很高的工作。济南供电公司在吸取国外经验的同时，结合自身特点，采取“摸着石头过河”、“小步快跑”、“低风险”的方式逐步实现了各个系统之间、各个部门之间的信息共享与集成，即多点对多点的信息集成。其在实施过程中，需要首先实现多点对一点的信息集成，即各个系统对公司领导层的信息集成，亦即辅助决策系统。为此，由济南供电公司信息中心牵头，以中创软件商用中间件有限公司作为中间件平台提供商，于2005年9月正式开工建设了辅助决策系统。
系统概述
1.系统目标
辅助决策支持系统可对分布在不同业务系统的当前及历史数据进行统计分析，并将其统一展示。系统在展示时以指标体系（包括电量、线损、电费等关键指标，输、配、变电设备装备水平和人力资源）为中心，支持深度分析和挖掘(包括历史趋势分析、增长率分析、极值分析、平均值分析等分析功能，以及柱状图、折线图、雷达图等图形展示功能)，可为各级管理人员决策提供强有力的支持。
2.系统业务功能
辅助决策支持系统为用户提供如下的业务功能：
基本业务指标
用户通过决策支持系统可以查看供电企业的电量、电费、线损、装备及人力资源等指标的基本信息。一方面，用户以表、图、摘要相结合的形式在决策支持系统中查看各指标对应的统计数据或明细数据，了解各个指标的运营状况；另一方面，由于采用了数据中心，用户也可以方便地在决策支持系统中获取不同业务系统中的数据，将它们关联展示，从而形成单个业务系统难以处理的指标综合信息。
数据分析挖掘
在展示基本业务指标的基础上，决策支持系统还提供数据的分析与挖掘功能。用户可以利用系统提供的80/20、TOPN、历史趋势等十多种分析，从不同维度对业务指标的基本信息进行更深入的分析和挖掘，找出其中对企业发展最至关重要的那部分数据。例如占总电费收入80%的那部分关键客户，损耗异常的那部分线路等等。通过这些分析工具的支持，用户可以更方便快捷地确认企业运营过程中的关键信息，及时采取相应措施，从而提升管理效率，增强盈利能力。
系统维护
为了保证辅助决策系统的稳定可靠运行，辅助决策系统还为管理人员提供了强大的维护功能。管理人员可以方便地调整使用人员的权限，控制允许访问的IP，从而避免关键业务数据外泄。另外，管理人员还可以通过系统维护功能随时调整数据抽取模块，保证决策数据的实时性。
3.系统技术框架
该方案采用业界标准的基于J2EE的三层B/S体系结构。系统主要由数据交换平台、分析构件和展示构件组成，如图所示。
其中：
数据交换构件：可完成辅助决策数据库和其他系统数据库间的数据共享与同步。
分析构件：可完成系统对发展模块、现状模块和通用模块的分析。
展示构件：可完成系统对电量、线损、电费等基本指标的有效展现。
核心技术
辅助决策系统的整合需求比较复杂，必须有强大的中间件产品进行支持。在辅助决策系统方案中，济南供电公司选用了中创软件商用中间件公司的应用集成中间件InforEAI、企业应用服务器InforWeb和报表工具InforReport。
1.InforEAI
辅助决策系统的数据来源于多个业务系统产生及积累的数据。这些数据存储在不同类型、不同版本、不同地点的数据库中，涉及上百个数据库表。业务系统的数据量很大，有几百万甚至上千万条记录，同时系统在运行中每天还会新增数万条记录。为提高系统的内聚性，降低耦合性，需要把辅助决策所需的分布在不同系统中的数据抽取到中心数据库集中存放分析。对于部分关键数据，还需要有即时反应的能力，一旦在业务数据库中发生了变更，必须立即在辅助决策数据库中反映出来。
对于上述需求，如全部采用传统方式手工开发，工作量大，技术复杂，后期维护也很困难。为了解决上述问题，整个辅助决策系统以应用集成中间件InforEAI为核心，构建跨地市和覆盖全省的信息整合平台，高效地抽取数据。在屏蔽了不同数据源的差异的同时，提供了实时/定时抽取模式，轻松地解决了数据变化即时更新的问题，其采用的触发器机制也避免了采用轮询机制带来的资源消耗。在开发过程中，使用者只需通过所见即所得的GUI界面进行简单配置即可实现数据抽取功能，不需任何编程工作，使得普通用户也可以自行抽取所需的数据。与手工方式相比，使用InforEAI使开发效率提高5-10倍，而且大大降低了后期维护的难度。
2.InforWeb
应用平台中间件InforWeb集合了业务流程管理、单点登录、Web服务器、EJB服务器，以及中西式报表和数据分析服务，能非常友好地支持业界标准的基于J2EE的多层B/S体系架构的开发，能快速地将现有应用系统无缝集成到统一的企业门户中，保证系统的可靠、高效和安全的运行。
3.InforReport
快速构建展示应用平台，对供电企业的电量、电费、电压合格率、供电可靠性、线损等关键指标，以及输、配、变电设备装备水平和人力资源的数据，进行发展、现状和通用等多个视角分析，以报表、柱状图、折线图、饼图、区域图、金字塔图、仪表盘图等多种手段进行展示，并能对全公司、分部门、分变电站、分电压等级、分时间段、分线路的供电量和售电量数据进行有效展现。
在中创软件Infor系列中间件的强力支撑下，济南供电公司辅助决策系统于2005年11月投入试运行，12月投入正式运行。系统实施过程中，理清了各个关键系统的关系及其数据结构，发现了未来系统整合中可能存在的问题。系统上线运行后实现了预期的多点对一点的信息整合，同时也为实现多点对多点的信息整合，构建统一、完整、有机的信息平台奠定了基础。
系统上线运行后，为领导的决策和调控提供了有力支持，取得了良好的社会效益与经济效益。为此，该系统荣获了电力系统省科技进步一等奖。
应用系统整合 篇6
关键词：电力 物资调配 系统整合
1 调配中心建设背景
2012年5月，北京电力物资调配中心开始建立。物资调配中心立足于北京公司物资集约化管理实际，合理构建仓储配送体系，提高物资供应服务的效率与效益。调配中心建设过程中未开发新系统，而是集成了北京公司现有各类系统如基建管控系统、生产PMS系统、ECP、ERP、抢修GIS定位、电力应急指挥系统、仓库可视化等。这样不仅降低了建设成本，更使调配中心能够以最快速度投入运行。
2 调配中心运行现状
物资调配中心依靠现有各类系统，按照“月计划、周协调、日调度”工作机制，在2013年上半年完成1-6月份六个批次的物资供应计划编制工作，供应计划共计2630条，涉及金额约12亿元；按月分别组织与建设单位、与供应商的物资到货协调会，共12个批次；按周组织业务协调会，共组织20批次；另外，组织25次重点工程、特殊需求专题协调会；接收并完成协议库存11批次，涉及供应商60家，建设单位20余家，工程项目300余项，200余种物资，供应计划1000条。
另外，调配中心针对重点工程进行了重点调配。主要完成了望京220千伏扩建、桃园220千伏工程、白云桥、万明路110千伏等10项基建度夏工程、29项生技配网度夏工程，以及新增53项2013年度夏扩展性工程物资供应工作；完成西北热电中心220千伏送出工程（温泉）、（聂各庄、栗园）中的钢管塔的催交及供应工作；组织新一代智能变电站未来城、海鶄落工程对重点设备中标厂商的现场实地考察、设计联络会等工作。
3 目前信息系统主要问题
3.1 各系统协作性能有待改善 随着信息技术的飞速发展和北京公司管理工作信息化的需要，北京公司陆续开发和建设了众多信息系统，这些信息系统都具备各自的功能，但是信息资源未共享，系统间协作性能差，从而形成了“信息孤岛”。
3.2 调配中心系统支撑亟需提高 北京电力物资调配中心具备五大管控功能，即统一业务受理、合同履约协调、物资配送调度、监控预警、应急响应。然而在实际工作中，监控预警功能多为人为跟踪，缺少信息系统的支撑与保障。调配中心工作人员不仅需监控物资供应链各节点，对于可能影响工程进度、晚交货等情况及时发布预警信息，监督风险消除。依靠信息系统实现监控预警、辅助决策等功能，在调配中心目前仍未实现。
4 问题成因分析
4.1 改善系统间协作性能 北京公司为了提升管理水平，建设了大量信息系统，具备查询基建工程进度及订货情况的基建管控系统，记录了所有在网设备运行状况信息的生产PMS系统，国网公司统一部署已成为电力公司与供应商信息交货平台的ECP，综合了公司各类管理及信息的ERP系统，定位抢修车辆位置GIS定位，满足应急情况下视频指挥的电力应急指挥系统，查看库区内视频画面的仓库可视化，这些系统相对独立，建设时未考虑系统协作的需求，开发语言、数据编码规范都存在差异，很难完成信息交互。不仅如此，为了满足数据交互建立的大量接口，反而降低了系统的工作效率，极大地提高了交互中产生不易纠察的错误数据的几率。
4.2 提高调配中心系统支撑 调配中心综合接入各信息系统，为各类系统数据查询提供了便利。然而在进行决策时往往需要查询多个系统，无法通过单一系统查询进行决策。比如想知道工程现场安装一台设备能否按期安装完成，则需要查询该工程的前期手续情况、施工招标情况、查看现场土建进度，另外查询设备订货时间，根据订货时间、合同签订情况、图纸确定情况、生产周期等信息综合计算具备交付条件日期，另外根据交通、天气等信息推断到场时间，最终才能得到预估的结果。各信息系统数据间相互联系不够紧密，不仅为查询带来了不便，对进行决策也提出了更高的要求。
5 如何整合信息系统
5.1 信息系统整合方案分析 一般来说，进行信息系统整合的主要方式有三种，完全重新建设、中间件整合、按需开发。在系统整合的过程中，还要注意根据调配中心的实际情况进行调整。
5.2 信息系统整合方案选择 北京公司目前已经有很多正在运行的信息系统，这些系统涵盖公司各类需求、业务，满足公司日常管理的需求。北京电力物资调配中心选取了其中部分系统接入，并进行应用，除ECP、ERP以外，多数系统仅为查询数据，所以调配中心的系统整合不需要推倒重来，可以选择适当的中间件，并按需进行部分开发即可。
5.3 整合前准备工作 要想进行调配中心现行的多个信息系统，要做好以下三方面的前提准备工作。首先，要做好信息化总体规划与管理体系保障。要了解国网公司、北京公司的信息化建设发展规划，避免重复开发，确保各信息系统间更容易数据共享。其次，选择统一的数据存储方式和编码标准。最后，要做好需求分析。在系统整合之前要做好需求分析。深入且透彻的需求分析可以使系统能够良好运行。
5.4 如何进行系统整合 要将北京物资调配中心多个信息系统整合，要从数据层面集成、应用层面集成、辅助决策提升三方面完成。
5.4.1 数据层面集成 基建管控系统、生产PMS系统、ECP、ERP都有各自的数据库，共享或者合并来自于多个系统的数据，通过数据共享、数据转化、数据迁移、数据复制等方式，将各系统数据有机集合。
5.4.2 应用系统集成 ①形式上借鉴ESB。在形式上，我们可以借鉴ESB（企业服务总线）进行串联。在物资调配中心将调配中心的各项业务流程串联成一条数据线，而每项业务则是由不同的信息系统提供服务。通过ESB将所有业务串联在一起，也将信息系统服务串联在一起。②数据上依靠ERP。ERP是目前公司应用最为广泛，数据存储最为完整的信息系统。北京公司拥有完备ERP运维团队，不仅可以维护现有ERP系统，更可以根据公司业务需求进行二次开发。除此以为，ERP已经与多个系统间开发了标准数据接口。众所周知，ECP是国网公司部署的系统，是不允许与一般信息系统进行接口交互的，而ERP已经与ECP有了接口，其他系统或者开发新系统则不具备可操作性。因此，ERP可以与基建管控系统、生产PMS系统等系统建立接口，其他系统为ERP提供服务，从而满足调配中心的各项业务需求。
5.4.3 辅助决策提升 调配中心一项重要的管控功能是监控预警。当应峰度夏即将来临，应该储备何种物资？数量如何？当出现突发状况需要紧急调用物资时，从哪里调配？这些决策不应该“拍脑袋”决定，而是应该根据历史数据等进行综合分析得出。如果让工作人员通过系统综合查询后得出结论，则会错过黄金时间。随着ERP BW模块的深入开发与应用，辅助决策具备一定基础，所以整合后系统的辅助决策能力成为备受关注的亮点。
6 信息系统整合应用
物资调配中心多系统整合后将实现物资供应链全过程管控、统筹规划，真正成为统一的物资调配平台。满足一般物资合同履约协调、重点物资合同履约协调、监控预警、应急响应等业务流程需求，可以通过统一的系统完成各类工作。
7 建议与结论
综上所述，北京电力物资调配中心的多系统整合与应用是可行且备受期待的。整合后的系统不仅较好的解决了“信息孤岛”问题，将已经建立的基建管控系统、生产PMS系统、ECP、ERP、抢修GIS定位、电力应急指挥系统、仓库可视化有机地结合起来，而且有效地提升调配中心监控预警能力。可以认为，系统整合与应用是有效提升调配中心物资调配能力的有效途径。
参考文献：
[1]于宝琴等.企业物流信息系统整合与应用[M].北京.中国物资出版社，2007.
[2]甄镭.信息系统升级与整合[M]北京.电子工业出版社，2004.
[3]毛新生等.SOA原理·方法·实践[M]北京.电子工业出版社，2007.
通过系统整合达到最优 篇7
以系统的观念整合物流行业现有的资源或者成果,通过系统整合实现物流业整体最优
不久前,国家发改委、工信部等多个部门联合发布《关于加强物流短板建设促进有效投资和居民消费的若干意见》(以下简称《意见》),旨在解决“我国物流业发展水平总体还不高,发展方式比较粗放……已成为影响经济运行效率和居民消费升级的突出短板”的问题。该《意见》就是要通过物流短板领域建设,来提升物流业整体发展和服务水平。这是以系统的观念整合物流行业现有的资源或者成果,通过系统整合实现物流业整体最优。
在当前物流市场所处的阶段中,物流业需要更大程度的商业集中,企业必须能够顺应工业革新过程,必须面对更加开放、宽广的市场。物流系统整合就是物流系统为提供高效优质的综合服务,在同外部环境协调一致的基础上,内部各要素之间、各服务功能之间以及不同层次组织之间在实体上和软环境上进行的联系、协调乃至重组。物流整合服务能在普遍降低物流系统运作成本的同时,提供高效、优质的综合服务来满足各种灵活多变的物流需求。从逻辑上讲,物流系统整合服务将会创造更具规模的大型企业。在这一新兴综合服务领域,包括快递、对方付费货运、公路运输公司、国有铁路、私有铁路、邮政公司、海上运输公司、航空运输公司等货物运输经营者,这个综合系统为所有这些经营者提供无限发展的空间。物流企业间的整合是从行业发展的角度和提高自身生存发展能力的角度,进行的企业间的合作。通过整合,物流企业就拥有了更完善的功能、齐全的网络、规范的管理和高质量的服务。
论实时系统和办公系统的整合 篇8
在公司正式运作后, 公司自主开发了OA系统, 用于实现无纸化办公。领导发现办公信息只能在办公室处理、生产信息要去调度室处理、查看装车数据要去地衡室。如果要在公司任何地点都可以实时查看所有数据, 就要同步信号和数据, 将这些系统进行整合。
这些系统只有OA系统是公司自行开发的, 其它系统都是外购的, 二次开发成本都很高。为了节省成本, 避免长期依赖外部采购, 培养自己的管理人才, 公司决定自己进行系统的整合。第一步先整合雷达信号进入DCS系统, 采集上传的罗斯蒙特的液位状态生成实时的罐量示意图。第二步由DCS系统开发B/S结构的发布系统, 提供支持TCP/IP的网络输出, 上传DCS系统的整合信号给OA系统。第三步将地衡系统的后台数据库系统由ACCESS升级为SQL数据库。第四步在OA系统中建立调用DCS系统的上传信号和输出界面, 设计关键用户 (各级领导、生产和计量主管、调度) 需要的查询界面调用DCS系统信号和地衡的SQL数据库, 根据生产流程设计公司整体的运转流程数据查询、统计和分析图表。
第一步, 罗斯蒙特的专用软件将雷达信号显示为数字信号, 需要专门的RS485转RS232转换器将数据传入PC上位机, 动态的显示在罗斯蒙特的专用软件上, 如果不进行改造, 只能单机使用。我们使用Visual C++设计了一个RS232端口分析软件, 监测RS232的数据, 将信号进行分析, 并实时的显示分析软件中, 将分析的结果和罗斯蒙特软件显示的数据进行对比, 经过一个月的时间, 成功的完成了信号转移的准备。然后在力控DCS系统中建立罐量显示图, 将RS232的信号转移到力控的工控机上, 单机版的罐量示意图显示成功。实现了罗斯蒙特雷达信号和力控系统的初步融合。
第二步, 我们查阅力控的B/S架构发布参考, 在工控机上建立B/S结构的发布系统, 在工程中调用雷达信号、管线压力、阀门状态, 发布整体DCS系统的信息。通过路由器连接实时和办公系统的网段, 设置防火墙只能以特定的端口向办公网段提供信息, 不能写进信息, 以保证实时系统的安全性。OA系统中直接调用路由器转发的信息, 至此大部分实时系统的信息都可以在OA系统中监测了。
第三步, 升级装车系统的数据库。装车系统实时信息的采集通过托利多的LINUX内嵌系统将地衡数据通过RS232的方式传入PC机, 微分装车系统采集RS232的数据, 将过磅数据, 装车数据, 车辆信息都存入后台的ACCESS数据库中, 数据库的连接采用Windows的ODBC方式连接设定好的系统DSN。由于该系统使用的是Delphi编译后的系统, 我们联系开发商更新了数据引擎文件, 可以连接到MS SQL SERVER, 然后修改了系统DSN。将数据库服务器安装在机房, 安装双网卡, 对办公网段仍然只提供读取服务, 避免办公网段影响工控网段的运作。至此地衡系统的数控库升级完成, 原先地衡系统都是独立运行, 如果管理不当、维护不及时会出现数据不同步。升级网络数据库后, 原有的单机版的系统同时也升级成了网络版的系统, 所有的地衡数据库在一个数据库系统中, 维护管理工作减少了75%, 解决了数据不同步的问题。
第四步, 我们使用NET环境开发的OA系统, 使用C#语言, 数据库同样是MS SQL SERVER, 这样整体系统的整合就方便了。为了整合实时系统和OA系统, 我们增加了生产系统模块, 在该模块中实现了公司生产系统流程管理、工艺管理、数据查询、统计分析、报表出图等功能。实现过程中参考了中石油SAP油品流程设计系统, 从中借鉴和我们实际生产相同或近似的环节, 整合分析, 总结出我们自己的管控流程的方法, 设计了入库12步系统、出库16步系统、对油品的检查、化验、扫线、倒灌、加热、控制用电、配额输送、入库车辆管理等, 都纳入了我们的流程设计中。开发测试将近两年的时间, 最后终于实现了预期效果。整体系统交付运作一年以来我们不断的进行网络和数据库的优化, 不断的提高网络运作的可靠性, 系统的问题逐渐的减少。
经过这次实时系统和办公系统的整合, 在低成本的运作下, 公司的网络信息化上了一个层次, 信息部的技术水平和知识积累大幅上升, 公司的管理水平有了质的飞跃。整合费用大都投资在人员培训和学习上, 公司的凝聚力极大的提高。公司的业绩年年创新高, 我们的薪资也不断提高, 在不久的将来我们还要将知识变成力量, 让知识发挥更大的作用, 让知识学习创新带给我们更好的明天!
参考文献
[1]周韧研, 商斌, Visual C++串口通信开发入门与编程实践[M]北京:电子工业出版社, 2009.
[2]Kevin E.Kline, Daniel Kline, Brand Hunt, 李红军, SQL技术手册[M].北京:电子工业出版社, 2009年11月.
[3]黄永红, 电气控制与PLC应用技术[M].北京:机械工业出版社, 2011年9月.
[4]柳纯录, 信息系统项目管理师教程 (第2版) [M].北京:清华大学, 2008年1月1日.
Mashup整合技术的应用 篇9
1 Mashup整合技术
在这个领域不断增加的应用首先源于同样大量增加的基于网络的数据服务。这样通过一些应用程序接口(APIs(Application Programming Interface)),常见的比如Google或者Yahoo!或者淘宝、Amazon的接口,直接访问那些数据源的数据或者他们的数据服务,这可以是一个搜索,一次检索或者一次可视化的地图服务。另一个重要的原因,是AJAX(Asynchronous JavaScript and XML是实现了异步传输和展现信息的网络应用程序模型)的大范围的被采纳和应用。在AJAX模型中,往往只有很小的数据量在服务器和浏览器之间进行动态的后台交换,使得这类的web2.0的应用大幅改善了诸如响应时间等性能指标,用户对性能的体验,接近于本地安装的客户端程序。
2 Mashup的分类
基于Mashups的定义隐含了各种应用不同的实现形式,我们可以对这些应用进行相应的分类,比较常见的分类方法有按应用类型分类,按使用的技术分类和按应用的开放程度分类等等。以按应用类型分类为例,根据Novak和Voigt以及Merill的分类方法,有地图Mashups,图片及视频Mashups,搜索和网购Mashups,新闻Mashups。
2.1 地图Mashups
地图Mashups实际是基于地图的Mashups应用,他们集成包含有任意地点信息的数据到地图服务商提供的可在线使用的数据载体,常见的数据载体比方说地图。因为面向终端用户的地图服务商提供了相当简便的接口,使得这样的Mashups能很快的建立起来。Google,百度,Yahoo!或者微软都提供简易而强大的接口,使得实现一个互动的,由用户定制的地图易如反掌。比如说饭店的主人可以相当方便的把自己网页上原本的文本形式的地址,通过地图服务令之可视化,从而增加互动,提升用户体验。
2.2 图片及视频Mashups
图片及视频Mashups整合来自图片服务商和视频服务商的数据,比如来自Flickr的图片以及优酷的视频。最简便的实现方法是借助Metadata(元数据,描述数据的数据)来进行整合,因为绝大部分的图片或者视频都是加注了描述性的元数据,一些复杂的整合不仅会考虑关键词的匹配,还会考虑比如对说明文字textmining的结果,再比如资源节点在整个资源谱系中的位置,以期在某些特定的场合,获得更好的整合效果。通过这个类型的整合,可以比方为最新的新闻自动配上与之相应的图片和视频资源。
2.3 搜索和网购Mashups
搜索和网购方面的应用,出现于Mashup和web2.0概念被引入计算机学科之前,以Google Product Search(原名Google Froogle,2007年4月后更名)为代表相应服务应用,运用B2B或页面抓取技术,获取对货品的可比较信息。目前许多有国际影响的大型购物站点像Amazon,Ebay或者淘宝都提供接口访问它们的货品信息,所以构建这类整合应用也是非常简便的。
2.4 新闻Mashups
在新闻信息整合方面,从重要新闻媒体得到的新闻被植入博客,论坛等类似的载体。一些应用可以同时对多个数据源进行搜索,终端用户可以对文章进行评分,这可以直接影响文章在应用界面中的排名。与终端用户加强互动,提高用户在应用中的参与度正是web2.0应用的终极目标。
3 结束语
一个成功的应用,可以是各种类型的结合,也可以是一个独立的实现,由这个过程产生的新资源,同样可以作为一个资源单位,成为其他整合应用的一部分。
最近几年以来Mashups展现了一个在应用层相当活跃,新颖并且高度动态化的新领域,也因此得到了长足的发展。它曾经长期的被认为是微不足道的技术,以至于运用它来进行动态的数据或者应用整合的潜在能力也被低估。但是随着近年来应用的不断客户化,在特定的环境中,运用Mashups能带来更好的客户体验,减少用户一些重复的劳动,更加灵活。尽管这样,Mashups在复杂的数据整合过程中,常常遇到不同数据源数据结构不同等具体的问题,影响数据的进一步处理,所以对复杂度较高的整合流程,一个数据结构层面的整合势在必行,这超出了本文介绍的范围,感兴趣的读者可以查看相关的资料。
摘要：由于大量增加的基于网络的数据服务和AJAX的大范围的被采纳和应用,Mashup在整合技术这一领域不断扩大应用,即能够整合或者组合不同数据源的数据或者服务,并且通过这个过程创造新的价值的网络应用。基于Mashups的各种应用不同的实现形式,以按应用类型分类为例,可分为地图Mashups,图片及视频Mashups,搜索和网购Mashups,新闻Mashups。最近几年Mashups展现了一个相当活跃、新颖并且高度动态化的新领域,也因此得到了长足的发展。
关键词：整合,数据服务,应用,动态化,发展
参考文献
[1]Merrill,D.:Mashups:The new breed of Web app.2006.http://www.ibm.com/developerworks/library/x-mashups.html.
[2]hingran,A.:Enterprise information mashups:integrating information,simply.2006.
电力工程信息管理系统的整合应用 篇10
1 工程进度信息管理现况
随着我国信息化技术的更新, 电力工程信息化建设逐渐拓宽其发展空间, 近年来不断涌现出形式呈现多元化的工程项目管理信息化产品。因我国电力工程建设具有面广与专业性强的特点, 目前能够促使工程建设管理实现系统化作业的应用系统较少, 电力企业绝大多数工程项目根据各业务性质不同采用具有差异的信息系统产品, 同时为监督工程项目建设全过程构建信息平台而建立不同信息系统间接口。然而, 该信息平台虽收集与业务相关的大量资源, 但应用时却发现该信息平台开发缺乏深度、应用缺乏深度、管理思想落后, 难以整合各业务的相关信息, 因此, 管理者难以凭借该信息平台为电力工程建设提供预测。
进度作为电力工程项目的主线, 其管理属于工程项目管理中的重要内容, 管理者为工程进度构建切实可行的基本框架, 根据各类业务予以配置与之相对应的资源成为顺利实施工程建设的保障。目前, 我国电力工程信息管理系统的整合应用旨在提高工程项目的建设进度, 通常以进度作为工程信息管理系统的核心脉络, 将电力工程各业务信息与工程进度间的关联构建为框架, 形成一个系统化的信息管理平台, 从而提高项目经理工程管理的效率, 同时为决策者预测与评估提供科学、合理的依据。进度的提高往往受制于技术因素、机器设备因素、环境因素、社会因素及人为因素, 既包括主观因素也包括客观因素。因此, 在诸多因素影响之下, 应如何将工程建设过程中各业务的相关信息进行合理整合, 评估实践进度与实际进度成为信息管理者迫切解决的问题。
2 整合应用的深入研究
2.1 进度管理与资源管理的同向
资源管理实质是为工程建设配置人力、物力, 如机器设备购置、原材料采购及各岗位负责人。实现电力工程资源系统化管控需根据工程预计建设进度制定计划, 而制定计划需以进度与相关资源配置间的内外在关联为依据, 简称为联结。
进度管理与资源管理的同向主要概括为:1) 进度管理中各业务开展时间与预计完成时间均借助信息管理系统的接口传输入资源管理系统中, 从而确定各业务主要负责人及职责, 同时告知业务负责人该业务开展的具体时间。2) 各业务主要负责人确认自己的任务后, 将业务开展的具体时间输入进度管理系统中, 构建各业务初始时间数据库, 便于信息管理者审查。3) 信息管理系统在业务负责人完成业务前提醒其注意计划完成时间, 从而提高业务进度。4) 一旦资源到位, 信息管理系统将会自动登记录入资源到位的确切时间, 并与进度管理系统中的计划时间进行对比, 从而分析是什么原因致使资源到位时间出现延后。
2.2 进度管理与质量管理的同向
电力工程管理的全过程均以质量管理为核心内容, 其主要体现在工程设计、机器设备检修、施工监督、机器设备调试及生产运行前的准备。据研究, 质量管理与进度管理间既存在相互制约又平衡的关联, 实现进度管理与质量管理同向发展需合理融合两者的信息。
进度管理与质量管理的同向主要概括为:1) 确定进度管理中工程项目开展的初始时间与预测完成时间, 后经信息管理接口输入质量管理系统中, 从而为质量工作制定计划带来依据, 如工程项目质量监督计划及任务完成质量验收计划。2) 工程项目实施中, 每一环节的质量信息均应及时输入质量管理系统中以备分析施工过程是否存在问题。3) 工程项目完成后, 质量管理信息需与进度管理同步分析, 判断质量管理信息是否与施工实际情况相对应, 为管理者及时查询质量信息奠定保障。
2.3 进度管理与安全管理的同向
工程项目的实施以安全为前提, 安全生产旨在预防危险, 在进度管理中占据重要地位。目前, 为预防工程项目实施过程存在的危险, 应用科学手段对工程项目建设中存在的人为危险因素、物质危险因素进行系统化辨别, 根据危险因素的性质采取控制危险源的措施, 具有针对性的达到预控目的。
3 结语
以上论述, 当今时代属于信息化日新月异的发展时代, 企业的发展离不开信息化管理的支持, 是推动我国经济社会发展的核心力量。电力企业工程信息管理系统的整合应用有利于管理者掌控生产全过程, 为电力企业实现可持续发展奠定保障。
参考文献
[1]李伟丽.浅析电力工程信息管理系统的整合应用[J].广东城市建设理论研究 (电子版) , 2010.
[2]张明.电力工程进度管理的研究[J].中国科技资讯, 2010.
整合营销在我国的应用 篇11
在日常生活中人们常常受到大量广告的包围，许多企业家都感叹为什么自己投入了大量的广告费，可品牌形象在消费者心中仍是模糊的，一个品牌往往各领风骚没几年，不能长久维持自己的品牌优势。为了解决这一问题，大量的专业市场营销人员积极地学习并运用整合营销传播理论这一全新的更贴近市场的经营观念，使得整合营销从一开始进入我国，便成为了本土专家学者以及老总们争相学习和实践的“法宝”。
整合营销传播(Integated Marketing Communications-IMC)就是企业在经营活动过程中，以由外而内战略观点为基础．为了与利害关系者进行有效的沟通，以营销传播管理者为主体所展开的传播战略。也就是为了对消费者、员工、投资者、竞争对手等直接利害关系者和社区、大众媒体、政府、各种社会团体等间接利害关系者进行密切、有机的传播活动。沟通整合营销也就是一种适合于所有企业中信息传播及内部的管理体制，而这种传播与沟通就是尽可能与其潜在的客户和其他一些公共群体，如雇员、立法者、媒体和金融团体，保持一种良好的、积极的关系。即整合营销既是一种营销手段、理念和营销模式，更是一种沟通手段和管理体制。对外具有整合各种信息综合传播企业信息和品牌的功能．对内则有通过各种沟通渠道和方式实现有效管理的作用
应用系统整合 篇12
1 系统现状
负荷管理中心自实用化验收后，经过近10年的发展，现已建成3套独立运行的负荷管理系统，即宝鸡电力负荷管理系统、GPRS负荷管理系统和GSM用电自动监测管理系统。
宝鸡电力负荷管理系统主要采用无线通信，即最早使用的负荷控制系统。此系统有双机热备份主站1个，建有智能型中继站3座，即蟠龙塬一级中继站，庙王山二级中继站和岐山二级中继站。安装了195台双向终端，分布于宝鸡地区各个区县，主要监测宝鸡地区大电力客户的用电情况和采集宝鸡地区大电力客户的用电数据。此系统实现了限电不拉路、远方抄表、欠费回收、用电分析、负荷预测、电压监测、用电数据共享等多项功能。并完成了主站计算机网络的更换和04版主站软件的升级工作。为了保证系统安全可靠运行，目前采取新、老系统同时运行的方式。
2006年初供电局建成了GPRS负荷管理系统，此系统采用GPRS技术的通信方式，不用建立中继站就能完成各项数据、信息的传输。现有主站1个，终端60台，主要安装于宝鸡地区小水电站和部分大电力客户内，此系统主要以抄表功能为主。
同年底，又建成了GSM用电自动监测管理系统，此系统采用GSM技术的通信方式，现有主站1个，终端19台，主要解决部分偏远特殊电力客户计费点数据的自动远抄。在“抗震救灾保供电”、“奥运保电”、“迎峰渡夏”、优质服务等工作中，负荷管理系统发挥了重要的作用。
2 存在的问题
由于电力负荷管理系统已连续运行了10年时间，系统老化现象比较突出。随着科技的发展，系统需要不断更新、改造。就目前系统运行情况存在以下几方面的问题：
(1)主站、中继站设备老化现象严重。自1997年主站、3个中继站相继建成并投入使用后，4套设备一直未更换。电台、天馈线等零部件的性能严重下降。主站3套系统设备运行分别独立，维护工作量大，数据分析业务效率不高;
(2)无线终端设备严重老化。10余年来，系统主站软件经过了4次升级改造，在功能上不断适应着电力市场发展的需求，而终端设备只在原有设备的基础上进行过1次改造，所以终端性能下降比较严重，通信成功率也较低，尤其是GPRS终端只有70%左右;
(3)备品备件短缺。由于系统设备属于10年前的老设备，所以厂家现在的备品备件比较短缺，对平时班组检修工作影响较大;
(4)安装在趸售局、供电分局的终端设备存在运行管理受限的问题。
3 具体实施方案
3.1 整合资源、提高性能
(1)针对中继站设备超期运行已严重老化的实际情况，对负荷管理系统的3个中继站设备进行了更新改造，将老中继设备完全拆除，取而代之的是安装更新换代后的性能更优的新中继设备;
(2)对主站系统设备进行资源整合。重新整理设备电源线，集中路径;根据新系统运行方式的管理要求，重新更换、配置了前置机，后备机操作台等有关办公用具;通过局办公区内部的局域网搭建网络通道使系统软件前置维护和人员后备值班分离，清晰了设备性能和人员业务流程;依据负控系统主站设备升级合同约定，对新系统设备进行组装，搭建运行网络物理连接;联合厂家技术人员进行软件的运行测试，发现问题及时解决;通过新主站系统对待装的终端设备进行每一项性能的测试，确保新系统设备运行的安全、可靠。
(3)针对老终端通信效果极差的现实，对其进行大规模更新改造已显得刻不容缓。影响终端通信成功率的主要因素是终端电台，由于超期服役，系统绝大多数终端电台收发信号效果下降严重，导致系统通信成功率很低。要解决好终端通信问题，首要问题是解决终端电台问题。将原先的KPORO老式电台，更换为静噪自动调节的TAIT电台;将原先终端的201主板、抄表板更换为201+增强型主板(包含抄表板功能)，提高元件使用寿命。
3.2 加强技术手段措施、提高设备管理水平
针对现场设备运行可用率低的GPRS系统，采取了具体的消缺、改造等措施。
(1)针对GPRS终端设备电源电压稳定性差的情况，更换终端设备烧坏的保险管，客户停电督促其恢复;对于冲击性电压稳定性差的用电负荷重新选择终端电源接入点。
(2)针对现场终端SIM模块损坏、软件通讯参数丢失，对现场丢失参数重新设置，进行系统调试;更换SIM卡或检查移动业务是否正常、异常时督促移动商及时处理。
(3)对于GPRS终端现场运行软件版本低的问题，系统软件维护人员配合设备厂家人员进行系统软件版本的程序修改、升级;现场检修人员和厂家技术人员通过计算机笔记本对现场运行终端软件实地升级。
(4)对终端现场参数设置不全或错误的问题，安装前确定终端内部参数的设置和主站系统通信APN和IP地址参数的一致性;对现场运行终端通信地址无效或设置与主站系统重复、不匹配进行修改。
(5) GPRS网络业务的运行支持受其移动商内部业务效率的制约影响较多。建议加强业务联系，采取投诉、督办等方式。
(6)对于水电站的GSM/GPRS设备客户安装点的运行档案变更，要加强业务协调，提高管理手段。建议通过在营销自动化系统中取得资源共享支持。
(7)对系统检修备件不足的问题，定期与设备厂家人员沟通并对设备进行返修处理，对设备运行中存在的问题及时与厂家工程师交换意见，进行排查。
3.3 细化业务管理、积极进行信息沟通
对于趸售局、供电分局的终端设备管理受限的情况，加强业务、制度管理中存在的不足，及时与趸售局、供电分局进行设备运行信息的沟通，对出现的运行缺陷共同解决。
4 效果分析
(1)原系统中无线系统和GPRS系统设备得到了整合(主通讯前置机)，优化设备间运行环境，设备系统集中管理，运行可靠性得到增强，人员维护工作量得到减轻。
(2)新版本(2004)的软件数据分析功能增强，设备缺陷分析效率提高。
(3)建立双机互备、双信道的工作模式，增强系统运行的可靠性。
(4)消除了人为因素、现场环境、元件故障等方面对设备系统可用率下降的影响。
(5)提高了系统在营销自动化业务流程中的实时数据分析能力;减少了现场人工量、企业成本耗材、作业时间;加强了电费数据计算机抄读的应用水平，降低电费抄表人员的业务工作量;提高了实际的工作效率，在市场开拓工作中发挥了积极的作用。
(6)优化了系统设备间的工作环境，提高了设备的运行使用寿命。
参考文献