Oracle APEX数据库内低代码开发与EBS集成实战

简介：《Oracle APEX深入浅出》是一份面向Oracle APEX初中级开发者与企业应用搭建者的系统学习文档，围绕基于Web快速构建企业级应用这一目标，梳理从环境准备到部署集成的完整知识链路。内容覆盖APEX系统探究、账户与权限管理、开发概要、页面布局美化、常用控件、Report增删改、文件上传下载、CSS与JS运用、图表报表、插件使用及APEX部署，并延伸到调试技巧、常用API与EBS集成等进阶主题，便于读者建立从页面设计到数据可视化的整体认知。压缩包共1个doc文件，约8.11MB，适合作为案头手册按章节查阅，也可跟随目录进行阶段性练习。已有1592人学习，说明其在APEX入门与实战参考方面具有一定认可度。读者可从中获取较完整的开发流程框架、控件与报表的落地思路，以及部署和EBS集成的衔接方法。

1. 从一次 ADMIN 登录被拒说起：Oracle APEX 到底跑在哪一层

装完 Oracle APEX，浏览器能打开登录页，ADMIN 密码改了三遍还是进不去——这个场景我遇到过，最后发现不是密码错，是数据库里还留着上一代版本的用户。这类“页面起来了但进不去门”的故障，恰好说明 APEX 的定位：它不是一台独立的中间件，整个开发环境和运行时都压在 Oracle 数据库里，页面是数据表里的元数据，渲染是 PL/SQL 调htp.p拼出来的 HTML。这份《Oracle APEX 深入浅出》要走的正是这条线，从 11g 上重装 4.2.5、Workspace 与 Schema 的账户映射，到 Grid Layout 布局、控件与 Dynamic Action、Tabular Form 多行增删改、文件上传下载，再到与 EBS 页面互调。适合已经在写 PL/SQL、要给业务快速搭一套 Web 录入和报表界面的开发者，也适合被 Form 个性化拖慢节奏、想换一种交付方式的人。

2. 从 11g 自带 3.0 到 4.2.5：重装、网关与 Workspace 的完整命令链

2.1 页面是元数据、渲染是 PL/SQL：先看懂这条请求链

很多人第一次接触 APEX 会把它当成 PHP 那类部署在 Web 服务器上的框架，于是习惯性地去找 war 包、找 Tomcat 目录，找不到就开始怀疑安装包不全。实际情况是：浏览器发出的 URL 请求先到 HTTP 监听程序，如果是 11g 自带的嵌入式 PL/SQL 网关，这一步就在数据库监听里完成；请求被解析成一次 PL/SQL 调用，数据库里的 APEX 引擎接手，做会话状态还原、认证、授权、页面流控制、校验、渲染，最后用sys.htp.p把 HTML 刷回浏览器缓冲区。

理解这条链路的价值很直接：备份 APEX 应用等于备份数据库里的那批对象，迁移应用等于在另一个库上导入导出，性能调优先看数据库会话和 SQL 而不是看 Web 容器线程数。页面本身是无状态的，每次请求都是新的数据库会话，所以“为什么我在页面上改了一个值，另一个区域没跟着变”这类问题，答案通常在会话状态（Session State）什么时候被提交，而不是在浏览器缓存。

下面这段过程能说明“页面”在数据库眼里是什么样子，它不依赖 APEX 引擎，只靠 PL/SQL 网关就能跑通：

-- 一个能被 DAD 映射到的存储过程，就是一张最原始的“页面” create or replace procedure hello_apex as begin htp.p('<html><body>'); htp.p('<h1>server time: ' || to_char(sysdate, 'yyyy-mm-dd hh24:mi:ss') || '</h1>'); htp.p('</body></html>'); end; /

htp.p往输出缓冲区写一段文本，网关在过程结束后把缓冲区一次性刷给浏览器，这就是 APEX 页面最终呈现的机制。区别只在于，APEX 的这段“过程”不是人手写的，而是根据存在表里的页面元数据动态拼出来的。

2.2 卸载旧版本：别让两代内部用户并存

11g 自带 APEX 3.0，直接装 4.2.5 会出现两套内部用户共存，元数据视图的前缀不一样（APEX_030200与APEX_040200），认证链路可能仍然指向旧的那一套。这就是开头那个“密码怎么改都进不去”的根因。所以安装顺序必须是先卸干净再装新版，而不是覆盖。

动手前先把现状摸清楚，这一步花两分钟，能省掉后面两小时：

