[AEM Forms]{class="badge positive" title="AEM Formsに適用）。"}
同じアダプティブフォームに対する環境固有のREST エンドポイントの設定
アダプティブフォームを開発からステージングから実稼動に昇格させる場合、フォーム自体は同じままですが、通常、各環境のdifferent REST エンドポイントにフォームを送信する必要があります。 フォームの送信アクションでエンドポイント URLをハードコーディングすると、同じURLがフォームとともにあらゆる環境に移動するため、これを壊します。
この記事では、ポータブルな単一のアダプティブフォームを保持し、そのREST エンドポイントに送信 アクションを各環境の正しいエンドポイントに解決する方法について説明します。 フォームはURLではなく名前 でREST設定 を参照し、各環境はその設定に独自の値を提供します。
前提条件 prerequisites
- コアコンポーネントに基づくアダプティブフォーム。
- クラウド設定が有効になっている設定ブラウザー（ツール > 一般 > 設定ブラウザー）を介して作成された設定コンテナ 。
- 各環境（またはCloud Manager デプロイメントパイプライン ）でツール > Cloud Servicesおよびプロモーション用に パッケージマネージャーにアクセスするための権限。
ステージングでのRESTful サービス設定の作成 create-rest-configuration
ステージング作成者インスタンスで、フォームが参照する名前付き設定を作成します。 サービスエンドポイント URLをステージング用のRESTまたはWebhook エンドポイントに設定します。
-
ツール／クラウドサービス／データソースに移動します。
-
設定コンテナを選択し、作成を選択します。
-
「一般」タブで、設定に「名前」を入力します（例：
restTest）。 すべての環境で same の名前を使用して、プロモーション後にフォームが一貫して解決されるようにします。 -
「認証設定」タブで、次の設定を行います。
- RESTful サービスを選択：サービスエンドポイント。
- メソッドの種類: 投稿。
- サービス エンドポイント URL: ステージング エンドポイント URL （ステージングからの送信をテストするために使用するWebhook URLなど）。
- コンテンツタイプ：例：複数部品フォームデータ。
- 認証タイプ: エンドポイントで必要とされる場合（例：なしまたは基本認証）。
-
「保存して閉じる」を選択します。
アダプティブフォームを設定コンテナにポイントします set-configuration-container
ステージング時に、フォームをREST設定を保持する設定コンテナに関連付けます。
-
Formsとドキュメントで、アダプティブフォームを選択し、プロパティを開きます。
-
「基本」タブで、設定コンテナを、RESTful サービス設定を保持するコンテナ（
/conf/restConfigTestなど）に設定します。 -
「保存して閉じる」を選択します。
REST エンドポイントに送信アクションの設定 configure-submit-action
ステージング時に、ハードコードされたURLではなく、名前付きREST設定を使用して送信するフォームを設定します。 完全な送信アクションのリファレンスについては、REST エンドポイント送信アクション用のアダプティブフォームの設定を参照してください。
-
アダプティブフォームを編集用に開き、ガイドコンテナ コンポーネントを選択し、そのアダプティブフォームコンテナ プロパティを開きます。
-
「送信」タブを開き、送信アクション ドロップダウンリストから、REST エンドポイントに送信を選択します。
-
アクション設定で、POST リクエストを有効にするを選択します。
-
オプションを選択するには、設定 （URLではなく）を選択します。
-
リストから名前付き設定（例：
restTest）を選択します。 -
「完了」を選択します。
フォームは、固定URLではなく、名前付き設定を使用して送信エンドポイントを解決するようになりました。
フォームをステージングから本番環境に宣伝します promote-across-environments
ステージングで設定およびテストを行った後、同じフォームと設定コンテナを実稼動環境に移動します。 次のいずれかの方法を使用できます。
オプション 1：オーサーとパッケージのアプローチ option-package
作成者が各環境でフォームと設定を直接管理する場合に使用します。
-
ステージング オーサーインスタンスで、フォームとその設定コンテナを含むコンテンツパッケージを パッケージマネージャーに作成します。次に例を示します。
/content/dam/formsanddocuments/<your-form-path>/content/forms/af/<your-form-path>/conf/<your-config-container>（.../settings/cloudconfigs/fdm/<your-config>を含む）
-
パッケージをダウンロードし、本番 オーサーインスタンスにインストールします。
オプション 2：コンテキストに応じた上書きアプローチ（自動化に推奨） option-context-aware
このオプションは、デプロイメント後に手動で編集することなく、エンドポイント、ユーザー名、パスワードが環境ごとに自動的に解決されるパッケージ構成を1つ使用する場合に使用します。 この方法では、Cloud Managerの環境変数を使用して、設定プロパティを上書きします。
REST設定の場合、通常、serviceEndPoint、userName、passwordのプロパティの環境変数を作成し、プロジェクトのOsgiConfigurationOverrideProvider設定ファイルからそれらを参照します。
完全な手順については、 コンテキストに応じたクラウド設定を参照してください。
実稼動時のエンドポイント URLの更新 configure-endpoint-on-production
実稼動環境にパッケージをインストールすると、アダプティブフォームとREST設定name （例：restTest）がステージングと一致します。 この設定の サービスエンドポイント URL は、引き続きパッケージのステージングエンドポイントを指しています。 実稼動環境で設定を開き、実稼動環境のエンドポイント URLに置き換えます。
-
本番 オーサーインスタンスで、ツール > クラウドサービス > データソースに移動します。
-
デプロイした設定コンテナ （例：
restConfigTest）を選択し、名前付き設定（例：restTest）を開きます。 -
「認証設定」タブで、サービスエンドポイント URLを実稼動RESTまたはWebhook エンドポイントに設定します。
-
「保存して閉じる」を選択します。
テスト中に、Webhook キャプチャサービスなどのリクエストインスペクターによって環境ごとに一意のURLが提供されるため、各送信を受信するエンドポイントを確認できます。
ルーティングの確認 verify
ステージング環境と実稼動環境から同じフォームを送信し、各環境が他の環境のURLではなく、独自のエンドポイントに投稿することを確認します。
-
ステージング作成者インスタンスで、アダプティブフォームを開き、テストデータを使用して送信します（例：テキストフィールドに
stagetestと入力します）。 POST リクエストが、ステージング時に設定したステージング サービスエンドポイント URLに届くことを確認します。 -
本番 オーサーインスタンスで、同じアダプティブフォームを開き、テストデータを使用して送信します（例えば、テキストフィールドに
prodtestと入力します）。 POST リクエストが、ステージング URLではなく、実稼動環境で設定した実稼動 サービスエンドポイント URLに届くことを確認します。 -
各リクエストが想定されるコンテンツタイプ（例：複数部品フォームデータ）を使用し、送信されたフォームデータを含んでいることを確認します。 本番環境では、実際のセキュアエンドポイント（HTTPS）を使用します。
ベストプラクティス best-practices
- すべての環境で同じ設定 name を使用して、プロモーション後にフォームが一貫して解決されるようにします。
- エンドポイント valueは環境固有のままにします。 フォームの送信アクションに単一の環境のURLをハードコーディングしないでください。
- 実稼動エンドポイントの場合は、URLがセキュア（HTTPS）であり、受信パスが認証モデルに応じてPOST リクエストを適切に処理するように設定されていることを確認します。
- デプロイメントを繰り返し可能にし、デプロイメント後に手動で編集する必要がない場合は、コンテクストに応じた上書きアプローチを選択します。