Oracle Forms是非常高效、健壮的开发工具，它的历史已经超过了20年，在今后几年里将会继续完善和支持下去。APEX已经具备了相当多的Web 2.0因素，它继承了Oracle Forms最大优势，那就是几乎可以用PL/SQL来完成所有的开发工作，对于企业内部应用，它无异成为了首选的平台。在这种趋势下，自APEX 3.2版本开始，就引入了Forms Converter，该工具用于将传统的Forms应用转换到APEX应用，对于一些Oracle Forms应用丰富、历史悠久的企业而言，它是相当吸引眼球的。 从FastForms到SQL*Forms，从CS架构到现在基于Web的WebForms，Oracle Forms的基础结构却变化不大，本质依旧是Java程序，程序逻辑的实现几乎完全基于SQL和PL/SQL。APEX则是非常纯粹的WEB应用开发平台，它需要的是PL/SQL、Java Script、CSS和最基础的HTML知识。对于开发人员而言，两者需要技术技能几乎相同。从Oracle Forms转移到APEX，对开发人员的技能培训几乎可以省略。Oracle Forms的几个核心组件：块(Block)、触发器(Trigger)、PL/SQL库、值列表(LOV)都可以交由Forms Converter完成转换。 转换器会生成XML格式的原数据文件，然后上传到APEX生成具体的Web应用。在这里，转换器的作用是“转换”，而不是“迁移”。两个平台在技术上是不同的，从而导致某些功能上的差异，比如Forms中的快捷键在目前的APEX中是不存在的，此外，Forms中某些java beans的应用也无法在APEX上实现。Oracle Forms和Oracle APEX各元素的差异主要如下表所示： Oracle Forms Oracle APEX Alerts 在应用层或页面上的验证逻辑中实现文本消息 Blocks 在APEX是区域(Region) Canvases 在转换过程中被忽略 Editors HTML编辑器 Lists of Values 记录组在转换过程中将会被调整 Program Units 对应PL/SQL程序单元 Triggers APEX中没有触发器，不过页面查询过程有相应的机制实现逻辑，比如Processes 对于APEX 4.0版本，或许还有另外一些特殊的差异，比如Websheets，内置的图表引擎（这是非常酷的，可以做简单的BI），加强的Web Services功能等。在用户界面上，Oracle Forms响应迅速，而APEX则可以通过AJAX特效实现类似功能。 关于转换的具体操作，可以参考《Oracle® Application Express Application Migration Guide，这本书《Oracle Application Express Forms Converter》有更详细的介绍。
Archives for February 2010
不应因习惯而麻木
案例：ERP系统中项目数量非常多，在项目管理模块，有个WEB界面是用于调整任务信息的。克隆环境后，用户发现该功能的访问速度和正式环境有明显差异。经询问各方面人员（包括用户和实施顾问），都说没有做过任何特殊变动。 任何一名实施顾问，首要的经验就是要学会明确自己和普通用户的不同。一种业务，或者一个功能，绝对不能完全站在用户的立场来看待问题。如果用户说没有做过更改，那是从功能使用角度来讲的，作为系统和功能之间起到桥梁作用的ERP实施人员，还应当关注系统本身的变化。首先，克隆本身就是一种变化，比如硬件平台的变化、文件路径的变化、访问方式的变化，甚至系统参数（数据库或应用）也可能变化。任何一种变化，都可能导致用户体验的不同。一个新克隆的系统，第一次访问就发现速度变慢（或者变快），实施顾问应当事先就预料到各种可能的情况。从我的经验来看，没有做过变动的可能性非常小，那就通过一些简单的技术手段来找到这种变化。 先对该功能启用诊断后发现，有一段执行任务列表查询的SQL存在明显的性能问题。 克隆环境检查该SQL的执行计划： SQL> set linesize 1000 SQL> set pagesize 1000 SQL> explain plan for SELECT * 2 FROM (SELECT * FROM pa_task_progress_v) qrslt 3 WHERE (task_manager_person_id = 126) 4 ORDER BY project_name ASC, 5 task_name ASC 6 ; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT —————————————————————————————————- —————————————————————————————————- | Id | Operation | Name [...]
Oracle UPK 和操作手册
一个很小的问题：Oracle ERP的操作手册怎么写？ 我联想到一个很小的例子。过完年回来后，很多中餐馆都还没有营业，哪怕已经营业的餐馆里菜式也非常少，老板解释说厨师还没上班。再回头看肯德基、麦当劳之类的洋快餐，什么时候会说因为某人没来上班而不能吃某样食物？在每个营业员都可以做厨师的餐厅里，我们甚至没进去就可以先想好吃什么，而中餐馆里却不行，甚至很多时候，因为某厨师的离职而导致我们再也不去某家餐馆。 在很长的时间里，以及绝大多数的企业里的，操作手册就是一个文档，里面配以相关截图和简单的说明，花哨一点的可能会录制屏幕配以简单解说，而更规范的企业里或许直接以SOP来代替。基本上，如果没有规范的制定，每个人的操作手册肯定是五花八门，更多时候彼此都很难看懂对方写的手册，而没有经验的用户则更是看得云里雾里。 我心目中标准的操作手册应当包含以下几个要素： 具备明确的目标，该手册将让用户掌握什么功能的操作？ 要直观，简洁。 对于关键点，应该有适当的说明。 导航要清晰、明确。 用户在看到操作手册之前，应当已经接受过初步培训。很多人拿着操作手册想了解背后的数据模型，拿着功能介绍想看操作细节，结果一个手册变成了大杂烩，什么都有，搞到最后则是连用户都不想看了。操作手册不是功能设计，更不是用户需求说明书，它只是让用户明白某个功能是如何运作的，要正常工作中应当如何规范操作。用户和实施顾问的角色是完全不同的，用户看的文档和实施顾问看的文档也完全不同。所以在操作手册中配以复杂的理论说明是非常应当避免的，我的看法是，连流程图都没有存在的必要。 一个规范的格式化的文档永远比个性化的文档更有价值。有时候，写手册也是一种艺术，哪怕已经制定了规范，不同的人写出的手册还是区别很大，比如用于习惯，比如符号表示，比如章节划分，这些细节上的区别往往很容易造成阅读上的障碍。 行业范围的标准和规范有时候比团队内部甚至企业内部的规范要有力的多，而且这种规范会更得人心。习惯也可以成为一种竞争力，团队协作经验有时候和个人能力一样重要。如果某一天因工作需要进入另一个团队，结果发现其管理方式迥异，转变的过程也会是非常痛苦的。在Oracle ERP领域，UPK的使用或许就是一种每个从业人员都应当掌握的技能。 Oracle UPK的上手非常容易，通过简单的设置，甚至只需要重复一遍操作过程就能形成一套非常棒的培训方案。它可以生成屏幕回放，对于每步操作都配以解释，有需要的话，可以按章节用HTML附上一段说明。若有需要，也可以直接发布成Word格式的操作手册，其质量丝毫不逊于以前手工截图的手册。也可以发布到网站上，并且和EBS系统进行菜单集成，直接从EBS跳转到操作手册。目前，Oracle EBS R12、PeopleSoft、JD Edwards等应用都已用UPK做培训文档，相信今后Oracle会有越来越多的产品的培训文档采用该种方式发布。 对于Oracle ERP操作手册编写，希望今后能有更多的企业采用UPK。这种工具和规范，对每一位从业人员都是有利无害的。 Oracle UPK 官方站点：http://www.oracle.com/us/products/applications/tutor-upk/index.html
MPS Relief Worker
mps-relief-worker