前回 Dynamic Deck を試用 しましたが、これだけでは不足に感じるようになってきました。単純に画像を抽出してはめ込んでいくだけならいいのですが、より複雑な要件に対応する POC を開発する必要が出てきた次第です。具体的にやりたいのは:
- Content Fragment(以下CF) 単位でアイテムを取得・配置していきたい
- CF に関連付けられた JCR 上の関連画像を、それぞれの CF の文脈内に配置したい
- 画像のパスは CF がプロパティとして持っているのでそこから導出したい
つまり AEM Assets 上で、 CF と画像に形成されている親子関係をそのまま DTP でも表現したいのです（DeskTop Publishing というより Server Side Publishing ですが笑）。商品情報とその商品の画像のようなイメージですね。しかし SQL2 でそのように階層構造を保って抽出するような SELECT 文を書く方法がどうしても見当たりませんでした
そこで抜本的に異なるアーキテクチャを志向していくことにします。こんどは Dynamic Deck に依存せずに AEM/IDS 連携を実証しようというお話です
前提条件
- AEM6.5.9
- (port 4502 で起動)
- IDS
- (port 8080 で起動)
- Node.js
- curl
※すべて同一のローカルマシンで完結するものとします
準備: AEM 上に素材を配置しておく
AEM に次のような CF がデフォルトで入っていました。これを流用することにします
該当する CFs の CF Model を特定し、
このようなプロパティを新設し
各々の CF に値を入れていきます。画像の JCR パスは AEM Assets に実在するものであれば適当でよいです
次に AEM Assets に次のフォルダを作成します
/content/dam/we-retail/en/experiences/destination
/content/dam/we-retail/en/experiences/template
InDesign のテンプレート を /content/dam/we-retail/en/experiences/template/template.idml としてアップロードする
AEM 側ではこのような条件を満たしているという前提で以降進めていきます
設計
"抜本的に異なるアーキテクチャ" と標榜しましたがこれを冒頭の画像のようにしてはどうか？ と思い立ちました。 AEM <-> IDS という経路だと未知の部分も多く、いっそ両者は疎にしたほうが円滑に行くのでは、と思ったからです。 中継に Node.js を選定したのは自分が書き慣れているから、という理由が大きいです。また IDS で走らせる ExtensScript も Javascript ですから、 採用言語が統一できている、とも言えるでしょう（一応は）
実装に向けて各ポイントを抑えていきます
AEM から素材を取得する
Assets HTTP API を使用します。 CF は json で取れます。同 json に前工程で新設したプロパティとその値も入っているので都合が良いです。値には画像のパスが入っている（前工程で自分で入れた）ので、同じ要領でその画像も取れるという寸法
そしてこれは http.request() で普通に実現できます
取得した情報を元に XML を構成する
これは純粋に文字列処理となります。 AEM から配信された CF は JSON です。これを InDesign に解釈させるための専用 XML に翻訳します。この XML は次工程で InDesign の Document にインポートさせるためのコンテンツデータです
IDS に処理命令を発行する
SOAP クライアントを実装 できます。これで IDS に対し、任意の ExtensScript を実行するよう命令するわけです。引数も渡せます
この ExtendScript 内で、「この template.idml に基いてこの data.xml をインポートし、artifact.indd として保存しなさい」と命令します
IDS 側の処理終了を検知する
簡単な IPC を構成します。方法はともかく終了フラグを立てればよいわけですが、ひとまず ExtendScript 側で終了時にフラグ用のファイルを作成し、 Node.js 側でそれを見張る、ということにします
余裕があれば Socket で通信しても良いでしょう
出来上がった .indd を AEM Assets にアップロードする
AEM as a Cloud Service であればアップロードクライアントが npm で用意されているようですが、 6.5.9 ではうまく動作しませんでした。不本意ですが child_process で アップロード用 curl コマンド を直接実行することにします
実装
設計段階でポイントは抑えてありますのであとはそれらを組み合わせれば OK
https://github.com/o2-ninja/aim-poc
試運転
npm run dev すると
できました
※ Assets の destination フォルダにアップロードされたものをローカルに落として表示しています
template.idml は全然作り込んでおらず適当なので見栄えの点ではいまいちながら、 やりたかったことは出来ています。左 pane の "Structure" で item と Image が親子関係になっているのがお判りいただけるでしょうか。これがやりたかったのです
備考
"InDesign に解釈させるための専用 XML" なるものが出てきましたが、なぜこの方法にしたか簡単に触れておきます。
ExtendScript は大変万能にいろいろな事が出来ますので、わざわざ XML を生成しなくても直接 json などのデータを読み込んでコンテンツを形成していくことは可能です。しかしこれは結構大変なんですよ。いちアイテム毎にデータをパース・成形して所定の箇所にコンテンツ文字列を配置してスタイルを適用させていったりとか改行、改ページ制御とかね。これを for 文とかで愚直に書いていくことになるのですが、それじゃ開発工数もかかるしいろんな体裁上の調整を事細かにやらなくてはいけなくなってきます。当然バグが発生する可能性も書けば書くほど増えます。さらにそれを ExtendScript というマイナーな言語でやるということは専任のプログラマーへの依存度が高くなってしまい、つまり属人性が高くなってしまい、メンテ等の中長期的な影響も踏まえ好ましくない、と導けるかと思います
一方、XML を生成するスクリプトは ExtendScript で書く必要は全くありません。 Node.js だろうと他のなにかだろうと、プレーンテキストを操作できれば何でも良いわけです
あとは template.{idml,indd} ですが、これは InDesign の世界になりますので、何れにしろプログラマと言うより professional に InDesign を扱えるデザイナーの職域になるでしょう
XML を境に住み分けることで、 XML でどう構造を表現するかと、それに対応する template をどう制作するか、に注力していけば良くなるとともに、 ExtendScript 依存度を低減できるのです。なにしろ ExtendScript で書くことは、単純に言えば「XML をインポートしなさい」だけで済みますからね。
もちろん、 XML だけでは対応しきれない局面が出てくることもないわけではありませんので、そのときは遠慮せず ExtendScript を書けばよいでしょう
補足
この最後の話は「エンタープライズレベルで複雑または高度に DTP を全自動化したいときの話」だとご理解いただけると幸いです。それに当てはまらない日々の小規模タスク等を自動化したいのであれば、細かいことは気にせず思うようにスクリプトを書いたほうが、制作体験の向上に資する場面も多いかと存じます。