David's Untitled Life

从MCOD/Central Instance开始乱弹

Wed, 23 Dec 2009 08:14:08 +0000

企业的系统架构正在变迁。以前是一个个单独的小系统，之后当业务变得复杂的时候，企业引入了越来越多的解决方案，为了避免解决方案之间成为信息孤岛，各种作为proxy和集成器的中间件应运而生，系统似乎不是分布式的，都不好意思跟人打招呼。而当企业的信息系统变得更加复杂的时候，似乎应该回归到一个中央访问点的时候了。

从SAP对DB的MCOD（Multiple Components in One Database）的DB layout的支持，到近期三星电子的全球性single instance实施的上线——从此三星将运行世界上最大的单一实例的ERP系统。

也许，底层软件和硬件的支持应该继续分布式，继续云下去，可是构架在此之上的业务软件，应该越不分布越好。否则，系统的维护将慢慢变得不可能。

---------

MCOD at a Glance

Kehinde Eseyin (Systems Support Manager) posted 4/27/2009 | Comments (1)

Definition
MCOD is an acronym for Multiple Components in One Database.
With MCOD, SAP Netweaver components are installed and managed in a single database. Individual system data is isolated in the database. Every system application runs as if they were installed separately

Features and Benefits
Single logical and physical database instance
Reduction in the number of databases to administer
Optimizing of licensing for database and database management tools
Flexibility in change management and maintenance as result of componentization of systems
Ease of database and system maintenance (patching) because all system uses the same release of database.
Individual systems can be upgraded independently of the other system
Independent tuning and administration of systems
Synchronized backup and restore strategy for all MCOD systems is possible.

Administrative Challenges and considerations

Duplication of maintenance and support effort for multiple applications
Single point of failure
High availability solution cost
High system resources and consumption need

ERP的发展历程

Mon, 19 Mar 2007 13:21:30 +0100

Copy from http://www.ccw.com.cn/htm/net/erp/door/01_10_29_4.asp

七十年代闭环MRP

60年代时段式MRP能根据有关数据计算出相关物料需求的准确时间与数量，但它还不够完善，其主要缺陷是没有考虑到生产企业现有的生产能力和采购的有关条件的约束。因此，计算出来的物料需求的日期有可能因设备和工时的不足而没有能力生产，或者因原料的不足而无法生产。同时，它也缺乏根据计划实施情况的反馈信息对计划进行调整的功能。

正是为了解决以上问题，MRP系统在七十年代发展为闭环MRP系统。闭环MRP系统除了物料需求计划外，还将生产能力需求计划、车间作业计划和采购作业计划也全部纳入MRP，形成一个封闭的系统。

1．闭环MRP的原理与结构

MRP系统的正常运行，需要有一个现实可行的主生产计划。它除了要反映市场需求和合同订单以外，还必须满足企业的生产能力约束条件。因此，除了要编制资源需求计划外，我们还要制定能力需求计划(CRP)，同各个工作中心的能力进行平衡。只有在采取了措施做到能力与资源均满足负荷需求时，才能开始执行计划。

而要保证实现计划就要控制计划，执行MRP时要用派工单来控制加工的优先级，用采购单来控制采购的优先级。这样，基本MRP系统进一步发展，把能力需求计划和执行及控制计划的功能也包括进来，形成一个环形回路，称为闭环MRP，如图1示。

图1 闭环MRP逻辑流程图

因此，闭环MRP则成为一个完整的生产计划与控制系统。

2．能力需求计划(Capacity Requirement Planning, CRP)

（1）资源需求计划与能力需求计划

在闭环MRP系统中，把关键工作中心的负荷平衡称为资源需求计划，或称为粗能力计划，它的计划对象为独立需求件，主要面向的是主生产计划；把全部工作中心的负荷平衡称为能力需求计划，或称为详细能力计划，而它的计划对象为相关需求件，主要面向的是车间。由于MRP和MPS之间存在内在的联系，所以资源需求计划与能力需求计划之间也是一脉相承的，而后者正是在前者的的基础上进行计算的。

