D365商务中最常见的挫败感听起来看似简单：
“我更新了一个产品（或图片）。为什么在电子商务中看不到？”
简短回答：
因为D365商务使用异步模式来实现性能和缓存。
稍微长一点（也更诚实）的回答是：
因为你的“简单更新”现在必须经过一个小障碍，包括作业、同步进程、缓存和服务——这些任务分布在多个系统上——才能获得出现在商店界面的权利。
这篇文章将详细介绍实际发生的事情、你需要做什么，以及——最重要的是——你在时间安排上现实中应该预期的事项。
从高层来说，更新通过三层流动：
- 创作层
- D365 F&O（产品数据）
- 网站建设器（内容、图片、CMS）
- 分配层
- 商业规模单位（CSU）
- CDX职位
- 展示层
- 电子商务前端（缓存，CDN 支持）
第一步：F&O产品更新
在F&O中，通常会：
- 更新产品名称、属性和价格
- 分配类别
我假设你的类别已经关联到某个系列（如果没有，那就是你的第一个问题）。
还值得一提的是：
从技术角度看，D365商务部主要针对产品，而不是你在F&O中理解的“已发布产品”。数据来源于此——但商务部的消费方式不同。所以“F&O看起来正确”并不保证任何问题。
在做其他事情之前，先确认：
- 产品发布并分配到一个类别
- 产品/类别包含在一个组合中
- 商品组合与正确的电子商务渠道相关联
- 填充了必需属性
然后运行你的分发任务：
- 1040 – 产品
- 1150年——目录
- 1070 – 通道配置（有时需要）
或者，如果你觉得高效：
- 9999 – 全同步（三角）
这会将来自F&O→CSU的数据推送。
时间安排：
- 手动运行：~1–3分钟
- 批次（反复出现）：通常5–15分钟
所以不，它不会“立即”显示出来。
步骤2：图片和网站建设器（让事情感觉像实时……直到不再是）
下一站：网站建设器。我猜你用的是全渠道媒体管理——因为2026年的其他操作都是自我施加的痛苦。
给你：
- 上传图片
- 将图像映射到产品
是的——这部分很重要：
你必须同时发表：
- 媒体资产
- 产品-介质映射
保存不是发布。预览不是上线。我们都吃过亏。
第三步：隐藏往返（CMS → F&O）
这里有大多数人意想不到的部分：
在电子商务中任何内容显现之前，F&O中的批量作业必须运行：
- CMS与总部的全渠道媒体同步
这份工作：
- 从CMS拉取媒体映射
- 在F&O中存储引用
是的——正确：
你的产品图片在电子商务使用之前，实际上已经在F&O注册。
这也解释了为什么：
- 你可以（带扩展）在 F&O 里 Surface，电商图片
- 还有为什么错过这份工作会导致……什么都没出现
典型配置：
- 每~5分钟作为批处理作业运行一次
第四步：然后返回（F&O→CSU……再说一次）
此时，你可能合理地认为自己已经完成了。
你不是。
现在F&O已经收到了媒体映射，你必须再次发送：
- 运行1040（或9999)
为什么？
因为电子商务并不是直接读取CMS。
它是读取CSU，CSU读取F&O。
所以流程是：
CMS → → CSU →电子商务
虽然不算直观，但非常稳定。
步骤5：搜索索引和缓存（最终Boss）
运行1040有两个重要作用：
- 更新CSU的产品+媒体参考
- 触发产品搜索索引
这些索引为Azure AI Search提供能量，从而驱动产品搜索结果。
所以：
- 直接产品网址可能先于搜索功能
- 搜索结果可能会落后
还有缓存。
摘自Microsoft自身流程：
- 产品数据的缓存TTL可长达2小时
- Azure AI 搜索索引可能需要相当长的时间
现实观察：
- ~10,000个产品→索引每个通道可耗时1+小时
是的，按频道。
重要结论
请先：
- 上传和发布媒体
- 同步CMS→F&O
- 再运行一次CDX。
- 等待搜索索引
- 让缓存功能过期
… 这样你的产品可能会出现在你预期的位置。
最终的现实检验
D365商务最终是稳定的。
不是“稍微延迟”。
不是“近实时”。
最终。
如果你把它当作实时系统来看待，你将花费时间：
- 重发作业
- 二次猜测配置
- 并且积极刷新浏览器
而不是仅仅了解自己处于流程中的哪个位置。
这就是猜测和准确知道为什么还没有任何东西出现的区别。
所以最终结论是，如果你做得都正确;明天再检查一下你的电子商务网站。
D365 eCommerce : Do you get the picture ?
转载请注明：ww12345678 的部落格 | AX Helper » D365 eCommerce : 如何正确设置图片资源 ?