SAP入门经典（第4版•修订版）

本书是由业内专家编写的SAP入门教程，其中对SAP的各种主要产品与组件进行了较为详细的介绍，并且从项目管理、业务、技术等多个视角对SAP的部署过程进行了全面介绍。本书结构清晰、内容丰富，而且各部分内容详略得当。读者通过阅读本书，可以深入浅出地了解SAP的历史演进、术语、用途、配置、部署和管理等各方面的内容，对原本极其复杂的SAP领域获得清晰认识。

本书在上一版本的基础上增加了云技术等SAP相关新内容的介绍，更为贴近当前的实际应用。本书既可以充当了解SAP实际业务应用的入门读物，也可以作为从事或学习相关专业的人士的参考用书。

George W. Anderson 博士及其家人居住在得克萨斯州的休斯顿市。作为有着 13 年工作经验的SAP顾问和25年经验的IT专家，他领导过无数SAP实现、升级、迁移工作，以及其他许多业务项目的实施工作。George 拥有 SAP 技术顾问、SAP NetWeaver’04 OS/DB 迁移顾问、PMI PMP、MCSE、MBA 等认证资格和学位，最近还获得了博士学位。他喜爱写作，愿意通过自己的图书、杂志文章、讨论会等形式与他人分享经验。在 Microsoft 工作期间，围绕SAP的下一代平台和架构以及其他业务范围（LOB）应用，他展现了强大的思维领导力，为大家指明了战略方向。另外，他还是《SAP Professional Journal》（SAP 专业期刊）屈指可数的几位技术编辑之一。George没有花太多的时间陪伴家人、朋友或者去参加教会活动，但是他在Microsoft的TechNet网站（http://www.blogs.technet.com/b/lobapps/）开设了自己的博客。他喜欢弹吉他、钻研圣经、去新牛排餐馆尝鲜，以及与自己的读者交流。读者可以在午夜后通过george.anderson@microsoft.com与他取得联系，因为这是他一天中精力最充沛的时间。

本书谨献给我美丽的贤内助 Michelle、3 个可爱的孩子和我的朋友 Fazil Osman，他们为我完成自己的第一本SAP著作提供了巨大的鼓励和帮助。还要将本书献给我的朋友Raymond Smith以及我所有的小帮手们，他对我最近一本书的撰写贡献良多。

1997年，当我开始自己的SAP职业生涯之时，我从来没有想到会获得今天的成就。诚然，我一直以来都勤勉努力。但是本书的完成以及我所取得的成就却完全不能归功于我个人。我最信仰的书告诉我，没有上帝的帮助我将一事无成。而有了他的鼓励，我将无往而不利。10年前当我的生活发生改变时，我对此话深信不疑。我的成功接踵而来，但是它们应归功于上帝。我的家庭人丁兴旺，和谐美满，这无一不源于上帝的祝福。我的工作和爱好协调良好，这是我过去所不敢奢望的，无疑也应称颂于他。因此，当我长坐于此深思是谁成就了此书时，我只能虔诚地对耶稣道声：“感谢您”。

接到要我升级《SAP入门经典》的邀请时，我真是感到兴奋不已！过去几年中SAP领域和我自己的生活都发生了天翻地覆的变化，我非常高兴能够与现在以及过去的SAP从业人员分享这些变化。与此同时，我也很希望能够有机会像《Teach Yourself SAP》的原作者 Danielle Larocca 那样对本书的结构进行调整和简化。Danielle Larocca的工作值得借鉴，她把目标瞄准了企业用户和技术读者，而放弃了其他SAP项目参与者。我在本书中也尝试了侧重相同的读者群体，同时也专门照顾到了一些自己读者关注的问题。而且，我还希望能够满足读者在一致性、避免重复、提供更能说明问题的插图等方面要求。在此感谢您阅读最新版、当然也是目前最佳版本的《SAP入门经典》。您会发现它物有所值，我对此信心十足。

为了达到简明易懂的目的，我对内容的结构重新进行了安排，划分成了5个部分。第一部分从介绍各种基本概念开始本书，第二部分覆盖了SAP的商业应用和组件。之后，顺理成章地先让我们从企业用户的角度了解 SAP（第三部分），然后从 IT 专业人员的角度深入分析（第四部分）。为了介绍最近5年出现的新知识和新焦点，以及回应许多读者关切的问题，第五部分对云技术进行了扩展介绍，用于帮助您顺利开始SAP的职业生涯。

纵观全书，我对SAP新手需要了解的重点知识都覆盖到了。对于企业用户来说，我没有浪费时间去介绍如何设置SAP访问，以及定制用户界面，而是带您浏览了实际的业务事务流程。总之，我们对创建销售订单、升级雇员个人记录等工作的意义进行了探讨。您可以学到如何为SAP用户分配角色，并且根据角色为执行事务提供授权。我们研究了大量的业务流程，如“从订单到现金”，以及它们是如何分解成具体的SAP业务事务的。另外，我们还对报告和排队流程进行了详细的介绍，这些流程不仅仅需要SAP本身，还涉及了一些常用的企业生产力提升工具，如Microsoft的SharePoint、Adobe的Forms等。通过本书的学习，尚未使用SAP的企业用户可以真正地体验到SAP终端用户的日常工作情况。

对于许多阅读我的书籍的技术读者而言，您会发现我这次进行了一些全新的改变。过去5年中，我从有兴趣安装了SAP演示版的新手那里收到了不下上百封的来信。因此毫无疑问，在最新版的《SAP入门经典》中我们不仅要一步步地一起了解真正的技术安装过程，而且要找到和安装SAP自己的免费软件。SAP过去称之为MiniSAP，现在则直接把它叫做SAP试用版了。它会彻底改变您对从本书中所学到的知识的应用方式。比如，学习完成后您将有能力像 SAP IT 专业人员在实际工作中所做的一样，对 SAP 系统进行基本的管理、调整、维护和监视。而且我们还会谈到如何为技术升级做准备，以及管理SAP项目。通过从多个不同的角度认识SAP技术，包括对SAP和云计算的深入了解，有经验的技术读者也可以更出色地完成本职工作。

最后，在阅读完本书之后，您会对SAP有深入理解，我打赌您对SAP的认识也一定会有所突破。您会成为为数不多的既了解业务情况，同时又精通技术的工作人员。您会了解到实施和运行SAP的重要意义，并且因而主动去改变您周围的世界。

再次感谢您购买本书。

自从本书20世纪90年代出版以来，SAP已经有了长足的发展。从只有一种产品的公司发展到创造了丰富多样的应用程序和技术，并使之为全球的各大公司所采用的全球软件巨头， SAP开发出了众多无可比拟的稳定的现代企业解决方案。即使在发生全球经济衰退，采购和部署技术的方式发生全球性转变之时，该公司及其产品仍然成为了不断演进、创新的典范。

但是SAP是什么呢？与大家熟悉的Microsoft的Word和Excel这种个人用于完成自己工作的桌面办公软件不同，SAP是一套业务应用程序。通过它，个人就可以运行整个公司的财务系统、管理库房和配送设施，搞清如何更快速地销售产品，为公司处理薪水发放问题等。正是这套覆盖整个公司的 SAP 系统成为了当今世界的大型企业复杂而必不可少的工具。然而，要实现和维护好这套软件系统耗资巨大，颇费时日，而且需要经验丰富的技术团队和训练有素的企业用户才能获得超乎想象的投资回报。而这正是本书希望为您提供帮助的地方，它可以提供IT人员和企业用户所需的基础知识，使他们能够理解、支持并开始使用SAP。

