在所有主题上，我都完全同意Nikunj！

此外，我的建议是与单独的所谓子组织合作， 参见此处：在多种环境中工作。

原则是，您将获得另一个URL（通过OSS消息请求，据我所知，没有额外的许可证）。 这个额外的URL只有一个"沙箱"，它是Development，应该连接到ECC-Dev系统。

从这里，您可以将数据流提升（=传输）到以下站点的"沙箱"中： 您的主要网址将作为质量系统，连接到ECC质量系统。 因此，您不需要创建单独的数据流。

从这里您将可以升级到"生产"，应该将其连接到ECC生产系统。

对于额外的子组织，您将需要一个额外的代理。 在主URL上添加一个代理：理论上，您可以在此处使用相同的代理，但是通常出于安全方面的考虑，公司会使用附加的代理，如Nikunj所述。
如果您的服务器在Linux上运行，则可以 在一台服务器上安装多个代理。 在Windows上运行时，您将需要单独的服务器。 而且，如果您已经在使用SDI代理进行基于订单的计划或将其他云产品的云连接器用于服务，则可以使用同一台服务器。
同样，出于安全原因，最佳做法是为该服务器使用单独的服务器 生产代理，无论使用什么操作系统。

-----

以IBP作为目标系统：我假设您只有两层IBP，即dev和production？ p>

然后，您可以将IBP-DEV连接到附加和主CPI-DS-URL作为数据存储，并在主URL上产生作用。 这意味着，您可以通过切换目标存储从ECC-DEV加ECC-Q加载到IBP-Dev。 只要您使用相同的计划区域，就不需要复制任何数据流。 只需确保您不会同时将相同的产品/位置加载到相同的版本中，否则在数据方面会出现不一致之处。

IBP-Production应该仅通过以下方式连接到ECC-Production： 主要的CPI-DS-URL，并且只有在升级为"生产"之后才能完全混淆？ 只需阅读在线文档…

如果您在此处中搜索CPI-DS，则您

-----

，即使您问自己为什么要使用sub- 组织：有几个原因。

一个是，您拥有更好的层级策略，并且所有内容都将井井有条，特别是如果您有许多数据流，更好的概览。 您将获得清晰的升级/传输路径，每个CPI-DS在ECC（或BW或APO或其他任何文件）中都有一个源系统。

此外，当您需要使用Web服务将数据从IBP写回ECC时，使用3个单独的CPI-DS区域要容易得多。

还有其他一些原因...

您的
Irmi