在很多基于 RAP 的应用里，action不只是执行一段后端逻辑，它经常承担一种更贴近业务的交互：用户点一个按钮，系统先弹出popup让用户补充一些上下文信息，接着才真正开始处理数据。典型例子就是 Excel 导入：用户上传文件只是第一步，导入前往往还需要输入备注、选择是否试运行、指定生效日期、选择目标组织等。
麻烦点在于：这些popup里的字段并不天然受 RAP 业务对象字段的mandatory规则约束。你会看到界面上字段可以留空，用户一路点确认，直到后端逻辑跑起来才发现缺参数，体验和可维护性都不太理想。
下面用一个 Excel Upload 的场景，把popup必填字段的落地方式拆开讲清楚，并给出两条可选方案：一条偏快速校验，一条偏长期可持续建模。
场景：Excel 导入前的参数弹窗，为何必填不生效
在 Report Pattern 类的应用里，常见交互是：
- 用户触发
Load Excel之类的action - UI 弹出参数对话框（
popup），让用户输入EventComment、选择TestRun - 确认后才执行后端导入逻辑
RAP 里，业务对象字段的必填通常写在 behavior definition（BDEF）里；但这里的字段并不一定属于