本书覆盖了您需要详细了解的SAP核心产品和组件的所有相关内容，这些产品和组件通常合在一起简称为SAP。尽管只是一本入门书籍，但是它可以让您对当今SAP的方方面面和发展方向获得非常全面的了解。作为身经百战的SAP专业人士，我可以保证这本书有效实用。在本书中，我会与您分享您需要知晓、理解的信息，共同完成必要的练习。此版比之前的版本更注重了两大部分志在学习 SAP 的读者的需求：企业用户和专业 IT 人员。我根据这两种不同类型的读者所需的技能和侧重点对本书内容进行了编排，希望读者能够对此感到满意。本书对SAP的各个领域进行了概述，并且结合了实用的操作步骤和指南，相信您必能从中获益。

本书从基本概念入手，介绍了SAP相关的术语、业务应用、基础技术知识，以及实施项目所需考虑的问题。从这些基本概念开始，学习过程会慢慢一点一滴地构筑起对复杂的SAP世界的全面认识。本书的教学步骤是首先为您打下坚实的概念基础，以便您能够掌握后面章节所要学到的更深入的内容。因此，即使是新手也可以很快了解规划、部署和使用SAP的意义所在。有了这种了解，您就可以开始体验真正的SAP工作人员是如何实施项目的了——包括如何实现行政领导、项目管理、业务应用、技术部署，以及应用中的企业用户是如何一起创建和使用SAP端到端应用的。

前面几章较之之前的版本打下的基础更为坚实，让读者能够快速入门，之后的内容就会分成针对企业用户和专业IT人员的各个部分了。本书还以章节或“学时”进行了清晰的划分，旨在让读者能够更方便地找到感兴趣的专题领域，从而快速找出对他们有用的学习材料。与之前的版本不同，本书的每一章都以一个实际案例分析作总结，使读者能够对自己新学到的知识加以检验。

除了重要的结构调整以及向企业用户和专业IT人员的明显侧重，书本还包括了许多新内容，例如：

对与新产品、能力、技术术语相关的内容进行了更新；

覆盖了一些热门技术，如基础设施即服务（Infrastructure as a Service，IaaS），平台即服务（Platform as a Service，PaaS）和软件即服务（Software as a Service，SaaS）；

我们专门用一章从SAP的角度以及许多SAP架构合作伙伴和托管服务提供商的视角讨论了云计算技术；

用一章专门对SAP的安全基础（如角色和授权）进行了介绍；

包括了使用ShairPoint和Adobe实现简单接入的方法；

改进了实际SAP项目实施指南；

简化了无数SAP基本从业人员日常司空见惯的与系统管理、监视和调整相关的简单内容；

改进和扩展了与从业指南问题相关的内容；

附录包括了SAP特有的简称和常用术语。

为了让您直观地感受到SAP企业是如何使用SAP进行日常工作的，本书还针对运行许多常见的SAP业务事务设置了实用的分步操作说明。全球有不计其数的用户都可以通过“运行业务”（running the business）执行着相同的事务或业务流程。最后，我还为您介绍了一些您可轻松地从Web上找到、使用的资源，而且带您回顾了一下本书的前几版。比如，在本书的第二版和第三版中，我和本书的合著者深入分析了许多现在事后看来是矫枉过正的技术，但是对于有志于深入学习的人来说，它今天仍具价值。这样做能够简化掉一些过于深入细琐的技术材料，从而真正地让初学者学习起来更轻松，并学到更全面的知识。

本书适合那些与SAP素昧平生以及希望弥补自己SAP知识空白的读者。例如，阅读第19章中描述的SAP对云计算的观点，或者浏览一下第3章中提到的一些新的热点技术，即使对于经验丰富的专业SAP人员来说也是不无裨益的。但我在本版中真正侧重的读者群体还是刚刚接触SAP的企业用户和技术人员。当然，如果您身为负责实施或升级SAP的执行主管或者项目经理，本书也给出了一些实用而且容易找到的指导意见。对于此类读者而言，最差的情况下也还可以在读过第1、4、5和第15章的内容之后把本书送给新入行的企业用户或者专业技术支持人员，为他们提供帮助。但是本书大部分内容是针对那些对SAP一无所知，而又不希望淹没在网络上毫无用处的介绍性内容之中的企业用户和专业技术人员的。

总而言之，本书是帮助您进入SAP世界的不二之选。站在作者的角度，我们希望您能够在阅读时乐在其中。更重要的是，希望您能够在将来的工作中将从本书中学到的知识学以致用。

业务架构和蓝图设计；

将业务需求映射到SAP应用程序中；

处理业务需求的4种视角；

SAP如何为业务需求提供支持。

尽管SAP可以提供大量的应用程序和底层技术来满足公司的业务需求，但首先需要深入理解这些需求和业务要求才能将其映射到软件应用程序中去。而揭示、定义和体现公司的经营目标，并将其转化为应用程序策略正是业务架构的核心内容。创建线路图可以在这一过程中为企业指明方向。在本章中，我们要了解业务架构的基本知识，并开发一份业务线路图。您将亲眼目睹业务需求是如何把机构的目标及其人员与业务应用程序联系起来的，他们最终将使用这些应用程序运行和改造业务。

在我们探讨SAP的应用程序和技术之前，我们需要首先从整体上了解一下建立业务架构的目的和重要性，特别是要对业务线路图进行一下说明。业务架构是一种高度抽象的表达方式，其中公司的经营目标被解构成了各种必要的业务功能。在对这些业务要求有了充分的理解之后，就可以把它们转变为一套基本的业务流程了（或工作流程），而这些业务流程反过来又可以与SAP和其他应用程序能够提供的更多具体业务功能相结合（如创建采购订单或管理招聘过程）。

有时候业务架构可以高度概括地描述为何人、何事、何处、何时这样的问题。而业务线路图是一种工具，用于将这些梳理成一个逻辑流程。它可以把使用SAP或SAP的数据和报表的最终用户与能够提供数据和报表的业务应用程序相关联。在首次实施过程中，业务线路图可以帮助机构避免偏离设计目标。而在SAP已经安装、启用之后，与业务线路图相似的工具和流程也可以帮助机构根据业务执行需求对SAP进行必要的改动。

就像建筑施工不能没有图纸一样，没有设计合理的业务线路图，公司就不可能实现自己的远景目标，或者解决好日常业务需求。业务线路图可以提取战略目标和业务架构的精髓，用来描述公司的业务需求、业务功能，以及提供这些功能的应用程序。从另一个角度看，线路图显示了业务功能是如何最终交付并满足公司的业务需求、实现其远景目标的（见图2.1）。其间，业务线路图首先要找出与业务操作相关的技术；然后将业务问题整合成一个SAP派生技术能够实现的业务解决方案。这样一来，SAP的应用程序和底层技术就简单地表示成了业务达到线路图终点所使用的工具。

图2.1 业务线路图把远景目标和战略与用于运行业务的SAP 应用程序联系起来

公司业务一般会提供货物和服务。有许多类型的业务以利润、股票价值等方式为公司及其所有人创造价值。而另外一些实体，如非盈利公司或慈善机构也要通过业务实现服务社会的目的，例如哺育饥饿的儿童、照顾贫困人群等。尽管目的不同，但如果不能补充成本损耗，那这种业务无疑就是失败的。

业务架构的核心，即真正的业务，是业务的工作内容（销售或提供什么东西）。汽车公司会销售汽车、石化公司要出售汽油，而慈善机构会为弱势群体提供物品和服务。尽管如此，公司提供服务的效果如何却完全是另一回事。从财务到销售、营销、供货链/物流、产品生命周期管理、支付等，影响业务执行的因素来自方方面面。所有这些方面的问题都可以简单归结成两条：利润（销售）最大化和支出（成本）最小化，下面我们就对它们进行讨论。

