EBS并发文件如何传输到应用服务器，有哪些方法？

EBS并发管理器生成的请求日志和输出文件，默认存放在并发管理器所在节点的本地文件系统，由应用服务器通过FTP或HTTP协议实时读取，供客户机浏览器下载查看。

要排查“EBS并发文件打不开”或“请求输出一片空白”这类问题，关键不在于“文件怎么同步”，而在于“文件在哪个节点、路径对不对、权限通不通”，下面从存储机制、访问链路、多节点场景和故障排查四条线展开。

加载中

个人如何申请正规的刷卡pos机，以及都有哪些乱收费的套路！一条视频，让你成为专家！

扬

扬州Pos服务商老陈

5313--

原视频地址

先看清一个事实：并发文件不在数据库里，也不在应用服务器的“某个共享盘”上

很多刚接手EBS运维的同学，习惯性去数据库查V$或APPLSYS的表，想找到请求输出的内容，结果什么都捞不到，行业共识认为：EBS并发请求的所有输出文件，包括.log日志、.out输出、.rdf报表文件，都是操作系统级别的普通文件,由并发管理器直接写在它所在节点的本地目录中。

这个目录不是随机分配的，而是由环境变量APPLCSF决定，默认情况下，APPLCSF指向$INST_TOP/admin/out这个路径,如果你在服务器上执行：

echo $APPLCSF

得到的路径就是并发输出文件的老家，在这个目录下，你会看到以请求ID命名的文件，例如out、req,它们分别对应某一次并发请求的标准输出和日志记录。

所以第一个结论非常重要：文件就在并发管理器跑的那台服务器上，如果你的EBS是多节点部署，应用服务器和并发管理服务器不是同一台机器，那“文件怎么到应用服务器”就成了一个跨节点的网络传输问题。

为什么你在浏览器里能下载到文件？这不是同步，是“随取随用”

EBS的架构里，用户通过浏览器访问应用服务器上的OAF页面或Oracle Forms界面，点击“查看输出”或“查看日志”时，应用服务器并不会提前把并发文件捞到自己本地，而是在收到请求的那一刻，通过内置的FTP或HTTP服务，去并发管理器所在节点把文件抓过来，再通过HTTP响应流回传给浏览器。

这套链路涉及三个角色的配合：

• 并发管理器节点：负责跑请求、写文件,文件留在本地。
• 应用服务器节点：负责接收浏览器的查看请求,启动FTP客户端去并发节点取文件。
• 浏览器端：只负责接收应用服务器转发过来的字节流,本身不直接连并发服务器。

也就是说，文件并没有被“推送”到应用服务器，而是应用服务器临时充当了一个“二传手”，这个机制带来的直接后果是：如果两个节点之间的网络不通、FTP端口被封，或者并发节点上的文件被手动删掉，用户在浏览器里就永远看不到输出。

多节点部署时，文件访问的完整路径要一步一步捋

在实际生产中，特别是做RAC或负载均衡集群时，应用服务器和并发管理器经常分散在不同物理机上，这时“并发文件怎么到应用服务器”的理解,需要落实到一条具体的访问链路上。

比如你有一个两节点的EBS环境：

• 节点A：运行HTTP Server和Forms服务,负责处理用户浏览器请求。
• 节点B：运行并发管理器,负责执行请求并写输出文件。

用户在浏览器点击某个请求的“查看输出”按钮时,发生的实际动作是：

1. 应用服务器（节点A）在收到查看请求后,先从数据库并发管理器的元数据表中查到该请求对应的输出文件路径和文件名。
2. 节点A根据配置文件FNDFS_SERVER或环境变量中的信息,得知并发管理器运行在节点B上。
3. 节点A建立到节点B的FTP连接，按照查到的路径去读取对应的.out文件，被拉取回节点A后,应用服务器再以HTTP响应的形式输出到用户浏览器。

这条链路中，任何一个环节出问题，用户看到的都是“无法获取输出文件”或“请求输出为空”。

各检查点优先级排序

根据故障出现的频率,建议按以下顺序排查：

• 第一优先：检查.out文件是否真实存在，很多请求状态显示“已完成”,但输出文件在清理磁盘时被误删了。
• 第二优先：确认应用服务器和并发管理器之间的FTP连接是否正常，测试方式很简单,在节点A上手动执行FTP命令去连节点B。
• 第三优先：核对文件系统路径是否存在权限问题，特别是APPLCSF目录的所有者和权限位。
• 第四优先：检查应用服务器的配置文件$FND_TOP/resource/FNDSVC.env或manager.env中的FTP端口设置。

单节点部署也别掉以轻心，文件权限是隐形杀手

如果EBS应用和并发管理器在同一台服务器上，文件跨节点传输的问题就不存在了，但另一个问题会频繁出现：权限错乱。

并发管理器以APPL系统用户运行，写出来的文件归属applmgr:applmgr，但当应用服务器的HTTP进程以nobody或oracle用户身份去读文件时，如果APPLCSF目录权限是700，HTTP进程就没有任何访问权限，结果就是用户能查日志元数据,但下载不了实际内容。

这种情况最常见的表现形式是：

