APEX 上传xls文件
Posted on August 22, 2010 - Filed Under APEX | Leave a Comment
上一篇文章介绍了APEX中上传文件的方式，以纯文本文件为例说明了如何对上传的文件进行后续处理。PL/SQL可以直接对纯文本内容进行处理，那么如果直接上传xls二进制文件呢？通常，可以用Java Procedure做这件事，但是自APEX Listener 1.x 发布后，有更简单的方式实现对xls内容的处理。 1.10 版本之后，apex-config.xml 中多了下面这个参数： false 将该参数设置为true则开启excel到collection的转换功能，简单设置步骤如下： 1. 添加File Browse…的Page Item，名字为P1_FILENAME，Storage Type 为 WWV_FLOW_FILES 2. 添加名为UPLOAD的Button Item，Button Request 设置为 xls2collection 运行该页面，选择一个xls后缀的Excel文件，点击UPLOAD按钮即可上传该Excel文件。 上传的文件和数据分别存放在wwv_flow_files和apex_collections中。其中COLLECTION_NAME的默认名称为Page Item的名称，此例中为P1_FILENAME，C001为Excel的TAB页名称，接下来的各字段为表格内容。 SELECT * FROM apex_collections a WHERE a.collection_name = ‘P1_FILENAME’ apex_collections是视图，限制了security_group_id，你需要在应用程序中，并且是当前会话中使用。 删除Collection方式为： apex_collection.delete_collection(p_collection_name => ‘P1_FILENAME’); 详细说明可参考APEX 4.0的API Reference文档中的APEX_COLLECTION章节。 有了APEX Listener，很多事情变得更简单了，当然，除了文档，APEX的文档令人吃惊的简单，很多内容都没有提及。
APEX 4 中的文件上传功能
Posted on August 13, 2010 - Filed Under APEX | 1 Comment
有一个APEX小应用需要提供Excel数据上传功能，并且要对上传的数据进行后续加工处理，于是就有了下面这段有点通用的代码。 APEX 4.0中上传的存储位置有两个选择，一个是集中式的WWV_FLOW_FILES，一个是自定义的表。对于前者我不喜欢，所有应用上传的文件都存储在一个地方，有些时候管理起来不够方便；如果是自定义的表，每个应用单独存放，那么不论在迁移还是某些维护都相对简单，当然，对于上传功能的设计而言就需要多花几分钟时间了。下面是自定义表的一个例子。 1. 先创建存储表 attach_data blob 二进制数据 attach_mimetype varchar2(255) 文件类型 attach_filename varchar2(255) 文件名 attach_last_update date 上传时间 attach_charset varchar2(128) 字符集 attach_id number 文件ID 一般而言，最好将该表最小化，包含必须的几个字段即可，如果需要和其他表关联，则可以通过ATTACH_ID关联。 2. APEX页面中增加File…上传的item，属性设置如下： 3. 添加提交表单的按钮，提交时触发一次Automatic Row Processing (DML)的Process，设置表名和主键，系统会自动将相关数据（包括上传的文件）插入对应的表中。关于主键ID的自动生成，可以在After header位置增加一个自动fetch row的设置即可。 4. 文件上传功能本身是非常简单的，接下来是针对该上传文件的后续处理。在顺序上，要先有处理上传的Process(就是第3步)，然后再有后续处理的Process。手工在Page Process处再添加一个名为Parsing Attachment(名字随意)的Process，再Source处理加入匿名PL/SQL代码。例如我喜欢直接调用写好的包，那就写上： process_upload.process_file_upload; 这里需要用户首先对Excel做一个另存问文本文件的操作，目前为止，我还没发现可以用PL/SQL来直接操作二进制Excel文件。如果有必要，可以考虑使用Java Procedure对Excel文件进行处理。 附上几段代码： PROCEDURE process_file_upload IS l_blob_data BLOB; l_blob_len NUMBER; l_position NUMBER; l_raw_chunk RAW(2); l_raw_line RAW(32767); l_line [...]
迎接变化
Posted on August 1, 2010 - Filed Under Uncategorized | Leave a Comment
最近工作和生活都发生了些变化，参加新的团队，实施新的项目，也可能要投入新的ERP阵营。在企业信息化的工作经历中，我乐意了解并接触不同的产品。就像博客，保持独立性是重要的，不要把人生绑在一张船票上，也不要把企业绑在一个软件厂商上。 由于目前还处于ERP系统选型阶段，所以一切未知，一切也不便多说，但是一些通用的，依旧存在于那里。在工作变换的简短假期中有所憧憬，也有所忧虑，对之前走过的路和将来要走的路都有一些不算深入的思考。一些经验和体会零零碎碎的，整理出了下面几点： 对待变化不忧虑，迎接它。 面对现实，不逃避。 预估风险，面对风险，承担风险。 质量往往和时间成正比。 关键部分坦然面对。 不捣浆糊，有帐迟早要还的。 学好一门语言，其他的，可以在用到时再学——你不是程序员。 了解一些技术，有助于深入吃透功能本身。 愿意花一部分工作时间在其他需要你的地方，尽管它不属于本职工作。 多读官方文档。 沉得下去，浮得上来。 纯属个人体会和感触，不具有任何其他意义。一旦选型结束，将重新投入到实施和技术分享中来，自然会忙，会觉得辛苦，但值得。 面对变化，迎接变化。
EBS 11i升级到R12
Posted on July 5, 2010 - Filed Under E-Business Suite | Leave a Comment
花了大概一周时间完成了一套11i系统(到12.1.1)的升级，之所以耗费如此多时间，简单归纳了一下大致有以下原因： 历史遗留的配置问题（比如用中文做关键词），此类问题导致数据转换错误。 客户化（索引，物化视图等）导致升级错误。 测试机性能差，耗时颇巨。期间多次由于内存的原因，导致java程序出错。 很多R12本身的升级过程中的bug需要处理。 部分业务数据升级时出错，可能是旧数据完整性被破坏所致。 一些前期工作跳过没错，这本来可以缩短升级过程的一部分排错时间。 其他的一些可在升级之前就预先解决的问题。 整体上说，机器的性能问题很关键，有些步骤运行动辄数个小时，有些是升级程序有优化余地而事先没有发现，这些一般都在metalink上有了解决办法。对于升级，很多人第一反应就是克隆环境升级，然后导入最新数据并进行主备切换，其实这种方案对于多数企业而言很难，因为升级过程中会修改大量的表结构，甚至很多应用级别的调整，我很怀疑有哪家公司能够做到对Oracle EBS的数据结构了解的如此洞彻明晰，至少国内没有。这是我第一次对11i进行升级，积累了一些经验，在此分享。 升级前的准备 升级前的准备包括三方面，一个是应用本身的准备工作，这个在升级手册里已经详细说明；另一个就是对服务器性能做一个充分的评估，确保整个升级过程不会跳到deadline之外；还有一个，就是将所有能提前做的工作都做好，比如invalid objects，韩语分词补丁，OLAP升级等等，这些在数据库升级阶段不是必须的，但是EBS升级时却是无法直接忽略的步骤，此外可靠的网络连接也很重要，patching过程中断线后虽然可以继续，但是光启动就要花不少时间。 升级过程中的注意事项 这里依旧按照升级步骤来进行说明。 Disable AOL Audit Trail (conditional) 关闭所有审计功能，包括标准功能提供的，以及客户自行在DB级别上添加的。 Shut down application tier listeners and concurrent managers (required) Migrate database to at least Oracle10g Release 2 (conditional) 这一步之前已经做了，考虑到停机时间，分两步走是比较合适的方案。 Update init.ora with upgrade parameters (required) 同上，升级数据库时已经基本做好了。 Disable custom triggers, constraints, and indexes (conditional) 注意：最好将所有直接关联到标准表的客户化索引和Materialized [...]
EBS 11i数据库升级(9i->10g)几点事项
Posted on June 9, 2010 - Filed Under Database, E-Business Suite | Leave a Comment
最近几日在评估和测试EBS的系统升级(11i升级到R12)，虽然官方的升级文档里介绍的比较详细了，但是依旧会出现一些容易疏忽的问题，这里做一些记录。这里并不是单纯的数据库升级，需要考虑EBS的特殊应用。对于升级方案，标准的有三种： 同时升级数据库和应用。 先升级数据库到10gR2，然后升级应用到R12。 先升级数据库到11gR2，然后升级应用到R12。 其中第2和第3种方案有点类似，都是将整个升级方案划分为两个阶段，只是数据库版本不同。实际上，从技术上看，第1种方案也是两步走，只是在应用层跳过一些过渡性的补丁直接升级到R12。 在数据库升级方面，升级路线主要有下面两种： 路线1: 9.2.0.6 -> 9.2.0.8 -> 11.2.0.1 如果是Solaris系统，则要求系统版本至少为 Solaris 10 Update 6。 路线2: 9.2.0.6 -> 10.2.0.1 -> 10.2.0.4 注：最新patchset是10.2.0.5，只是升级文档依旧停留在10.2.0.4。 从一般认识上讲，Oracle数据库在下一个大版本出来后，上一个版本才被认为是相对更稳定的，所以此处选择第二条路线。 数据库升级方式简单而言有以下几种： DBUA，直接通过图形化工具升级，这个最简单。 Manual，类似于上一种方式，只是手工进行各个步骤的升级操作。 Export/Import 有利于数据表的整理，重构数据库，比如修改字符集、数据文件、表空间参数等，在升级时间上，比DBUA和Manual两种方式都要长。 利用数据复制等技术，升级备用环境后再切换。 由于允许停机，并且暂无特殊的要求，所以这里使用DBUA做升级操作。 在升级之前，建议卸载statspack，并且先解决Invalid Objects的问题。此外，数据库升级后DBLINK需要重建，所以先准备相关重建脚本。下面按照文档步骤升级数据库9.2.0.6 至 10.2.0.4，每个步骤都列在下面，对几个步骤中需要额外关注的地方做了备注。 Verify software versions 检查现在软件版本，基本上应该不会有问题的，留意一下AD版本，最新版本是11i.AD.I.7，不过要求11i.AD.I.6就可以了。 Migrate to Oracle Portal 10g (conditional) Deregister the current database server (conditional) Update application tier [...]
关闭功能顾问的那些诊断模式
Posted on May 28, 2010 - Filed Under E-Business Suite | Leave a Comment
相对于SAP而言，Oracle ERP的另一个显著特征或许就是大量的BUG和补丁吧，也或许正因为如此，Oracle ERP中的故障诊断越来越便捷，方式也越来越，有Server级的诊断（如Form Server），有DB级的诊断，也有功能级的诊断（输出程序步骤和关键业务数据）。对于Form/Report Server之类的故障诊断，通常有专门的技术顾问负责，多数情况下，功能顾问在Oracle Support的建议下也会进行各种形式的、针对各个模块和功能的诊断，有的记录在表里，有的形成日志文件，也有的直接显示在页面上。对于不影响用户操作的诊断，事后很容易就忘记了关闭，于是大量的五花八门的被遗弃的debug和trace偷偷占用着宝贵的系统资源。 通常，功能顾问们涉及的诊断功能可直接通过配置文件启用，主要有下面这些： FND：启用调试日志 启用日志。如果为否 (‘N’)，则运行时不会进行记录和发出预警。 OE：调试 选择“是”以激活 Oracle 订单分录管理系统表单用户退出和并发程序中的调试信息 OE：调试跟踪 选择“是”以激活 oracle 订单分录管理系统并发程序的跟踪输出 OSO：启用调试消息 用于显示/隐藏调试消息的 Sales Online 配置文件 PA：调试模式 指明是否按调试模式运行项目会计管理系统报表和流程；在调试模式下运行时，线索会被打开，附加信息会打印至日志文件 PO：将调试工作流设置为“打开” 启用/禁用 PO 工作流调试模式 PO：启用对接收处理程序的 SQL 跟踪 启用数据库 SQL 跟踪，以便调试接收事务处理程序。 RCV：调试模式 如果将此模式设置为“是”，则将在日志文件中打印消息。 初始化 SQL 语句 – 自定义 初始化会话的自定义 SQL 语句 其中“初始化 SQL 语句 – 自定义”比较特殊，可以自行设置event。它的格式如： BEGIN fnd_ctl.fnd_sess_ctl(”,”,”,’TRUE’,”,’ALTER SESSION SET TRACEFILE_IDENTIFIER=’ [...]