各种SAP应用程序在日常工作中习以为常地运行着各式各样的业务。但是仔细观察就会发现SAP对财务基础的影响；如果SAP业务解决方案实施得很好，就可以帮助机构提高总收入（top-line revenue）和降低净支出（bottom-line expense）。例如，从盈利的角度看，SAP可以在以下方面提供帮助。

发现和管理新市场（通过SAP客户关系管理、业务数据仓库和商业智能程序）。

在产品和服务商方面进行创新，以迎合新市场的需求（通过SAP复合应用程序、产品生命周期管理和客户关系管理程序）。

改善公司与现有客户关系，从而提高销售量，建立更巩固的销售联系，或获得更大的市场份额（通过SAP客户关系管理、商业智能和企业资源规划程序）。

同理，通过在以下方面发挥作用，SAP还可以帮助降低成本。

通过精简业务流程、最大限度地提高资产生产力、最大限度地缩短无收益时间（使用SAP企业资源规划程序）等。

通过纵向整合降低公司的原材料成本（使用SAP供货链管理程序）。

通过提高管理可见性和业务流程透明度，降低公司在货品、物料、劳动力等方面的成本（使用SAP供货链管理程序和企业资源规划程序）。

降低内部运营成本（使用SAP供货商关系管理程序）。

最大限度提高库存和供应商折扣（使用SAP企业资源规划程序）。

重新设计公司的服务交付流程（使用SAP企业资源规划程序）。

通过更快速地找出改进成本模型和优化低效流程的机遇，来降低公司的“改变成本”使用SAP业务数据仓库和商业智能程序）。

改进公司管理、交付、优化、跟踪和提高产品和服务质量（或用于推动产品和服务的业务流程）的方式（使用SAP企业资源规划程序）。

在提高销量的同时又能降低成本的公司必然可以比竞争对手取得更大的商业成功，而能够更好地管理改变风险的公司甚至更有希望能够在激烈的竞争中拔得头筹。

每项业务改变都可能带来轻微的紊乱甚至重大失误。为了尽量避免此类失误（来自错误的判断、领导、产品营销、销售策略、合作关系、联合方式等）带来负面影响，睿智的机构需要前瞻性的发现、管理和化解风险。其适用于各种旨在提高收益或降低风险的改变措施。

应急预案的重要性不言而喻。实施 SAP 所造成的影响深入而复杂，需要方案 B 甚至方案C（甚至更多应急预案）作为后备方案。了解可能对方案A进行的改动并为之未雨绸缪常常成为成功实施业务解决方案的关键，否则 SAP 也可能从一开始就无法带来预期的改变后果。出于这种对部署的担忧情绪，要成功地开发和执行它就需要在业务架构，特别是在SAP业务线路图方面多加入一层考虑，那就是：业务敏捷性（将在后面讲到）。

业务敏捷性是指公司能够对产品、服务、供货链、销售策略、IT架构等进行调整从而满足客户需求的能力。敏捷性并不事关当下，而是与未知的将来息息相关；灵活敏捷的机构由于能够更迅速地弥合当下的能力限制与未来的能力需求之间的差距，从而战胜竞争对手。因此，一份设计合理的业务线路图必须能够反映出业务敏捷性，即使机构工作能够更高效快速、灵活有效。同时这些要求也应该反映在SAP应用程序和技术的功能上。

提高业务灵活性可谓说易行难。改变就意味着要摆脱一直以来习以为常的惯性。而摆脱惯性就意味着要改变员工和机构的工作方式和处理业务的流程；但是人们有着巨大的固守现状的思维倾向。就像许多公司在艰难的改变过程中发现的，固守现状并非公司的经营之道。实际上，实施SAP经常被看作是打破现状、彻底改变工作方式，对业务流程重新进行优化、划分和处理的一种有效途径。优化是其中的关键，因为最终决策的精简将使机构能够实现：

更优质、快速地管理客户关系；

更高效、低成本地进行供货链管理；

提高管理透明度，符合法规要求；

降低处理风险的相对成本，获得更好的效果；

可以测量完成业务的投资回报（ROI）。

只有有了设计合理的业务实施线路图才有望改进业务流程，从而提高收益或降低成本。但是最重要的是接下来的一步。如果把业务架构和战略看作是我们所在大楼的地基，那么实际的SAP业务流程开发过程（SAP把它称为“业务蓝图设计”）可以看作是为我们的大楼搭建框架。

要设计业务流程蓝图，必须首先确定公司希望达到的业务流程效果，找出当前状态与这种理想状态之间的差异，决定如何应用SAP模板，明确对这些模板的定制需求，并对之进行优先排序，然后划清完成这些目标所必须涉及的工作范围。现在该考虑组织问题和机构的原始目标了（还要根据实际业务情况对这些目标进行修订）。总之，设计业务蓝图是内部线路图开发工作的高潮。

SAP在其加速SAP项目实施的方法论（ASAP）中重点突出了蓝图设计规程。设计蓝图之前有多项与项目准备相关的任务要完成。蓝图设计完成时，每个SAP应用程序都应该已经具体配置完成了，把预想的业务流程变成了实实在在可用的工作流程，它们由各种专门为客户量身定制的业务事务构成。这个ASAP阶段称为实现阶段，项目的大多数时间和预算都用在这个阶段。（对功能性、集成性的多次迭代以及其他类型的测试要消耗大量的时间、人力和其他资源。）实现阶段完成后，需要最终准备、现场支持以及SAP运行后现场支持来最终圆满完成整个ASAP项目生命周期。ASAP和项目管理方法学的其他问题将在第4章和第15章进行更详细的讨论。

如前所述，开发出一种行之有效的业务视角是解决业务问题或者迎合业务需求的第一步，也是关键的一步。业务视角要阐明的是为什么需要解决特定的问题，或者为什么要去寻找机遇的问题。

为一家公司开发独特的业务视角要求处理好以下方面的问题。

找出与业务相关的利益相关人。

坚持长期贯彻策略。

短期业务目标。

非核心竞争力（合作、联合开发或者外包某些服务的机遇）。

采购和其他资源策略（其他策略和关系随时可能如何变化）。

实现SAP全球化和本地化（其重点在实现全球一致性和汇总财务报表之间来回变换，比如为解决本地用户群体的货币和语言要求等）。

在这个层次上与业务关系最紧密的利益相关人是那些涉身于战略调整和执行与公司生存息息相关的实际业务流程或工作流程的人。因此，必须保证企业执行官和其他董事局成员以及功能性部门的经理和团队主管、业务分析师和其他行业领袖都能参与到业务视角的开发和沟通中来。

有了业务视角为我们提供支持，就可以处理设计业务蓝图后面的几项工作了。诸如开发底层架构和设计IT平台这样的问题都需要我们去考虑和完成。通过这种方式，我们可以把业务线路图与预期的业务目标实际结合起来，灵活敏捷地对不断变化的市场、新业务需求、增强治理等问题做出响应——所有这些问题都需要在灵活的技术平台上进行处理。技术基础知识将在第3章进行详细讨论，该章的知识将为在第16章中详细学习开发技术线路图创造条件。

如果不能深入了解利益相关人的想法和他们的各种独特观点，就不可能构建好业务线路图。因此为保险起见，应该给这些利益相关人发表意见的机会。一般来说，利益相关人是对机构的问题和隐忧最感同身受的人，因此他们对拟议的解决方案的某些方面会表现出极大的兴趣。他们可能代表着整个公司（例如董事会），也可能只是代表着某个专门团队或者功能部门（如IT、财务团队或者销售和营销团队）中的几个人。