（2）能力需求计划的依据

①工作中心：它是各种生产或加工能力单元和成本计算单元的统称。对工作中心，都统一用工时来量化其能力的大小。

②工作日历：是用于编制计划的特殊形式的日历，它是由普通日历除去每周双休日、假日、停工和其它不生产的日子，并将日期表示为顺序形式而形成的。

③工艺路线：是一种反映制造某项"物料"加工方法及加工次序的文件。它说明加工和装配的工序顺序，每道工序使用的工作中心，各项时间定额，外协工序的时间和费用等。

④由MRP输出的零部件作业计划。

（3）能力需求计划的计算逻辑

闭环MRP的基本目标是满足客户和市场的需求，因此在编制计划时，总是先不考虑能力约束而优先保证计划需求，然后再进行能力计划。经过多次反复运算，调整核实，才转入下一个阶段。能力需求计划的运算过程就是把物料需求计划定单换算成能力需求数量，生成能力需求报表。这个过程可用图2来表示。

图2 能力需求报表生成过程

当然，在计划时段中也有可能出现能力需求超负荷或低负荷的情况。闭环MRP能力计划通常是通过报表的形式(直方图是常用工具)向计划人员报告之，但是并不进行能力负荷的自动平衡，这个工作由计划人员人工完成。

3．现场作业控制

各工作中心能力与负荷需求基本平衡后，接下来的一步就要集中解决如何具体地组织生产活动，使各种资源既能合理利用又能按期完成各项订单任务，并将客观生产活动进行的状况及时反馈到系统中，以便根据实际情况进行调整与控制，这就是现场作业控制。它的工作内容一般包括以下四个方面：车间定单下达：定单下达是核实MRP生成的计划订单，并转换为下达定单。

作业排序：它是指从工作中心的角度控制加工工件的作业顺序或作业优先级。

投入产出控制：是一种监控作业流(正在作业的车间定单)通过工作中心的技术方法。利用投入/产出报告，可以分析生产中存在的问题，采取相应的措施。

作业信息反馈：它主要是跟踪作业定单在制造过程中的运动，收集各种资源消耗的实际数据，更新库存余额并完成MRP的闭环。

八十年代的MRPII

闭环MRP系统的出现，使生产活动方面的各种子系统得到了统一。但这还不够，因为在企业的管理中，生产管理只是一个方面，它所涉及的仅仅是物流，而与物流密切相关的还有资金流。这在许多企业中是由财会人员另行管理的，这就造成了数据的重复录入与存贮，甚至造成数据的不一致性。

于是，在八十年代，人们把生产、财务、销售、工程技术、采购等各个子系统集成为一个一体化的系统，并称为制造资源计划（Manufacturing Resource Planning）系统，英文缩写还是MRP，为了区别物流需求计划（亦缩写为MRP）而记为MRP II。

1．MRPⅡ的原理与逻辑

MRPⅡ的基本思想就是把企业作为一个有机整体，从整体最优的角度出发，通过运用科学方法对企业各种制造资源和产、供、销、财各个环节进行有效地计划、组织和控制，使他们得以协调发展，并充分地发挥作用。

MRPⅡ的逻辑流程图如图1所示。

图1 MRPⅡ逻辑流程图

在流程图的右侧是计划与控制的流程，它包括了决策层、计划层和控制执行层，可以理解为经营计划管理的流程；中间是基础数据，要储存在计算机系统的数据库中，并且反复调用。这些数据信息的集成，把企业各个部门的业务沟通起来，可以理解为计算机数据库系统；左侧是主要的财务系统，这里只列出应收帐、总帐和应付帐。各个联线表明信息的流向及相互之间的集成关系。

2．MRPⅡ管理模式的特点

