What are the kind of challenges faced when we migrate/move from versions of ATG commerce (<10) that were not using EndecaExp Manager to versions that use it. For ex, would all the JSPs undergo a change in the way they are rendered, given that the pages will now have to be template driven ?
What would be some best practices here to have a minimum impact of the move on the UI & maximize the reuse of the JSPs ?
I have read the migration docs but they do not seem to cover this aspect.
如您所知，ATG 和 Endeca 才真正开始在 ATG 10.2.x 中集成。因此，在旧版本的 ATG 中，集成需要开发人员做更多的工作。我已经完成了 ATG 9.2 和 Endeca 3.1.2 的实现。您的问题实际上应该是您距离迁移到与 Endeca 很好集成的 ATG 的更高版本还有多远，以及在这样的迁移之后您希望保留多少当前系统？这一点很重要，因为这意味着您要么需要构建一个模仿ATG 汇编器管道功能的解决方案（在与 Experience Manager 集成时让您对模板和插件具有最大的控制权），要么需要构建一个基于InvokeAssembler 小滴的侵入性较低的方法。
要考虑的另一件事是您希望通过 Experience Manager 渲染多少。通常你会做主页和类别页面。产品详细信息页面会调用 Experience Manager 中的某些组件（例如面包屑），但索引中的数据通常不如数据库中的数据准确（例如库存水平），因此对于 PDP，您可以直接转到存储库. 您也不太可能在 Experience Manager 中构建结帐流程。这应该告诉您您可能会保留大量现有页面。
您最快的方法是构建一个 droplet，它将从 Experience Manager 中检索您的 contentItems，然后开始呈现它们。请记住，内容项只是经过美化的 JSON 响应，因此您可以在获取它们时轻松解析它们。