BizTalk Mapper通过循环路径自动推导迭代次数：拖拽源/目标循环字段即可，输入几个节点就生成几个；多源循环需用Table Looping+Extractor Functoid，否则静默丢弃。
循环路径怎么自动生效？
BizTalk Mapper 不需要手动写 for 循环，它靠「循环路径」自动推导迭代次数：只要把源架构中一个 循环记录 的字段（比如 /Root/Order/Item）拖到目标架构中对应的 循环记录 字段（比如 /Root/PO/Line），Mapper 就会根据输入 XML 中该节点的实际出现次数，生成等量的目标节点。
- 输入有 5 个
Item，输出就生成 5 个Line；输入是空的，目标节点也不会创建 - 这个行为由 XSLT 编译器在编译映射时静态分析决定，不是运行时动态判断
- 如果源和目标的循环层级不匹配（比如一对多、多对一），Mapper 会静默选第一个路径，或报 Warning —— 这就是最常被忽略的隐患
多个循环源合并时为什么只取了一个？
当你试图把两个不同来源的循环记录（例如 /Root/Survey1/Address 和 /Root/Survey2/Address）都连到同一个目标循环节点 /Root/Master/Address，Mapper 会检测到「多个循环路径」，并默认只走第一个链接（通常是先拖的那个），其余被丢弃。
hermes-dingtalk-media
下载
在处理 Hermes Agent 钉钉媒体投递功能时使用：从钉钉机器人发送图片或文件、修复 MEDIA 附件处理逻辑、调试 dingtalk-bot 配置文件、robotCode 相关问题、流式模式（Stream Mode）回调、media_id 上传流程、群聊与单聊机器人端点的差异，以及验证钉钉原生照片/文件附件。
- 现象：目标只生成 Survey1 的地址，Survey2 的完全消失
- 编译时会出现警告：
Multiple looping paths detected. Using the first one. - 正确解法不是硬连，而是用
Table Looping Functoid+Table Extractor Functoid统一收口
Table Looping Functoid 怎么配才不翻车？
Table Looping Functoid 是处理多源/复杂循环的刚需组件，但它的输入参数顺序和含义极易配错：
- 第一个输入参数必须是源循环记录（如
/Root/Orders/Order），这是控制循环次数的唯一依据 - 第二个输入参数必须是整数，代表你后续「表网格」里要定义的列数（最大
228），不是行数 - 后续所有输入参数，按顺序填入表网格中每列的值：常量、字段引用、函数输出都行，但顺序必须和列序严格一致
- 漏掉第二个参数（列数）会导致编译失败；顺序错一位，整个表提取结果就会全部偏移
为什么 Table Extractor 总连不上目标字段？
Table Extractor Functoid 只能从左往右单向接收数据，且**只能连到目标架构的叶子字段（不能连到记录节点）**：
- 错误操作：把 Extractor 拖到
/Root/Address（记录）上 → 链接灰色不可用 - 正确操作：必须拖到
/Root/Address/Street、/Root/Address/City等具体字段上 - 每个目标字段需单独配一个 Extractor；6 个字段就要放 6 个 Extractor，并分别设置「列索引」（从 0 开始）
- Extractor 的第一个输入参数必须是上游
Table Looping Functoid，否则无数据可提
Table Looping Functoid 那几个看似随意、实则位置敏感的输入参数。 