MRPⅡ的特点可以从以下几个方面来说明，每一项特点都含有管理模式的变革和人员素质或行为变革两方面，这些特点是相辅相成的。

1．计划的一贯性与可行性

MRPⅡ是一种计划主导型管理模式，计划层次从宏观到微观、从战略到技术、由粗到细逐层优化，但始终保证与企业经营战略目标一致。它把通常的三级计划管理统一起来，计划编制工作集中在厂级职能部门，车间班组只能执行计划、调度和反馈信息。计划下达前反复验证和平衡生产能力，并根据反馈信息及时调整，处理好供需矛盾，保证计划的一贯性、有效性和可执行性。

2．管理的系统性

MRPⅡ是一项系统工程，它把企业所有与生产经营直接相关部门的工作联结成一个整体，各部门都从系统整体出发做好本职工作，每个员工都知道自己的工作质量同其他职能的关系。这只有在"一个计划"下才能成为系统，条块分割、各行其是的局面应被团队精神所取代。

3．数据共享性

MRPⅡ是一种制造企业管理信息系统，企业各部门都依据同一数据信息进行管理，任何一种数据变动都能及时地反映给所有部门，做到数据共享。在统一的数据库支持下，按照规范化的处理程序进行管理和决策。改变了过去那种信息不通、情况不明、盲目决策、相互矛盾的现象。

4．动态应变性

MRPⅡ是一个闭环系统，它要求跟踪、控制和反馈瞬息万变的实际情况，管理人员可随时根据企业内外环境条件的变化迅速作出响应，及时决策调整，保证生产正常进行。它可以及时掌握各种动态信息，保持较短的生产周期，因而有较强的应变能力。

5．模拟预见性

MRPⅡ具有模拟功能。它可以解决"如果怎样��将会怎样"的问题，可以预见在相当长的计划期内可能发生的问题，事先采取措施消除隐患，而不是等问题已经发生了再花几倍的精力去处理。这将使管理人员从忙碌的事务堆里解脱出来，致力于实质性的分析研究，提供多个可行方案供领导决策。 6．物流、资金流的统一

MRPⅡ包含了成本会计和财务功能，可以由生产活动直接产生财务数据，把实物形态的物料流动直接转换为价值形态的资金流动，保证生产和财务数据一致。财务部门及时得到资金信息用于控制成本，通过资金流动状况反映物料和经营情况，随时分析企业的经济效益，参与决策，指导和控制经营和生产活动。

以上几个方面的特点表明，MRPⅡ是一个比较完整的生产经营管理计划体系，是实现制造业企业整体效益的有效管理模式。

九十年代的ERP系统

进入90年代，随着市场竞争的进一步加剧，企业竞争空间与范围的进一步扩大，80年代MRPⅡ主要面向企业内部资源全面计划管理的思想逐步发展为90年代怎样有效利用和管理整体资源的管理思想，ERP（Enterprise Resource Planning）��企业资源计划也就随之产生。ERP是在MRP-Ⅱ的基础上扩展了管理范围，给出了新的结构。

1．ERP同MRPⅡ的主要区别

在资源管理范围方面的差别

MRP II主要侧重对企业内部人、财、物等资源的管理，ERP系统在MRP II的基础上扩展了管理范围，它把客户需求和企业内部的制造活动、以及供应商的制造资源整合在一起，形成企业一个完整的供应链并对供应链上所有环节如订单、采购、库存、计划、生产制造、质量控制、运输、分销、服务与维护、财务管理、人事管理、实验室管理、项目管理、配方管理等进行有效管理。在生产方式管理方面的差别

MRP II系统把企业归类为几种典型的生产方式进行管理，如重复制造、批量生产、按订单生产、按订单装配、按库存生产等，对每一种类型都有一套管理标准。而在 80年代末、90年代初期，为了紧跟市场的变化，多品种、小批量生产以及看板式生产等则是企业主要采用的生产方式，由单一的生产方式向混合型生产发展， ERP则能很好地支持和管理混合型制造环境，满足了企业的这种多角化经营需求。

