Campaign Classic でビルドのアップグレードを実行するための主な手順とベストプラクティスについて説明します。

推奨事項

このドキュメントでは、アップグレードプロセスのほか、競合を検出して解決する手順について詳しく説明します。

ビルドのアップグレードは慎重におこなう必要があります。必ず事前にアップグレードが及ぼす影響を検討し、作業は高度なスキルを備えた人が実行するようにしてください。アップグレードを正常に完了するために、後述の手順を実行する人はエキスパートユーザーに限定してください。また、アップグレードを開始する前に Adobe Campaign カスタマーサポートに連絡することを強くお勧めします。

アップグレードの前提条件は以下のとおりです。

  • Campaign のアーキテクチャに関する理解
  • システムおよびサーバーサイドの知識
  • 管理者としての権限とアクセス許可

詳しくは、Adobe Campaign の更新移行ガイドのドキュメントを参照してください。

ホストされているインスタンスおよびハイブリッドインスタンスの場合、アドビのテクニカルオペレーションチームにビルドのアップグレードをリクエストする必要があります。詳しくは、このページの下にあるよくある質問の節を参照してください。また、ビルドのアップグレードに関する FAQ 記事も参照してください。

Plan

アップグレードのスケジュール設定と準備

ここをクリック


Conflicts

競合が発生した場合

ここをクリック


icon_process

アップグレードの実行

ここをクリック


Audience

よくある質問

ここをクリック


アップグレードの準備

Plan

ビルドのアップグレードを開始する前に、必ず準備を完了させておいてください。

アップグレードの準備が整った後、ビルドをアップグレードするには 2 時間以上かかります。


ビルドのアップグレードをおこなうには、以下のリソースが必要です。

  • アドビのアーキテクト:データベース構造(標準のスキーマや追加されたスキーマ、キャンペーンデザイン、決められた順番で開始してテストしなければならない重要なパス機能)を把握するために必要です。
  • プロジェクトマネージャー:ビルドのアップグレードに、様々なインスタンス(本番、ステージング、テスト)のほか、サードパーティ製のサーバーやアプリケーション(データベース、SFTP サイト、メッセージサービスプロバイダー)が関係する場合に、プロジェクトマネージャーにすべてのテストを調整してもらうことをお勧めします。
  • Adobe Campaign 管理者:管理者はセキュリティ、フォルダーの配置、レポート、インポートおよびエクスポートの要件をはじめとするサーバーの設定を把握しています。管理者がいない状況でビルドのアップグレードを実行しないでください。
  • Adobe Campaign オペレーター(マーケティングユーザー) - アップグレードの成功は、ユーザーが日常業務を実行できるかどうかにかかっています。この理由により、アップグレードされたサーバーをテストする際には必ず、日常業務をおこなうオペレーターを 1 人以上含めるようにしてください。

計画

ビルドのアップグレードを計画する際に重要なポイントを紹介します。

  1. アップグレードには、少なくとも 2 時間確保しておきます。
  2. アドビおよびお客様側担当者の連絡先詳細を配布しておきます。
  3. ホスト版インスタンスの場合:アドビとお客様側担当者でアップグレードの日時と実行者を調整します。
  4. オンプレミス版インスタンスの場合:お客様側担当者がすべてのプロセスを管理します。カスタマイズされたワークフローや配信ロジックのテスト時にサポートが必要な場合は、コンサルティングサービスを依頼してください。
  5. アップグレード先の Adobe Campaign のバージョンを決定して確定します。Adobe Campaign Classic のリリースノートを参照してください。
  6. アップグレードの実行可能ファイルがあることを確認します。

主要ユーザー

ビルドのアップグレードプロセスには、次のユーザーを含める必要があります。

  • アドビのアーキテクト:ホステッドアーキテクチャまたはハイブリッドアーキテクチャの場合は、Adobe Campaign クライアントケアと調整する必要があります。

  • プロジェクトマネージャー:

