在软件中体悟人生 在人生中感悟软件

专注Web项目设计、实现和管理
  博客园  :: 首页  :: 联系 :: 订阅 订阅  :: 管理

[转]SAP技术解析

Posted on 2009-09-04 04:49  王景  阅读(600)  评论(0编辑  收藏  举报
前言:
随着对SAP了解和理解的加深,不难发现SAP除了OS几乎提供了所有软件和solution, 并且不断在适应和更新,不间断的吸收引入业界的新技术,改造调整自己原有的技术, 新技术名词,新概念也层出不穷,比如mySAP, NetWeaver, ESA, AP, TP, BPP等等, 这些概念或名词,经常让人confuse.其实,这完全正常,用逻辑去试图严密清晰的建立和揭示他们之间的联系和区别,本身不大可能,用一个大的概念来概括SAP的架构也是很难的。因为,这些名词或概念, 他们有的不只是一个产品, 有的又只是产品中蕴含的,或是技术发展蓝图中的一个概念, 他们的边界本身不甚清晰, 他们之间不可避免会有Overlap. 比如DataArchiving, 它是一项负责保存应用数据的技术, 最早是在ABAP上实现的, 但是在SAP J2EE中也有实现, 所以, 它既属于NetWeaver, 也属于mySAP. 无论是mySAP, 还是NetWeaver, 他们都不是代表一项技术, 而都是代表以一组技术(或概念)为核心的一整套技术(或概念)体系.这也是完全可以理解,作为一个优秀的企业,如同世界上其它的优秀领先企业一样,他们不可能停滞不前的,他们曾经优秀的传统和内在的管理和文化都要求他们不断的创新、进取,与时俱进,如同生物遗传基因一样,只要没有重大的环境或人为灾难,基因是不会发生变异的,从而企业也不大会发生畸变,不大会停滞落伍衰败没落。
那么,SAP技术解析一个好的办法是从SAP的技术发展历史开始切入。
SAP发展历史
1972年, 五名IBM的经理人和consultant(看来工程师是永远写程序的命)离开了IBM, 在德国曼海母创建了他们自己的公司, 这就是SAP(是德文系统,应用和数据处理产品的缩写. 德国公司的名字永远这么朴素直接). (2002年4月1日是SAP 30周年纪念日)
他们创建SAP的原因是, 当时他们发现自己的客户正在自行开发类似的程序来处理业务流程. 于是他们意识到他们可以提供可重用的标准化的系统, 来集成和实现用户的业务流程, 并且, 重要的一点是他们认为电脑现实器为普及作为业务流程的关键点. 当时没有微机, 计算机最多仅有500k内存. 有趣的是, 苹果公司于同年成立.
SAP的第一个产品是一个自动化财务和交易程序.命名RF, 就是后来的R/1. (值得敬佩的是, 他们的产品是利用晚上和周末开发出来的, 而我用了6年证明, 这几乎是不可能的 :P )
1976年, SAP 迁到现在的总部所在地Walldorf.
1979年, SAP推出用于大型机的R/2.
1988年, SAP在德国上市.
1992年, SAP推出了著名的R/3. 基于C/S 模式, 统一的图形界面, 兼容关系数据库, 可以运行在WindowsNT等多种*台和计算上等先进的特性, 使SAP成为世界领先的系统提供商.
但是, 至此SAP的所有应用都是独立的, 仅仅是client加上DataBase.
1996年, 随着互联网的迅猛发展, SAP推出了支持Internet的新版R/3 3.1
1998年, 退出全新CRM和SCM解决方案.
1999年, SAP 推出所谓的mySAP Business Suit. 这其实又是新版的R/3, 但是它的应用已经不是孤立的, 它支持全面的协同的的电子商务和ERP解决方案.
现在的SAP, 是员工超过30000, 实验室分布全球的世界第三大独立软件供应商. 提供超过21个行业,13个跨行业的解决方案, 拥有18000多家客户, 5000个系统安装点, 并已进入中小型企业市场. 技术上, SAP 有自己的商业开发语言(ABAP), 有自己的application Server, 自己的开发*台. SAP几乎可以提供除OS外所有基础软件和解决方案. 其实, netweaver或mySAP的概念对我们了解SAP的技术而言并不重要, 因为SAP的技术几乎概括一切, SAP的整个架构就是一个现代IT的领先技术架构的实现. 无论mySAP 还是NetWeaver, 还是AP/TP/BPP, 都是SAP为了适应更先进技术, 而发起的对SAP总体技术框架的改造运动.
通过mySAP, SAP 实现了更方便, 更容易沟通的系统框架, 通过NetWeaver04, SAP成功的把它以前的所有技术和业务逻辑通过和J2EE*台集成而开放出来. 通过NetWeaver05 和AP/BPP/TP/ESA, SAP实现更高程度的技术/业务分离(TP/AP), 更好的业务封装(AP), 更方便的顶层业务实现(BPP). R/3到底属于NetWeaver吗, 这个问题不重要, 可以属于也可以不属于, 你只要知道R/3的业务, 在新的web application 中可以依然被使用, 并且可以更好更漂亮更方便的被使用就可以了.
领先的*台提供者
SAP其实并不是现在才想做业务*台的领导者, 自他的ABAP出世, SAP一直就是世界最先进最主流的电子商务*台提供者. 只是现在, 特别是J2EE普及之后, 人们更多的认识到*台的重要性. SAP将围绕电子商业提供三种*台:
1. 技术*台 TP(Technical Platform)也就是所谓的NetWeaver.
它提供了所以技术基础设施. 他是J2EE的扩展, 它提供的内容远远超过J2EE的范畴. 他的架构同时也包括了基于ABAP vm 的应用服务器.
2. 应用*台 (AP)
NetWeaver虽然提供了技术*台, 但是, 要用他来实现一个企业的业务流程, 根本还是件极其复杂的事. 因此必须有离应用更*的*台, 提供基础业务设施的封装. 这就是所谓的AP (Application platform). 他是由SAP的ESA(Enterprise server architecture)来实现的. 简单的说, NetWeaver加上ESA, 就是AP, 他提供了一个实现基础业务逻辑的*台.
3. 业务流程*台(BPP)
这是一个面向业务流程的*台. 基础业务逻辑可以用AP实现, 通常SAP已经提供大量基于SAP系统的业务逻辑. 同时, 第三方也可能提供业务逻辑. BPP的开发人员只需要使用BPP的开发环境(Visual composure)去组装这些业务逻辑.
现在
下面我们分别来看每个概念
SAPBasis
应该是从R/3开始(有待考证), SAP的底层已经形成基于ABAP的一个应用*台. 有统一的数据设计方案(DDIC), 界面设计方案, 开发流程, 版本控制, 数据库连接, 进程管理, 共享内存管理, 事务管理等等.它为商务的应用的编写提供了可靠的技术支持.
简单的说R/3是一个基于ABAP虚机的,基于进程(进程间通过share memory通信)的, 基于数据库的,提供事物特性的简单应用服务器。这在当时,是极为先进的架构。也只有这种架构, 是的企业级的, 可灵活改造的,可高效管理的应用成为可能。
当NetWeaver出现后, SAPBasis被改造为NetWeaver中的ABAP Application server.
mySAP(mySAP.com)
1999年9月, CEO哈索.普拉特纳宣布以”开放和集成”为中心的mySAP.com的战略. 改造技术架构和方向, 统一和整合原有的系统, 推出mySAP协同化电子商务解决方案.
当时的背景是Internet 技术趋向成熟和普及. 独立的应用之间的交流和灵活性扩展性的问题显得异常突出。业界技术的发展使得开放接口,整合产品成为共识。因此SAP决定提供可剪裁的,高度集成和开放的系统。
主要手段为:
将R/3上的业务系统划分的更细更合理, 提供不同功能的组建和系统。数据类型是统一和跨系统的。SAP制定了一系列标准接口(如BAPI),让各种应用之间可以互相通信。开发Single Sign On 来简化Authentication等等。
这张图是当时定义的mySAP.COM
现在的mySAP Business Suit是一套协同化商务解决方案套件, 它包括:
mySAP CRM(Client Relationship Management)
mySAP SCM(Supply Chain Management)
mySAP PLM(Product Lifecycle Management)
mySAP SRM(Supplier Relationship Management)
mySAP ERP(Enterprise Resource Planning).
他们可以无缝的同其他系统集成.
mySAP ERP 又提供4套单独的解决方案:
mySAP ERP Financial
mySAP ERP Capital Management
mySAP ERP Operation
mySAP ERP Corporate Service.
下面这张图描绘了mySAP Business Suit的主要构件.
NetWeaver出现之前, mySAP的技术*台应该是SAPBasis.
如今的mySAP, 已经是基于NetWeaver了, 因为SAPBasis已经被改造为NetWeaver的一部分。NetWeaver是SAP的新一代技术*台.

NetWeaver

NetWeaver

刚刚提到, NetWeaver是取代SAP Basis的新一代技术*台(TP). 简单说, NetWeaver体现了在2000年到目前为止的以Java/SOA为主要商务应用实现技术的时代里, SAP在技术上与业界技术的整合.

它主要是在J2ee application serverABAP application Server的基础上提供了统一的技术基础设施. 除了J2EE以外, NetWeaver还提供了WebDynproPortal作为 Web 开发的基础设施, 用户管理, .NET 或其他J2EE*台的集成, R/3的连接, ESA的实现等等.

所有开发都在NetWeaver Studio中进行.NetWeaver Studio是基于Eclipse 的开发环境.

下面这张图描述了NetWeaver技术*台的主要功能:



这张图显示了NetWeaver的最基本组件. 事实上整个NetWeaver几乎涵盖了所有电子商务会用到的技术, 下面简单列一下主要的部分:

SAP Web AS:

包括了SAP J2EE engineabap application server

下面就是SAP WEBAS 的架构

server 架构:



Cluster

架构:

CIM: Internet Communication Manager. 负责接受Web请求. 支持HTTP, HTTPS, SMTP. 通过URL, 它可以区分是对ABAP BSP(Business Server Page)的请求, 还是对J2EE的请求, 从而dispatch到不同的engine.

Message Server: 是全局的消息服务器, 负责server间的异步或同步通信

Engueue Server: 是全局的队列服务器, 负责保存全局队列和锁.任何应用都可以申请使用它.

Work Process: ABAP engine中的一个工作进程.

JCO/Fast RFC: 用于基于SAP自己的远程调用规范RFC的调用

Gateway: 我的理解是用于翻译RFC call, RFC call的协议是CPI-C(Common Programming Interface – Communications, SAP专门用于程序对程序的远程调用的协议, 说白了就是一个定义描述函数名,参数之类调用需要的信息的数据格式).

SAP J2EE Engine: 2002, SAP收购了保加利亚的J2EE Application Server 开发商Inqmire(全称In-Q-My). 开发自己的J2EE Engine.目前的稳定版本为6.4. 这个Engine给人的感觉就是三个字巨无霸”. 没有2G的内存是很难看到它在工作的. 通常巨无霸给人的另一个柑桔就是笨重和土气. 7.0以前的版本的管理方式比较土, 是基于rich client. 7.0以后才逐步使用webIDE作为管理工具.

下面是SAP J2EE Engine 的简单架构图

下图是SAP J2ee engineCluster 架构

NetWeaver Studio: SAPNetWeaver 开发*台. SAP的几乎所有开发解决方案都通过这个IDE实现. NetWeaver Studio IDEWebSphere Studio一样, 是在Ecllipse的基础上开发的.目前的稳定版本也是6.4.

SAP DB: 就是MAXDB. 现在与MySQL技术合作. 把源代码提供给MySQL. SAP将不在放更多人力在DB的开发上了.也许DBOSSAP唯一暂时不愿去占领的技术.

WebDynpro: MVC架构的Web 开发解决方案. 提供所见即所得的UI开发方式. 不但是基于SAP J2EE engine, 也可以用ABAP开发

Portal: Portals是一家Israel公司Top Tier的产品, 2001 SAP收购Top Tier并组建SAP Portals公司. Top Tier的总裁Shai Agaci, 现在是SAP Border Member, 是呼声最高的未来SAP CEO. Portal提供了另一种Web开发模式, 同时提供Content ManagementKnowledge management, Portal 可以基于Tomcat, 但现在是SAP J2EE engine的一部分.

XI(Exchange Infrastucture): SAP 的系统总线.

TREX: SAP的搜索引擎

RFC: Remote Function Call. SAP 的远程调用技术. 支持ABAP<->JAVA, JAVA<->JAVA, ABAP<->ABAP之间的调用, 旧的RFC使用SAP CPI-C协议, 必须通过SAP Gateway进行翻译, 新的fast RFC则不需要使用CPI-C协议.

下图是RFCWeb AS中的位置.

下图是JCO(Java connector)SAP RFC之间的关系:

WebService: SAP J2EE engine NetWeaver Developer Studio提供了WebService UDDI的支持.通过studio, 可以使用wizard简单的生成Web Service client proxyserver side, 不需要写任何WSDL. 但是WebService server端必须先implementEJB(session bean).

SLD: System Landscape Directory. SAP Web AS提供的系统管理方案。使用SLD可以方便的管理整个庞大SAP 系统群。

ESA (Enterprise Service Architecture)

ESA (Enterprise Service Architecture)

简单的说, ESA是SAP 基于SOA(Service Oriented Architecture)的概念。主要目的通过WebService, 进一步提高SAP各业务系统间的统一性, 可重用性,建议更方便的业务流程开发模式。主要手段为

建立以Service为中心的开发模式. 因为service相对于组建或者其他软件封装技术来说, 有耦合度低,跨Internet, 范围更广, 跨*台, 粒度更自由等优点。

在web service的基础上, 建立统一的service infrastructure(就是后面说到的ESI).

建立所谓“模式-驱动”的开发模式。 其实, 我的理解是,在强大的Service Infrastructure基础上,有统一的数据类型来描述数据,有Business Object来封装逻辑,有UI pattern来封装UI, 有了这些,就可以用一个简单的设计工具,就可以快速的描述数据, 拼装业务逻辑,建立UI,这就是使所谓的“模式-驱动”的开发模式,成为现实。这里指的开发,不是简单应用的开发,而是业务流程的开发。这各设计工具, 就是Visual Composure.

先介绍几个概念:

Service:

Service就是SOA中的service概念. 它提供了企业的某个业务功能.

ESA中有三种Service:

Core Service: 提供对Business Object的直接访问, 如retrieve, access, action...

Compound Service: 由对多个core service的call组成.

Enterprise Service: 也是一种compound service, 但是它是组成Business Process的直接service. 它提供企业的关键业务功能.

Business Object:

BO可以看作是Service的实现. Service的定义和其实现无关. SAP在ESA中主要用BO实现 Service的功能.

BO是结构化的. 每个BO之间由Association连接.但是只有一个root node.

一个BO可以有多个service interface, 一个service interface由多个operation组成

BO定义了一组Attribute和Operation. 每个BO都由一个Business Object provider class 实现, 它实现了一组Generic Interface.

BO的attirbute的type必须是Global Data Types(GDT)

Global Data Type

要统一service interface的定义, 就必须统一数据类型.

Business Process:

LDU(Logical Deployment Unit)

一个LDU由一组语义相关的componenet组成, 为了可以简单的activate/deactive一个业务功能.s

Process Agent:

提供Message-Based的LDU之间的通信.

下图是ESA实现:

ESI(Enterprise Service Infrastructure) 为ESA的实现提供了基于Web Service的统一的Service定义。使“模式驱动”的开发成为可能。这种设计由需求开始, 定义服务, 服务驱动实现.

下图显示了ESA的开发模式:

ESI由三部分组成:

ESD: Enterprise Service Designtime: 提供ESI的设计时的支持。包括三个项目:

ESR(Enterprise Service Repository), 包括ES Object, Modelling, ESR Framework

ES Java Tools, 包括Repository Browser, Service and Consumer Definition Editor, Service Configuration and Consumer configuration Editor, Proxy Generation.

ES ABAP Tools: 包括Repository Browser, Service and Consumer Definition Editor, Proxy Generation

ESF: Enterprise Service Framework, 提供了ESI的运行实现。(应该叫做Enterprise Server Engine)

ESF Runtime Architecture,如图:

ESP: Enterprise Service Protocol: 定义所有ESI的协议