在管理功能方面的差别

ERP除了MRP II系统的制造、分销、财务管理功能外，还增加了支持整个供应链上物料流通体系中供、产、需各个环节之间的运输管理和仓库管理；支持生产保障体系的质量管理、实验室管理、设备维修和备品备件管理；支持对工作流（业务处理流程）的管理。

在事务处理控制方面的差别

MRP II是通过计划的及时滚动来控制整个生产过程，它的实时性较差，一般只能实现事中控制。而ERP系统支持在线分析处理OLAP（Online Analytical Processing）、售后服务即质量反馈，强调企业的事前控制能力，它可以将设计、制造、销售、运输等通过集成来并行地进行各种相关的作业，为企业提供了对质量、适应变化、客户满意、绩效等关键问题的实时分析能力。

此外，在MRP II中，财务系统只是一个信息的归结者，它的功能是将供、产、销中的数量信息转变为价值信息，是物流的价值反映。而ERP系统则将财务计划和价值控制功能集成到了整个供应链上。

在跨国（或地区）经营事务处理方面的差别

现在企业的发展，使得企业内部各个组织单元之间、企业与外部的业务单元之间的协调变得越来越多和越来越重要，ERP系统应用完整的组织架构，从而可以支持跨国经营的多国家地区、多工厂、多语种、多币制应用需求。

在计算机信息处理技术方面的差别

随着IT技术的飞速发展，网络通信技术的应用，使得ERP系统得以实现对整个供应链信息进行集成管理。ERP系统采用客户/服务器（C/S）体系结构和分布式数据处理技术，支持Internet/Intranet/Extranet、电子商务（E-business、E-commerce）、电子数据交换（EDI）。此外，还能实现在不同平台上的互操作。

2．ERP系统的管理思想

ERP的核心管理思想就是实现对整个供应链的有效管理，主要体现在以下三个方面：

体现对整个供应链资源进行管理的思想

现代企业的竞争已经不是单一企业与单一企业间的竞争，而是一个企业供应链与另一个企业的供应链之间的竞争，即企业不但要依靠自己的资源，还必须把经营过程中的有关各方如供应商、制造工厂、分销网络、客户等纳入一个紧密的供应链中，才能在市场上获得竞争优势。ERP系统正是适应了这一市场竞争的需要，实现了对整个企业供应链的管理。

体现精益生产、同步工程和敏捷制造的思想

ERP系统支持都混合型生产方式的管理，其管理思想表现在两各方面：其一是�精益生产LP（Lean Production）�的思想，即企业把客户、销售代理商、供应商、协作单位纳入生产体系，同他们建立起利益共享的合作伙伴关系，进而组成一个企业的供应链。其二是�敏捷制造（Agile Manufacturing）�的思想。当市场上出现新的机会，而企业的基本合作伙伴不能满足新产品开发生产的要求时，企业组织一个由特定的供应商和销售渠道组成的短期或一次性供应链，形成�虚拟工厂�，把供应和协作单位看成是企业的一个组成部分，运用�同步工程（SE）�，组织生产，用最短的时间将新产品打入市场，时刻保持产品的高质量、多样化和灵活性，这即是�敏捷制造�的核心思想。

体现事先计划与事中控制的思想

ERP系统中的计划体系主要包括：主生产计划、物流需求计划、能力计划、采购计划、销售执行计划、利润计划、财务预算和人力资源计划等，而且这些计划功能与价值控制功能已完全集成到整个供应链系统中。另一方面，ERP系统通过定义事务处理（Transaction）相关的会计核算科目与核算方式，在事务处理发生的同时自动生成会计核算分录，保证了资金流与物流的同步记录和数据的一致性。从而实现了根据财务资金现状，可以追溯资金的来龙去脉，并进一步追溯所发生的相关业务活动，便于实现事中控制和实时做出决策。

