系列之三ORACLEEBS系统应用基础概述Word格式.docx

系列之三ORACLEEBS系统应用基础概述Word格式.docx

《系列之三ORACLEEBS系统应用基础概述Word格式.docx》由会员分享，可在线阅读，更多相关《系列之三ORACLEEBS系统应用基础概述Word格式.docx（7页珍藏版）》请在冰豆网上搜索。

ORACLEEBS系统应用基础概述

十一、预警（Alert）

十二、应用开放接口（OpenInterfaceandAPI）

十三、结语

（注：

网站批量发图有问题，上传后显示不清楚。

点击图片打开后，质量尚可）

今天在企业的办公场所或酒店的房间等很多地方，我们都可以见到天花板上装有“烟感报警器”以及“自动喷淋器”，国家对建筑物的消防安全有明确的法律法规，因此这些“报警或灭火”装置几乎已成了建筑物的标准配置。

与之类似，预警平台对于今天的ERP系统来说也几乎是一个标准装备，无论是从系统实现角度还是从业务应用角度来看，它都不是很复杂，比较容易掌握。

ORACLE的系统预警分两种方式，一是“事件预警”，二是“周期预警”。

两者的基本工作方式均是使用SQLSelect语句基于对数据库中的相关值作出条件判定，以决定是否执行某种活动（发出信息，执行并发程序、执行操作系统程序、执行SQL语句）。

更进一步，对于“发出信息”类预警，系统在收到对此信息的符合规定格式的“回复”后，还可以据此自动执行相关活动并完成相关事务处理。

所谓“事件预警”，即当用户在相关数据表中“插入”或“更新”某些值时，系统自动启动已定义的“SQLSelect语句”的检查，已确定是否需要发出预警信息或执行某种活动，如下图33所示的一个事件预警定义：

在采购管理系统模块中，当出现一个巨大数量的申请行数量被输入时，系统需要向相关责任人发出预警通知（以提醒诸如做好资源准备等）。

所谓“周期预警”，即系统按照事先定义好的周期间隔或频率，自动启动已定义的“SQLSelect语句”针对数据库中表的某些值作检查，已确定是否需要发出预警信息或执行某种活动，如下图34所示的一个周期预警定义：

在采购管理系统模块中，系统按每两个工作日的间隔频率对所有“一揽子采购协议

BPA”的到期情况进行检查，并将需要关注的检查结果（例如某些BPA将在一周之类过期）通知到相关责任人。

任何ERP系统都无法做到在任何情况下都能满足企业实际使用的各种要求，企业有时可能需要从其它来源向系统中批量输入数据，如从物料的Excel电子数据表格向EBS的INV系统导入Item信息等等，或者需要与其它第三方应用系统建立业务数据的交换机制，如从专用的“费用报销或发票申付”管理系统向EBS的AP系统导入事务处理数据并将事务处理执行结果反馈回来源系统等等。

理论上，使用相关数据库工具可以向数据库的数据表中直接批量写入数据，但这样做无法对写入的数据进行正确性、合规性校验，无法保证写入数据的质量以及对存在问题进行有效管理。

为此，ORACLE提供了接口表InterfaceTable作为“中间表”过渡，并在此基础上，根据某些业务需要提供业务视图BusinessView，以便对导入的数据进行修改、更正、重新导入等等管理。

如下图35所示“OpenInterfaceDiagram”：

更进一步，ORACLE将某些数据的导入导出功能进行封装，成为一个应用程序可以调用的接口（API），以实现在各模块之间以及内部模块与外部系统之间的数据与流程集成。

如下图

36所示“OpenApplicationProgrammaticInterface（API）Diagram”：

开放接口（API）的基本工作模式分为两个阶段：

一是先将来源数据装入（Load）接口表。

如果是在两个应用系统之间，这通常是由专用的装入程序完成，例如EBS内部采购申请要转成内部销售订单，需先运行“创建内部销售订单流程”，以便将内部采购申请发送并插入订单管理系统的接口表。

如果是从某些电子表格如EXCEL等导入，则需要先使用专门的SQL*Load工具将数据格式转换后直接插入相关接口表，例如要通过物料的EXCEL数据表直接批量装入Item数据，必须先通过SQL*Load工具如DataLoad等将来源数据插入Item数据接口表。

在将数据插入接口表的过程中是否对数据进行校验（或是在将接口表数据导入正是表时再校验），取决于系统各应用模块的不同设计；

二是系统将存在于接口表中的数据导入正式的业务数据表，如EBS订单管理模块的“订单导入”，库存管理模块的“导入Item”等等。

在从接口表导入“正式表”或数据装入“接口表”过程中因数据校验而产生的错误或失败信息，如系统提供专门的业务管理视图，则可以在其中进行查看、更正、重新提交，如

EBS的“订单导入更正”窗口等。

如系统未提供管理视图，则可以在并发程序请求的“输出”文件中查看结果。