-- 1) 当前有哪些 APEX 相关账户，状态如何 select username, account_status from dba_users where username like 'APEX%' or username in ('ANONYMOUS', 'APEX_PUBLIC_USER') order by username; -- 2) 当前注册的 APEX 版本（视图不存在说明版本更老） select version_no from apex_release; -- 3) 组件在注册表里的状态，VALID 才算装完整 select comp_id, comp_name, version, status from dba_registry where comp_id = 'APEX';

第一条查询的输出要重点看有没有APEX_030200这类旧版本用户；第二条如果报“表或视图不存在”，说明库里的版本比你能查到的视图还老，卸载脚本更要跑。确认之后执行卸载：

# 卸载脚本必须在 APEX 安装目录下执行，用 SYSDBA 连接 cd $ORACLE_HOME/apex sqlplus / as sysdba @apxremov.sql # 卸载脚本跑完后，把残留的安装文件清空，避免新旧脚本混在一起 # 注意：清空前确认当前目录确实是 $ORACLE_HOME/apex，这条命令不可恢复 pwd && rm -rf *

apxremov.sql会删除 APEX 内部用户及其全部对象，不可回退，务必先在测试库走一遍。清空目录那一步原文是直接rm -rf *.*，我建议先pwd确认路径，血泪经验：在$ORACLE_HOME根目录下敲这条命令的代价，不是重装 APEX 能解决的。

2.3 表空间、解压与安装脚本

给 APEX 单独建一个表空间，好处是引擎对象和业务数据分开，日后做表空间级备份、迁移、配额控制都方便。生产环境我不建议直接用 SYSAUX，虽然默认安装允许这么做：

-- APEX 引擎对象独立表空间，初始 100M，按 100M 自动扩，封顶 1G CREATE TABLESPACE APEX01 DATAFILE '/u01/app/oracle/oradata/ORCL/apex01.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE 1000M;

把安装包上传到$ORACLE_HOME下解压，然后跑安装脚本：

# 解压到 $ORACLE_HOME/apex unzip apex_4.2.5.zip -d $ORACLE_HOME cd $ORACLE_HOME/apex # 四个参数：引擎表空间、文件表空间、临时表空间、静态资源虚拟路径 sqlplus / as sysdba @apxins.sql APEX01 SYSAUX TEMP /i/

参数逐个说明：第一个APEX01是 APEX 引擎对象（包、视图、元数据表）存放的位置；第二个SYSAUX是用户上传文件（APEX_APPLICATION_TEMP_FILES之外的持久文件）所用表空间；第三个TEMP是排序和临时段；第四个/i/是静态资源（CSS、JS、图片）在数据库里的虚拟目录前缀，浏览器请求/i/...时由网关从这里取文件。四个参数写错任何一个，脚本跑到一半会停，报错信息一般很直白，按提示换参数重跑即可，不需要重新卸载。

装完立刻解锁账户并设置口令，这是最容易被跳过、又最容易导致“登录不了”的一步：

-- 匿名用户负责登录页本身的渲染，不解锁就打不开登录界面 ALTER USER ANONYMOUS ACCOUNT UNLOCK; -- 网关连接池使用的用户，不解锁 EPG 连不进 APEX 引擎 ALTER USER APEX_PUBLIC_USER ACCOUNT UNLOCK; -- 4.2.5 的内部用户，名称随版本变化，按实际查到的用户名替换 ALTER USER APEX_040200 ACCOUNT UNLOCK; -- ADMIN 口令：大写+小写+数字+特殊字符，长度 8 位以上 -- 特殊字符必须用双引号包住，否则 sqlplus 会当成语法符号 ALTER USER ADMIN IDENTIFIED BY "Apex#Dev_2024";

注意：ADMIN 是 APEX 应用层的超级管理员，和数据库的 SYS、SYSTEM 完全不是一回事。改 ADMIN 口令不会影响数据库账户，反过来，用数据库账户去登 APEX 登录页也永远登不进去。

2.4 嵌入式网关：端口、监听与 404

11g 自带嵌入式 PL/SQL 网关（EPG），不用装 Apache 也不用装独立监听器，配置成本最低。默认端口常常和已有服务冲突，我一般直接改成 8888：

-- 查看当前 EPG 端口 select dbms_xdb.gethttpport() from dual; -- 改成 8888，改完必须重启监听才会重新注册 HTTP 端口 exec dbms_xdb.sethttpport(8888);

# 重启监听，让新端口生效 lsnrctl stop lsnrctl start # 确认 HTTP 端口已经出现在监听列表里 lsnrctl status | grep -i http