- オンプレミス版インストールの場合:お客様側の社内プロジェクトリーダーがアップグレードを主導し、ライフサイクルテストを管理します。

- ホスト版 インストールの場合ホスティングチームは Adobe Campaign クライアントケアチームおよびお客様と連携し、すべてのインスタンスのアップグレードタイムラインを調整します。

  • Adobe Campaign 管理者:

オンプレミス版インストールの場合:管理者がアップグレードを実行します。

- ホスト版インストールの場合:ホスティングチームがアップグレードを実行します。

  • Adobe Campaign オペレーターとマーケティングユーザー:オペレーターが開発用、テスト用および本番用のインスタンスのテストをおこないます。

ビルドのアップグレードの準備

ビルドのアップグレードを開始する前に、以下の準備を整えておく必要があります。

  1. アップグレード前にすべての開発作業がエクスポート(パッケージとしてエクスポート)可能であることを確認する。

  2. 移行元の環境と移行先の環境のすべてのインスタンスについてデータベースの完全バックアップを作成する。この手順はオンプレミス版のお客様についてのみ必要です。PostgreSQL のコマンド例:

    Pg_dumpmydatabase> mydatabase.sql
  3. 最新バージョンのサーバー構成ファイルを入手する。

  4. 最新のビルドをダウンロードする。

また、ビルドのアップグレードを開始する前に便利なコマンドラインを一通り把握しておく必要もあります。

  • nlserver pdump:実行中のプロセスのリストを表示します
  • nlserver pdump -who:アクティブなクライアントセッションのリストを表示します
  • nlserver monitor -missing:不足しているプロパティのリストを表示します
  • nlserver start process@<instance>:プロセスを開始します
  • nlserver stop process@<instance>:プロセスを停止します
  • nlserver restart process@<instance>:プロセスを再開します
  • nlserver shutdown:すべての Campaign プロセスを停止します
  • nlserver watchdog -svc:ウォッチドッグを開始します(UNIX のみ)

アップグレードの実行

Upgrade

ここで紹介する手順はオンプレミス版のお客様のみを対象にしています。ホスト版のお客様については、ホスティングチームがこの作業を実行します。Adobe Campaign を新しいビルドにアップグレードするための詳細な手順は以下のとおりです。


環境の複製

ここでは、Adobe Campaign の環境を複製する方法を説明します。これにより、移行元の環境が移行先の環境に復元され、同一の作業環境が 2 つになります。これを実行するには、次の手順に従います。

  1. 移行元となる環境に含まれているすべてのインスタンス上にあるデータベースのコピーを作成します。

  2. 作成したコピーを、移行先となる環境のすべてのインスタンス上に復元します。

  3. 移行先の環境を起動する前に、移行先の環境で nms:freezeInstance.jscauterization スクリプトを実行します(これにより、ログ、トラッキング、配信、キャンペーンワークフローなど、外部と通信するすべてのプロセスが停止されます)。

    nlserverjavacsriptnms:freezeInstance.js–instance:<dev> -arg:run
  4. 次のように、正常に実行されたことを確認します。

    1. ID が 0 に設定されているのが配信パートのみであることを確認します。

    SELECT * FROM neolane.nmsdeliverypart;

    2. 配信ステータスが正しく更新されていることを確認します。

    SELECT iSate, count(*) FROM neolane.nmsdeliveryGroup By iProd;

    3. ワークフローのステータスが正しく更新されていることを確認します。

    SELECT iState, count (*) FROM neolane.xtkworkflowGROUP BY iState;
    SELECT iStatus, count (*) FROM neolane.xtkworkflowGROUP BY iStatus;

サービスのシャットダウン