• 请求状态“正常完成”，点“查看日志”时浏览器卡住,过一会儿报超时。
• 下载链接生成，但点击后文件内容为空或提示“文件不存在”。
• 管理员在服务器上用applmgr用户能看到文件,但浏览器始终打不开。

这类问题不是并发文件“怎么到应用服务器”的传输问题，而是“应用服务器以什么身份读文件”的权限问题，解决思路是检查

APPLCSF目录的权限设置，行业专家指出，保持目录为755或最低750，并确保HTTP进程所属用户在文件所在组的读权限范围内,是规避此类故障的有效手段。

与数据库服务器的关系：并发文件在那里永远找不到

经常有运维人员混淆EBS三层架构中各层的职责，数据库服务器上跑的是Oracle数据库实例，存储的是表、索引、包、视图等数据库对象，并发管理器生成的输出文件，本质上是文本文件或PDF文件，它们绝不会出现在数据库的FND_CONCURRENT_REQUESTS表的任何大数据字段里。

你以为“文件在数据库里”是因为Oracle EBS的诊断页面里能看到请求的CLOB输出片段，没错，某些请求（特别是SQLTrace输出和XML Publisher报表）会把结果同时写入数据库表FND_CONCURRENT_REQUEST_OUTPUTS，但这个写入仅限于特殊类型请求，且写入的是结构化数据,不是完整的物理文件。

想要验证这个区别,你可以做一个简单实验：

1. 跑一个输出内容为几行文本的简单并发请求。
2. 去服务器的$APPLCSF目录找到对应的.out文件，用cat命令查看内容。
3. 再登录数据库查询FND_CONCURRENT_REQUEST_OUTPUTS表,看是否有相同内容。

绝大多数情况下，你在数据库表里什么都看不到，或者只能看到一条记录引用,物理内容全部在操作系统文件里。

如何跨节点让并发文件“落”到应用服务器的本地盘？直接改环境变量

有些企业有合规需求或审计要求，希望并发输出文件能统一汇总到应用服务器的固定目录，方便备份，这里没有现成的同步Agent，最常见的做法是修改并发管理器节点上的APPLCSF环境变量，把它指向一个网络共享目录。

具体操作步骤：

1. 在应用服务器上创建共享目录，比如/u01/app/ebs_shared/out。
2. 通过NFS协议把这个目录挂载到并发管理器节点的同一路径下。
3. 修改并发管理器启动脚本中的APPLCSF变量,指向这个共享路径。
4. 按顺序重启并发管理器,让新环境变量生效。

前提条件是这个共享目录对两个节点可见，且写入权限归并发管理器运行用户所有，这个方案的落地效果是：并发文件写入共享目录后，应用服务器本地路径直接可见,不再需要FTP回拉。

但要注意，NFS挂载点如果发生脱落，或者网络抖动，并发管理器可能会报错“无法写入输出文件”，所以在实施这个方案前,需要权衡可用性和合规压力。

不同查看方式的路径差异不能忽略

用户查看并发文件有两种入口,底层走的是不同的访问通道。

在Forms界面查看时，客户端直接通过应用服务器的FNDFS功能定位文件，它调用的是内置的FTP协议，这个通道依赖FNDFS_SERVER配置参数。

在OAF（HTML）界面查看时，应用服务器通过fnd.output这个Java服务去拉取文件，走的同样是FTP，但解析路径的逻辑略有不同，涉及LocalOutputDir的定义。

如果你发现“Forms里能看，HTML里看不了”，大概率不是文件本身的问题，而是两个查看入口各自依赖的服务或参数不一致，排查时不要一头扎进文件系统,先去官网文档查对应的Profile选项在不同界面里的默认值差异。

Q&A：EBS并发文件访问常见问题排查

并发请求显示已成功，但查看日志时提示“无法获取输出文件”，是怎么回事？

这个提示几乎可以断定.out或.log文件在并发管理器节点上不存在，或者文件路径与数据库中记录的路径不一致，排查思路：登录并发管理器节点，用请求ID去$APPLCSF目录查找对应文件，文件存在则检查文件权限和属主,文件不存在则回溯请求运行过程中是否有手工清理或磁盘空间满导致写入中断。

多节点环境里应用服务器和并发管理器分开部署，第一次配置后要看哪些文件？

核心是看应用服务器的环境变量文件$APPL_TOP/admin/adop_context.txt或$INST_TOP/appl/APPS_节点名_主机名.xml，重点核对APPLCSF值（指向并发节点的输出目录）、FNDFS_SERVER、以及HTTP服务器配置中的FTP端口映射，配置完成后，在应用节点执行ftp 并发节点IP来验证链路可达性,再通过运行一个测试并发请求来验证端到端访问。

并发输出文件能在数据库表里永久保存吗？

不能，EBS的物理文件输出永久存在操作系统层，数据库只记录请求元数据和部分特殊类型的CLOB内容，行业共识认为，依赖数据库表去“永久保存”输出文件是不符合架构设计的做法，正确的归档方式是定期备份$APPLCSF目录，或将输出重定向到专用文件服务器，数据库的FND_CONCURRENT_REQUEST_OUTPUTS表只适用于少数将XML输出存库的特定请求类型,无法覆盖通用文本日志和报表文件。