0 引言
企业门户的发展依次经历了分散的应用系统、企业信息门户(EIP)、企业知识门户(EKP)三个阶段。美林公司的一份研究报告首次提出信息门户的概念，认为它是企业管理内部和外部信息资源的应用程序，是为用户提供进行商业决策所需的个性化信息的唯一途径。EIP是基于Web的系统，集成企业的所有应用和数据，提供给用户统一的界面。而企业知识门户，更关注企业内部员工和信息内容，它是知识管理系统KM与企业信息门户的结合，其目标是知识生产、知识集成和知识管理。
EKP的主要功能是管理和组织知识资源并寻找之间的联系，提供给用户准确的知识导航和交互环境。此外，宋绍成等认为智能企业门户是融入智能技术，集中在智能门户和决策支持两个方向。然而，无论是企业信息门户还是企业知识门户，其基础架构、实现功能差别不大，都为企业提供了一个单一访问各种信息资源的入口，无缝集成企业内容，为企业信息系统提供稳定、可靠的架构。国外对于智能企业门户的研究在系统设计、开发、实验阶段做了大量工作，包括首次提出智能门户的EOSCENE公司宣称其产品整合各种ERP、CRM、SCM等系统和信息源，给出了其结构模型、元数据模型、平台支持技术等相关阐述。但是，总的来说，智能门户的研究仍然处在研究发展阶段，并没有一个标准的系统论述。实际上，相当多的实施SAP门户项目的企业其主要软件产品可以以服务的方式供应或者交付。此类企业对于门户的智能性有着更迫切的需求，急于寻求一种整合软件服务流程的门户解决方案以降低传统的供应链、人力等方面资源耗费，提高效率，增加收益。基于此，如果采用SaaS(软件及服务)思想改善企业的软件服务供应流程并整合进企业的门户之中，对于智能企业门户的研究与实际应用都有着相当重大的意义。SAP Web Dynpro是一种采用高级的MVC/DataBinding架构模式的Web应用开发工具，允许业务应用程序以独立于后台业务平台以及前端表现层的形式而存在。ABAP是SAP系统的开发语言。本研究将基于SAP平台企业门户框架，结合WebDynpro及ABAP语言的功能，采用SaaS思想改善并整合软件服务流程，实现智能企业门户的开发。
1 需求实例分析
假设H公司主要软件服务是提供对客户SAP系统的性能、安全、数据三方面分析，帮助客户减少生产机数据量提高系统性能，减少系统的升级、备份和恢复所需时间，提高数据访问的安全与高效性，增强数据生命周期的管理，以满足企业对风险控制、访问控制、流程控制三大需求。智能企业门户实施前的软件服务流程是：H公司顾问将该公司软件产品安装在客户SAP系统上并运行数据采集、分析程序，之后卸载软件，将分析后的数据带回公司做成分析报告，再以邮件等方式交付给客户分析评估结果。基于SaaS思想重新设计该服务供应流程，其结果是：分离出数据采集程序通过企业间安全网络连接从客户SAP生产机上抓取所需分析数据，将抓取的数据回传并导入H公司的SAP服务器运行分析程序，分析服务的结果以商务报告、高级报表等形式置于企业门户上交付给客户。据此服务流程可以使客户方在线浏览、下载分析报告，公司业务顾问借助企业门户实施服务和维护。图1显示了此智能门户开发项目架构图。
图1 H公司门户开发架构图
由图1可知，此门户的开发工作分为三部分：前端UI的设计和Web应用、后端与SAP系统交互的Web应用以及用户的权限分配管理与访问控制。SAPEP的框架提供了对SAP系统极好的集成性，在此框架内，容易实现业务顾问单点登录多个SAP系统，用户权限访问管理也可以通过其提供的配置工具快速实现。Web Dynpro根据开发环境的不同分为Web Dynpro Java(WDJ)和Web Dynpro ABAP(WDA)。在此实例中，前端的应用主要是提供对分析出的数据结果在UI展现方式上的支持，H公司对于前端UI的动态性和美观度有着较高的要求，希望客户登录门户之后可以以动态的形式查阅报告。考虑到语言的可扩展性，采用Web Dynpro Java嵌入FLASH技术可以达成公司的需求。门户后端的Web应用主要基于SAP系统，选用Web Dynpro ABAP对应用的稳定性与时间相关性能的表现有着较高的保证。两者的架构以及开发的过程大体相同，图2显示了两者的运行机制。从图中可以看出，两者的应用实现都需要运行在各自的运行时环境之上，并基于对应的网络协议与后台服务端提供的相应接口完成底层数据访问或实现与前端UI的交互。下面就以WDA为例阐述并探讨开发方法的设计与实现。
图2 WebDynpro运行机制
2 WDA的开发与门户实现
2.1 WDA的功能分析
对应图1中门户与H公司的SAP服务器交互的部分，结合实例的需求分析，WDA的Web应用主要完成四大功能：客户维护、服务维护、服务合同维护和数据采集器维护。
客户维护 维护客户方在系统中的主数据，包括为客户在系统中创建业务伙伴账号，分配给相应的组织，维护客户基本信息等。
服务维护 提供给客户的各项服务主数据维护，包括服务所属的项目号、服务运行所在的系统、服务类型、服务状态等。
服务合同维护 与客户签署服务合同后，需要对合同业务数据进行相应维护，主要包括服务订单、状态、所属客户方、公司联系人、客户的SAP系统、服务条目、每一项条目的具体信息等。
数据采集器维护 数据采集器是从客户生产机上抓取所需分析数据的采集程序，对主数据的维护包括采集器名、采集器类型、采集器所属类、采集器版本、采集器的维护者信息等方面。
2.2 基于WDA的开发和技术难点的解决
Web Dynpro ABAP应用程序是依照改进的MVC模型建模的，它没有具体的Model对象，而是采用如Function Module，Class Method作为业务逻辑的封装，View负责数据在浏览器中的表现，Controller介于view和model之间。Controller格式化显示在view中的数据，处理用户的操作，并返回给功能模块或类的方法。WDA将业务逻辑与显示逻辑清楚地分开。一个运行在前端的WDA应用通过一个服务访问本地或远程的后端系统。这意味着显示逻辑被包含在WDA应用中，业务逻辑和持久化的业务对象运行在后端系统。WDA采用组件化的开发思想，每一个组件(Component)被视为一个可重用的实体和最基本的功能单位，组件之间可以相互包含，一个应用的实现可以只基于一个组件或是由多个组件组合而成。一个Component负责一个具体业务，它可以通过Componentinterface调用其他组件提供的功能。每一个组件的全局控制器(ComponentController)，为所有视图提供通用性的服务。开发者可以根据需要创建自身的全局控制器。Controller中则负责处理与屏幕元素的交互，调用模型层业务逻辑等功能。视图(View)提供对UI的布局(Lay out)以及行为的描述，视图被嵌入到窗口(Window)中才可以被浏览器显示。因此窗口总是包含一个或多个视图。窗口是应用的屏幕交互元素的容器，窗口对外表现为接口视图(Interface view)视图，同样的，组件控制器对外表现为接口控制器，然后才可被外部处理。视图和窗口可以包含输入和输出(Outbound，Inbound)Plug，用作导航时的出发点或目标点，视图间的导航通过在窗口中创建导航链接(Navigationlinks)实现。视图和窗口也具有自身的本地控制器。所有控制器对行为的控制都通过操作其包含的方法(Methods)。WDA的组件模型如图3所示。
图3 WDA的组件模型
在此例中，客户维护、服务维护、服务合同维护和数据采集器维护四项业务功能每一项分别由一个组件实现。依据图3的组件模型，开发的过程实际上是对改进的MVC模型每一层的具体实现。考虑到本例的实际应用环境，业务顾问的需求具有较大的不确定性，需求共识需要反复修改才可达成，从而影响到视图层的元素设计。然而，视图层的元素设计直接影响模型层中功能模块或类方法中参数的设计，进而影响到程序代码的具体实现方式。因此在这里，针对需求不确定度较高的情况，借鉴软件工程中以需求驱动开发的思想，站在使用者的角度，以需求为第一优先，驱动整个开发过程，按照V-M-C即视图层-模型层-控制层的开发顺序进行开发。
视图层的开发 以需求作为驱动，首先进行页面元素的设计。确定视图Layout的控件类型，明确业务顾问的业务流程，完成布局的设计。视图Layout的页面元素的数据载体实际是该视图Context中每一个节点的具体属性，所以之后需要分析页面元素所对应的数据类型。WDA对显示逻辑数据承载与传递的方法是采用Binding/Mapping的两级三层的机制。页面元素所需的数据载体必须先在组件控制器的Context中创建包含相应属性类型的节点。视图Context中的所有节点通过从组件控制器的Context中的节点映射而来。映射机制相当于是对本体创建了一个映像，映像与本体之间存在关联性，任何对映像的修改都会反映到本体中。这样的设计可以实现对本体数据的实时共享与同步操作，当多个视图需要实时获取同一本体进行业务操作时，这样设计的好处尤其明显。视图Context的节点属性绑定到视图Layout上之前设计的页面元素之后，完成数据承载关系的建立。服务合同维护功能的视图层开发结果如图4所示。
图4 服务合同维护的视图
模型层的开发 实际上是实现业务逻辑需要的功能模块和类的开发。功能模块(FM)是SAP开发语言ABAP所提供的完成某一特定功能的程序模块，可以被其他程序或者功能模块所调用，类似于子程序的概念。此部分的开发是整个WDA开发过程中的重点与难点，要在深入理解用户需求与业务逻辑的基础上，遵循ABAP的语法规范完成程序的编写。一段完成部分服务合同维护关键功能的FM代码如下：
在本例中，每项服务是按照使用次数进行计费的，客户每次使用服务时的操作流程完全相同，如何获取客户对某项服务的使用信息并出于访问性能的考虑尽量减少变量的使用与流程的跳转是开发中的一个难点。在此段程序中，引入了一项系统数据从而解决了问题。每当客户登录门户查看分析报告时，系统后台会自动在当前服务的页面地址后加入一段唯一的标识RUN_GUID作为本次访问的记录。获取这段含有唯一标识的地址可以作为服务使用次数统计的依据。此段代码先生成一个服务合同类的对象实例，调用该类的方法得到具体的某一合同所包含的服务信息，并以此为参数传递给另一功能模块完成获取客户使用某项服务所生成的所有唯一地址，并存放进一个内存表中，供后续程序处理。
控制层的开发 WDA包含四种控制器，分别是：组件控制器、视图控制器、窗口控制器、自定义控制器，通过它们所包含的方法、属动作等内容实现控制层对显示逻辑的控制以及模型层与视图层之间的数据交互。一个单视图完整功能的WDA开发过程如图5所示。
图5 WDA开发过程
实际上，包括WDA在内，软件业务流程的开展全部通过Internet实现。H公司提供应用服务并部署其在自身的服务器上，客户方不再需要购买软件，而是通过互联网全天候获取服务结果，且可以灵活定制所需服务项目，无需对软件进行维护。此过程取消了传统的软件授权费用，免除了客户服务器硬件、网络设备、软件升级维护的支出，仅通过Internet即可获取所需服务。
以上正是SaaS理念的体现与价值所在。
2.3 门户的实现
基于以上开发过程，完成了门户后端客户维护、服务维护、服务合同维护和数据采集器维护的WDA开发及前端客户动态访问分析报告的应用开发，实现了H公司对智能企业门户的需求。图6显示的是该企业门户。
图6 门户
此门户结合了企业门户的信息整合与SaaS架构的思想，将传统的软件交付周期流程无缝集成进门户系统中，这是一般意义门户系统所不具备的特性。在此门户内，业务流程的开展摈弃了过多的人工干预，核心功能全部自动实现，无需繁琐耗时系统配置、人力监控运行过程。最重要的是，通过此门户项目的实施改进了企业业务流程的方法论，一切基于服务的理念，而不再是传统的实施、交付、运行、维护，从而实现智能的特性。
3 结语
本文针对已部署SAP系统的企业对智能企业门户的需求，给出了利用SAP的Web Dynpro工具进行开发的方法与具体的实现。本研究认为，以下几点是在开发过程中应着重注意的：
(1)显示逻辑与业务逻辑的分离。WDA改进的MVC模型使开发者可以专注于显示逻辑的开发，业务逻辑应全部通过在后端系统中开发相应的功能模块或类方法来实现，显示逻辑的设计中不应包含业务逻辑，降低两者的耦合度可以极大地降低日后修改维护工作可能的工作量。(2)针对不同的需求业务背景，灵活地选择开发方式。对于需求多变、不确定性较高的情况，采用需求驱动开发的思想往往能起到较好的效果。对于需求较为清晰的情况，从模型层开始实现是更为普遍认可的方式。(3)组件的可重用性。WDA是基于组件化的开发思想，较为复杂的功能实现可能需要重用多个组件，每一个组件在设计过程中应更多地考虑本身结构的独立性与对外的接口，便于重用的实现，降低开发量。
智能企业门户是企业门户的发展趋势，它不再局限于技术工具，更是企业发展的战略组成。它的理论与实际价值在于：融入的智能思想和技术能够进一步完善发展门户整合理论，改善企业的业务流程可以极大提升企业运营水平，并最终促进企业信息化管理体系的不断创新。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：基于SAPERP平台的智能企业门户的实现
本文网址：http://www.toberp.com/html/consultation/1082058031.html
相关文章