通过直接招募利益相关人参与项目，并从一开始就提炼出他们最关注的问题，以及在整个实施过程中与他们积极合作，SAP项目资助人和SAP项目经理可以更有效地设计和成功实施项目。通过这种方式，由于有了正确的人选从开一始就参与其中并发表真知灼见，项目很可能能够有的放矢地一次性就解决所提出的问题。

如何让利益相关人参与项目没有一定之规。常见的合作方式包括请他们参加项目启动动员会和定期的后续会议，参加具体功能研讨会，以及召开总结会和项目进度会议。定期给利益相关人发送邮件对项目方案、范围、资源等方面变化进行说明的方式也值得提倡。经常沟通通常要比花很多时间提供进展情况更为有效。

使利益相关人能够在某种程度上访问用于跟踪和维持所有业务、功能、项目管理，以及进行技术决策、解决问题、联系信息等细节所使用的数据库也非常重要。由于项目的充分透明，以及让利益相关人感觉获得了认可和“知情权”，项目团队将更有希望构筑和保持成功执行和完成实施SAP这样复杂项目所必不可少的认同感。

在我们总结对业务蓝图设计的讨论之际，您无疑已经注意到了业务蓝图设计是多么严格地从业务视角来审视SAP的。但是，这只是实施SAP的四个重要方面中的一个，其他三个重要方面是功能、技术和项目实施，我们将在后面几页内容中对这些视角进行详细介绍。

由于参与实施、使用和支持SAP的利益相关人类型各异，单一视角永远不可能获得每一个人的共鸣。几乎不可能有人能拥有如此广泛丰富的经验能够掌控整个SAP实施以及其他复杂业务解决方案的复杂度。因此，长期以来的经验证明从其他视角审视如何开发、管理和改进业务解决方案绝对是大有裨益的。

从这种观点看，功能、技术和项目实施角度都是行之有效的视角。对于IT利益相关人来说，从业务、功能要求和项目的角度审视业务解决方案有助于弥补他们的知识空白。通过这种方式，分别从功能角度和更深化的技术角度观察问题之后，再换成端到端的项目实施角度，这就几乎使所有利益相关人都能一窥业务解决方案的全貌了，正如咱们下面将要讨论的。

功能视角是熟悉如何运行业务的人最容易掌握的视角。而对于功能专家意外的人来说又是最难掌握的。这种视角解决的是解决方案的周边环境问题。它处理的问题不是方式、时机或者工具的问题，而是单纯的内容问题。它要回答的问题是“一个业务流程具体要做什么？”

也就是说，功能视角处理以下问题。

以分步的方式描述或说明工作的流程（业务流程的工作步骤）。功能视角会质问对于执行业务流程、实现特定的最终状态来说哪些工作步骤是必不可少的。

描述业务流程展示出的工作性质和工作量。因此，功能视角力求发现每个业务流程反映出的特性和属性，以及反映出它们的程度。

在不考虑技术问题和SAP问题的情况下独立处理这些工作流程和性质问题，恰当的功能透视甚至不会提及 SAP，因为它与应用程序提供商提供的特定解决方案根本不相关。

不难想到，持有这种视角的重要利益相关人是最终用户，他们的日常工作就是执行业务流程。业务流程设计师、同类业务的主管以及其他与解决方案所体现的功能有牵连的人也都是重要的利益相关人。

技术视角处理的是解决方案各个部分的平衡问题。它帮助功能视角主体从技术角度了解业务解决方案是如何通过技术实现的。重要的考虑因素包括以下几方面。

关注系统的关键维度；找出并建立系统提供性能、可用性、可升级性、安全性、敏捷性、可管理性等业务所需特性的方式。

描述解决方案中业务应用方面的所有组件和其他SAP组件、数据和相关的依赖关系、结构要求、底层技术架构，以及所有实现前述功能视角目标所必需底层关系和集成要点。

对技术如何帮助实现功能透视尽可能地提供一个与技术不相关的视角。

技术视角利益相关人主要包括企业和技术构架设计师、解决方案开发人员和程序员、基础设施和其他方面的技术专家，以及其他侧重技术的供应商、出售商和合作伙伴。业务工程师也会发现这种视角非常有用。

项目实施视角很容易理解。它回答的问题是解决方案用什么来建构、需要多长时间，以及利用哪些资源。这种实施视角需要考虑以下方面的问题。

描述和详细制定部属方案，因此需要收集机构和第三方资源、时间期限、约束限制（业务、功能和技术等）等。

描述用以实现公司战略目标和战术功能需求的SAP产品和组件，直到这些需求得到了充分的开发和满足。

一般来说，实施视角利益相关人包括项目经理和协调员、技术专家、开发人员/程序员、测试人员、业务流程拥有人、执行官、业务主管、主要用户等。

设计阶段我们经常遇到的一大诱惑就是倾向于以特定学科领域或专业知识领域来限定具体的视角。显而易见，业务和功能视角可以汇总出业务关注点，而技术视角可能会被看作是“IT”工作，实施视角一般被看作“项目管理”工作。但这些狭隘的偏见应该予以避免，并且应该牢记 SAP 的成功实施取决于公司及其合作伙伴的通力合作。应该打破偏见壁垒、构架跨领域的团队，并且让所有团队都能在整个实施过程中发表独特的见解。这样一来，项目结果将不言自明。

本章中描述的这4种视角结合在一起形成了业务解决方案的目的（什么原因）、功能（什么内容）、技术基础（什么方式）以及实施细节（用什么实现）。把一个解决方案分解成这些视角使公司能够打破业务和技术界限而进行良好的沟通。

但是您可能会注意到，本章并没有对具体的SAP产品和组件进行介绍。这是有充分理由的：在确定具体的ERP解决方案之前，应该先开发出合理有用的业务线路图。根据特定的软件提供商（包括SAP）提供的解决方案来规划线路图就像是没量好具体的身材尺寸就先做衣服一样，是本末倒置而没有任何意义。首先查明业务需求，然后才能确定SAP和其他提供商如何能在应用解决方案空间内最大限度地处理好这些需求。在后面的章节中，我们将讨论从概念性的线路图过渡到公司实施方案、技术平台和功能业务解决方案所不可缺少的SAP具体细节。

本章中概述的概念可以让您为开发高水平的业务线路图做好准备。如果您对SAP的应用程序和技术有更深入的理解，就能稳扎稳打地把公司的业务目标和需求与SAP的应用程序实际结合起来，从而为设计出量身定制的SAP解决方案创造良好的条件。但是在实现这种结合之前，必须要找出业务战略和切实的业务需求，并对其进行优先排序，就其进行良好的沟通。这包括了与提高收益、降低成本、管理改革风险相关的目标和要求。本章中我们还讨论了实现业务敏捷性的重要性，它是公司对自身进行转型以适应业务驱动力变化和经营现实变化的能力。最后，我们对审视业务问题时可能采取的4种高层次的视角进行了考察：业务视角、功能视角、技术视角以及项目实施视角。

请考虑以下与开发 SAP 业务线路图相关的案例分析并回答问题。您可以在附录 A 中找到与此案例分析相关的问题答案。

通过与自己的竞争对手进行对比，MNC发现自己在多个领域都严重落后。MNC的客户基础的重复购买率更低，展现出的产品忠实度也更低，并且维持相似的客户竞争力消耗的成本更高。此外，对于 MNC 的商品来说，商业前景明显越来越倾向于直销模式。他们有机会通过提高能力超越竞争对手，这看似合情合理，因此MNC的董事会获得了前所未有的激励，要去尝试企业资源规划（ERP）实施方案。适逢其时，您被选中参加找出重要的启动切入点的工作。请使用您在本章中学到的知识回答以下问题。