改完端口不重启监听，是 404 的高频原因之一。另一个高频原因是安装脚本没跑完，静态资源目录没建，/apex/apex_admin这种带路径的地址就会返回 404。验证顺序建议固定下来：

# 先探登录页，返回 200 或 302 说明网关和引擎都通了 curl -I http://127.0.0.1:8888/apex/apex_admin

-- 仍然是 404 就回到数据库里确认组件状态 select comp_id, version, status from dba_registry where comp_id = 'APEX';

status不是VALID，说明安装中断过，重新跑apxins.sql比到处猜要快得多。

2.5 建 Workspace：把 Schema 挂到工程上

APEX 的账户模型是三层：ADMIN 在最上面，负责创建和删除 Workspace；Workspace 是一个“工程”，对应数据库里的一个 Schema；Workspace 内部再分管理员、开发者和最终用户三种角色。原文里把 Workspace 类比成项目、把 Application 类比成 EBS 里的一个 Form，这个类比是准确的，后续做权限隔离时全靠这一层。

以 ADMIN 登录后创建 Workspace 时，会让你选“使用已有 Schema”还是“新建 Schema”。这里有个选型判断：纯 APEX 开发，给 APEX 单独建一个 Schema（比如APEX_DEV），权限边界清楚；要和 EBS 集成、直接读写apps下的对象，才挂到apps上，但同时要接受一个事实——开发者在 APEX 里能碰到的对象范围，等于apps的权限范围。

-- 建完 Workspace 后核对映射关系，需要 DBA 权限 -- 视图名带版本前缀，不同版本前缀不同，先 desc 确认再查 select workspace_name, schema_name? from APEX_040200.APEX_WORKSPACES;

如果这条查询报视图不存在，不要怀疑装错了，先select view_name from all_views where view_name like 'APEX%WORKSPACE%'找到实际视图名。版本前缀（APEX_040200）是 APEX 内部用户的命名规则，升级大版本时会变，这一点在写运维脚本时要注意，别把前缀硬编码进去。

3. Grid Layout 翻译成 TABLE/TR/TD：布局、控件与 Dynamic Action

3.1 主题定骨架：Body 是 TABLE，Position 是 DIV

APEX 自带二十来个主题，选中主题之后页面的整体布局和 CSS 基本就定了，剩下能动的部分是主题开放出来的几个占位区域。原文提到的Body1、Body2、Body3和Position1到Position4是其中常用的几个，理解它们的关键是看渲染出来的 HTML 标签：Body 系列区域最终渲染成<table>，Position 系列渲染成<div>。

这个差异决定了布局方式。放在 Body 区域里的子区域，是按表格单元格排列的，你配置的每一个“列号”最终都会变成一个<td>；放在 Position 区域里的子区域，是块级元素，靠主题的 CSS 做浮动或弹性排布。所以看到设计稿上“三块内容一行排开、中间那块更宽”时，先判断它属于哪种容器，再决定是调 Grid Layout 还是改主题 CSS。

4.1.1 时代最让人难受的一点是：Column 属性在同一个 Body 内是全局的，子区域想重新排布几乎做不到。4.2.5 之后每个子区域都有独立的 Grid Layout 配置，可以重新起表、重新分行，这就是“页面布局变得相当 Easy”的实际含义。

3.2 三个开关：Start New Grid、Start New Row、Column

Grid Layout 只有三个配置项，但组合出来的行为足够覆盖大部分布局需求。先把它们和 HTML 的对应关系钉死：

原文那个六区域实例，配置抄下来是这样：

重点看 Search2 和 Search3：两者 Column 都是 2，但 Search3 的 Start New Row 是 Yes，所以它换到了下一行，落在第二列，视觉上就是“缩进了一格”。很多人在这里翻车，以为 Column 是绝对坐标，其实它只在当前行内有效，换行之后列号重新算。

提示：布局调不出来时，别在浏览器里反复刷新猜，直接看页面源码里那几个<table>和<td>的嵌套关系，比对着 Grid Layout 的配置看，一次就能定位是哪一层的 Row 没设对。

3.3 控件、事件、校验各管一段

APEX 的控件（文本框、下拉框、值列表、日期选择、报表）本身没有太多玄学，真正需要建立心智模型的是它周围那三组配置：属性管“长什么样、能不能空、什么时候显示”，事件管“用户操作之后发生什么”，校验管“提交之前拦不拦”。