至此我们就完成了对整个ERP原理的介绍。当然，ERP仍旧处于不断发展变化的过程中。对于它的最新发展，我们还会在以后的系列中给予详尽的介绍。最后，作为一个总结，我们可以通过图1来对ERP发展的几个主要阶段进行一下简要的回顾：

图1 ERP发展阶段图

Program for searching Usr-exit

Sun, 04 Feb 2007 08:12:38 +0000

http://blueoxygen.dflying.net/3/resources/Z_USER_EXIT.txt.html

ALE and IDoc

Fri, 02 Feb 2007 16:56:55 +0000

from internet:

作为目前ERP市场上最为领先的应用系统之一，一直以来，SAP R/3在提供API应用编程接口和接口工具方面也同样领先于其它ERP厂商。ALE/IDocs是SAP公司为SAP R/3 R4.6C 版本所提供的接口机制，目前应用最为广泛。在 R4.0以后的版本中，又添加了技术上先进的BAPI。本文作为系列介绍之一，对ALE/IDocs， BAPI以及其它可用的整合方式进行介绍。

1、ALE/IDocs是什么？

ALE 是Application Link and Enabling 的缩写，是SAP专门为SAP与SAP之间所设计的整合中间件。IDocs是中介文本 (Intermediate DOCument) 的缩写，是 SAP提供的系统整合专用的数据/消息格式。ALE在SAP 3.0版本开始就作为SAP整个应用体系的一部分，为分布式数据交换提供了可靠安全的通讯机制。ALE的设计，原本作为两个SAP流程之间的一种消息传递服务(Messaging Service) ，使SAP与SAP的业务流程之间企业数据能够有效的交换，为两个独立的SAP之间提供了的系统整合服务。不过，随着应用的发展，ALE/IDocs接口机制也已然成为与其它非SAP系统的标准的整合方式。2、ALE/IDocs的消息发送接收过程

ALE的设计结构可以分为三层，即应用层，数据/消息分配层和通讯层。通讯层是SAP整合机制的基础，它利用远程功能呼叫RFC(Remote Function Call) 调用SAP系统的功能模块。

数据/消息分配层，主要提供三个关键服务：

按数据分配模型决定数据接收者。
消息的过滤和转换。
数据/消息的压缩，以提高传递效率。

应用层直接与SAP系统接口，生成或从其它系统接收含有路由信息的消息文本IDocs，包括消息接收者的姓名，要求发送的类型以及对消息进行处理的规则。

ALE 的机制代替了原来的SAP所提供的批数据通讯BDC(Batch Data Communication) 方式。顾名思义，BDC为系统之间提供了简单的数据批处理服务，还不能作为一种中间件技术，它没有提供系统之间进行无缝整合所要求的纠错功能、系统管理和其它安全措施。总得说来，应用SAP的ALE 机制进行SAP与SAP或非SAP系统整合有以下几个好处：

ALE技术不受SAP版本升级的影响，它提供了版本向后兼容性。ALE定义于SAP应用层，与SAP的逻辑层相对独立，整个ALE中间件独立于发送和接收系统。
ALE消息设计逻辑保证消息的�一次且只有一次�的消息传递。ALE采用�存储-发送�技术确保消息即使系统发生故障或接收方没有准备接收时也可以达到目的地。这样就保证接收方不至于收到重复消息。
ALE也提供了IDocs管理功能。主要有文本缩减、文本版本控制以及文本数据过滤。三种控制机制使得SAP开发人员可以根据实际需要对IDocs文本在运行中进行动态处理。
ALE提供了系统管理功能，允许对ALE系统进行启动/复位/恢复等系统操作，为开发人员提供了进一步的管理控制。

IDoc 几乎可以传带任何SAP应用的数据，是一种�外围�定义格式，与SAP的应用数据定义不直接相关。IDocs已经广泛应用于早期的SAP-EDI的数据交换，因而它的设计有点类似于EDI的标准，即EDIFACT标准。

