以前の投稿 で示した設計をアップデートしました。一応実装済みで形にはなっていますので（非公開ですが）、少し振り返りたいと思います
冒頭の画像がそのものです。大きな変更点としては
- エントリーポイントを AEM に移行（Workflow から起動）
- XML の生成は AEM のカスタムファンクションで実行する
こんなところです
これにより、UI は Workflow で完結でき、 ビジネスロジックの側面が強い CF-> xml 生成は AEM 、組版に関わる処理は中間処理+ IDS という分かりやすい棲み分けで見通しが少し改善しています
以前の投稿 で示した基本的な考え方まで変わっているわけではありません。逆にこの基本方針のままで実装を進めたことでその有効性が確認できた、とも言えるのではないかと考えております。すなわち、 「AEM と IDS を疎にするとともに、中間に据えた汎用言語に処理を寄せて ExtendScript は低依存にする」という点です
実は今回の開発中、 IDS のバージョンを 16.4 -> 17.0 へアップグレードしているのですが、これにより生じた対応の大半はテンプレートのアップデートでした。もし AEM と IDS が密でさらに ExtendScript への依存度が高かった場合、テンプレートだけでは済まず、それ以上に工数が増大してしまうなどの弊害が出ていた可能性はあるかと思います
とはいえテンプレート(template.indd)も XML 流し込みを想定した特別仕様だったので、そのアップデートも楽ではなかったのですが、それでも当初方針で狙った通り設計上の利点が活かされたとは言えるかと考えているところです
逆に、 AEM のほうがアップデートしたときにも疎結合である点は有利に働くのではないかと推測しています。その際に改修する必要性が出る可能性のある領域は中間処理(当ケースの場合 Node.js) に留まるはずであり、 ExtendScript までもを改修しなくてもよいはずだからです
XML Documentation for AEM
このような機能があります
この機能と上記の連携機構も相性がいいかもしれませんね。 XML のオーサリングはこの機能を使い、組版データとして出力したい時などがユースケースとして考えられます
InDesign にインポートさせる時は InDesign の仕様に則った様式である必要はあり、変換の必要はあろうかと思いますが、そこは自動化できるケースも少なくないでしょう。 上記にならって AEM で WF -> XML to XML というふうにすれば、中間処理以降の仕組みはほぼ同じでいけるかもしれません
そのようなことを想定した場合、中間処理と IDS(ExtendScript) が特定のビジネス事情に特化していないよう汎用的に設計できていれば移植工数の削減、あるいはそのまま使いませる事も期待でき、好ましいかと思います