属性里最常用的几个：Form Element Width控制控件宽度，Value Required是否必输，Condition Type决定控件是否显示（比如只有某个角色登录才显示审批按钮），Read Only Condition Type决定是否只读，Default Value设默认值，Format Mask做格式掩码（日期、金额）。这组配置的价值在于：大量业务规则不用写代码，配一下就落地了，这也是 APEX 声明式开发的核心卖点。

事件的主体是 Dynamic Action，它最实用的能力是执行 PL/SQL 而不刷新页面，效果上等价于一次 Ajax 回调。配置结构是三层：When（什么时候触发：事件类型、选择类型、具体元素、条件）、True Actions（条件为真时做什么）、False Actions（条件为假时做什么）。常见的动作包括显示/隐藏区域、设值、刷新区域、执行 PL/SQL。

校验的配置项是另一组：When Button Pressed指定哪个按钮触发，Condition Type加Condition Expression决定这次校验要不要执行（比如只有表里有数据才校验），Validation写具体逻辑，Error message display location决定错误提示显示在页面顶部还是字段旁边，Associated Item把错误关联到具体控件上，用户一眼能看到是哪一栏填错了。

3.4 从零复现一个页面：必填校验、日期默认值、区域联动

把上面三组配置串起来做一个能跑的页面：点查询按钮时校验文本框非空，但只有参照表里存在user_id='123'这条记录时才校验；页面加载时日期控件默认今天；第二个文本框有值时隐藏一个区域，清空时再显示出来。

先建参照表和测试数据：

-- 参照表：校验条件用的，字段结构照原样保留 create table demo_test ( user_id varchar2(50), resp_id varchar2(50), resp_appl_id varchar2(50), login_name varchar2(50), login_count number, login_date date ); insert into demo_test (user_id, login_name) values ('123', 'demo'); commit;

第一步，校验。在P1_X_TEXT上建一个 Validation，类型选Function Returning Boolean，触发按钮选SEARCH2_BTN，条件类型选Exists (SQL query returns at least one row)：

-- Condition Expression：只有这条查询有结果，校验才生效 select 1 from demo_test t where t.user_id = '123'

-- Validation Expression：返回 true 表示通过，false 表示拦截 begin if :P1_X_TEXT is not null then return true; end if; return false; end;

这里有个容易忽略的点：Function Returning Boolean的返回值语义是“校验是否通过”，返回false才会触发错误提示，错误信息配在Error message里。写成“值为空返回 true”就完全反了，页面会表现为“填了才报错”。

第二步，页面加载时给日期控件赋当天日期。建一个 Page Load 类型的 Dynamic Action，动作选Set Value，Set Type选SQL Statement：

-- 返回必须是一行一列，多行会报错，多列只取第一列 select sysdate from dual

Affected Elements选Item(s)，目标填P2_DATA。用 SQL 而不是固定值的好处是：默认值随数据库时间走，不受客户端时区影响。

第三步，文本框联动显隐。建一个 Change 事件的 Dynamic Action，Selection Type选Item(s)，元素是P2_X_TEXT，Condition选is not null，True Action 配Hide Region，False Action 配Show Region，目标都是new search2那个区域。

When : Event = Change, Selection Type = Item(s), Item = P2_X_TEXT, Condition = is not null True : Hide Region -> new search2 False : Show Region -> new search2

跑起来之后，输入内容区域消失，清空内容区域回来，整个过程没有页面刷新。真正要在生产里用，还得补一件事：被隐藏区域里的必填项仍然参与提交校验，用户会看到“明明没显示的字段报错了”。处理方式是在该字段的校验上加Condition Type = Item is not null，或者在隐藏的同时用另一个 Set Value 动作把它清空。

4. Tabular Form 与文件、EBS 集成：多行提交怎么写才不出 ORA 错

4.1 数据源为什么选视图

APEX 的 Tabular Form 允许在一个页面里批量编辑多行记录，一次提交完成多条更新，交互上非常接近 EBS 的块式 Form。原文强调它“基于视图去开发”，这不是风格偏好，而是由 APEX 的提交机制决定的：Tabular Form 提交时，APEX 会按报表的列生成一批 DML，如果数据源是基表，你能改的列就是基表的列；如果是视图，你能改的范围就被视图定义约束住了，多表关联场景下反而更安全。

代价是视图必须可更新。Oracle 对可更新视图的要求是 key-preserved：视图里参与连接的那个基表，连接列上必须有主键或唯一约束。否则提交时报ORA-01779: cannot modify a column which maps to a non key-preserved table，这个错误在 APEX 里不会告诉你哪张表缺约束，只能自己回推。