IDocs是以字符基础的，因而是可读的。它有三种纪录类型，即：

控制纪录-含文本信息，如IDoc类型，发送/接收方信息以及文本标识。
数据纪录-含管理和实际数据部分。
状态纪录-用来追踪文本传递各点的状态，如状态码，系统时间，错误标识等。

下面对ALE/IDocs在系统整合过程中消息的实际传递进行介绍。

让我们首先看发送过程。3、BAPI简介

一个发送过程由事件触发，文本生成，数据打包以及交由传输媒介传递这四个步骤组成，具体如下：

应用系统事件触发

系统目标(Objects) 的状态变化，用户自主活动或其它数据库特定变化等可以启动数据表的触发程序，从而进行数据传递的初始化工作，如数据准备。

生成主IDoc文本(Master)

按标准格式生成主IDoc文件，包含所有可以传递数据(不分接收者)

生成通讯Idoc

从主IDoc中生成只与特定接收者有关的文本，通讯文本是主文本的子数据集(Subset)

Idoc 发送

利用异步通讯方式将一定版本的IDoc传递到接收方。

下面，让我们看接收过程。

接收过程始于SAP系统从外部收到IDoc文本。接收过程的优点在于，接收方既可以是SAP系统，也可以是第三方系统，这也是SAP与第三方进行有效整合的基础。接收过程由以下三个步骤组成：

存储Idoc-将文本存储于数据库，并进行语法校验
邮件处理程序读取Idoc--一个专门设计的IDoc处理程序读取IDoc并产生SAP或其它系统所需的系统消息。多个程序可以同时运行。
生成系统文本--处理程序进一步生成系统文本供系统使用，并将结果信息存于Idoc d的状态纪录中。

BAPI 是Business Application Programming Interface的缩写，是SAP为3.0版本以上提供的基于企业目标 (Business Object) 技术的接口应用界面。SAP在3.0版本以上采用了Object-oriented技术，逻辑定义了SAP R/3 系统的所有功能目标，并且将所有的目标(Objects) 和BAPIs存储于企业目标库BOR (Business Objects Repository). SAP R/3 企业目标的目标类型(Object Type) 相当于目标设计语言中类(Class) 的概念，其定义结构由以下几部分组成：

基本数据--所有目标类的通用属性，如目标标识和默认方法(Method) 。
接口界面--目标的方法(Method)，事件(Event), 特征(Attributes) 。
键(Key Fields)--供BOR中目标检索使用
方法(Methods)-- 对目标进行所要求的各种操作。
特征(Attibutes)-- 描述目标特征。
事件(Events)-- 触发以改变目标状态。
4、应用SAP-DCOM接口

SAP于1998首次提供SAP-DCOM接口，以满足各种桌面应用开发的要求。利用DCOM连接端口，开发人员可以利用VB， C++，以DCOM目标方式访问SAP数据。在Web应用上，可以用VBScript, JavaScript 以DHTML方式页面访问，也可以用ASP访问数据。

另外，利用DCOM也可以间接访问SAP的企业目标库BOR。上面提到的BAPI是SAP系统上专用的，在实际应用上不如DCOM来得广泛。DCOM端口主要有两个技术模块组成，一个是管理模块，另一个模块生成 SAP BO的DCOM 代理组件(Proxy Components)，生成的DCOM组件存放于C++。代理组件有以下属性：
另外，每个组件具有以下方法：
总起说来，SAP R/3 作为一个相对灵活的ERP系统，利用上述的各种整合技术能够实现SAP系统之间以及SAP 与其它系统之间的数据/过程的整合。当然，一个应用系统的高度客户化导致了系统整合的难度。随着系统功能的增加，多种可供采用的整合技术也就显得很有必要。对于SAP R/3用户来说，正确选择适用的整合技术是实现成功系统整合的关键。

