Fans Or Not

OAF开发中，如果多个功能同用一个EO，很多人习惯将其放到一个package（例如cux.oracle.apps.asf.schema.server)。如果它只存在于一个人的wordspaces中，那会非常方便。如果每个功能自己独立的EO，是否也该放到这个schema的包里？ 所有对象放在一起管理固然非常清晰明了，但是当我们进行团队开发时，却时常会遭遇一些只有个别人能重现的错误提示。尽管在口头协调中要求过，但是常常，总是有会两个人的电脑中存在不同版本的schema包。而更常见的错误提示就是：Unable to find referenced object。 修复方法是，手工修改相应的server.xml或者jpr文件补上相应对象。如： 当我手工进行了两次修复后，终于意识到了开发前写整体设计文档的重要性了——哪怕仅仅只有两个页面。

基本上，一些异常情景的实时的电子邮件预警都是通过plsqlmailer发送的，但是发现某些地方，在“发送时间”的显示上有很多不同。有些邮件用Outlook阅读时，发送时间会是N年后，这是怎么回事？ 首先检查email源码，查看头信息中的Date值，发现有些邮件是：Date: 5, 17 10 2008 16:56:25 +0800，而另外一些则是：Date: Fri, 17 Oct 2008 17:19:02 +0800。显然后一种格式是符合RFC规范的，但是同样的程序，为何造成如此不同。 Date字段的值是通过以下SQL生成： SELECT to_char(SYSDATE, ‘FMDy, dd FMMon yyyy hh24:mi:ss’) FROM dual; 按理说，换而言之，根据Oracle的SQL参考手册中to_char的使用说明中所述，它应该产生正确的结果。而对于同一套系统，我们应该忽略语言不同造成的差异，因为没人会去更改语言呀。 仔细对照两封邮件，以及各自调用plsqlmailer发送邮件的程序，发现了下面这点： 尝试使用修改语言来测试一下： ALTER SESSION SET nls_language=american; 结果果然是正确了。原来对于Oracle Report，它上面的“语言”就是如此起作用的。

去年简单介绍过表单个性化的基础知识，如果使用得当，可以起到很好的控制作用。做内部顾问有一个明显的职业习惯就是对用户不信任，各类输入的信息都是不可信的，必须经过验证才能通过。对于一些关键业务来讲，这确实起到了很好的防范作用。只要存在一处没检查出来，那就等着吧，往往就如洪水泛滥，后面会有的忙。 通过表单个性化来进行关键字段和关键逻辑的控制，肯定少却很多麻烦，但是个性化所支持的事件非常有限，很多情况下，或许我们可以通过及时检查，而不是界面上的输入控制来达到目的。比如采购订单，是支持POST-DATABASE-COMMIT事件的。当所有数据都提交到数据库中后再对业务数据进行检查，如果存在问题就发送预警邮件，通常情况下，这种防范已然足够。但遗憾的是，并不是所有表单都支持POST-DATABASE-COMMIT事件。 现在打开采购订单表单(POXPOEPO.fmb)，看看里面的玄机。查看Triggers -> POST-DATABASE-COMMIT： BEGIN — ———————————————————– — OGM_0.0: PO integration with Grants. — ———————————————————– IF NOT (appcore_custom.pre_event (‘POST-DATABASE-COMMIT’)) THEN NULL ; END IF ; appcore_custom.post_event (‘POST-DATABASE-COMMIT’) ; /* Globalization ecso 5/19/97 */ app_globe.event(‘POST-DATABASE-COMMIT’); EXCEPTION when others then fnd_message.debug (‘Exception error on POST-DATABASE-COMMIT’); po_message_c.show; raise form_trigger_failure; END; 留意几个appcore_custom的调用，这就是支持个性化事件的奥妙所在。这个事件并不在个性化事件选择列表中，需要手工输入。