1．鉴于这个ERP项目正处于初期阶段，且具有尝试性的性质，假定他们会选择SAP实现项目，这样做是否审慎？

2．为了帮助团队整合，您建议重新检查MNC已经部分完成的业务线路图。在这张线路图中您希望考察哪4个高层次的领域？

3．对于MNC客户重复购买率低的问题，哪些商业原则最为合适？

4．该工作应该从哪4种视角和角度进行探讨？

5．哪种视角处理的是业务解决方案环境的问题？

6．技术视角具体处理的是哪些问题？

硬件服务器和磁盘基础知识；

操作系统考虑因素；

数据库考虑因素；

传统和现代架构提供商。

经过前面章节的学习，我们已经对SAP的基本概念和使用SAP运行业务的意义有所了解了，现在我们要花一些时间讨论一下更深层的基本技术。本节我们将考察几个常用的与架构相关的技术术语，粗略地了解一下支持任何SAP应用程序都必不可少的3种核心技术：硬件、操作系统和数据库。本章最后我们要讨论一下这些技术是如何发挥作用的。即使您有着深厚的技术背景，本章的内容也仍然值得您花些时间进行了解。

在第2章中，我们已经对业务架构的概念有所涉及。现在，让我们把注意力转向技术架构。业务架构涉及的是逻辑业务流程和工作流程，而技术架构涉及的是用于支持业务流程的底层技术。它用与提供商无关的方式描述了需要整合起来实现某些工作的技术。从我们教学的角度看，硬件、操作系统、数据库和与具体应用相关的技术结合在一起构成了业务应用的实现基础。当建构在这一基础之上的是SAP时，我们把该层面上的技术整合称为“SAP基础”。

我们通常更普遍地把这种技术“堆栈”称为SAP计算平台、解决方案堆栈，或技术堆栈。这些意义相同的术语表述的都是多层技术结合起来的，共同构成了SAP系统的基础。与建设房屋相似，SAP的底层技术就像是房屋的地基。如果地基构建不能坚如磐石，那么SAP系统也就无力抵抗暴风骤雨，满足多变的业务需求、实现用户的预期（SAP最终用户社区）。

我们可以对技术架构的概念进行扩展，把更多内容包含进来，而不仅仅是SAP的基础技术。诸如笔记本电脑、平板电脑、智能手机以及传统的 PC 和打印机等客户端设备在技术架构中的角色十分重要。网络架构的重要性也同样无须赘言，它要把所有设备连接起来——需要无线热点、路由器，甚至旧式的调制解调器，才能让我们“前端”的客户端设备能够与“后端”的应用连接起来。这些前端技术都将在后面的小节中有所涉及。而现在，让我们把注意力集中到SAP之下的核心功能上，从服务器和磁盘开始学习吧。

硬件是SAP系统最基本的组件。硬件由服务器（体积巨大、功能强劲的计算机）、磁盘存储系统（从存储区域网络或网络附加存储，到基于云的虚拟存储空间，种类多样）和网络设备（如路由器、网络交换机以及安全防火墙等）构成。所有这些硬件必须协同工作才能构建成高效的SAP基础架构。如果技术架构设计不正确，或者只是简单地把一些硬件堆积起来搭建成的架构就会连接薄弱、潜在问题多多，从而导致问题接连不断。因此，合理的硬件架构和设计（SAP所谓的术语“适型”（sizing））绝对是至关重要的。

所有的主流硬件提供商都出售规格各异、适合各种类型SAP应用需求的系统。根据声誉和认可度选择硬件合作伙伴不失为一个很好的开始。惠普、IBM以及后起之秀Oracle都是知名的物理硬件提供商，您尽可以选购他们的设备、安装到机架上，搭建起自己的数据中心。但是没有什么东西是永远不变的，流年似水、逝者如斯，今天搭建的硬件平台可能在短短几年后就对新技术望尘莫及了。举例来说，大名鼎鼎的Amazon、Microsoft和思科都可以向您出售用于搭建SAP系统的虚拟化服务器平台。当然，硬件始终是幕后英雄，但这次可是完全在仰仗别人的数据中心。这种被称为基础设施即服务（IaaS）或云架构的虚拟化硬件代表着一种有趣而且经济有效地为SAP提供技术基础的方式。其他许多IaaS云提供商也都在纷纷加入这一行列，这就同时给已经错综复杂的技术架构生态系统添加了更多种多样的方式和实践。

我们将在第19章讨论IaaS和其他云交付方式。而现在，请牢记任何拟议的硬件解决方案，无论提供商是谁，都需要进行相互对比检查，检查 SAP 设计的风险状况，以及最终对比检查 SAP 反映出的工作负荷的种类。毕竟并不是所有的云都成熟到了可以支持任务关键型的 SAP 工作负荷的，同时也不是所有的 SAP 工作负荷对业务运行来说都必不可少。

无论您的SAP服务器硬件是物理安装或者运行在自己的数据中心里，还是托管给了传统的外包提供商或更时兴的云提供商，服务器一般都还是根据成本和性能进行分类。有趣的是这些分类现在相互重叠得非常严重。行业内现在还在按大、中、小型划分服务器（见图3.1），物理尺寸和“马力”（按SAPS测量，在“SAPS基准”一节将会讲到）都适用。使大、中、小型的界限更加模糊的是今天许多小型服务器也可以承载SAP工作负荷了，这在几年前还被认为只有大型服务器才能做到。

根据规格和配置不同，如果上网购买一台惠普服务器，一次性的投入可能会从几千美元到数百万不等（还不包括之后的日常维护费用，这笔费用也非常可观）。另一方面，根据云提供商不同，在云中租用相同的服务器计算能力需要的每小时成本从几美分到几百美元不等。成本变成了“计时付费”（pay-as-you-go）的形式，从一次性的资本投资（CAPEX）变成了重复性的运行支出（OPEX）。对“斤斤计较”的人来说，这种变化可能颇具吸引力。

服务器和其他SAP架构的成本会发生明显的变化，但是公司必须处理好五花八门的财务方式，才能计算出哪种方式对他们来说最适用。但是您如何对比运行着不同操作系统和数据库的不同服务器支持的工作负荷（例如计算平台的马力）呢？对于服务器来说，马力是许多因素的结合体。除了种种操作系统和数据库差异之外，CPU以及底层处理器核心的数量和速度、每台服务器中的内存量、服务器系统总线的特性，以及许多其他内部服务器构架的具体情况都是不可忽略的因素。简单的对比几乎不可能。幸运的是，SAP为我们提供了一个测量工作负荷的标准单位：SAPS基准。

SAP应用程序性能标准（SAPS）会对SAP基准计算平台进行相互对比。测量的标准单位与事务处理委员会（TPC）提供更一般性的 tpmC 性能定级相似，测量的 SAPS 单位基于SAP 企业资源处理（ERP）的销售和分销（SD）模块，是目前最流行的 SAP 基准。100 个SAPS定义为每小时完全处理2000份端到端订单（每份订单包含5个售出的单项产品）。驱动这种基准的SD业务流程由6种不同的SD事务构成。最终，这2000份订单相当于6000次屏幕变化（从创建订单到显示、开具发票等）！