-- 基表：用户与班级 create table demo_class ( class_id number, class_name varchar2(50) ); create table demo_user ( user_id varchar2(50), login_name varchar2(50), class_id number ); -- 关键：连接列上必须有主键，否则视图不可更新 alter table demo_class add constraint pk_demo_class primary key (class_id); alter table demo_user add constraint pk_demo_user primary key (user_id); -- 可更新视图，作为 Tabular Form 的数据源 create or replace view demo_user_v as select u.user_id, u.login_name, c.class_name from demo_user u, demo_class c where c.class_id = u.class_id;

视图定义里只暴露了user_id、login_name、class_name三列，class_id这类内部字段不出现在界面上，这是用视图的第二个好处：界面和数据模型解耦，日后改表结构不影响已发布的页面。

4.2 Process 里遍历 g_f 数组的正确姿势

Tabular Form 提交后的数据不在普通页面项里，而在APEX_APPLICATION.G_F01到G_F50这组数组里，每个数组对应报表的一列，数组元素是该列每一行的值。这里有个必须记住的规则：数组编号按报表列的先后顺序分配，不是按字段名，也不是按你在数据源里写的顺序。

所以第一步不是写业务逻辑，而是确认编号。在 Process 里临时打一行调试信息，跑一次看 Debug 输出：

-- 临时调试：确认每一列对应哪个 g_f 编号 declare l_idx number; begin for i in 1 .. nvl(apex_application.g_f01.count, 0) loop apex_debug.message('f01[%s] = %s', i, apex_application.g_f01(i)); end loop; for i in 1 .. nvl(apex_application.g_f02.count, 0) loop apex_debug.message('f02[%s] = %s', i, apex_application.g_f02(i)); end loop; end;

确认完编号再写正式逻辑。下面这个 Process 挂在 Apply 按钮上，执行时机选On Submit - After Computations and Validations，做的事情是：逐行读取提交上来的班级名，先查班级是否存在，不存在就报错，存在就更新用户名并把记录写入一张日志表：

declare l_user_id varchar2(50); l_class_name varchar2(50); l_class_id number; begin -- 编号按实际调试结果替换，这里假设 f02 是 user_id、f03 是 class_name for i in 1 .. nvl(apex_application.g_f02.count, 0) loop l_user_id := apex_application.g_f02(i); l_class_name := apex_application.g_f03(i); -- 空行直接跳过，Tabular Form 会提交整表，包括没改动的行 if l_user_id is null then continue; end if; begin select class_id into l_class_id from demo_class where class_name = l_class_name; exception when no_data_found then -- 用 raise_application_error 才能中断提交并回滚，普通 raise 在 APEX 里行为不一样 raise_application_error(-20001, '班级不存在: ' || l_class_name); end; update demo_user set class_id = l_class_id where user_id = l_user_id; insert into demo_user_log (user_id, class_name, log_time) values (l_user_id, l_class_name, sysdate); end loop; end;

几个参数和写法上的说明。nvl(..., 0)不能省，报表没有数据时g_f02.count是空值，for 1 .. null在某些情况下会报错。raise_application_error与普通raise的区别很关键：前者会把错误信息推到页面并让整个提交失败，后者在 APEX 的 Process 上下文里可能被吞掉，表现为“点了按钮没反应也没报错”，这是排查起来最费时间的一类问题。日志表的插入放在 update 之后、同一个循环里，保证要么都成功要么都失败，不会出现“主表改了日志没写”的半截状态。

4.3 文件上传下载：BLOB 存表与 wpg_docload

文件上传在 APEX 里由“文件浏览”类型的页面项完成，用户选完文件点提交，文件内容不会直接进入你的表，而是先落在APEX_APPLICATION_TEMP_FILES这个会话级临时视图里，你在 Process 里把它读出来，再决定是写进 BLOB 表还是别的存储。

-- 文件表：主键用序列生成，11g 没有 identity 列 create sequence demo_files_seq; create table demo_files ( file_id number primary key, file_name varchar2(255), mime_type varchar2(255), blob_data blob );

-- 上传 Process：从临时文件视图取内容写入 BLOB 表 declare l_file apex_application_temp_files%rowtype; begin select * into l_file from apex_application_temp_files where name = :P3_FILE_ITEM; insert into demo_files (file_id, file_name, mime_type, blob_data) values (demo_files_seq.nextval, l_file.filename, l_file.mime_type, l_file.blob_content); end;

`where name = :P3

本文还有配套的精品资源，点击获取