基于QuickFix/J的Acceptor接收CSV订单并回传执行报告至Initiator的方案咨询

结合你的业务需求和技术栈（QuickFix/J），先分析你提到的两个方案的问题，再给出更优的实现思路：

现有方案的问题 #

• 方案一（独立Initiator复用A的标识）：QuickFix/J的Acceptor会将执行报告回复给当前建立会话的Initiator（即你的独立进程），而非原应用A。若要让B将回复路由到A，需大幅修改B的会话路由逻辑，额外维护会话关联关系，复杂度较高。
• 方案二（简单Socket客户端发二进制FIX消息）：QuickFix/J的Acceptor依赖完整的FIX会话机制（登录协商、心跳维持、序列号同步等），直接发送裸二进制FIX消息会因会话未建立、序列号不匹配等被B拒绝，无法正常处理订单。

最优实现方案：在Acceptor B内部扩展CSV处理逻辑 #

直接在B中添加CSV上传解析模块，复用A与B已有的FIX会话回流执行报告，是改动最小、最稳定的方案，具体步骤如下：

1. 在B中新增CSV上传入口：比如开发HTTP接口或文件上传服务，接收用户上传的CSV订单文件。
2. 解析CSV生成模拟FIX订单：将CSV每行数据转换为符合规范的NewOrderSingle FIX消息，设置消息的SenderCompID=A的标识、TargetCompID=B的标识、BeginString与原会话一致，同时确保ClOrdID（客户订单ID）全局唯一，避免与A发送的订单冲突。
3. 直接送入B的业务处理流程：将生成的FIX订单绕过B的FIX会话接收逻辑，直接传入业务处理模块（无需经过QuickFix/J的接收消息解析流程）。
4. 复用现有会话回流执行报告：B处理完成后生成的执行报告/拒绝信息，会自动通过A与B已建立的FIX会话发送给A（因为执行报告的TargetCompID=A），A作为Initiator可直接接收并处理这些消息。

关键注意点 #

• 若B的业务逻辑依赖FIX会话上下文，需为模拟订单构造对应的上下文参数，或修改业务逻辑使其仅关注订单内容而非来源。
• 确保模拟订单的字段完整性（如价格、数量、合约代码等）与A发送的订单一致，避免业务处理异常。

备选改进方案（若需独立进程） #

如果必须使用独立进程处理CSV，可对方案一做如下修改：

• 在独立Initiator发送的FIX订单中添加自定义字段（如OrigSource=CSV_UPLOAD）标记来源。
• 修改B的消息处理逻辑，当收到带有该标记的订单时，生成执行报告后不回复当前会话，而是通过A与B的原FIX会话发送给A（需在B中维护与A的会话实例引用）。

内容的提问来源于stack exchange，提问作者Yoshiro