下图37所示“应付款管理模块费用报表类发票导入流程图”是一个典型的应用过程示例：

我们经常见到有些国内产品在宣传中，总是喜欢嘲讽国外产品如SAP已经是“老古董”，刻意强调自己的技术是如何先进、平台是如何创新等等这些于企业应用实践其实相距甚远、华而不实的东西，而在产品研发过程中，却忽略了于企业信息化实践更为重要的基本元素与应用基础的研究。

这就好比卖房子的开发商总是卖弄自己造房子的钢筋质量是如何好、水泥标号是如何高、施工所用的机械设备都是进口的等等，问题是这些与买房人真正所关心、所需要的

“户型结构、空间适用以及小区配套”等又有多大关系呢？

技术的进步无疑会对企业管理实践中的组织形态、业务模式等诸多方面产生重大影响，管理作为一门“科学”而诞生的这近一百年来，企业管理实践从早期的“职能管理”到现代的“流程管理”，从早期主要内向关注“生产效率”到现代重点外向关注“客户需求”，技术的进步尤其是近二十年来信息技术的飞速发展起到了重要的推动作用。

但管理科学毕竟是属于“形而上”的范畴，相较于“形而下”的器物层面，技术进步的作用与影响方式总是承前继后、继往开来而非颠覆性的。

回顾SAPR3或ORACLEEBS过往十多年的发展历史与演化进程，我们可以发现，系统开发设计人员于早期阶段就融入软件的那些于企业核心业务运作所至关重要的管理思想、业务模式等核心内容并未过时，它们今天依然是支撑企业高效运作的核心与基础，并且它们也在随着时代的发展而与时俱进、不断得到充实与完善。

管理软件从三十年前的主机时代，到二十年前C/S架构的客户机/服务器时代，再到十年前开启的B/S架构的互联网时代，软件具体技术的发展较之于信息技术整体进步对企业管理实践的影响，总的来说还是局部的、非决定性的。

今天大概不会再有人相信“管理软件从C/S架构进化到B/S架构是企业管理实践的一场革命”这样的夸大其辞，遑论更为等而下之的诸如.NET平台、Java平台、私有的ABAP平台等等这些纯技术领域的开发工具对于管理软件中所蕴含的管理思想、业务流程模式能有多大影响。

喜欢看美剧的人或许经常可以在片中看到美国纽约于上世纪三十年代初期所建造的两座美轮美奂的标志性大厦：

克莱斯勒大厦（77层）和帝国大厦（102层）。

八十年前的技术条件与工具手段和今天简直没法比，但我们今天能说它们已经落后、不是“现代化”的大厦吗？

有谁知道克莱斯勒大厦还是世界现存最高的“砖体”建筑呢！

人类的认识总是从已知的东西逐步推展到未知的领域。

如果我们暂且抛开系统具体的业务流程、功能应用以及操作细节不谈，仅针对前述ORACLEEBS系统的11个基本组成元素，从实践来源与系统实现两方面，作并非详细深入但比较直观概要的探讨，我们也许就能获得这样一个总体上的认识，即无论多么庞大、复杂的一个软件应用产品体系，它仍然是由一些使用比较简单、理解并不深奥的基本构件所组成。

这些基本构件来源于业务实践或与日常工作息息相关，我们其实并不陌生，它们是

“从业务到技术，再从技术回到业务”两者高度融合的结晶体，也是神妙莫测、不可捉摸的代码空间通往纷繁复杂、多姿多彩的真实世界的桥梁。

大多数情况下，对于普通的EBS系统用户而言，结合自身的业务，掌握了上述十多个基本元素中前几个，例如表单、查询、事务处理、文件夹以及报表类并发请求等，就足以可应付一般的日常工作；

而对于系统实施、维护人员来说，相对而言后几个技术味较浓的基本元素，诸如并发处理、弹性域、配置文件、工作流等则可能是工作的重点与难点。

但需指出的是，本篇有关系统基本组成元素的介绍，只是起到一个帮助初学者打破神秘、入门引路的作用，进一步深入掌握系统还必需结合ORACLEEBS的具体测试环境，对照单调抽象、枯燥乏味的海量应用帮助文档，进行大量的、艰苦的、耐心细致的学习研究，绝非一朝一夕之功。

关于EBS系统的具体测试环境，对于今天即使普通配置的计算机来说，安装与使用也基本不是问题，网上有大量图文并茂、详尽细致的安装帮助文档可供参考。

而ORACLE系统官方的应用帮助文档，针对每个模块则主要有三种：

ImplementationGuide（实施指南），UserGuide（用户指南）以及onlinehelp（在线帮助）。

这三种文档基本上也是顾问、实施人员需经常用到的工具书。

码字到这里，突然想起一位资深ORACLE顾问喜欢在其文章封面中引用的亘古励志名言，这里且搬来与大家共识、共勉：

（本资料素材和资料部分来自网络，仅供参考。

请预览后才下载，期待您的好评与关注！

）