利用BAPI，开发人员可以实现对BOR进行实时访问，从而实现应用系统(SAP-SAP)之间在数据/逻辑层上的有效整合。

SAP用户出口类型

Fri, 02 Feb 2007 16:39:56 +0000

by　http://www.sapclub.org/blog/arron99/archive/2006/11/20/4428.html

sap的用户出口总共有三代:

1、第一代
sap提供一个空代码的子过程，在这个子过程中用户可以添加自己的代码，控制自己的需求。这类增强都需要修改sap的标准代码。
示例：USEREXIT.. in SAPMV45A

2、第二代
sap提供的是CUSTOMER-FUNCTION，它是通过SMOD和CMOD完成实现。参见我的

3、第三代
sap提供的第三代的用户出口就是BADI，他的调用方式是CALL METHOD (instance)，（相关的TCODE是SE18和SE19），你可以通过EXIT_HANDLER这个单词查找BADI。

BADI primer

Fri, 02 Feb 2007 16:28:48 +0000

http://blog.csdn.net/jiden/archive/2006/06/30/856862.aspx
https://www.sdn.sap.com/irj/sdn/thread?threadID=11927&tstart=0
http://www.sapclub.org/blog/arron99/archive/2006/11/20.html

Oracle EBS 各模块名称

Mon, 18 Sep 2006 05:30:10 +0100

财务系统模块:
Oracle 总帐管理（GL）
Oracle 应付帐管理（AP）
Oracle 固定资产管理（FA）
Oracle 应收帐管理（AR）
Oracle 现金管理（CE）
Oracle 项目会计（PA）
Oracle 财务分析（OFA）

分销系统模块:
Oracle 库存管理（INV）
Oracle 采购管理（PUR）
Oracle 销售定单管理（OE）
Oracle 销售&市场管理（SM）
Oracle 销售补偿管理（SC）
Oracle 售后服务管理（SR）
Oracle 销售分析（OSA）

制造系统模块:
Oracle 计划管理（MPS/MRP）
Oracle 能力计划管理（CAP）
Oracle 制造数据管理（BOM）
Oracle 车间生产管理（WIP）
Oracle 成本管理（CST）
Oracle 项目制造（PJM)
Oracle 质量管理（QM)

其他系统模块:
Oracle 设备管理（EM）
Oracle 人事管理（HR）
Oracle 薪金管理（PAYROLL）
Oracle 系统管理（SYSTEM ADMIN）
Oracle 预警（ALT）
Oracle 多维数据分析/商业智能系统（OLAP/BIS）
Oracle 桌面集成（ADI）

Step One

Thu, 17 Aug 2006 15:30:20 +0100

Step ONE's achievement:

Step TWO's GOAL:

ABAP learning map

Thu, 15 Jun 2006 05:53:52 +0100

download it and enjot it.

SAP new UI

Thu, 08 Jun 2006 10:52:59 +0100

A couple of weeks ago in Sapphire Orlando, SAP introduced the world to a new user interface, code-named �Project Muse�. I thought I'd give the SDN'ers a quick overview of what it is. Basically, Muse is a new interface thru which SAP users can access any SAP application directly from their Macintosh, Linux or Windows client device, and in the future from integrated mobile devices.

Project Muse is being built from the ground up as an open, standards-based architecture-- using Flash and Flex technologies from Adobe/Macromedia. Project Muse can be easily extended to deliver applications, composites and any other service-enabled software from SAP and its partners or from other solution providers (think: ubiquitous business user interface for all your enterprise systems). The new client adds the richness of desktop software to the deployment efficiency of Internet software, delivering on SAP's vision of simplifying the user experience and the software ownership experience.

I've created a short (8 minutes) demo of Project Muse so you can get a good sense of what it's capable of. There's also a fact sheet that was distributed at the Sapphire launch.
More infor plz check here https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/3748
And we should pay attention on Apollo this framework.