Oracle APEX流程类型介绍
# 把 APEX 的 Process Type 讲人话：从"我想干什么"出发，10 种流程怎么选
做 Oracle APEX 久了会发现，新手配 Process（流程）时最常见的困惑不是"某个类型是什么意思"——官方文档一句话就写了——而是**"我这个需求，到底该用哪个类型？"**。官方文档是按类型罗列的，可我们干活是按任务来的。所以这篇我换个角度：不背类型清单，而是从**你实际要做的事**出发，把 APEX 内置的流程类型一个个"对号入座"，顺带把我踩过的坑和选型判断一并说了。
读之前先记住一个大前提，它能帮你省掉一半的纠结。
## 一个前提：流程分两种"战场"
APEX 的流程其实活在两个完全不同的场景里，混淆它俩是新手最大的坑：
- **页面上的流程**：挂在某个页面的处理时机上（比如点了"提交"之后），干的是"这一下要做什么"——存库、发信、调接口。
- **工作流里的活动**：画在 APEX Workflow 流程图里的节点，干的是"整条流程怎么走"——从哪开始、到哪结束、遇到条件往哪拐、要不要停下来等一等。
同样叫 Process，这两类的思维方式不一样。下面我按"任务"来讲，每讲一个都会标明它属于哪个战场。
---
## 场景一：我要动数据库 / 跑一段逻辑
**→ 用 Execute Code（页面流程）**
这是你会用得最多的一个，没有之一。表单填完点提交，要把数据写进表、要算点东西、要调自己写的 PL/SQL——都靠它。本质上它就是给你一个能直接跑 PL/SQL 的口子，里面可以随手引用页面上的值。
一个最朴素的例子，提交后插一条记录：
```plsql
insert into t_order (customer, amount, created_by, created_at)
values (:P10_CUSTOMER, :P10_AMOUNT, :APP_USER, sysdate);
```
**我的经验**：别把几百行业务逻辑全塞进这个框里。APEX 的流程框适合写"调用"，不适合当代码仓库。正确姿势是把逻辑写成数据库里的存储过程/包，这里只写一句 `my_pkg.do_something(...)`。好处是能复用、能单测、改起来不用在 APEX 界面里翻。
---
## 场景二：我要调一个已经写好的过程 / 对接外部接口
**→ 用 Invoke API（页面流程）**
当你要调的东西"已经存在"——要么是数据库里现成的存储过程/函数，要么是外部的 REST 接口——这个类型比 Execute Code 更省心。因为它会**自动把参数列出来让你一一映射**，不用你手写调用、也不容易把参数名拼错。
对接外部 REST 的正确顺序是：先去 `Shared Components → REST Data Sources` 把接口（地址、鉴权）定义好，再用 Invoke API 去"发起那个操作"，流程本身只管映射进出参数。
**我的判断**：调数据库存储过程时，Invoke API 和 Execute Code 都能做，但**优先 Invoke API**——参数映射是可视化的，出错率更低。手写 `begin ... end;` 调用只在逻辑需要拼装时才用。
---
## 场景三：我要通知到人
这里有两个类型，看你是"发邮件"还是"发推送"。
**→ 发邮件用 Send E-Mail（页面流程）**
能发正文（纯文本或 HTML）、能带附件，正文里可以用 `&P10_NAME.` 这种写法把页面上的值拼进去。常见于：提交后给管理员发通知、审批结果外发、附带报表。
**这里有两个坑，官方文档一笔带过但很致命**：
1. 能不能发出去，**取决于 APEX 实例级的 SMTP 配置**——这是管理员在实例设置里配的，你应用里配得再好，SMTP 没通照样发不出去。
2. APEX 发信是**异步的**：它底层走 `APEX_MAIL`，邮件先进队列、由后台作业稍后发出。所以你点完提交邮件不会"秒到"，调试时别干等，去邮件队列/日志里看状态。
**→ 发推送用 Send Push Notification（页面流程）**
面向具体用户发 Web 推送，该用户**订阅过的所有设备**都会收到。多用在 PWA 场景。前提是用户确实在支持的浏览器上**订阅**了你这个应用的推送——没订阅，发了也收不到。这个功能对环境（浏览器、HTTPS、订阅机制）有要求，不是开箱即用，上线前先验证。
---
## 场景四：我要把地址变成坐标
**→ 用 Server Side Geocoding（页面流程）**
表单里填了街道、门牌、邮编、城市，想自动算出经纬度放地图上——这个类型就是干这个的。它在服务端调 Oracle 的地理编码服务，把**第一个匹配到的地址**的坐标写回你指定的页面项；还能把所有候选结果塞进一个 Collection 让你后续处理；如果开了"地址清理"，它会用标准化后的地址**反过来覆盖**你页面上填的地址字段。
**最重要的一句话（也是最大的坑）**：它**只能在 Oracle Autonomous Database（ADB）上用**。你要是跑在普通数据库或本地库上，这个类型根本用不了，得另找地理编码方案。选型前先确认你的库是不是 ADB，别设计到一半才发现用不了。
---
## 场景五：我在画工作流，要控制流程怎么走
下面这几个都是**工作流活动**，只在 APEX Workflow 里有意义，别拿去当页面流程用。
**起点和终点：Workflow Start / Workflow End**
- `Workflow Start` 是流程图的入口，启动整条工作流。
- `Workflow End` 是出口，而且能区分"怎么结束的"：结束状态设成 `Completed` 就是正常跑完，设成 `Terminated` 就是被中止。给流程设计好正常出口和异常出口，靠的就是它。
**遇到条件要分叉：Switch**
相当于流程图里的菱形判断块。它按条件算出一个结果，工作流根据这个结果决定下一步走哪条路。审批流里"金额大于 X 走高级审批、否则走普通审批"就是典型用法。
**需要停一下：Wait**
让工作流暂停。两种叫醒方式：一是设个**超时时间**到点自动继续，二是外部代码调 `APEX_WORKFLOW.CONTINUE_ACTIVITY()` 主动把它唤醒。适合"等外部系统回调""等人工处理完""延迟一段再继续"这类需求。
**想复用子流程：Invoke Workflow**
在一个工作流里调用**另一个工作流**。把常用的子流程拆出去独立维护，主流程里一句调用——工作流也能模块化，这就是手段。
---
## 还会冒出来的"插件类型"
如果你在类型列表里看到名字后面挂着 `[Plug-in]` 的，那是**插件型流程**，来自你这个应用共享组件里装的流程类型插件，不是 APEX 自带的。所以有时候"同事那有、我这没有"，不是版本问题，是人家装了插件——去 `Shared Components → Plug-ins` 一看便知。
---
## 一张表，回头能查
| 你想干的事 | 用哪个 | 属于 |
| :--- | :--- | :--- |
| 写库 / 跑 PL/SQL | Execute Code | 页面流程 |
| 调现成存储过程 / 外部 REST | Invoke API | 页面流程 |
| 发邮件（可带附件） | Send E-Mail | 页面流程 |
| 给用户发推送 | Send Push Notification | 页面流程 |
| 地址转坐标（**仅 ADB**） | Server Side Geocoding | 页面流程 |
| 工作流起点 / 终点 | Workflow Start / End | 工作流活动 |
| 工作流里按条件分叉 | Switch | 工作流活动 |
| 工作流里等待 / 延时 | Wait | 工作流活动 |
| 工作流里调子流程 | Invoke Workflow | 工作流活动 |
---
## 我自己的选型顺序
每次配流程，我脑子里大致是这么过一遍的，分享给你：
1. **先问这是"页面上的一下"还是"整条流程的编排"**——前者在页面流程里选，后者去画工作流。
2. 页面上的一下，**要调的东西是否已经存在**？存在（存储过程/REST）就 Invoke API，不存在、要现写逻辑就 Execute Code。
3. **是通知类**吗？邮件 Send E-Mail、推送 Send Push Notification，并提前确认 SMTP / 订阅这些前置条件。
4. **地址转坐标**单独记住一条：先确认是不是 ADB。
5. 到了**工作流**里，就用 Start/End 定边界、Switch 做判断、Wait 做暂停、Invoke Workflow 做复用。
---
## 几句收尾的实在话
- 复杂逻辑往数据库 PL/SQL 包里放，流程里只做调用——这一条能让你后面省很多事。
- Send E-Mail 记住"靠实例 SMTP + 异步发送"，别对着界面干等。
- Server Side Geocoding 记住"只认 Autonomous Database"。
- 善用流程的**服务端条件**控制它执行不执行，用**成功/错误提示**给用户明确反馈。
> 不同 APEX 版本在流程类型的数量和细节上会有出入，具体以你所用版本的 Builder 实际界面为准。欢迎在评论区补充你踩过的坑。
-- 刘轶鹤