すべてのファイルを新しいバージョンで置き換えるために、nlserverservice のすべてのインスタンスをシャットダウンする必要があります。

  1. 以下のサービスをシャットダウンします。

    - Web サービス(IIS):iisreset /stop

    - Adobe Campaign サービス:net stop nlserver6

    注意:

    IIS で使用されている nlsrvmod.dll ファイルを新しいバージョンで置き換えることができるように、リダイレクションサーバー(webmdl)が停止したことを確認してください。

  2. nlserver pdump コマンドを実行してアクティブなタスクがないことを確認します。アクティブなタスクがない場合、以下のような出力が返されます。

    C:\<installation path>\bin>nlserverpdump
    12:12:12 > Application Server for Adobe Campaign version x.x (build xxx) dated xx/xx/xxxx No tasks
  3. Windows タスクマネージャーですべてのプロセスが停止していることを確認します。

Adobe Campaign サーバーアプリケーションのアップグレード

  1. Setup.exe ファイルを実行します。このファイルをダウンロードする必要がある場合は、Adobe Campaign サポートページにログインして、ダウンロードセンターにアクセスします。

  2. インストールモード(アップデートまたは修復)を選択します。

  3. 次へ」をクリックします。

  4. 完了」をクリックすると、インストールプログラムによって新しいファイルがコピーされます。

  5. 処理が完了したら「完了」をクリックします。

リソースの同期

  1. コマンドラインを開きます。

  2. nlserver config -postupgrade -allinstances を実行して以下の作業をおこないます。

    1. リソースの同期
    2. スキーマの更新
    3. データベースの更新

    注意:

    この処理は nlserverweb アプリケーションサーバー上で 1 回だけおこなってください。

    同期するデータベースが 1 つだけの場合は、以下のコマンドを実行します。

    nlserver config -postupgrade -instance: <instance_name>
  3. 同期後にエラーや警告が発生していないか確認します。

サービスの再起動

以下のサービスを再起動する必要があります。

  • Web サービス(IIS):issreset /start
  • Adobe Campaign サービス:net start nlserver6

クライアントコンソールのアップデート

Adobe Campaign アプリケーションサーバーがインストールされているマシン(nlserverweb)で、以下のファイルをダウンロードしてインストールします。

Setup-client-7.xxxx.exe in [path of the application]\datakit\nl\en\jsp

次回クライアントコンソールに接続したときに、ウィンドウが開いて新しい更新が利用可能なことを知らせるメッセージが表示され、その更新をダウンロードしてインストールするよう促されます。

特定の追加タスク

一部の設定では、新しいビルドにアップデートするために、特定の追加タスクが必要となります。

Campaign インスタンスでトランザクションメッセージ(Message Center)が有効になっている場合、アップグレードするには、次の追加手順をおこなう必要があります。

  1. Message Center の本番サーバーを、選択したバージョンに更新します。
  2. ポストアップグレードスクリプトを実行します。
  3. テストを実行して E メールが Message Center の本番用インスタンスを通じて正常に受信されることを確認します。
  4. クライアントをアップグレードし、キャッシュをクリアします。
  5. パッケージをエクスポートします。
    1. クライアントパッケージエクスポートツールを使用してパッケージをエクスポートします。
    2. スキーマパッケージをインポートします。
    3. クライアントを一旦切断してから再接続します。
    4. データベースを更新します。
    5. 一旦切断してから再接続します。
    6. 管理パッケージをインポートします。
    7. コンテンツパッケージをインポートします。
    8. コンテンツ管理パッケージをインポートします。
    9. 一旦切断してから再接続します。
    10. ワークフローのクイックサニティチェックを実行します。
  6. Message Center テンプレートをパブリッシュして、サーバーと Message Center インスタンス間のインターフェイスが機能していることを確認します。
  7. テストを実行して E メールが Message Center の本番用インスタンスを通じて正常に受信されることを確認します。
  8. 本番環境でワークフローのテストを実行して、配信が受信されることを確認します。