让我们思考一下SAPS的价值。凭借标准的测量单位，您可以对大相径庭的计算平台以公平合理的方式进行对比。假定所有的硬件提供商对运行着各种操作系统和数据库的各种服务器都采用一种基准，那么您就可以安心地假定一个特定平台之间的马力是可以相互比较的。例如，您可以将运行着Windows系统和SQL Server数据库的服务器与相似配置的运行着Linux系统和Oracle数据库的服务器的SAPS进行对比，然后再与运行着AIX系统和DB2数据库的IBM p系列服务器进行对比。通过公平对比，您可以减轻SAP性能方面的相关风险，而把注意力集中到可用性策略、总拥有成本和战略合作或整合计划上来。而对于没有进行过基准测试的服务器，您可以与硬件提供商的SAP研发中心合作计算出该平台能够支持的大概SAPS指标。

要检验我们提供信息的有用性，请用浏览器访问 www.sap.com/solutions/benchmark/sd2tier.epx。最常见的是双层基准（因为这种基准不至于运行成本过高而使硬件提供商无法承受）。为举例说明，请单击SAPS列，对所有结果进行分类（结果数量成百上千）。向后翻页，直到您可以对能够支持 50000 SAPS 的各种服务器型号和配置进行对比的一页。您很容易发现，尽管不是所有的硬件、操作系统和数据库组合都应有尽有，筛选结果还是很多，需要查看许多不同提供商的产品。如果您对此特别感兴趣，请注意最新的4P/32C（4处理器、每个处理器8个核芯）Intel平台与仅仅几年前还不可一世的庞然大物32P甚至更大型的服务器相比优势是多么突出！

无论您的服务器是虚拟服务器、托管给了 Computer Sciences Corp 或我本人最偏爱的Freudenberg IT 这样的第三方公司，还是安装在您自己的数据中心里，物理服务器本身都是由为数不多的几个硬件提供商制造的。知名度最高的提供商富士通、惠普、IBM、Oracle和Unisys销售的服务器通常都是基于他们自己专利的CPU，或者Intel和AMD。IBM就是一个很好的例子。他们拥有阵容强大的行业标准服务器产品（x系列），以及拥有专利权的基于PowerPC的服务器（p系列）和一些更老式的传统平台（i系列和z系列）积极参与市场竞争。惠普和Oracle的产品同样种类繁多。

Intel和AMD生产的低成本CPU（通常统称为商用、x86或x64平台）构成了该市场中的主流。商用服务器规格多样，一直以来为IT部门提供了丰富的选择——从密集型的刀片服务器、细长的“披萨盒”设计，到更传统的机架式和独立大型箱式设计，可谓千差万别。而且它们的增长速度在逐年加快。但即使这些商用服务器一直在价格和性能上不断突破，硬件提供商也还是在持之以恒地开发着自己的具有高可用性、虚拟化等特点的新技术解决方案，力图凭借自己的专利权、传统上一直能力出众的合作伙伴为自己的产品争取一席之地。

在为SAP系统购买服务器和相关硬件时，即使要多支付一些费用，为了实现平台的高可用性也应该不吝投入。大多数服务器都提供冗余电源、冗余内存，以及能够在多块磁盘驱动器间平移数据的磁盘控制器，并且支持多种网络接口卡（NIC），以便能够在网段、网络交换机或者单个网卡发生故障时方便地解决问题。这些技术可以有效地提高您SAP解决方案的整体正常运行时间（尽管有人可以争辩说随着购买的服务器越来越多，相对的成本增加也很显著）。

服务器网络也应该配置成冗余的形式。在许多IT数据中心里，网络都是一个重要的（虽然是可避免的）单点故障源。采用双交换机或者使用前面提到的冗余NIC可以消除或者降低可能造成重大故障的危险。当然，这些NIC和交换机都必须妥善、专业地进行安装、连接和配置才能真正提高可用性。

一般来说知名的服务器硬件提供商也都出售磁盘存储系统（一般可以容纳多个磁盘驱动器）。与虚拟化服务器的计算能力一样，您也可以购买基于云的虚拟化存储服务。无论采用哪种方式，该系统都需要能够存储SAP数据库、SAP安装的二进制文件或可执行文件，以及所有与安装的操作系统相关的文件。所有存储工作都会涉及的两个关键需求是速度和可用性。

目前最强大、性能最高的磁盘子系统称为存储区域网络（SAN），它包含有一个或多个装有几十到几百块物理磁盘的机柜，所有磁盘都通过被称为主机总线适配器（HBA）的专门的 SAN I/O 卡连接到 SAP 的数据库服务器上。SAN 的速度非常快，可以由多个应用程序共享。实际上，SAN通常也被称为共享存储。目前的大多数SAP系统都是用SAN作为自己的基本磁盘存储系统。

SAP系统还有可能会使用网络附加存储（NAS）系统，这种系统成本更便宜，当然一般来说相应的能力也会稍逊一筹。与SAN相似，NAS设备也都通过安装在数据服务器上的接口卡连接到数据库上。NAS 设备使用标准的 NIC 而不是 HBA。这些 NIC 可以是同型号的NIC，这种网络可以由SAP应用服务器和其他应用程序共享。由于这种网络会相当繁忙，因此连接到这种网络上的NAS设备会出现SAN环境中没有的反应迟缓现象。

为SAP系统采用直接附加存储系统的情况目前还很少见。这种磁盘解决方案可能只是把几块磁盘驱动器装到一个数据库服务器中就算完成了。另外一些情况也可能是用能够容纳几块到也许最多24块磁盘的小型机柜直接连接到每个SAP数据库服务器上。小型的IT部门可能会觉得这种方式可用，因为直接附加存储设备一般速度会比较快，而且成本也很低。当然，随着SAP组件（企业资源规划[ERP]程序、客户关系管理[CRM]程序、产品生命周期管理程序[PLM]等）和情景（生产、测试、开发、数据移动、培训、沙盘等）的增多成本会急剧攀升。

为SAP提供存储空间的最新方式是基于云的磁盘空间提供方式。Amazon、Microsoft和Rackspace 等提供商都在出售虚拟化存储空间，价格大概为每吉字节几美分。尽管以任何标准衡量这都很便宜，但云存储面临的最大挑战是性能：活跃的SAP数据库每秒钟要处理千千万万次I/O操作，而云存储（除少数例外之外）是要通过网络链接（可能快似闪电，也可能慢慢吞吞）来访问的。您购买的虚拟存储服务有可能能够满足您的SAP数据库需求，因此您需要咨询SAP专家，以便了解到足够的信息，从而向您的存储服务提供商解释清楚自己的系统需求。从现实角度考虑，对于沙箱和演示系统来说可以很方便地使用虚拟化存储。（或者在云内租赁整个系统，特别是那些我们将在第21章说明的对改进生产流程作用不大的系统。）您需要花更多时间分析需求和设计合理的存储解决方案的是其他一些系统，特别是生产相关的SAP系统。最终，您可能会对一些非生产性的系统使用云存储，而对生产和生产支持环境使用传统的本地SAN或NAS存储设备。

无论您的磁盘空间来源于哪里，提供商都会不遗余力地推销和出售中、低、高各档磁盘存储系统。需要记住的最主要的衡量标准是存储配置能够支持的每秒I/O操作次数，以及能够流过设备的每秒若千兆字节的吞吐量指标。在众多的因素中，关键指标包括磁盘旋转轴的速度和数量，以及二级缓存（用于存储最近访问和频繁访问的数据从而避免磁盘I/O操作相对变慢的存储器）。在谈到性能时，磁盘空间本身并不成其为问题，但是在处理SAP启动和每个月的磁盘增长需求时，它就显得非常重要了。许多SAP系统每个月要增长10GB到20GB，一个月增长500GB也并不是闻所未闻！

