APEX:在系统后台跑PL/SQL
Posted on September 20, 2009
在一个ERP环境中，经常遭遇到一些执行时间非常长的情况。对于EBS产品，可以考虑使用并发请求的方式来让表单将控制权快速返回给用户，有些人也喜欢利用Workflow来应对此类情况(使用Deferred特性)。在和Oracle的对话中，以及Oracle Database 11g产品组件透露的信息上可以看出，APEX(Application Express)越来越成为一个非常重要的角色。从以前独立版本的HTML DB，到现在直接内置到11g中，仿佛就是在向企业用户宣告了另一种企业信息化方案。开发的Web应用程序通常具备非常快速的响应，但是偶尔也会遭遇一些非常情形，比如某个财务报表的运算逻辑非常复杂，通常无法立即返回结果，这时该如何处理呢？
一种比较简单的方式就把这部分工作还给EBS，Web应用程序等处理完毕后再直接获取运算结果，这种方式不需要对原EBS应用做太大调整，而纯粹作为一个结果呈现的客户端。其实还有另外一种方式来处理该问题，即将PL/SQL代码放到后台去执行。APEX给出一个官方的解决方案，使用APEX_PLSQL_JOB。它的原理就是通过DBMS_JOB的功能来让代码延迟执行：
APEX_PLSQL_JOB.SUBMIT_PROCESS (
p_sql IN VARCHAR2,
p_when IN DATE DEFAULT SYSDATE,
p_status IN VARCHAR2 DEFAULT 'PENDING')
RETURN NUMBER;
该过程提交后台执行的PL/SQL代码，它会返回新创建的job number，可以根据该标识来跟踪job执行状态。这个包里已封装的过程主要包含：
- JOBS_ARE_ENABLED 判断是否支持使用APEX_PLSQL_JOB提交后台执行的PL/SQL代码。
- PURGE_PROCESS 清理已提交的jobs。
- SUBMIT_PROCESS 提交后台执行的PL/SQL
- TIME_ELAPSED 统计job提交后过了多少时间
- UPDATE_JOB_STATUS 更新当前执行中的job状态，通常在提交的PL/SQL代码中调用。
为什么是DBMS_JOB而不是DBMS_SCHEDULER呢？众所周知，APEX的前身是HTML DB，它在10g版本以前的数据库中也可以正常工作，而DBMS_SCHEDULER则是10g时代才被引入的。事实上，在很多内部程序或表结构上，如今的APEX还是遗留有许多HTML DB的影子。
只要明白了原理，我们也可以设计更适合自己工作环境的wrapper package，比如可以考虑充分利用DBMS_SCHEDULER的新特性。
Related Posts
» Filed Under APEX 
Print This Post
Comments
2 Responses to “APEX:在系统后台跑PL/SQL”
Leave a Reply
个人感觉这个包太简陋，适合简单的后台pl/sql
事实上，在用的时候我通常直接使用DBMS_JOB包。
感觉APEX做这个简单的封装，可能有其他用途吧，比如将来支持的某event事件……