ミッドソーシング環境との関連で、アップグレードするには、次の追加手順をおこなう必要があります。

  1. Adobe Campaign サポートにミッドソーシングサーバーのアップグレードの調整を依頼します。 
  2. テストリンクを実行して、バージョンが更新されていることを確認します(例:http://[InsertServerURL]/r/test)。

注意:

ミッドソーシングサーバーでは、常にマーケティングサーバーと同じ(またはそれ以降の)バージョンを実行する必要があります。

競合が発生した場合

競合の検出

同期結果を確認する必要があります。ここで紹介する手順はオンプレミス版のお客様のみを対象にしています。ホスト版のお客様については、ホスティングチームがこの作業を実行します。同期結果の表示方法は 2 つあります。

コマンドラインインターフェイスでは、エラーは 3 重の右山括弧(>>>)で示され、同期は自動的に停止します。警告は 2 重の右山括弧(>>)で示され、同期完了後に解決する必要があります。ポストアップグレードの最後に概要がコマンドプロンプトで表示されます。以下はその一例です。

YYYY-MM-DD HH:MM:SS.749Z 00002E7A 1 info log =========Summary of the update========== 
YYYY-MM-DD HH:MM:SS.749Z 00002E7A 1 info log <instance name> instance, 6 warning(s) and 0 error(s) during the update. 
YYYY-MM-DD HH:MM:SS.749Z 00002E7A 1 warning log The document with identifier 'mobileAppDeliveryFeedback' and type 'xtk:report' is in conflict with the new version. 
YYYY-MM-DD HH:MM:SS.749Z 00002E7A 1 warning log The document with identifier 'opensByUserAgent' and type 'xtk:report' is in conflict with the new version. 
YYYY-MM-DD HH:MM:SS.750Z 00002E7A 1 warning log The document with identifier 'deliveryValidation' and type 'nms:webApp' is in conflict with the new version. 
YYYY-MM-DD HH:MM:SS.750Z 00002E7A 1 warning log Document of identifier 'nms:includeView‘ and type 'xtk:srcSchema' updated in the database and found in the file system. You will have to merge the two versions manually. 

リソースの競合に関する警告は、見落とさないように注意して、解決してください。

postupgrade_<サーバーのバージョン番号>_<ポストアップグレードの時刻>.log ファイルには同期結果が含まれています。デフォルトで、<installation directory/var/<instance/postupgrade ディレクトリから入手できます。エラーと警告はそれぞれエラーと警告の属性で明示されます。

競合の分析

競合はサーバーの postupgrade.log 内、または Campaign のクライアントインターフェイス(管理/設定/パッケージ管理/競合を編集)で見つけることができます。

識別子が「stockOverview」およびタイプが「nms:webApp」のドキュメントは、新しいバージョンと競合します。

競合が見つかった場合は、以下の条件に該当するかを確認します。

  • お客様が変更またはカスタマイズしたオブジェクトか
  • 本番環境で変更したオブジェクトか

どちらにも該当しない場合は、誤検出です。どちらにも該当する場合は、実際に競合が存在します。

  1. 競合しているオブジェクトを特定します。
  2. お客様にオブジェクトを変更したかどうかを問い合わせます。
  3. オブジェクトに異常がないかを確認します。
  4. オブジェクトのコードに最終変更日が設定されているかを確認します。
  5. 競合の XML コードに _conflict 属性がないかを調べます。カスタマイズされた形跡がないかを確認します。

  1. 「常習犯」の仕業かもしれません。ビルトイン Web アプリケーションまたはレポート(例:「deliveryValidation」、「deliveryOverview」、「budget」)。
  2. 変更ログを見て更新がないかを調べます。
  3. Adobe Campaign のエキスパートに尋ねます。
  4. コードに対して「差分表示」を実行します。

競合の解決

競合を解決するには、次の手順に従います。

  1. Adobe Campaign エクスプローラーで管理/設定/パッケージ管理/競合を編集に移動します。
  2. リストから解決する競合を選択します。

競合解決のオプションは、新しいバージョンを許可、現在のバージョンを維持、コードを結合(および解決済みとして宣言)、競合を無視(非推奨)の 4 つです。

  • 標準機能が必要な場合
  • カスタマイズしていない場合(カスタマイズした内容はすべて削除されます)

  • カスタマイズしている場合
  • 結合を実行したくない場合
  • アップグレードが原因で競合しているオブジェクトを修正する必要がない場合

  • 結合できるのはフォーム、レポート、Web アプリケーションのみです。
  • 小規模な結合であればコードの知識がなくても実行できる場合があります。
  • 複雑な結合は適切なスキルと能力を持った人が実行する必要があります。
  • 結合の実行を参照してください。

  • 競合した状態が続きます。
  • オブジェクトはアップグレードされません。
  • バージョンの互換性が失われたり、バグ修正を適用しても改善されなかったりといった長期的な影響が生じます。

警告:

競合は解決することを強くお勧めします。

結合の実行

結合には様々なタイプがあります。

  • 簡易結合:カスタムの要素と新しい要素が小規模で関連性がなく、コーディングも不要です。
  • 変更なし:新しいバージョンを承認します。最終更新日のみ変更され、コメント、タブ、スペース、新規行のみ反映されます(例:意図しない保存)。
  • 軽微な変更:1 行のみ変更されます(例:xpathToLoad)。
  • 高度な結合:コーディングが必要な場合です。開発に関するスキルが必要です。「高度な結合」を参照してください。

  1. 3 つのバージョン(元のバージョン、新しいバージョン、およびカスタムバージョン)をすべて取得します。
  2. 元のバージョンと新しいバージョンの「差分表示」を実行します。
  3. 変更を抽出します。
  4. 変更がない場合、現在のバージョンを維持して競合を解決します。

  1. ビルトインコードは datakit フォルダー XML ファイルに格納されています。競合しているオブジェクトに対応する XML ファイルを探します。例:<Adobe Campaign インストールフォルダー>\datakit\nms\fra\form\recipient.xml
  2. 元のバージョンの取得:ダウンロードセンターリンクを使用して Adobe Campaign サポートページから、または製品の未アップグレードインストールから取得します。
  3. 新しいバージョンの取得:ダウンロードセンターリンクを使用して Adobe Campaign Support ページから、または顧客がインストールしたファイルから取得します。
  4. カスタムバージョンの取得:Campaign クライアント内からオブジェクトのソースコードを取得します。

  1. テキストエディターまたは結合エディター(Notepad ++、AraxisMerge、WinMerge など)をインストールします。
  2. エディターで元のファイルと新しいファイルを開きます。
  3. 差分表示(2 つのファイルの比較)を実行します。
  4. 差分を特定します。

  1. カスタムバージョンから着手します。
  2. 変更を適用します。
  3. 解決済みとして宣言し、競合を解決します。
  4. 非回帰性を確認します。

手動で競合を解決する場合の手順は以下のとおりです。

  1. ウィンドウの下部セクションで _conflict_ string を検索して競合しているエンティティを探します。新しいバージョンでインストールされたエンティティは新しい引数を持ちます。古いバージョンと一致するエンティティはカスタム引数を持ちます。
  2. 維持しないバージョンを削除します。維持するエンティティから _conflict_argument_ という文字列を削除します。
  3. 解決した競合に移動します。アクションアイコンをクリックし、「解決済みとして宣言」を選択します。
  4. 変更を保存します。これにより競合が解決します。

  1. 変更による影響を把握します(変更のリバースエンジニアリング、変更ログの調査、Adobe Campaign のエキスパートと協力したフォローアップ)。
  2. 変更をどう処理するかを決めます(お客様への問い合わせ)。
  3. カスタマイズによる影響を理解します(変更のリバースエンジニアリング、お客様への問い合わせ)。

以下は高度な結合を実行する際の手順です。

  1. 変更セットからコードを取り出してコピーします。
  2. カスタマイズしたバージョンに貼り付けます。
  3. カスタマイズ結果の非回帰性を確認します。
  4. 変更の効果を確認します。
  5. 顧客によるユーザー承認テストを依頼します。
  6. テスト環境で実行します。

警告:

開発に関するスキルが必要です。