尽管性能至关重要，但磁盘子系统正常工作时间（或称可用性）的重要性也不在其次。传统上来说，高等级的可用性可以通过硬件冗余配置和部属多套软件解决方案来实现。这种设计可以消除或至少把出现单点故障的可能性降到最低。最低限度您的SAP存储系统也应该支持与数据库服务器实现冗余连接——冗余HBA（针对SAN）、NIC（针对NAS或云存储）或者磁盘控制器（针对直接附加存储）。接下来，您的磁盘系统应该配置成能够承受单块磁盘故障。将便宜（或独立）磁盘组合成冗余阵列或 RAID 配置可以消除与磁盘相关的 SPOF。如表3.1所示，RAID分为几种类型，每一种在成本、可用性和性能上的平衡方式都不同。

软件解决方案也可以提高磁盘存储系统的可用性。高端的 SAN 一般都支持先进的远距离复制技术，它对于实现灾难恢复极为有用。请一定对这种能力加以重视：远程互连的SAN之间相互复制数据的能力或动态生成SAP数据库“快照”的能力在许多方面都非常有用，包括可以帮助实现系统快速备份，对系统进行克隆以便进行离线测试和培训，在发生灾难事件时为实现灾难恢复和业务不间断提供支持等。

从我们学习的角度来说，操作系统（OS）是一种特殊的软件，它使诸如数据库、SAP这样的应用程序能够使用计算机的处理能力、内存、磁盘、文件和网络连接以及其他资源。OS是硬件和应用程序进行交互的中间人。诸如 Microsoft Windows Server、Red Hat 和 SUSE Linux以及许多 UNIX 的派生版（HP-UX、IBM AIX、Oracle Solaris等）等的操作系统都是当今的SAP环境中常见的系统。偶尔您还可以看到一些老版本的SAP运行在OS/400和z/OS操作系统上，它们分别运行在IBM的i-series和z-series大型机上。有意思的是，SAP首先会在Windows和Linux平台上开发新组件，这是早期采用SAP的用户非常重视的一点。

在经过多年波澜不惊的相对稳定之后，OS 市场目前正在发生显著的变化。在商用服务器市场上，强大的64位技术已经让许多传统的基于UNIX的SAP提供商开始重新考虑自己的战略，并向Windows和Linux迁移。而更有意思的是，更前沿的云技术已经崭露头角，如Microsoft 的Azure 和 VMware 的 vShere4可以提供更新的能力、灵活弹性的收费模式，这就为用户带来了更多选择。在选择 OS 时，您需要考虑该 OS 是否有能力支持构建灵活、敏捷的SAP计算平台。然后，要了解一下该OS提供商是否与SAP建立了战略合作关系，您的公司或IT部门与该提供商的关系，以及您公司本身的IT技能储备和IT部门是否有能力高效地采用新技术。

所有的OS生来都各具特色。OS的特点主要在于其计算平台或服务器支持方式、支持的物理和虚拟内存的大小、灾难恢复功能、补丁管理以及安全和防病毒保护能力。先进的集群功能也非常重要。我们需要考虑OS内置的管理和配置工具，以及对第三方工具的需求程度。第三方实用程序，如监视应用程序、病毒扫描程序包以及备份软件，都必不可少地需要投资购买，但是您必须首先对它们的有效性进行验证，在我们需要它们的同时，它们也确实能够与SAP、底层数据库和文件系统，以及整个计算平台协调配合、物尽其用。

从OS的角度看，SAP只是一套能够把用户与数据和应用逻辑连接起来的可执行程序和库。为了实现这一点，SAP 会在 OS 之上运行许多服务和进程。UNIX 和 Linux OS 会把它们的SAP二进制文件、日志文件、配置文件和库存储在一个名为/usr/sap的目录中；而Windows会把SAP文件存储在x:\usr\sap文件夹里。在UNIX和Linux系统中，/sapmnt安装成NFS（网络文件系统），而把/usr/sap/<SID>作为本地文件系统。在Windows中，x:\usr\sap目录共享为SAPMNT，可以用\\servername\sapmnt 来访问。对于只在一套 OS 上运行多个 SAP 实例的Windows服务器来说，所有的SAP实例都必须安装到SAPMNT目录中；只有一个SAPMNT能够共享。

但是我们强烈推荐您选择另一种方式，它是一种称为SAPOSCOL的服务，会运行在OS收集器，使SAP能够收集与OS相关的性能和其他统计数据，如CPU利用率、内存利用率、磁盘I/O活动等。还有一种Windows被称为SAPService<SID>（其中<SID>是SAP实例的系统标志符），OS 上的每个 SAP 实例都会带一个 SAPService<SID>。该服务随可执行程序sapstartsrv.exe启动。它会调用SAP启动配置文件，而SAP启动配置文件会告诉系统如何启动SAP。

术语“SAP系统”在操作系统层面上才有意义。一个SAP系统是指容纳着一个支持单一系统标志符（SID）的SAP单个数据库的单个系统或多系统集合。例如，一个名为SAP企业资源规划（ERP）生产系统由一个数据库、一个核心服务（二进制文件或可执行文件）以及1～100任意数量的应用服务器实例构成（最常见的是2～10个，这取决于需要支持的工作负荷和每个物理服务器的能力）。一个SAP实例（或安装）就是一个已安装的组件。这些实例相结合就构成了一个 SAP ERP 生产系统。与之相似，您可以配置另一套 SAP 实例，来构建一个SAPCRM生产系统。

SAP 使用 OS 来运行8种工作进程，如表 3.2 所示。您有时候会发现它们被统称为DVEBMSG。其中，“D”表示对话框工作流程；“V”表示更新工作流程（通过V1、V2优先级、指定版本来区分）；“E”表示队列；“B”为后台或批处理任务；“M”为消息服务；“S”用于表示假脱机打印；“G”代表SAP网关。每个SAP实例的实例配置文件描述了每种流程中有多少个会随着系统一起启动（实例配置文件是一种存放在系统上的简单的文本文件，我们将在“OS级SAP配置文件”一节中对其进行讨论）。您可以看到您的OS正在通过执行特殊的每种OS各不相同的实用程序，或者通过使用SAP自己的事务SM50和SM66运行哪种工作流程。尽管我们在不断进步，但看到SAP工作流程状态的能力对我们来说仍然是必不可少的：除了显示系统的工作负荷，根据每种工作流程的工作内容，它还可以实时地显示实例和整个系统的状态。SM50 只能为您展示单个应用服务器的工作流程，而 SM66 使您可以全局性地审视整个SAP系统上运行的每个活动工作流程的状态。

每种SAP实例都包含三种配置文件：默认配置文件、启动配置文件和实例配置文件。配置文件是文本文件，由SAP数据库导入并进行维护，用于启动和运行实例。默认配置文件包含了特定SAP系统中所有SAP实例的公共信息。例如，生产系统可能会包含一个数据库、核心实例和6台应用服务器；而所有这些实例都使用一个相同的默认配置文件。启动配置文件可以调用可执行程序启动SAP，在这方面每个实例也都基本相似。最后，实例配置文件详细包含了每个实例的具体信息。在包含有两个应用服务器的实例配置文件中，您可以定义一簇批处理工作流程（例如，创建批处理服务器）。其他具体实例的详细信息可能会包含具体的内存配置参数、缓存设置等。使用SAP事务RZ10可以修改和维护所有这些配置文件，并可以访问一个包含了所有可用配置文件参数的简表。

掌握了硬件和操作系统的知识细节之后，现在我们可以把注意力转到在下层支持SAP业务应用的数据库了，看看它所承担的角色。在选择数据库时，还应像选择硬件平台和 OS 时一样慎重挑选。鉴于平台和 SAP 版本限制，您可能只有一两种数据库可选（这就凸显了把SAP基础设施作为一个整体计算平台加以考虑的重要性）。主流的数据库SAP均能支持，包括 Microsoft SQL Server（最终将可以搭配 SQL Azure 使用）、IBM DB2 和多种 Oracle数据库产品。SAP自己本身也有名为MaxDB的数据库，它的发展非常有意思，目前一般来说只有小型系统才会使用。SAP在2010年收购了Sybase，现在它已经在向原来的Sybase客户宣传，它在将来的某个时间将会向基于SAP-on-Sybase数据库平台提供有限支持。

Microsoft SQL Server 只能运行在基于 Windows 的操作系统上。对能运行在 Windows、Linux和所有主要UNIX操作系统上的Oracle，SAP均能支持。DB2获得的支持更广泛一些，因为它运行在IBM的传统大型机系统上。

大多数部署SAP的IT部门都会根据他们当前支持的平台以及自己对各种平台的经验和熟悉程度来选择数据库提供商和数据库版本。但是这可能是在犯一个代价高昂的错误，因为大量由数据库管理员（DBA）来完成的传统工作在SAP环境中根本就不必要。这就是说，SAP会把大量管理和维护底层数据库的复杂工作“剥离”掉。因此，鉴于各种数据库具有相似的性能、可升级特性和差异巨大的定价模式，请一定要对 Oracle、SQL Server和 DB2 予以考虑。

除了价格，还应考虑每种数据库的高可用性方案。集群、镜像和快照，或克隆能力都是重要的区别点。其他选项也很有用，比如日志传送（log shipping）就会为灾难恢复提供支持。

无论您选择哪种数据库，像SAP这样的企业应用归根结底都是由程序和这些程序创建和使用的数据构成的，而数据库要做的就是将这些数据以一种有意义的方式组织起来，使程序能够快捷方便地访问和查找它们，从而完成需要这些数据才能完成的有用工作，例如运行财务报表或创建销售订单。对于大多数SAP组件来说（如ERP），程序和数据会存放在同一个数据库中。

各种组件一般都需要有自己的数据库（尽管有少数例外）。例如，由 SAP ERP、SAP NetWeaver企业门户（EP）和 SAP CRM 构成的“生产环境”包含有3个不同的生产数据库。在每个SAP系统中，数据库都担当着重要的角色，因为SAP组件和应用程序使用的所有数据都存放在数据库里。最简形式的数据库由表、列（称为字段）和行（称为记录或数据）构成。数据库的基本结构与 Microsoft Excel 这样的电子表格的概念十分相似，其中用列存放一行一行的记录（数据）。数据库与电子表格最大的区别只是数据库可以包含多张（同时也是极大的）表，而这些表通过关系相互关联。因此，数据库可以被看作是一种复杂度更高而且极其有用的电子表格。

SAP 数据库可以包含千千万万个存储着信息的表。有些产品，如 ERP，可以包含超过40000 张表；而复杂度稍弱的系统，如 SAP NetWeaver Process Integration（PI）包含的表可能不到10000张。请注意，在大多数SAP系统中，10%的表容纳了90%的数据，因此，某些表的体积会变得硕大无比而且变化无常，而另一些则善于保持体形，而且相对来说更加静态。但无论如何，所有这些表都是通过既定关系相互绑定在一起的。而正是这套相互连接的表创建了所谓的关系数据库管理系统（RDBMS）。

除了容纳原始数据，数据库还会存储索引，索引用于帮助提高检索数据的速度。对索引的最佳描述是一个内容表，或者把它看作是缩减成了几个关键字段的一个数据库表的副本。这种缩减版副本中的数据根据一些预定义标准进行存储，以便能够快速访问数据。并非所有副本表的字段都会进入索引，而索引会包含有一个指针，指向实际表的相关记录。可能会让您大吃一惊的是，索引的体积大约会占到整个SAP数据库体积的50%！

SAP 还使用另一种被称为透明表的概念，它是一种只在运行时刻包含数据的 SAP 数据表。当ABAP/4数据字典中的表被激活时，系统会自动创建一个透明表。这种透明表与您在ABAP/4 数据字典中的数据库表同名。它的每个字段也都与相应的数据库字段同名，但是字段的顺序可能会不同。字段顺序变化使新字段可以插入到表中，而不必对其进行转换，从而能够加快运行时刻的数据访问速度。

最后，对数据结构有所了解也非常重要。您只需记住数据结构是一组逻辑上有隶属关系的内部字段即可。数据结构要在 SAP ABAP/4 数据字典中激活和定义，它们只是临时包含数据（在程序执行过程中）。数据结构与数据库表的区别主要有以下3方面。

结构不包含或反映相关的ABAP/4数据字典表。

结构不包含主键。

结构没有任何技术特征，例如类、大小、范畴或缓冲规格等。

本章内容覆盖了SAP基础架构的重要组件：硬件、操作系统和数据库。除了为SAP搭建基本架构或计算平台的传统方法，我们还考察了用服务方式提供这种基本架构的新方法。我们讨论了如果挑选合作伙伴和提供商，并与他们紧密合作，为SAP构建性能良好的计算平台。

请阅读本章案例，并利用您刚刚学到的硬件、操作系统和数据方面的知识分析和处理下面的问题。您可以在附录A中找到与此案例分析相关的问题答案。

您的雇主 MNC 公司在 Microsoft Windows 和 SQL Server 系统上运行着最新版的 SAP 应用。最近MNC收购了Archaic制造公司（AMI），这是MNC的一大竞争对手，它也分别在运行着Oracle和DB2数据库的UNIX和大型机平台上运行着最新版的SAP应用程序。MNC希望根据自己的IT成本削减策略，将两个公司之间相似的系统进行整合。尽管据说AMI的SAP IT 成本要远远高于 MNC，但系统构架团队还是不认为简单地改变平台就能够降低整个SAP基础设施的成本。在MNC首席财政官（CFO）的领导下，该团队对从IT资本支出预算上削减附加成本给予了特别的关注。

作为团队中的一名技术架构设计师，您已经找出了4种备选方案。第一种方案是一切保持原样，由每个团队支持各自的系统。第二种方案是该团队把所有的硬件和其他设备都整合到单一的公共数据库中。第三种方案是对计算平台进行标准化。第四种方案是团队购买某种采用云技术的策略。假定您拥有必要的途径、资源和时间实现其中任意一种方案，请回答以下问题。

1．请找出第一种方案“一切保持原样”的主要优点。

2．试列举“一切保持原样”的几种缺点和问题。

3．第二种方案“把现有资产整合到唯一的公共数据库中”如何？能够证明它有优势吗？

4．请列举对计算平台进行标准化的若干优点。

5．如果 AMI 的生产格局包括 SAP ERP、CRM 和 PLM，而且它们每个都包含有4个实例，则AMI目前支持着多少个生产系统？

6．团队应如何处理CFO的要求？

SAP入门经典：第4版/（美）安德森（Anderson, G. W.）著；刘扬译.--北京：人民邮电出版社，2012.8

ISBN　978-7-115-28821-9

Ⅰ.①S…　Ⅱ.①安…②刘…　Ⅲ.①应用软件—介绍　Ⅳ.①TP317

中国版本图书馆CIP数据核字（2012）第144351号

本书中文简体字版由美国Sams出版公司授权人民邮电出版社出版。未经出版者书面许可，对本书任何部分不得以任何方式复制或抄袭。

SAP入门经典（第4版•修订版）

图书目录:

详情

图书摘要

相关图书

相关文章

相关课程