# mulesoft Design Center - Full Documentation # API Designer API Designer Web UI を使用して、次の API 仕様を設計できます。 - RESTful API Modeling Language (RAML) バージョン 0.8 または 1.0 - OpenAPI 仕様 (OAS) バージョン 2.0 または 3.0 - AsyncAPI 2.0 RESTful API Modeling Language (RAML) バージョン 0.8 または 1.0 の API フラグメントも設計できます。 ## [](#テキストエディターまたはビジュアルエディターを使用した設計)テキストエディターまたはビジュアルエディターを使用した設計 API 仕様を作成するには、テキストエディターまたはビジュアルエディターを使用できます。 テキストエディターでは、次の作業を行うことができます。 - 適切なメソッド、リソース、パラメーター、セキュリティコンポーネントを自動入力するコンテキストアウェアシェルフを使用して、ベストプラクティスに従って設計する。 - Exchange の RAML API フラグメント (セキュリティスキーマやデータ型など) または独自に作成した RAML API フラグメントを含める。 - Exchange からルールセットを適用して、プロジェクトのガバナンス準拠を検証する。 - 既存の API 仕様をインポートする。 ビジュアルエディターでは、次の作業を行うことができます。 - RAML フラグメントを含める必要のないユースケースの仕様を作成する。 - テキストエディターで入力およびカスタマイズできる仕様をスキャフォールディングする。 ## [](#ドキュメントの追加および表示)ドキュメントの追加および表示 仕様やフラグメントに説明を追加するときに、テキストエディターの右側のペインに自動生成される対話型ドキュメントでそれらを表示できます。 ## [](#モッキングサービスを使用したテスト)モッキングサービスを使用したテスト RAML または OAS API にモッキングサービスを使用して、次の作業を行うことができます。 - 1 行のコードを作成する前に API 機能をプレビューする。 - 仕様に要求を送信して、定義された応答を受信する。 - 動作ヘッダーを使用して、さまざまなシナリオ (タイムアウトやエラーなど) をシミュレーションする。 ## [](#exchange-および-api-manager-での共有)Exchange および API Manager での共有 API 仕様を Anypoint Exchange にパブリッシュして、API Manager、Anypoint Studio、Flow Designer で使用できます。API 仕様を API Manager に直接追加することもできます。 ## [](#mulesoft-製品全体での仕様やフラグメントの使用)MuleSoft 製品全体での仕様やフラグメントの使用 API Designer で設計した仕様やフラグメントを統合された MuleSoft 製品で使用できます。 - API Designer を使用して API 仕様や RAML フラグメントを設計する。 - Exchange でホストされているアセットを RAML 仕様で使用する。 - API 仕様の反復と最終バージョンを Anypoint Exchange にパブリッシュする。 - API Designer で設計された仕様を Anypoint Studio および API Manager にインポートする。 - API Designer から Anypoint Studio に仕様を直接インポートする。 ## [](#関連情報)関連情報 - [API Designer のテキストエディターでの API 仕様の作成およびパブリッシュ](https://docs.mulesoft.com/jp/design-center/design-create-publish-api-raml-editor) - [API Designer のビジュアルテキストエディターでの API 仕様の作成およびパブリッシュ](https://docs.mulesoft.com/jp/design-center/design-create-publish-api-visual-editor) - [API Designer のテキストエディターでの API フラグメントの作成およびパブリッシュ](https://docs.mulesoft.com/jp/design-center/design-create-publish-api-fragment) # API Designer のテキストエディターでの API フラグメントの作成およびパブリッシュ テキストエディターに表示されるコード提案を参考にしながら、RAML、OAS 3.0、JSON スキーマで API フラグメントを直接作成することができます。 ## [](#このタスクについて)このタスクについて API フラグメントは、バージョンと識別子を持ちながら、それ自身では完全な仕様ではないドキュメントです。 RAML API フラグメントを作成する場合、RAML.org で定義されている次のいずれかの種別になります。これらの種別の説明については、RAML 0.8 または 1.0 仕様 (使用する方) を参照してください。 - 特性 - リソース種別 - ライブラリ - 型 - ユーザードキュメント - 例 - アノテーション種別 - セキュリティスキーム API フラグメントでは、OAS 3.0 フラグメントの外部化をサポートするために OAS 3.0 コンポーネントと JSON スキーマがサポートされています。 - コンポーネント (YAML) - コンポーネント (JSON) - JSON スキーマ OAS 3.0 コンポーネントには、OAS のさまざまな側面の再利用可能な​`コンポーネント`​オブジェクトのみが含まれている必要があります。 ## [](#手順)手順 1. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで、​**\[Create + (作成 +)\]**​ をクリックします。 2. **\[New Fragment (新しいフラグメント)\]**​ を選択します。 3. **\[New Fragment (新しいフラグメント)\]**​ ダイアログで、フラグメントプロジェクトの名前を入力します。 4. API 仕様形式を選択します。 RAML 1.0、OAS 3.0、JSON スキーマ形式のいずれかを選択できます。 RAML 1.0 を選択した場合、そのフラグメントタイプを選択できます。 名前またはフラグメントタイプは必要に応じて後から変更できます。 5. 作成する API フラグメントのタイプを選択し、​**\[Create Fragment (フラグメントを作成)\]**​ をクリックします。 _結果:_​ テキストエディターが開きます。エディターは 3 つのパネルに分かれています。 - 左側のパネルには、プロジェクトファイルのリストが表示されています。 新しいファイルを作成するには、​**\[+\]**​、​**\[New file (新規ファイル)\]**​ の順にクリックします。ファイルの API 形式 (RAML 1.0、OAS 3.0、JSON スキーマなど) を選択します。必要に応じて、ファイル種別を選択し、ファイルに名前を付けて、​**\[Create (作成)\]**​ をクリックします。 デフォルトでは、エディターはプロジェクトと同じ名前のファイルを作成します。このファイルは、プロジェクトのルートファイルとして設定されます。 ルートファイルとして YAML、RAML、JSON スキーマファイルを設定できます。 左側のパネルには、​`exchange.json`​ ファイルもリストされます。このファイルには、プロジェクトを Anypoint Exchange にパブリッシュするときに Exchange から要求されるメタデータが含まれます。このファイルは参照のみです。 - 中央のパネルには、API フラグメントを作成するためのエディターがあります。 - 右側のパネルには、中央のパネルに表示されている API フラグメントに含まれる型やリソースのリストが表示されます。 6. API フラグメントを作成します。 テキストエディターは、カーソル位置に挿入できる RAML ノード、メソッド、および他の要素を提案します。 プロジェクトには、ファイルを 1 つずつ、または .zip ファイルにまとめてインポートできます。RAML 1.0 ファイル、JSON ファイル、OpenAPI Specification (OAS) 2.0、または OAS 3.0 ファイルがサポートされています。コンピューター上のローカルファイルを指定するか、またはファイルがオンラインで保存されている場合は URL を指定できます。 ## [](#次のステップ)次のステップ API フラグメントを Anypoint Exchange にパブリッシュすることができます。 1. テキストエディターの右上隅にある ​**\[Publish (パブリッシュ)\]**​ ボタンをクリックして ​**\[Publish to Exchange (Exchange にパブリッシュ)\]**​ をクリックします。 2. Exchange で​_アセット_​として処理されるプロジェクトのバージョン番号を指定します。この番号は、Exchange のプロジェクトのページの右側のペインにある ​**\[Version (バージョン)\]**​ セクションに表示されます。 Anypoint Exchange で API フラグメントプロジェクトのアセットバージョンが表示される場所は次のとおりです。 ![「Versions (バージョン)」 セクションの場所](/mulesoft/current/ja-jp/design-center/_images/apid-location-of-asset-version-in-exchange.png) API フラグメントプロジェクトをパブリッシュしたら、他の開発者はそのフラグメントを連動関係として独自の API 仕様プロジェクトに含めることができます。 API フラグメントプロジェクトをパブリッシュすると、その API Portal が自動的に作成されます。 ## [](#関連情報)関連情報 - [API プロジェクトへのファイルのインポート](https://docs.mulesoft.com/jp/design-center/design-import-files) - [Exchange 公開ポータル](https://docs.mulesoft.com/jp/exchange/about-portals) - [テキストエディターのプロジェクトのルートファイル](https://docs.mulesoft.com/jp/design-center/design-change-root-file) - [オープンプロジェクトの名前の変更](https://docs.mulesoft.com/jp/design-center/design-rename-project) - [プロジェクトの削除](https://docs.mulesoft.com/jp/design-center/design-delete-project) - [API 仕様プロジェクトへの連動関係の追加](https://docs.mulesoft.com/jp/design-center/design-add-api-dependency) # API Designer のテキストエディターのプロジェクトのルートファイル テキストエディターで作成する API 仕様プロジェクトや API フラグメントプロジェクトでは、1 つのファイルが常に「ルートファイル」として指定されます。 ​**\[Files (ファイル)\]**​ ペインでは、ルートファイルが ​**\[Root file (ルートファイル)\]**​ という表示ラベルが付けられた長方形で示されます。プロジェクトを Anypoint Exchange にパブリッシュすると、ルートファイルにより、プロジェクトのファイルを検証するパーサーのコンテキストが設定されます。 たとえば、RAML API 仕様プロジェクトに 2 つの仕様が含まれていて、それぞれの仕様では ​`!include`​ キーワードを使用して、異なる API フラグメントセットが設定されているとします。これは、プロジェクトにもあります。プロジェクトを Exchange にパブリッシュすると、プロジェクトのすべてのファイルがパブリッシュされます。ただし、Exchange はプロジェクトに含まれる仕様とファイルを検証する必要があります。ルートファイルがないと、Exchange は最初に解析するファイルや解析対象のファイルセットを確認できません。 別の例として、複数のフラグメントが含まれる API フラグメントプロジェクトをパブリッシュするとします。1 つは独立しており、フラグメントの残りのファイルはライブラリフラグメントとその連動関係です。プロジェクトでルートファイルが指定されていない場合、Exchange はファイルを適切に解析できません。この場合、独立したフラグメントをルートファイルとして設定し、そのファイルが単独で解析可能であることを Exchange に示すことができます。または、ライブラリファイルをルートファイルとして設定し、そのファイルから解析を開始して、独立したフラグメントに進む必要があることを Exchange に示すことができます。

API Designer の 2020 年 2 月 8 日リリースの前の作成されたプロジェクトをテキストエディターで初めて開く場合、ルートファイルを設定するように求められます。

## [](#テキストエディターの-api-仕様プロジェクトのルートファイル)テキストエディターの API 仕様プロジェクトのルートファイル すべての API 仕様プロジェクトは、デフォルトルートファイルを使用して作成されます。プロジェクトに複数の仕様がある場合、ルートファイルを切り替えることができます。 ### [](#デフォルトルートファイル)デフォルトルートファイル API 仕様プロジェクトを作成すると、デフォルトで作成されるファイルがルートファイルとして設定されます。 ![「Orders API」という名前の API 仕様プロジェクトのデフォルトルートファイル](/mulesoft/current/ja-jp/design-center/_images/apid-default-root-file-api-spec-project.png)
1RAML API 仕様プロジェクトの名前は ​Orders API​ です。
2このデフォルトファイルは ​orders-api.raml​ という名前で、ルートファイルとして設定されています (すべての API 仕様プロジェクトにはルートファイルが必要であるため)。
### [](#複数の仕様が含まれる-api-仕様プロジェクトのルートファイルの設定)複数の仕様が含まれる API 仕様プロジェクトのルートファイルの設定 仕様をプロジェクトにインポートすると、API Designer から、その仕様をプロジェクトのルートファイルとして設定するかどうかを尋ねられます。 API 仕様プロジェクトの任意の仕様をそのプロジェクトのルートファイルとして設定できます。たとえば、次の画像は 2 つの仕様が含まれているプロジェクトを示しています。 ![2 つの仕様が含まれている API 仕様プロジェクト。現在のルートファイルは、RAML バージョンの仕様です。](/mulesoft/current/ja-jp/design-center/_images/apid-root-file-api-spec-project-multi-specs.png)
1OAS バージョンのインベントリプロセス API 仕様。
2RAML バージョンのインベントリプロセス API 仕様。このバージョンの仕様が現在ルートファイルとして設定されます。
現在ルートファイルでない仕様の右側にある 3 つのドットをクリックすると、その仕様をルートファイルとして設定するオプションが含まれるメニューが表示されます。 ![3 つのドットをクリックすると開くメニューの上部にある \[Set as root file (ルートファイルとして設定)](/mulesoft/current/ja-jp/design-center/_images/apid-root-file-api-spec-project-multi-specs-2.png) オプション。\]
1クリックするとファイルのアクションメニューが開く 3 つのドット。
2アクションメニューの上部にある ​[Set as root file (ルートファイルとして設定)]​ オプション。
## [](#api-フラグメントプロジェクトのルートファイル)API フラグメントプロジェクトのルートファイル すべての API フラグメントプロジェクトは、デフォルトルートファイルを使用して作成されます。プロジェクトに複数のフラグメントがある場合、ルートファイルを切り替えることができます。 ### [](#api-フラグメントプロジェクトのデフォルトルートファイル)API フラグメントプロジェクトのデフォルトルートファイル API フラグメントプロジェクトを作成すると、デフォルトで作成されるファイルがルートファイルとして設定されます。 ![「Retail Common」という名前の API フラグメントプロジェクトのデフォルトルートファイル。](/mulesoft/current/ja-jp/design-center/_images/apid-default-root-file-api-frag-project.png)
1RAML API フラグメントプロジェクトの名前は Retail Common です。
2このデフォルトファイルは ​retail-common.raml​ という名前で、ルートファイルとして設定されています (すべての API フラグメントプロジェクトにはルートファイルが必要であるため)。
### [](#複数のフラグメントが含まれる-api-フラグメントプロジェクトのルートファイルの設定)複数のフラグメントが含まれる API フラグメントプロジェクトのルートファイルの設定 フラグメントを API フラグメントプロジェクトにインポートすると、API Designer から、そのフラグメントをプロジェクトのルートファイルとして設定するかどうかを尋ねられます。 API フラグメントプロジェクトの任意のフラグメントをそのプロジェクトのルートファイルとして設定できます。たとえば、次の画像は 2 つのフラグメントが含まれていて、最初のフラグメントがルートファイルとして設定されているプロジェクトを示しています。 ![2 つのフラグメントが含まれている API フラグメントプロジェクト。](/mulesoft/current/ja-jp/design-center/_images/apid-root-file-api-frag-project-multi-frags.png)
1ルートファイルとして設定されているフラグメント。
2もう一方のフラグメント。
現在ルートファイルでないフラグメントの右側にある 3 つのドットをクリックすると、そのフラグメントをルートファイルとして設定するオプションが含まれるメニューが表示されます。 ![3 つのドットをクリックすると開くメニューの上部にある \[Set as root file (ルートファイルとして設定)](/mulesoft/current/ja-jp/design-center/_images/apid-root-file-api-frag-project-multi-frags-2.png) オプション。\]
1クリックするとファイルのアクションメニューが開く 3 つのドット。
2アクションメニューの上部にある ​[Set as root file (ルートファイルとして設定)]​ オプション。
# API Designer の外部で作成された API 仕様のアップロード API 仕様は、API Designer を経由しなければ Anypoint Exchange にパブリッシュすることはできません。API Designer の外部で作成した API 仕様をパブリッシュするには、API Designer で API 仕様プロジェクトを作成し、外部で作成してある仕様をインポートしてから Anypoint Exchange にパブリッシュします。 ## [](#始める前に)始める前に Anypoint Platform で、自分のユーザー ID に Design Center 開発者権限を割り当てておく必要があります。 ## [](#手順)手順 1. Anypoint Platform のホームページから Design Center を開きます。 2. 作業できる API 仕様プロジェクトを作成します。 1. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで、​**\[Create (作成)\]**​ をクリックして ​**\[New API Specification (新しい API 仕様)\]**​ をクリックします。 2. **\[New API Specification (新しい API 仕様)\]**​ ダイアログで、プロジェクトに名前を付けます。名前は後で必要に応じて変更できます。 3. **\[I’m comfortable designing it on my own (自分でデザインします)\]**​ を選択します。 4. **\[Specification Language (仕様言語)\]**​ 項目で、API 使用を記述する言語を選択します。 5. **\[Create API (VPN を作成)\]**​ をクリックします。 + ​**結果**​: Design Center で API 仕様プロジェクトが作成されます。このプロジェクトには 2 つのファイルが含まれます。 - プロジェクトと同じ名前のデフォルトの空白の仕様。 後の手順でこのファイルを削除できます。現在、これはプロジェクトのルートファイルとして設定されています。ルートファイルとして設定されているファイルを削除することはできません。 - Anypoint Exchange で必要とされるメタデータを含む ​`exchange.json`​ という名前のファイル。 このファイルは参照のみです。 3. API 仕様をインポートします。 1. テキストエディターの右上隅にある歯車アイコンをクリックして ​**\[Import (インポート)\]**​ を選択します。 2. **\[Import (インポート)\]**​ ダイアログで、​**\[File or Zip (ファイルまたは Zip)\]**​ を選択します。 3. ファイルまたは ZIP ファイルを参照して選択します。 + ​**結果:**​ エディターの左側のペインにファイルのリストが表示されます。インポートした ZIP ファイルに、フォルダー構造内のファイルが含まれる場合、ペインにそのフォルダー構造が表されます。 4. 仕様を右クリックし、​**\[Set as root file (ルートファイルとして設定)\]**​ を選択して、プロジェクトのルートファイルを設定します。 5. API Designer がデフォルトで作成した空白の仕様を削除します。 ## [](#次のステップ)次のステップ API 仕様プロジェクトを Anypoint Exchange にパブリッシュします。​[「API 仕様のパブリッシュ」](https://docs.mulesoft.com/jp/design-center/design-publish)​を参照してください。 ## [](#関連情報)関連情報 [Anypoint Exchange](https://docs.mulesoft.com/jp/exchange/) # API フラグメントプロジェクトへのファイルのインポート RAML フラグメント、OAS コンポーネント、JSON スキーマを API フラグメントプロジェクトにインポートできます。インポートするフラグメントは、RAML 0.8、RAML 1.0、OAS 3.0 で記述できます。アノテーション種別、データ型、JSON 応答ペイロードの例、ライブラリ、リソース種別、セキュリティスキーム、特性、OAS コンポーネントをインポートできます。プロジェクトのいずれかのフラグメントをプロジェクトのルートファイルとして設定する必要があります。 インポート元の場所として、自分のコンピューター、URL、Anypoint Exchange の 3 つがあります。 ## [](#手順)手順 - テキストエディターを使用している場合、コンピューターに保存されているファイルまたは ZIP ファイルのコンテンツをインポートします。 1. テキストエディターの右上隅にある歯車アイコンをクリックして ​**\[Import (インポート)\]**​ を選択します。 2. **\[Import (インポート)\]**​ ダイアログで、​**\[File or Zip (ファイルまたは Zip)\]**​ を選択します。 **結果:**​ エディターの左側のペインにファイルのリストが表示されます。インポートした ZIP ファイルに、フォルダー構造内のファイルが含まれる場合、ペインにそのフォルダー構造が表されます。 - テキストエディターを使用している場合、URL を介して使用可能なファイルをインポートします。 1. テキストエディターの右上隅にある歯車アイコンをクリックして ​**\[Import (インポート)\]**​ を選択します。 2. **\[インポート\]**​ ダイアログで、​**\[URL\]**​ を選択します。 **結果:**​ エディターの左側のペインにファイルが表示されます。

このファイルのインポートの方法では、一度に 1 つのファイルのみをインポートできます。ライブラリフラグメントをインポートする場合、ライブラリで使用する各ファイルも個別にインポートする必要があります。

- API フラグメントをその連動関係と共に Exchange からインポートする手順は、次のとおりです。 1. 次のいずれかの方法を使用して、​**\[Import Asset from Exchange (Exchange からアセットをインポート)\]**​ ダイアログを開きます。 - API Designer でプロジェクトと共に作成されたデフォルトファイルのみがプロジェクトに含まれる場合、​**\[Files (ファイル)\]**​ ペインに表示されているリンクテキストをクリックします。 - プロジェクトにデフォルトプロジェクトファイル以外のファイルがすでに含まれている場合、テキストエディターの右上隅にある歯車アイコンをクリックして ​**\[Import from Exchange (Exchange からインポート)\]**​ を選択できます。 2. ダイアログの左上隅にあるドロップダウンメニューで、アセットを所有するビジネスグループを選択します。 3. 次の列を持つテーブルに表示されているいずれかのアセットを選択します。 **Name (名前)** API 仕様または RAML フラグメントの名前。 **Version (バージョン)** 仕様またはフラグメントのバージョン。 ダイアログの左下隅にある ​**\[Include snapshots (スナップショットを含める)\]**​ チェックボックスをオンにすると、この列にスナップショットが含まれます。 **Type (種別)** アセットの種別。 値は ​**\[API Fragment (API フラグメント)\]**​ である必要があります。 **Language (言語)** RAML、OAS、JSON スキーマのいずれかを選択できます。 **Date modified (変更日)** 現在選択されているアセットの現在選択されているバージョンがパブリッシュされた日付。 **Created by (作成者)** 現在選択されているアセットの現在選択されているバージョンをパブリッシュしたユーザーのユーザー ID。 4. **\[Import asset (アセットをインポート)\]**​ をクリックします。 **結果:**​ エディターの左側のペインにファイルのリストが表示されます。 ## [](#関連情報)関連情報 - [テキストエディターのプロジェクトのルートファイル](https://docs.mulesoft.com/jp/design-center/design-change-root-file) # API 仕様のパブリッシュ API 仕様を他の開発者と共有する場合、Anypoint Exchange にパブリッシュできます。 ## [](#始める前に)始める前に プロジェクトを Anypoint Exchenge にパブリッシュする前に、参照されていないファイルを削除することをお勧めします。​_参照されていない_​ファイルは、プロジェクトのルートファイルから直接または間接的に参照されていません。 たとえば、ファイル ​`example.raml`​ がプロジェクト内のファイルの 1 つであり、プロジェクトのルートファイルが ​`!include`​ タグを使用して ​`example.raml`​ を参照していない場合、ルートファイルは ​`example.raml`​ を直接参照しません。ルートファイルからの参照のチェーン内にあるどのファイルも ​`example.raml`​ を直接参照していない場合、そのファイルはルートファイルから間接的に参照されません。そのため、​`example.raml`​ は参照されていないファイルとなり、おそらくプロジェクト内に含まれるべきではありません。 開始する前にそれらを削除しないと、Exchange にパブリッシュするオプションを選択したときに参照されていないファイルが検出され、それらをパブリッシュするかどうかのオプションが表示されます。 ## [](#api-仕様のパブリッシュ)API 仕様のパブリッシュ 1. API Designer で、パブリッシュする API 仕様プロジェクトを開きます。 2. 仕様に連動関係がある場合は、​`Exchange Dependencies`​ の横にある更新ボタンをクリックして、Design Center にすべての連動関係の最新の状況とコンテンツが適用されるようにします。 3. **\[Publish (パブリッシュ)\]**​ をクリックし、​**\[Publish to Exchange (Exchange へのパブリッシュ)\]**​ をクリックします。 ![API Designer から Exchange にパブリッシュするときに表示されるパブリッシュダイアログ](/mulesoft/current/ja-jp/design-center/_images/apid-publish-dialog-api-specs.png)
1 Asset version (アセットバージョン)​: Anypoint Exchange によって作成される、プロジェクト用のページの ​[Version (バージョン)]​ セクションに表示されるバージョン番号。この項目についての詳細は、「​アセットバージョン​」を参照してください。
2 API version (API バージョン)​: API 仕様のバージョン番号。この項目についての詳細は、「​API バージョン​」を参照してください。
  • 次の条件を使用して、​[Asset version (アセットバージョン)]​ および ​[API version (API バージョン)]​ 項目が事前入力されるようになりました。

    • API 仕様でバージョンが定義されていない場合、推奨されるアセットバージョン項目と API バージョン項目にデフォルト値 ​1.0.0​ と ​v1​ が事前入力されます。

    • API 仕様で定義されたバージョンがアセットバージョン項目の推奨値 (​1.0.3​ など) と一致する場合、アセットバージョン項目にその値が事前入力され、API バージョン項目に ​v​ とメジャーアセットバージョン (​v1​ など) が事前入力されます。

    • API 仕様で定義されたバージョンが API バージョン項目の推奨値 (​v2​ など) と一致する場合、API バージョン項目にその値が事前入力され、アセットバージョン項目に抽出されたメジャー値 (​2.0.0​ など) が事前入力されます。

    • API 仕様で定義されたバージョンが異なる文字列 (​7.4​ など) である場合、API バージョン項目にその値が事前入力され、アセットバージョン項目にそのデフォルト値 (​1.0.0​) が事前入力されます。

    • API にすでに Exchange にパブリッシュされたバージョン (​3.2.5​ など) がある場合、API 仕様で定義されたバージョンを変更することなく新しいバージョンをパブリッシュすると、アセットバージョン項目に以前の値から 1 つ増加した値 (​3.2.6​) が事前入力され、API バージョン項目は同じままになります。

3 LifeCycle State (ライフサイクル状態)​: アセットのライフサイクル状態。アセットは API Designer から ​[Development (デプロイメント)]​ または ​[Stable (安定)]​ としてパブリッシュできます。API Designer からアセットを非推奨にすることはできません。
4 Business group ID (ビジネスグループ ID)​: プロジェクトが属する Anypoint Platform のビジネスユニットの ID。
5 [Asset name (アセット名)]​: Anypoint Exchange がパブリッシュされたプロジェクトを識別するために使用する名前。
6 Asset ID (アセット ID)​: Anypoint Exchange がパブリッシュされたプロジェクトを識別するために使用する一意の ID。同じ ID のパブリッシュ済みアセットがない場合、デフォルトを使用する必要があります。
1. 必須項目の入力が完了したら、​**\[Publish to Exchange (Exchange にパブリッシュ)\]**​ をクリックします。 プロジェクトにルートファイルから直接的または間接的に参照されていないファイルが残っている場合は、ダイアログが開き、参照されていないファイルを含むプロジェクトをパブリッシュするかどうかが尋ねられます。デフォルトでは、API Designer は Anypoint Exchenge にパブリッシュされたプロジェクトからこれらのファイルを削除します。
2017 年 4 月より前にリリースされたバージョンの Anypoint Platform を使用しており、Exchange へのパブリッシュ中にアセットを API Manager に追加する場合は、​[Add to API Manager (API Manager に追加)]​ を選択します。この機能は、それ以降のバージョンでは使用できません。代わりに、API Manager の API インスタンスを Exchange のアセットにリンクできます。
## [](#asset-version)アセットバージョン Anypoint Exchange では、パブリッシュされた API 仕様ごとにアセットバージョン番号が必要です。セマンティックバージョン管理ルールを使用して、アセットバージョンを指定する必要があります。詳細は、​[「アセットのバージョンを変更する」](https://docs.mulesoft.com/jp/exchange/to-change-raml-version)​を参照してください。 パブリッシュダイアログの ​**\[Asset version (アセットバージョン)\]**​ 項目のコンテンツは、次のように条件によって異なります。 - 仕様を初めてパブリッシュする場合、セマンティックバージョン管理スキームに基づいて任意の有効な番号を使用できます。一般的な開始バージョンは ​`1.0.0`​ です。 - 仕様を再パブリッシュする場合、​**\[Asset version (アセットバージョン)\]**​ 項目には、API Designer によって既存のパッチレベル番号を 1 ずつ増分した値が自動的に入力されます。この番号を変更できますが、すでに使用されているバージョン番号を使用してこの API の安定バージョンをパブリッシュすると、再パブリッシュは失敗します。 - 仕様を再パブリッシュして ​`Development`​ を選択する場合、以前にパブリッシュされた API の開発バージョンと同じ番号を使用できますが、以前にパブリッシュされた安定バージョンと同じ番号は使用できません。 ## [](#api-version)API バージョン Anypoint Exchange では、パブリッシュされた API 仕様ごとに API バージョン番号が必要です。 パブリッシュダイアログの ​**\[API version (API バージョン)\]**​ 項目のコンテンツと状態は、次のように条件によって異なります。 - 仕様にすでにバージョンが含まれている場合、パブリッシュダイアログで更新することはできません。 - 仕様にバージョンが含まれていない場合、​**\[API version (API バージョン)\]**​ 項目にバージョンを入力する必要があります。 ## [](#関連情報)関連情報 - [アセットのパブリッシュワークフロー](https://docs.mulesoft.com/jp/exchange/workflow-sharing-assets) - [アセット情報の探索](https://docs.mulesoft.com/jp/exchange/asset-details) - [アセットのバージョンを変更する](https://docs.mulesoft.com/jp/exchange/to-change-raml-version) - [API インスタンス](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page) # API 仕様プロジェクトへのファイルのインポート RAML フラグメント、OAS コンポーネント、JSON スキーマを API 仕様プロジェクトにインポートできます。 1 つの API 仕様プロジェクトに複数の API 仕様を含めることができます。機能が関連した複数の仕様であれば 1 つのプロジェクトで管理することが望ましい場合もあります。いずれかの仕様をプロジェクトのルートファイルとして設定する必要があります。ただし、ルートファイルは必要なときにいつでも変更できます。 インポートするフラグメントは、RAML 0.8、RAML 1.0、OAS 3.0 で記述できます。アノテーション種別、データ型、JSON 応答ペイロードの例、ライブラリ、リソース種別、セキュリティスキーム、および特性をインポートできます。 インポート元の場所として、自分のコンピューター、URL、Anypoint Exchange の 3 つがあります。 ## [](#手順)手順 - テキストエディターを使用している場合、コンピューターに保存されているファイルまたは ​`.zip`​ ファイルのコンテンツをインポートします。 1. テキストエディターの右上隅にある歯車アイコンをクリックして ​**\[Import (インポート)\]**​ を選択します。 2. **\[Import (インポート)\]**​ ダイアログで、​**\[File or Zip (ファイルまたは Zip)\]**​ を選択します。 3. ファイルまたは ZIP ファイルを参照して選択します。 **結果:**​ エディターの左側のペインにファイルのリストが表示されます。インポートした ZIP ファイルに、フォルダー構造内のファイルが含まれる場合、ペインにそのフォルダー構造が表されます。 - テキストエディターを使用している場合、URL を介して使用可能なファイルをインポートします。 1. テキストエディターの右上隅にある歯車アイコンをクリックして ​**\[Import (インポート)\]**​ を選択します。 2. **\[インポート\]**​ ダイアログで、​**\[URL\]**​ を選択します。
  • URL を指定してオンラインで提供されているファイルをインポートする場合は、ファイルに ​!include​ ステートメント (RAML) または ​$ref​ ステートメント (OAS) が含まれていないように注意してください。エディターは、URL の場所にあるファイルのみをインポートします。

**結果:**​ エディターの左側のペインにファイルが表示されます。 - API 仕様または API フラグメントをその連動関係と共に Exchange からインポートする手順は、次のとおりです。 1. 次のいずれかの方法を使用して、​**\[Import Asset from Exchange (Exchange からアセットをインポート)\]**​ ダイアログを開きます。 - テキストエディターを使用していて、API Designer でプロジェクトと共に作成されたデフォルトファイルのみがプロジェクトに含まれる場合、​**\[Files (ファイル)\]**​ ペインに表示されているリンクテキストをクリックできます。 - テキストエディターを使用している場合、テキストエディターの右上隅にある歯車アイコンをクリックして ​**\[Import from Exchange (Exchange からインポート)\]**​ を選択できます。 - ビジュアルエディターを使用していて、プロジェクトにリソースやデータ型がまだ含まれていない場合、​**\[New API (新しい API)\]**​ ペインに表示されているリンクテキストをクリックできます。 2. ダイアログの左上隅にあるドロップダウンメニューで、アセットを所有するビジネスグループを選択します。 3. 次の列を持つテーブルに表示されているいずれかのアセットを選択します。 **Name (名前)** API 仕様または API フラグメントの名前。 **Version (バージョン)** 仕様またはフラグメントのバージョン。 ダイアログの左下隅にある ​**\[Include snapshots (スナップショットを含める)\]**​ チェックボックスをオンにすると、この列にスナップショットが含まれます。 **Type (種別)** アセットの種別。 値は ​**\[REST API\]**​ または ​**\[API Fragment (API フラグメント)\]**​ のいずれかです。 **Language (言語)**​ (テキストエディターにインポートされる API 仕様の言語) 言語は RAML または OAS のいずれかです。 デフォルトで表示される値は、仕様の記述に使用された言語です。デフォルト以外の値は、仕様がパブリッシュされたときに Exchange でコピーを作成するために使用された言語です。 コピーをインポートする必要がある場合、インポート後にコピー内のエラーの修正が必要になることがあります。Exchange でコピーを作成するために使用されるプロセス (RAML から OAS またはその逆への変換) で、エラーのない仕様が作成される保証はありません。 **Language (言語)**​ (ビジュアルエディターにインポートされる API 仕様の言語) 言語は常に RAML です。 API Designer では、仕様の RAML バージョンがインポートされ、RAML バージョンが ​**\[RAML\]**​ ペインに、OAS バージョンが ​**\[OAS\]**​ ペインに表示されます。 **Language (言語)**​ (フラグメントの場合) RAML、OAS、JSON スキーマのいずれかを選択できます。 **Date modified (変更日)** 現在選択されているアセットの現在選択されているバージョンがパブリッシュされた日付。 **Created by (作成者)** 現在選択されているアセットの現在選択されているバージョンをパブリッシュしたユーザーのユーザー ID。 4. **\[Import Asset (アセットをインポート)\]**​ をクリックします。 **結果:**​ エディターの左側のペインにファイルのリストが表示されます。 ## [](#関連情報)関連情報 - [テキストエディターのプロジェクトのルートファイル](https://docs.mulesoft.com/jp/design-center/design-change-root-file) - [API 仕様の設計、作成、パブリッシュ](https://docs.mulesoft.com/jp/design-center/design-create-publish-api-specs) # API 仕様プロジェクトへの連動関係の追加 API 仕様または API フラグメントのプロジェクトでは、RAML フラグメント、OAS コンポーネント、JSON スキーマ、またはルールセットの連動関係を追加できます。連動関係は Anypoint Exchange で参照されるため、プロジェクトで直接編集することはできません。 プロジェクトをエクスポートする場合や、他のユーザーが Exchange からプロジェクトを RAML としてダウンロードする場合、生成される ZIP ファイルには参照された連動関係が含まれます。
参照される連動関係は、API Designer エディター以外のエディターで編集しないでください。プロジェクトをエクスポートして別のエディターで開き、参照された連動関係を編集してからプロジェクトをテキストエディターにインポートしようとすると、インポートは失敗します。
Studio では OAS 3.0 フラグメントはサポートされていません。
## [](#add-dependencies-to-api-project)API 仕様プロジェクトに連動関係を追加する API 仕様プロジェクトに連動関係を追加する手順は、次のとおりです。 1. テキストエディターナビゲーションメニューで、​**\[Exchange dependencies (Exchange 連動関係)\]**​ アイコン (​![manage dependency versions design center d96c7](/mulesoft/current/ja-jp/design-center/_images/manage-dependency-versions-design-center-d96c7.png) アイコン"\]​) をクリックします。 2. 追加する連動関係種別の追加アイコン (+) をクリックします。 3. 連動関係のリストを絞り込むには、次の操作を行います。 - 組織を選択する - キーワードで検索する - **\[Include versions in Development (開発中のバージョンを含む)\]**​ を選択する 4. 追加する連動関係バージョンを選択します。 - 連動関係の最新以外のバージョンを使用するには、​**\[Version (バージョン)\]**​ ドロップダウンでその連動関係のバージョンを選択します。 - 選択した連動関係のみを表示するには、​**\[Show selected only (選択済みのみを表示)\]**​ をクリックします。 - 各フラグメントの名前の横でフラグメントの形式 (RAML、OAS、または JSON スキーマ) を確認できます。 5. **\[Add dependency (連動関係を追加)\]**​ をクリックします。
API Designer では、連動関係は最大 1,000 個のファイル、300 MB 以下の合計ファイルサイズがサポートされています。
## [](#連動関係のコンテンツの表示)連動関係のコンテンツの表示 連動関係のコンテンツを表示するには、その連動関係のその他のオプションメニューアイコン (​![overflow menu icon](/mulesoft/current/ja-jp/design-center/_images/overflow-menu-icon.png "3 つの縦ドット")​) をクリックし、​**\[Show in Files (ファイルで表示)\]**​ または ​**\[Open in Exchange (Exchange で開く)\]**​ を選択します。
[Show in Files (ファイルで表示)]​ を選択すると、​[Files (ファイル)]​ セクションが展開されて、連動関係が ​exchange_modules​ セクションに表示されます。サブセクションは、参照される連動関係の URI に対応します。これは、そのアセット識別子、つまり Exchange の GAV (グループ ID、アセット ID、バージョン) になります。
API プロジェクトの作業を続行するには、​**\[Files (ファイル)\]**​ > API プロジェクトのファイル名をクリックします。 ## [](#ruleset-dependencies)ルールセットの連動関係 Unresolved include directive in modules/ROOT/pages/design-add-api-dependency.adoc - include::design-center::partial$design-add-ruleset-dependencies.adoc\[\] 要アクションとしてプロジェクトが識別されていない場合でも、パブリッシュされたルールセットを連動関係として API プロジェクトに追加して API の準拠を前もって確認できます。 組織による検証の対象となるルールセットに API が準拠していない場合、メール通知が送信されます。 **\[Code in Design Center (Design Center のコード)\]**​ をクリックして API Designer を開くか、​**\[API Details in Exchange (Exchange の API の詳細)\]**​ をクリックして API アセットの \[Conformance Status (準拠状況)\] ページにリダイレクトできます。 1. API Designer のアセットバージョンに編集可能な分岐がある場合、欠落しているルールセットをタグ、カテゴリ、ライフサイクル状態で絞り込まれた状態で確認できるポップアップが表示されます。それらの検索条件を編集するには、​**\[Edit criteria (条件を編集)\]**​ をクリックします。完了したら、​**\[Add all rulesets (すべてのルールセットを追加)\]**​ をクリックします。 _結果_​: ルールセットがプロジェクトに追加されます。 2. API Designer のアセットバージョンに編集可能な分岐がない場合、プロジェクトの編集可能な分岐を選択するか、現在のバージョンから新しい分岐を作成できます。その後、欠落しているルールセットをその編集可能な分岐に追加できます。 分岐がある場合、欠落しているルールセットをタグ、カテゴリ、ライフサイクル状態で絞り込まれた状態で確認できるポップアップが表示されます。それらの検索条件を編集するには、​**\[Edit criteria (条件を編集)\]**​ をクリックします。完了したら、​**\[Add all rulesets (すべてのルールセットを追加)\]**​ をクリックします。 _結果_​: ルールセットがプロジェクトに追加されます。 ## [](#fix-gov-issues)ルールセット検証の改善 ルールセットを連動関係として追加すると、ルールセットはデフォルトで自動的に検証されます。API とルールセットが複雑だと、計算される診断の数が増え、複数の自動検証がトリガーされる場合があります。 次の場合、検証にかかる時間が長くなります。 - API がモジュール化されているか、複雑な再帰型が含まれるか、循環参照が含まれる場合。 - 複数のルールセット連動関係を API プロジェクトに追加する場合。 - 大量のブラウザーリソースを消費している場合。 ルールセット検証時間を短縮する手順は、次のとおりです。 - 不要なブラウザータブまたはアプリケーションを閉じます。 - デバイスが効率的に実行されており、十分なメモリと CPU リソースがあることを確認します。 - 手動検証に切り替えます。これにより、複数の自動検証をトリガーして使用可能なリソースを枯渇させることなく、ルールセットごとに 1 回の検証が実行されます。 検証プロセスに時間がかかりすぎていると、警告メッセージが表示され、そのプロジェクトで自動検証が無効になることが通知されます。 - 手動モードに変更するには、​**\[Ok\]**​ をクリックします。 - 引き続き自動検証を使用するには、​**\[Cancel (キャンセル)\]**​ をクリックします。まだルールセットの自動検証に時間がかかりすぎている場合は、再び警告メッセージが表示されます。 自動検証と手動検証は API プロジェクトで切り替えることができます。これにより、その仕様でのみ検証設定が変更されます。 ルールセットの手動検証を有効にする手順は、次のとおりです。 1. テキストエディターの ​**\[Project Errors (プロジェクトエラー)\]**​ セクションで、​**\[Governance (ガバナンス)\]**​ タブを選択します。 2. **\[Governance auto-validation (ガバナンス自動検証)\]**​ アイコン (​![green governance auto validation](/mulesoft/current/ja-jp/design-center/_images/green-governance-auto-validation.png "Governance auto-validation (ガバナンス自動検証)")​) をクリックして、自動検証を無効にします。 3. **\[Validate for governance (ガバナンスの検証)\]**​ アイコン (​![validate for governance](/mulesoft/current/ja-jp/design-center/_images/validate-for-governance.png "Validate for governance (ガバナンスの検証)")​) をクリックして、手動検証を有効にします。 これにより、複数の自動検証をトリガーして使用可能なリソースを枯渇させることなく、ルールセットごとに 1 回の検証が実行されます。 自動検証を再び有効にする手順は、次のとおりです。 1. テキストエディターの ​**\[Project Errors (プロジェクトエラー)\]**​ セクションで、​**\[Governance (ガバナンス)\]**​ タブを選択します。 2. \[auto-validation (自動検証)\] アイコン (​![red governance auto validation](/mulesoft/current/ja-jp/design-center/_images/red-governance-auto-validation.png "Governance auto-validation (ガバナンス自動検証)")​) をクリックして、自動検証を有効にします。
自動検証に時間がかかりすぎている場合は、再び警告メッセージが表示されます。
## [](#ガバナンス準拠状況の問題の修正)ガバナンス準拠状況の問題の修正 ルールセットを連動関係として追加したら、テキストエディターの ​**\[Project Errors (プロジェクトエラー)\]**​ セクションで準拠メッセージを確認できます。提供された情報を使用して、準拠の問題を修正し、API 仕様を再パブリッシュします。 ## [](#関連情報)関連情報 - [API 仕様内の API 準拠の問題を検出](https://docs.mulesoft.com/api-governance/find-conformance-issues) - [アセットの作成](https://docs.mulesoft.com/jp/exchange/to-create-an-asset) # Design Center Release Notes The following release notes are provided for Design Center: - [API Designer Release Notes](https://docs.mulesoft.com/jp/release-notes/design-center/design-center-release-notes) - [API Mocking Service Release Notes](https://docs.mulesoft.com/jp/release-notes/api-mocking-service/api-mocking-service-release-notes) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Design Center について Anypoint Design Center は、次のツールで構成される開発環境です。 - [API Designer](https://docs.mulesoft.com/jp/design-center/design-create-publish-api-specs) API Designer では、API 仕様を複数のモデリング言語で作成したり、RAML API フラグメントを作成したりすることができます。仕様またはフラグメントを作成したら、Anypoint Exchange にパブリッシュして、MuleSoft 組織の全員が使用できるようにします。 - [Flow Designer](https://docs.mulesoft.com/jp/design-center/about-designing-a-mule-application) Flow Designer で、システムをワークフローに統合するための Mule アプリケーションを作成します。 ## [](#design-center-を使用する場合の前提条件)Design Center を使用する場合の前提条件 Design Center にアクセスしてその機能を使用し、アプリケーションを実行およびデプロイして、デザインを Exchange にパブリッシュするためには、次の要件を満たしている必要があります。 - 「Design Center Developer (Design Center 開発者)」権限が割り当てられているか、または組織のオーナーであること。 - 設計環境において CloudHub Admin (CloudHub 管理者) ロールが割り当てられていること。 - Exchange Contributor (Exchange コントリビューター) ロールが割り当てられていること。 - 0.2 仮想コアのキャパシティが利用可能な CloudHub デザイン環境を 1 つ以上持つ Anypoint 組織に属していること。 Design Center から本番環境にデプロイするには、本番環境専用の CloudHub Developer (CloudHub 開発者) ロールがユーザーアカウントに割り当てられていることも必要です。 ## [](#design-center-の使用を開始する場所)Design Center の使用を開始する場所 Design Center の使用を開始するには、Anypoint Platform にサインインしてから \[Design Center\] をクリックします。プロジェクトのリストが表示されます。API Designer および Flow Designer でプロジェクトを作成する手順については、これらのツールのドキュメントを参照してください。 ## [](#関連情報)関連情報 - [ロール](https://docs.mulesoft.com/jp/access-management/roles) - [CloudHub 環境](https://docs.mulesoft.com/jp/access-management/environments) # Exchange での Mule アプリケーションのテンプレートとしての共有:page-support-status: eolScheduled Exchange で Mule アプリケーションをテンプレートとして共有できます。これにより、今後、同様の Mule アプリケーションをあなたと他のユーザーは容易に作成できます。 ## [](#mule-アプリケーションをテンプレートとして共有するメリット)Mule アプリケーションをテンプレートとして共有するメリット Anypoint Platform で作業を組織の他のユーザーと共有する方法として、Mule アプリケーションをテンプレートとして共有する方法が優れています。同様のアプリケーションを構築する必要がある場合、まずテンプレートをダウンロードし、テンプレートを使用することで、独自のプロジェクトを開始できます。Exchange 内でテンプレートに適切な説明やスクリーンショットのほか、場合によっては動画を添付すれば、他のユーザーは作業をさらにすばやく進めることがことができます。 今後、すでに作成した Mule アプリケーションに似た Mule アプリケーションを作成する必要が生じることもあるでしょう。Design Center でプロジェクトを検索し、プロジェクトをコピーし、プロジェクトの機能と仕組みを思い出すのではなく、Exchange 内で対応するテンプレートに対して記述したページを参照することができます。

テンプレートには、Mule アプリケーションで使用されるコネクタに対して指定された認証ログイン情報は含まれません。認証ログイン情報がパブリッシュされることはありません。テンプレートを使用して独自の Mule アプリケーションを開始するユーザーは、独自のログイン情報を提供する必要があります。

## [](#始める前に)始める前に - Mule アプリケーションにエラーがないことを確認します。 - Anypoint Platform 組織の Exchange にパブリッシュするための権限がユーザー ID にあることを確認します。組織のシステム管理者は、ユーザー ID に Exchange コントリビューター、Exchange 管理者、または組織のシステム管理者のロールを割り当てることで、ユーザーにこの権限を付与することができます。 - 各カードの ​**\[Notes (メモ)\]**​ セクションに、カードの目的と、カードの設定で必要になる可能性があるすべての情報について説明するメモを記述していることを確認します。 - Mule アプリケーションが作成されたプロジェクトを開きます。 ## [](#手順)手順 1. Flow Designer 画面の右上隅にある ​**\[Publish (パブリッシュ)\]**​ ボタンをクリックします。 2. テンプレートの名前を指定します。 3. **\[Publish (パブリッシュ)\]**​ をクリックします。 ## [](#結果)結果 自分のテンプレート用に作成された新しいページが Exchange に表示されます。 Flow Designer でテンプレートをパブリッシュできなかった場合、Exchange にパブリッシュするための権限がユーザー ID にあることを確認します。 ## [](#次のステップ)次のステップ Exchange 内のテンプレートのページで、説明、スクリーンショット、または動画を提供し、テンプレートの目的と使用方法を説明します。 テンプレートの更新が必要になった場合は、Mule アプリケーションを更新して ​**\[Publish (パブリッシュ)\]**​ をクリックします。バージョン番号は自動的に増分されます。 テンプレートに関する Exchange 内の情報を更新する必要がある場合、Exchange でテンプレートのページを編集します。たとえば、Flow Designer から更新をパブリッシュするときに、テンプレートの名前を変更することはできません。ただし、Exchange で名前を変更できます。 # Exchange にパブリッシュされたアセットのソースプロジェクトの表示 アセットを Anypoint Exchange にパブリッシュした後、API Designer でソースファイルを表示できます。Exchange によって、ソースファイルが含まれる API Designer プロジェクトへの直接リンクが提供されます。 ZIP ファイル、または API Designer 外のその他のリソースを使用してプロジェクトを Exchange にパブリッシュした場合、表示できるのはそのプロジェクトのコンテンツのみです。ファイルを編集するには、ファイルのコンテンツに基づいて新しいプロジェクトを作成します。プロジェクトを Exchange にパブリッシュした後に API Designer から削除した場合、参照のみモードでのみ表示できます。 ## [](#手順)手順 1. API 仕様またはフラグメントを Anypoint Exchange で開きます。 2. 表示する仕様またはフラグメントのバージョンの横にある ​**︙**​ ドロップダウンメニューをクリックします。

Exchange にパブリッシュされた仕様またはフラグメントの以前にパブリッシュされたバージョンは表示のみ可能です。編集はできません。

または、アセットツールバーで ​**︙**​ をクリックして ​**\[View code (コードを表示)\]**​ を選択し、仕様またはフラグメントの最新バージョンを表示できます。 3. **\[View code in API Designer (API Designer でコードを表示)\]**​ を選択します。 API Designer で仕様またはフラグメントが含まれるプロジェクトが参照のみビューで開きます。 4. プロジェクトでファイルを編集するには、​**\[Edit spec (仕様を編集)\]**​ をクリックします。 このオプションは、プロジェクトに対する編集権限があり、プロジェクトが API Designer に存在する場合のみ使用できます。 プロジェクトを Exchange にパブリッシュした後で編集すると、API Designer に新しいバージョンの編集を続行するか Exchange にパブリッシュしたバージョンを表示するかを選択できるオプションが表示されます。 ## [](#関連情報)関連情報 - [API 仕様のパブリッシュ](https://docs.mulesoft.com/jp/design-center/design-publish) # Flow Designer からの Mule アプリケーションのデプロイ:page-support-status: eolScheduled Flow Designer を使用して作成するすべての Mule アプリケーションはデザイン環境に作成されます。作成した Mule アプリケーションを本番に移行する準備が整ったら、Mule アプリケーションを別の環境にデプロイできます (これを組織が許可している場合)。対象環境では、アプリケーションを実行するのに十分の仮想コアが利用できる必要があります。そうでないと、デプロイは失敗します。 アプリケーションのデプロイ時には、コネクタ設定と接続を変更できます。これらの変更は、テスト環境と対象環境の違いによって変更が必要な場合に行います。たとえば、アプリケーションを ​**Sandbox**​ 環境でテストした後に本番環境にデプロイするには、ほとんどの場合は、コネクタがテストシステムへの接続に使用していた接続情報を、本番システムへの接続用の接続情報に置き換える必要があります。

アプリケーションのデプロイ時に行った設定の変更は、プロジェクトの設定には適用されません。これらの変更は、デプロイするアプリケーションにのみ適用されます。

たとえば、アプリケーションのコネクタで ConfigA という設定を使用しているとします。プロジェクトでは、ConfigA は ConnA という接続を使用します。アプリケーションをデプロイするときに、別の接続である ConnB を使用するように ConfigA を変更します。この場合でも、プロジェクトの ConfigA は ConnA を使用します。

アプリケーションをデプロイしたら、そのすべてのプロパティの値は、Runtime Manager 内のアプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Properties (プロパティ)\]**​ セクションで保護されます。Runtime Manager でアプリケーションのプロパティのリストを表示するには、​**\[Applications (アプリケーション)\]**​ をクリックしてアプリケーションを選択し、​**\[Settings (設定)\]**​、​**\[Properties (プロパティ)\]**​ の順にクリックします。 ## [](#flow-designer-から-mule-アプリケーションをデプロイする方法)Flow Designer から Mule アプリケーションをデプロイする方法 1. Flow Designer の右上隅にある矢印をクリックして、​**\[Deploy application (アプリケーションをデプロイ)\]**​ を選択します。 ![「Deploy application (アプリケーションをデプロイ)」 オプションの場所](/mulesoft/current/ja-jp/design-center/_images/fd-deploy-option.png) Figure 1. **\[Deploy application (アプリケーションをデプロイ)\]**​ オプションがこのメニューに表示されます。
1矢印をクリックします。
2このオプションを選択します。
1. アプリケーションをデプロイする CloudHub 環境を選択します。 2. デプロイするアプリケーションのデフォルト名を受け入れるか、または新しい名前を入力します。 3. アプリケーション内のいずれかのコネクタをシステムに接続する方法を変更する場合は、​**\[Customize connections for this deployment (このデプロイの接続をカスタマイズ)\]**​ をクリックして、アプリケーション内のコネクタのリストを表示します。コネクタをクリックして、コネクタで使用できる接続のリストを表示します。 ## [](#次のステップ)次のステップ Runtime Manager に移動してアプリケーションを管理できます。Flow Designer で ​**\[Deploy (デプロイ)\]**​ ボタンの左側にある 3 つのドットのアイコンをクリックして、​**\[View in Runtime Manager (Runtime Manager で表示)\]**​ を選択します。 ## [](#関連情報)関連情報 - [コネクタの設定への接続の追加](https://docs.mulesoft.com/jp/design-center/fd-connection-create) - [アプリケーションプロパティを安全に隠す](https://docs.mulesoft.com/cloudhub/secure-application-properties) - [CloudHub 環境](https://docs.mulesoft.com/jp/access-management/environments) - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) # Flow Designer ツアー:page-support-status: eolScheduled 視覚的な指向性をもつ Flow Designer は、Mule アプリケーションを視覚的に構築するためのツールであり、これにより、データが各フローをどのように移動するかを端から端まで確認できます。 ## [](#flow-designer-インターフェースの機能)Flow Designer インターフェースの機能 Flow Designer の機能は 5 つの領域に整理されます。 ![FD annotated](/mulesoft/current/ja-jp/design-center/_images/FD-annotated.png) Figure 1. Flow Designer インターフェースの 5 つの領域 1. キャンバス ここでプロジェクトのフローを作成します。 キャンバスの左上隅にプロジェクトとフローの名前があります。 2. ペイン 上部のアイコンをクリックすると ​**\[Project (プロジェクト)\]**​ ペインが開き、プロジェクトのフロー、使用されている設定、および定義済みのすべてのグローバルデータ型が表示されます。 下部のアイコンをクリックすると ​**\[Dependencies (連動関係)\]**​ ペインが開き、プロジェクトの連動関係が表示されます。 開いているペインのアイコンをクリックすると、ペインを非表示にすることができます。ペインを再度表示するには、いずれかのアイコンをクリックします。 再利用可能な設定とは? 別のシステムに接続されるカードを追加する場合、Flow Designer でそのシステムを検索および認証できる方法を指定します。たとえば、Database カードをフローに追加する場合、データベースの種別、データベースのホスト、他の接続情報、および認証方法を指定する必要があります。この情報のセットを​_設定_​と呼びます。1 つの Database カードを追加した後、次の Database カードを追加すると、そのカードではデフォルトで同じ設定が使用されます。ただし、これは変更できます。\[Project (プロジェクト)\] ペインの再利用可能な設定のリストは、プロジェクトで作成した設定のうち、追加のカードで使用できるすべての設定のリストです。 データ型とは? データ型は、フローで使用するデータの形式を示します。ローカルデータ型は特定のカード内で定義されます。グローバルデータ型はプロジェクトに対して定義され、複数のカードで再利用できます。グローバルデータ型の作成および使用方法の例は、​[「Flow Designer での最初の Mule アプリケーションの作成」](https://docs.mulesoft.com/jp/design-center/salesforce-to-twilio)​を参照してください。 連動関係とは? 連動関係はフローで使用する任意のコネクタ、コアの Mule Runtime コンポーネント、API、またはモジュールです。このいずれかのオブジェクトをフローに最初に追加する場合、その最新バージョンを追加します。その後、フローでこのオブジェクトを再度使用するたびに、同じバージョンを使用します。Exchange 内のオブジェクトが更新される場合があります。この更新のメリットをフローで利用する必要がある場合、フローで使用しているオブジェクトのバージョンを更新できます。 3. ツールバー ここでは、プロジェクトの変更を元に戻したり、やり直したりできるほか、プロジェクトのダウンロードや、キャンバスのズームレベルの変更ができます。 4. コントロールバー ここでは、アプリケーションをテスト目的で実行できるほか、アプリケーションを別の環境にデプロイできます。 5. **\[Problems (問題)\]**​ タブと ​**\[Logs (ログ)\]**​ タブ 最初のタブをクリックすると、プロジェクトに存在するすべてのエラーのリストが表示されます。表示されたエラーをクリックすると、エラーの発生場所を開くことができます。 2 番目のタブをクリックすると、プロジェクトのログファイルが表示されます。アプリケーションの実行の問題をトラブルシューティングする場合、このファイルが役立つ可能性があります。 ## [](#フローの外観)フローの外観 単一のフローで構成される Mule アプリケーションの例を次に示します。 ![fd annotated 2](/mulesoft/current/ja-jp/design-center/_images/fd-annotated-2.png) Figure 2. 「Flow Designer での最初の Mule アプリケーションの作成」のフロー例のカード この例のカードは次のコアコンポーネントとコネクタを表します。 1. Salesforce Connector の Subscribe Topic 操作 2. Set Variable コアコンポーネント 3. Choice コアコンポーネント 4. Database Connector の SELECT 操作の 2 つのインスタンス 5. Transform コアコンポーネント 6. HTTP Connector の HTTP Request 操作 7. Transform コアコンポーネントのもう 1 つのインスタンス 8. Twilio Connector の Send Message 操作 このフローの作成方法と各カードの機能についての詳細は、​[「Flow Designer での最初の Mule アプリケーションの作成」](https://docs.mulesoft.com/jp/design-center/salesforce-to-twilio)​を参照してください。 フローの最初のカードはトリガーカードです。これは、フロー内のデータの移動を開始するために使用するコネクタと操作を表します。 フローの最後にカードを追加するには、前のカードに続くプラス記号をクリックします。 2 つのカードの間にカードを追加するには、それらの間に表示されている矢印の上にマウスポインターを置きます。矢印がプラス記号に変わったら、それをクリックします。 # Flow Designer でサポートされるシンプルデータ型:page-support-status: eolScheduled このデータ型はデータを特定の形式で保存しますが、カスタムデータ型などとは異なり構造を持たないため、シンプルと呼ばれます。シンプルデータ型は Boolean、Date、DateTime、Integer、Number、String です。 Boolean (ブール) true または false に評価します。使用可能な値: `true`​、​`false`​。 Date (日付) 年、月、日を ​`yyyy-MM-dd`​ 形式で保存します。 DateTime (日時) タイムゾーン内の日時を保存します。タイムゾーンはグリニッジ標準時 (GMT) を基準とする相対的な時間です。タイムゾーンには「+」または「-」を含める必要があります。たとえば、​`03:00:00`​ は時刻ですが、​`+03:00`​ はタイムゾーンです。マカオの 2019 年 6 月 1 日午後 12 時 30 分を表す例: `2019-06-01T12:30:00+08:00` Integer (整数) \-2,147,483,647 ~ 2,147,483,647 の整数を保存します。整数に小数点はありません。 Number (数値) `number`​ は浮動小数点数を保存します。これには、1.40129846432481707e-45 ~ 3.40282346638528860e+38 の値を使用でき、小数点または整数を含むことができます。 String (文字列) テキスト、数値 (​`number`​ データ型ではない)、またはこの両方の組み合わせを保存します。例: 「94u0sfjlk\*(f!\`lkkjd」、「18005555555」、「Fred」 ## [](#関連情報)関連情報 - [フローでのデータ型の定義および使用](https://docs.mulesoft.com/jp/design-center/about-data-types) - [Flow Designer でのカスタムデータ型](https://docs.mulesoft.com/jp/design-center/fd-custom-data-types) # Flow Designer での Mule アプリケーションプロジェクトのログの表示 Mule アプリケーションプロジェクトのログを表示できます。ログは、アプリケーションをテストしたり、MuleSoft サポートと一緒にアプリケーションの動作に関する問題を特定したりする場合に役立ちます。 ログファイルには、2 つの主要なメッセージカテゴリがあります。 システムメッセージ CloudHub から出力されるメッセージです。CloudHub がプロジェクトにワーカーを割り当て、そのプロジェクトでアプリケーションを開始する場合のメッセージ例は次のようになります。 17:36:19.894 03/12/2019 Deployment system SYSTEM Deploying application to 1 workers in us-east-1 region(s). 17:36:20.415 03/12/2019 Deployment system SYSTEM Provisioning CloudHub worker in region=us-east-1... 17:36:32.391 03/12/2019 Deployment system SYSTEM Starting CloudHub worker at 54.172.105.253 ... 17:37:18.402 03/12/2019 Deployment system SYSTEM Worker(54.172.105.253): Starting your application on mule=4.1.5... 17:37:21.147 03/12/2019 Deployment system SYSTEM Worker(54.172.105.253): Your application has started successfully. 17:37:21.520 03/12/2019 Deployment system SYSTEM Your application is started. プロジェクトに割り当てられたワーカーから出力されるメッセージ これらのメッセージは、ワーカーが実行する異なるタスクを示します。メッセージの例を示します。 17:37:18.814 03/12/2019 Worker-0 qtp630288493-49 INFO ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + New app 'thisApp-firs' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 17:37:18.938 03/12/2019 Worker-0 qtp630288493-49 INFO ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Initializing app 'thisApp-firs' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 17:37:18.947 03/12/2019 Worker-0 qtp630288493-49 INFO The PersistentQueueManager is NOT configured.The normal VM queue manager will be used. 17:37:20.397 03/12/2019 Worker-0 qtp630288493-49 INFO Registering extension ee (version: 4.1.5 vendor: MuleSoft, Inc. ) 17:37:20.400 03/12/2019 Worker-0 qtp630288493-49 INFO Registering extension mule (version: 4.1.5 vendor: MuleSoft, Inc. ) 17:37:20.648 03/12/2019 Worker-0 qtp630288493-49 INFO Initializing RegistryBroker このログファイルには、プロジェクトのフローに追加した Logger カードからのメッセージも示されています。 ## [](#手順)手順 - キャンバスの右下隅にある ​**\[Logs (ログ)\]**​ をクリックします。 ![log view](/mulesoft/current/ja-jp/design-center/_images/log-view.png) ## [](#結果)結果 \[Log (ログ)\] ペインが展開されてログファイルが表示されます。 ![log file](/mulesoft/current/ja-jp/design-center/_images/log-file.png) ## [](#次のステップ)次のステップ - ログの行をコピーするには、左側にある ​**\[Copy (コピー)\]**​ オプションをクリックします。 - ログファイルのコンテンツを削除するには、​**\[Logs (ログ)\]**​ 表示ラベルの右側にあるドットをクリックして、​**\[Clear Logs (ログを消去)\]**​ を選択します。 - ログファイルを Runtime Manager で表示するには、​**\[Logs (ログ)\]**​ 表示ラベルの右側にあるドットをクリックして、​**\[View in Runtime Manager (Runtime Manager で表示)\]**​ を選択します。

Anypoint Platform で自分のプロファイルのデフォルト環境を指定していない場合は、指定するように要求されます。指定したら、フローデザインキャンバスに戻って ​[View in Runtime Manager (Runtime Manager で表示)]​ を再び選択します。

Runtime Manager では、システムログのメッセージを、プロジェクトに割り当てたワーカーのメッセージとは別に表示できます。 # Flow Designer でのカスタムデータ型:page-support-status: eolScheduled カスタムデータ型を CSV、JSON、Java オブジェクト、XML のいずれかの形式で作成できます。カスタムデータ型は、キー - 値ペアまたは XML として構成されます。これに含まれる値はシンプルデータ型です。

カードの入力として必要とされるカスタムデータ型が、前のカードで出力として作成されるカスタムデータ型とは異なる場合があります。この状況では、この 2 つのカード間に Transform カードを配置する必要があります。Transform カードでは、カスタムデータ型の要素を別のカスタムデータ型の要素にマップする方法を Flow Designer に説明することができます。​「入力データへの出力データのマッピング」​を参照してください。

CSV データはカンマ区切り値としてカードに入ることができます。このデータ形式は、スプレッドシートのコンテンツをエクスポートする場合によく使用されます。Flow Designer でカスタムデータ型に対してこの形式を使用する場合、REST API Modeling Language (RAML) のスキーマを提供し、データ型をどのように解釈するかを Flow Designer に説明する必要があります。次に、簡単なスキーマの例を示します。 #%RAML 1.0 DataType type: array items: properties: firstname: type: string lastname: type: string age: type: number JSON JavaScript Object Notatation (JSON) はデータをキー - 値ペアで構成する形式です。この形式を使用する場合、サンプルデータを含む例か、データ型の基礎となる JSON スキーマを提供する必要があります。 JSON スキーマの例 { "$id": "https://example.com/person.schema.json", "$schema": "http://json-schema.org/draft-07/schema#", "title": "Person", "type": "object", "properties": { "firstName": { "type": "string", "description": "The person's first name." }, "lastName": { "type": "string", "description": "The person's last name." }, "age": { "description": "Age in years which must be equal to or greater than zero.", "type": "integer", "minimum": 0 } } } スキーマに基づく JSON ファイルの例 { "firstName": "Olafur", "lastName": "Karlsson", "age": "45" } Object この形式は Java オブジェクトです。Flow Designer でこの形式を使用する場合、REST API Modeling Language (RAML) のスキーマを提供し、データをどのように解釈するかを Flow Designer に説明する必要があります。次に、簡単なスキーマの例を示します。 #%RAML 1.0 DataType type: object properties: field1: type: string field2: properties: field21: type: string field22: type: string XML XML はタグ間でデータを構成する形式です。この形式を使用する場合、サンプルデータを含む例か、データ型の基礎となる JSON スキーマを提供する必要があります。 XML スキーマの例 スキーマに基づく XML ファイルの例 "Olafur Karlsson 45 ## [](#関連情報)関連情報 - [フローでのデータ型の定義および使用](https://docs.mulesoft.com/jp/design-center/about-data-types) - [Flow Designer でサポートされるシンプルデータ型](https://docs.mulesoft.com/jp/design-center/fd-supported-simple-data-types) # Flow Designer でのトラブルシューティング:page-support-status: eolScheduled Flow Designer で問題をトラブルシューティングする場合に参照できるいくつかのリソースを以下に示します。 [Logger を使用したデータのログ記録](https://docs.mulesoft.com/jp/design-center/logger-task-design-center)​ 1 つ以上の Logger コアコンポーネントをフローに追加して、実行時のフローからの情報をログに記録します。 [Mule アプリケーションプロジェクトのエラーのリスト表示とエラー箇所への移動](https://docs.mulesoft.com/jp/design-center/viewing-problems-fd-canvas)​ フローで発生している可能性があるエラーをどこで確認できるか、およびエラーの発生箇所をどのように特定できるかについて説明します。 [Flow Designer での Mule アプリケーションプロジェクトのログの表示](https://docs.mulesoft.com/jp/design-center/view-clear-logs-task)​ Mule アプリケーションプロジェクトのログの表示方法について説明します。このログは、アプリケーションをテストしたり、MuleSoft サポートと連携してアプリケーションの動作に関する問題を特定したりする場合に役立ちます。 [Flow Designer のエラーメッセージ](https://docs.mulesoft.com/jp/design-center/troubleshooting-reference)​ Mule アプリケーションプロジェクトを初期化、実行、デプロイするときに Flow Designer で発生する可能性がある問題を解決する方法について説明します。 # Flow Designer での最初の Mule アプリケーションの作成:page-support-status: eolScheduled あなたは Northern Trail Outfitters (NTO) 社で Salesforce Sales Cloud の接続担当リーダーを務めています。NTO はスタイリッシュで着心地のよい衣料品のほか、アウトドア用品やフィットネス用品を製造している会社です。 NTO は、Sales Cloud を利用してパイプラインの商談を追跡し、受注に結び付けています。商談が成立すると、営業担当者は注文管理システムで発注します。 また、顧客も NTO に対して頻繁に注文の状態を確認してきます。 NTO は MuleSoft を使用して、商談が成立した時点で自動的に発注し、SMS で顧客に注文の状況や商品の ETA (到着予定) などを知らせるためのプロセスを作成したいと考えています。 与えられた任務は、このプロセスを厳しいスケジュールで完成させることです。あなたは、NTO が使用する 4 つのシステムを統合する必要があると実感しています。
システム 目的

Salesforce Sales Cloud

商談の管理

MySQL データベース

製品情報と SKU の格納

NTO 注文システム

発注し、追跡情報と注文の ETA を返す。NTO Orders API で呼び出し可能。

Twilio

顧客への通知の送信

## [](#アプローチ)アプローチ このプロセスを自動化するためには、統合に関するいくつかの課題を克服しなければなりません。この受注から回収までのサイクルを自動化するためには、以下の処理が必要になります。 1. Salesforce は、商談が成立した時点でワークフローの自動化プロセスを開始します。このプロセスは、商談の状態が「成立」に移行した時点で Salesforce によってトリガーされます。 2. プロセスは、製品データベースから適切な製品情報を取得します。 3. プロセスが情報を入手すると、NTO Orders API によって発注をかけます。 4. Orders API は、注文番号、追跡情報、そして配送の ETA を返します。 5. API が返す情報は、人間が読める形式のテキストに変換され、SMS で顧客に送信されます。 このプロセスを図で表すと次のようになります。 ![salesforce to twilio flowchart](/mulesoft/current/ja-jp/design-center/_images/salesforce-to-twilio-flowchart.png) この計画を実現するために最適なツール、それが Flow Designer です! ## [](#始める前に)始める前に - [MuleSoft Anypoint Platform](https://anypoint.mulesoft.com/login/signup)​ へのアクセス情報を持っていない場合は、30 日間の無料トライアルにサインアップします。 - [Salesforce の無料開発者アカウント](https://developer.salesforce.com/signup)​にサインアップします。このアカウントにはログイン情報とセキュリティトークンが必要です。 - [Twilio の無料開発者アカウント](https://www.twilio.com/try-twilio)​にサインアップします。Twilio が新しいアカウント用に用意するトライアル電話番号が必要です。また、自分のアカウント SID と認証トークンも必要です。 ## [](#成立した商談の取得)成立した商談の取得 Salesforce で商談の状態が「成立」に移行した時点で、すぐにアプリケーションがトリガーされるようにする必要があります。そのためには、Salesforce で SOQL クエリを使用して、送信する項目とアプリケーションのトリガー条件を指定します。クエリを作成したら、MuleSoft アプリケーションのトリガーとして機能するプッシュトピックをセットアップできます。 1. [SOQL クエリビルダー](https://workbench.developerforce.com/query.php)​に移動します。(Salesforce ログイン情報でのログインが必要です。) 2. **\[Opportunity (商談)\]**​ をオブジェクトとして選択します。 3. **\[Fields (項目)\]**​ メニューから ​**\[Amount (金額)\]**​、​**\[CloseDate (成立日)\]**​、​**\[Id\]**​、および ​**\[Name (名前)\]**​ を選択します。 4. **\[Filter results by (結果の絞り込み条件)\]**​ 項目に ​`StageName = ‘Closed Won’`​ を追加します。 5. **\[Query (クエリ)\]**​ ボタンをクリックしてクエリをテストします。成立したすべての商談のリストが表示されたら成功です。クエリが次のようになっていることを確認してください。​`SELECT Amount,CloseDate,Id,Name FROM Opportunity WHERE StageName = 'Closed Won'` ![soql query screen 1](/mulesoft/current/ja-jp/design-center/_images/soql-query-screen-1.png) 6. クエリをクリップボードにコピーします。 7. ワークベンチの一番上にある ​**\[Query (クエリ)\]**​ メニューから \[Streaming Push topics (ストリーミングプッシュトピック)\] ページに移動します。 8. **\[Create New (新規作成)\]**​ オプションを選択して新しいプッシュトピックを作成します。 9. プッシュトピックに ​`ClosedOpps`​ という名前を付けて、作成したクエリに貼り付けます。 10. プッシュトピックを保存します。 ![streaming push topics](/mulesoft/current/ja-jp/design-center/_images/streaming-push-topics.png) これで、クエリ条件が成立する度に、Salesforce は ​`ClosedOpps`​ プッシュトピックにイベントをプッシュします。 ## [](#flow-designer-でのプロジェクトの作成)Flow Designer でのプロジェクトの作成 Flow Designer を使用して、プロジェクトで Mule アプリケーションを作成します。1 つのプロジェクトには 1 つの Mule アプリケーションしか作成できません。 1 つの Mule アプリケーションは、1 つまたは複数の​_フロー_​で構成されます。MuleSoft が定義するフローとは、Mule Runtime Engine の高度なメッセージフロー機能を使用してサービスのオーケストレーションを実現するためのシンプルで柔軟なメカニズムであり、サービスオーケストレーションとも呼ばれます。Flow Designer に限って言えば、フローはコアコンポーネント (ループ、条件、変換など) やシステムおよび API へのコネクタ (Salesforce、SAP、Google Docs など) を表す一連の​_カード_​を意味します。カードには別の側面もありますが、このチュートリアルではこの 2 点だけを覚えておけば十分です。 データは、フローの先頭から末尾に向かって流れます。フローに沿って、カードはシステムの更新、システムに対するクエリの実行、メッセージの送信、データベース行の削除など、コアコンポーネントやコネクタが行えるあらゆる処理を実行します。 多くのコアコンポーネントやコネクタが用意されています。このチュートリアルでは以下を使用します。 - Salesforce Connector - Set Variable コンポーネント - Choice router コンポーネント - Database Connector - Set Payload コンポーネント - Transform コンポーネント - Twilio Connector このプロジェクトでは、フローを 1 つだけ作成します。 以下の手順でプロジェクトを作成します。 1. Anypoint Platform にログインします。 2. Design Center を開いて新しい Mule アプリケーションを作成します。 1. **\[Projects (プロジェクト)\]**​ ページで、​**\[Create new (新規作成)\]**​ をクリックします。 2. **\[New Mule App (新しい Mule アプリケーション)\]**​ を選択します。 3. **\[New Mule App (新しい Mule アプリケーション)\]**​ ダイアログで、プロジェクトに「​`Order-to-cash automation`​」という名前を付けます。 4. **\[Create App (アプリケーションを作成)\]**​ をクリックします。 3. **\[Let’s Get Started (始めよう)\]**​ ウィザードで、左下隅にある ​`Go straight to canvas`​ のリンクをクリックします。 **結果:**​ Flow Designer が開き、キャンバスの中央に空白のトリガーカードが表示されます。 ![canvas empty trigger](/mulesoft/current/ja-jp/design-center/_images/canvas-empty-trigger.png) ## [](#フローのトリガーの設定)フローのトリガーの設定 トリガーとは、Mule アプリケーションでフローを開始するイベントです。このプロジェクトでは、Salesforce Sales Cloud で商談の状態が ​`Closed Won`​ に変化するというイベントがトリガーとなります。上記の「成立した商談の取得」で作成した ​`ClosedOpps`​ トピックをサブスクライブしている Salesforce Connector を表すようにトリガーカードを設定します。 1. トリガーカードをクリックします。 **結果:**​ 使用できるコネクタのリストがカードに表示されます。 2. **\[Search (検索)\]**​ 項目に「Salesforce」と入力します。 **結果:**​ リストに Salesforce Connector が表示されます。 3. Salesforce Connector を選択します。 **結果:**​ Salesforce Connector で Mule アプリケーションをトリガーするために使用できる操作のリストが表示されます。 4. **Subscribe Topic**​ 操作を選択します。 **結果:**​ カードが開きます。左上隅に Salesforce Connector であることが表示されます。操作名 (Subscribe Topic) も表示されます。カードの一番上には「You need to set up the Salesforce configuration. Click here to set it up. (Salesforce 設定をセットアップする必要があります。ここをクリックしてセットアップしてください)」というメッセージが表示されます。 5. Flow Designer での Salesforce への認証方法を指定します。 1. メッセージ中のリンクテキストをクリックします。 2. **\[Connection Type (接続種別)\]**​ 項目で ​**\[Basic Username Password (基本ユーザー名/パスワード)\]**​ を選択します。再利用可能な接続が使用できる場合、その 1 つを選択します。 3. ユーザー名、パスワード、およびセキュリティトークンを指定します。 4. **\[Test (テスト)\]**​ ボタンをクリックして、指定したログイン情報で Flow Designer が Salesforce に接続できることを確認します。接続できない場合は、ログイン情報とトークンを再確認してください。テストが成功したら設定内容を保存します。 6. **\[Topic (トピック)\]**​ 項目に ​`ClosedOpps`​ と入力して、プッシュトピックをコネクタに追加します。カードの右上隅にある \[X\] をクリックするか、またはキャンバス上の空白スペースをクリックして、カードを閉じます。 ## [](#twilio-用のカードの設定)Twilio 用のカードの設定 SMS で顧客に通知を送信しますので、Twilio Connector と Send Message 操作を使用します。 1. Salesforce カードの右側にあるプラス記号をクリックします。 2. Twilio Connector と ​**Send Message**​ 操作を選択します。 **結果:**​ Twilio カードが開きます。カードの一番上には「You need to set up the Twilio Connector configuration. Click here to set it up. (Twilio Connector 設定をセットアップする必要があります。ここをクリックしてセットアップしてください)」というメッセージが表示されます。 3. Flow Designer での Twilio への認証方法を指定します。 1. メッセージ中のリンクテキストをクリックします。 2. **\[Username (ユーザー名)\]**​ 項目で、Twilio 用のアカウント SID を指定します。​**\[Password (パスワード)\]**​ 項目で、Twilio 用の認証トークンを指定します。 これらの項目で自分のユーザー名やパスワードを指定しないでください。指定した場合、アプリケーションでフローをトリガーしたときに Twilio カードからメッセージ ​`HTTP POST on resource 'https://api.twilio.com:443//Accounts//Messages.json' failed: Timeout exceeded.`​ が返されます。 3. **\[Test (テスト)\]**​ ボタンをクリックして、指定したログイン情報で Flow Designer が Twilio に接続できることを確認します。接続できない場合は、ログイン情報とトークンを再確認してください。テストが成功したら設定内容を保存します。 4. **\[Account SID (アカウント SID)\]**​ 項目に自分のアカウント SID をもう一度入力します。その後、カードを閉じます。 ## [](#データ型の作成)データ型の作成 NTO のシステムは、すべて異なるデータ形式を使用しています。作成中のフローでは、これらのシステム間でデータを受け渡す必要があるため、Flow Designer では、これらのデータ型の例を定義する必要があります。データ型のいくつかは再利用しますので、フロー内で必要とされるポイントではなく、プロジェクトレベルで作成できます。 ### [](#salesforce-が送信するデータ型を作成する)Salesforce が送信するデータ型を作成する 1. プロジェクトサイドバーで、\[Data Types (データ型)\] の見出しの横にあるプラス記号をクリックします。 **結果:**​ \[New Type (新しい型)\] ダイアログが開きます。 2. Salesforce の商談を表し、プッシュトピックの ​`ClosedOpps`​ がフローをトリガーするために送信するデータ型を作成します。 1. データ型に「Salesforce Opportunity」という名前を付けます。 2. 次の JSON を \[Add your JSON example (JSON 例の追加)\] 項目に貼り付けます。 ```none { "Amount": 15000, "Id": "0061U0000079dWXQAY", "CloseDate": "2019-01-25T00:00:00.000Z", "Name": "Dickenson Mobile Generators" } ``` **結果:**​ ダイアログの右側のサイドバーで例の項目が自動的に解析されます。 3. **\[Save (保存)\]**​ をクリックします。 ### [](#orders-api-との間でやり取りするデータ型の作成)Orders API との間でやり取りするデータ型の作成 同じ手順で、次の 2 つのデータ型を作成します。 #### [](#名前-order-information)名前: `Order Information` プロセスは、この形式で Orders API にデータを送信します。 以下は \[New Type (新しい型)\] ダイアログで使用する例です。 ```none { "OppId": "fsjf3439d993", "OrderAmount": 500000, "orderdate": "2018-11-13T11:15:45", "productInfo": { "productID": "CK111274", "category": "Small", "SKU": "CKS0", "productName": "Old School Classic Kicks", "inventory": 9999 } } ``` #### [](#名前-order-tracking)名前: `Order Tracking` Orders API は、発注後に次の情報を返します。 以下は JSON 例です。 ```none { "OrderID": 50122, "TrackingNo": "Z34342211", "ETA": "2018-11-13T11:15:45" } ``` ### [](#製品データベースに格納されるデータ型の作成)製品データベースに格納されるデータ型の作成 このデータ型に ​`Product Information`​ という名前を付けて、次の JSON 例を使用します。 ```none [ { "productID": "CK989603", "category": "Medium", "SKU": "CKS50", "productName": "Air Fly High Quality Sneakers", "inventory": 22333 } ] ``` ## [](#商談データの変数への保存)商談データの変数への保存 フローの下流では商談データを使用し、トリガーの後方にあるカードはそれぞれの出力を作成するため、すべての商談データを変数に保存する必要があります。 1. Salesforce カードと Transform カードの間にある矢印にカーソルを置いて、矢印をプラス記号に変えます。プラス記号をクリックして、新しいコンポーネントを追加します。 2. Set Variable コンポーネントを検索して選択します。 3. 変数に ​`OppDetails`​ という名前を付けます。 4. カードの右側にある項目リストで ​**\[Custom Expression (カスタム式)\]**​ をクリックし、​**\[Value (値)\]**​ 項目までドラッグします。 5. 式ボックスの右側にある矢印をクリックして、​**\[EXPAND (展開)\]**​ をクリックします。 6. \[Custom Expression (カスタム式)\] ダイアログの ​**\[Expression (式)\]**​ 項目に ​`payload`​ と入力します。 式 ​`payload`​ は、Mule アプリケーションの 1 回のアクティベーション中に Set Variable カードに到達する入力全体を示します。カードの右側のペインに表示されているように、ペイロードはこの事例では 4 つのデータ要素で構成されています。式 ​`payload`​ ではなく、これらの 1 つ以上の要素を使用するように ​**\[Expression (式)\]**​ ボックスで指定できます。これらの要素をクリックしてボックスにドラッグできます。ただし、このチュートリアルでは、ペイロード全体を使用します。 ![fd tutorial set var right pane](/mulesoft/current/ja-jp/design-center/_images/fd-tutorial-set-var-right-pane.png) Figure 1. Set Variable カードに到達するペイロードを構成する 4 つのデータ要素。 7. **\[OK\]**​ をクリックして、カードを閉じます。 フローが次のようになっていることを確認してください。 ![flow with set variable card](/mulesoft/current/ja-jp/design-center/_images/flow-with-set-variable-card.png) ## [](#取引規模に基づいた-sku-の追加)取引規模に基づいた SKU の追加 NTO では、大企業、中小企業、小売業者と、顧客ごとに異なる SKU (ストックキーピングユニット) を使用しています。取引規模に基づいて、適切な製品情報を製品データベースから商談に追加する必要があります。製品カテゴリを下表に示します。
取引規模 (商談金額) 製品カテゴリ

$100,000 超

Enterprise (大企業)

$50,000 超

Small Business (中小企業)

$50,000 以下

Retail (小売業者)

Choice router コンポーネントと Database コンポーネントを併用することで、この分岐となる if-else ロジックを実現します。 たとえば、取引規模が $100,000 を超えている場合はプロセスが「大企業」製品カテゴリの SKU でデータベースを検索するように Choice router コンポーネントで指定できます。

Choice router コンポーネントは Mule Runtime の一部です。Mule Runtime には他にもいくつかのコンポーネントがあります。これらのコンポーネントは他のシステムには接続せず、フローのロジック作成を支援します。

1. Choice router ブロック (Choice カードと、ルーティングオプションを指定する複数のサブカードで構成されます) をフローに追加します。 1. Set Variable カードと Twilio カードの間にあるプラス記号をクリックします。 2. Choice router を選択します。 **結果:**​ Choice router ブロックがフローに表示されます。 ![choice router card](/mulesoft/current/ja-jp/design-center/_images/choice-router-card.png) 2. ルーティングオプションをセットアップします。 1. 最初のサブカードをクリックして開きます。 2. サブカードの右上隅にある 3 つのドットをクリックして ​**\[Add Below (下に追加)\]**​ を選択します。現在のサブカードが閉じて、その下に新しいサブカードが開きます。 3. 最初のサブカードをクリックします。 4. `payload.Amount > 100000`​ を ​**\[Expression (式)\]**​ 項目に貼り付けます。 5. サブカードに ​`Enterprise`​ という名前を付けます。 6. 2 番目のサブカードをクリックします。 7. `payload.Amount > 50000`​ を ​**\[Expression (式)\]**​ 項目に貼り付けます。 8. サブカードに ​`Small Business`​ という名前を付けます。 **結果:**​ Choice router ブロックに、フローで必要な 3 つのルーティングオプションが表示されます。デフォルトのオプションは $50,000 以下の注文用であるため、小売業者の SKU で使用されます。フローは次のようになっています。 + ![flow with choice](/mulesoft/current/ja-jp/design-center/_images/flow-with-choice.png) 3. 取引の規模が「大企業」か「中小企業」かに従って、製品データベースに対してクエリを実行します。 1. **Enterprise**​ サブカードの横にあるプラスアイコンをクリックします。 2. Database カードを追加して ​**Select**​ 操作を選択します。 3. 次の情報でデータベースドライバーを設定します。 - Connection Type (接続種別): `MySQL Connection` - Host (ホスト): `ntoproducts.c3w6upfzlwwe.us-west-1.rds.amazonaws.com` - Port (ポート): `3306` - User (ユーザー): `mulesoft` - Password (パスワード): `mulesoft` - Database (データベース): `nto_products` 4. 接続をテストして、成功したら ​**\[Save (保存)\]**​ をクリックします。 5. 次のクエリを Database カードに追加します。 ```none select * from products where category = "Enterprise" and inventory > 1 limit 1 ``` 6. Database カードを閉じます。 7. Database カードを ​**Small Business**​ サブカードの後に追加して、​**Select**​ 操作を選択します。

データベースドライバーを再び設定する必要はありません。その理由は、上の手順で設定したときに、Flow Designer で設定が保存されているからです。プロジェクトサイドバーの「Reusable Configurations (再利用可能な設定)」の下に「Database (データベース)」というエントリが確認できます。

8. この Database カードに次のクエリを追加します。 ```none select * from products where category = "Small Business" and inventory > 1 limit 1 ``` 4. 取引の規模が $50,000 以下の場合のデフォルトオプションをセットアップします。このケースでは、データベースに対してクエリを実行する必要はありません。 1. Set Payload カードを Default サブカードの後に追加します。ここでは、Set Payload カードを使用して、Choice router ブロックでこのデフォルトオプションへのルートが選択された場合に、フローが必要な SKU と関連情報を単純に追加するようにします。 2. 開いている Set Payload カードで ​**\[f(x)\]**​ ボタンをクリックして、​**\[Value (値)\]**​ 項目でスクリプトモードに入ります。 3. 項目に次の JSON データを貼り付けます。 ```none [ { "productID": "CK111274", "category": "Retail", "SKU": "CKS0", "productName": "Old School Classic Kicks", "inventory": 9999 } ] ``` フローが次のようになっていることを確認してください。 ![flow with complete choice](/mulesoft/current/ja-jp/design-center/_images/flow-with-complete-choice.png) ## [](#情報を-nto-orders-api-に渡す前の形式の変更)情報を NTO Orders API に渡す前の形式の変更 この時点で、フローは Salesforce から商談の情報を、製品データベースから製品の情報を取得しています。この情報を利用して NTO Orders API で発注をかける前に、API が期待する形式にデータを書式設定する必要があります。 1. Choice router ブロックの右側にあるプラス記号をクリックして Transform カードを追加します。 2. **\[Input (入力)\]**​ ペインで入力データ型を指定します。 1. `payload`​ の隣にある 3 つのドットをクリックします。 2. **\[Set (設定)\]**​ を選択します。 3. 以前に作成してある ​`Product Information`​ データ型を選択します。 4. `vars`​ の下にある ​`OppDetails`​ の隣の 3 つのドットをクリックして、データ型を ​`Salesforce Opportunity`​ に設定します。 3. **\[出力 (入力)\]**​ ペインで ​`payload`​ のデータ型を ​`Order Information`​ に設定します。 **結果:**​ Transform カードは次のようになっています。 ![transform first after input output](/mulesoft/current/ja-jp/design-center/_images/transform-first-after-input-output.png) 4. 下表を参考にして、左側の要素を右側にドラッグアンドドロップします。
左側の要素 右側の次の要素にマッピング

productID

productID​

category

category​

SKU

SKU​

productName

productName​

inventory

inventory​

Amount

OrderAmount​

Id

OppId​

CloseDate

orderDate​

`Output media type differs from expected one`​ (出力メディア型が予想と異なります) というメッセージが表示された場合は ​`Fix it`​ リンクをクリックして問題を解決してください。 形式の変更が終わると、Transform カードは次のようになります。 ![transform first final](/mulesoft/current/ja-jp/design-center/_images/transform-first-final.png) カードが ​**\[Preview (プレビュー)\]**​ ペインに表示する JSON は、フローが発注時に NTO Orders API に送信する JSON の例です。 ## [](#nto-orders-api-を使用した発注)NTO Orders API を使用した発注 フローで発注をかける準備ができました。フローは、REST API である NTO Orders API を使用して POST 要求を送信することで発注をかけます。API は、要求に対して注文 ID、注文の追跡番号、そして ETA (顧客への到着予定日) の情報を返します。 1. 今設定したばかりの Transform カードの右側に HTTP Request カードを追加します。 2. カードで次の情報を設定します。 - Method (メソッド): POST - URL (NTO Orders API の URL): [https://anypoint.mulesoft.com/mocking/api/v1/sources/exchange/assets/org.mule.examples/quick-start-nto-orders-api/1.0.0/m/orders](https://anypoint.mulesoft.com/mocking/api/v1/sources/exchange/assets/org.mule.examples/quick-start-nto-orders-api/1.0.0/m/orders) ## [](#twilio-api-用のデータの送信)Twilio API 用のデータの送信 この時点で、NTO Orders API は、注文 ID、注文の追跡番号、および ETA の情報を返しています。最後のステップは、この情報を Twilio API に送信して、SMS 経由で顧客に伝達することです。Twilio がこの情報を受け取るためには、Twilio が必要とする形式にメッセージを書式設定する必要があります。 1. Transform カードを Twilio カードの左側に追加します。 2. **\[Input (入力)\]**​ セクションで 2 つのデータ型を設定します。 1. `payload`​ のデータ型を ​`Order Tracking`​ に設定します。 2. `OppDetails`​ のデータ型を ​`Salesforce Opportunity`​ に設定します。 3. **\[出力 (入力)\]**​ セクションで次のステップを実行します。 1. `To`​ 項目をダブルクリックして、先頭に国番号を付けた電話番号を入力します。(例: 米国の国番号は 1 ですので「12223334444」のように入力します。) 2. `From`​ 項目をダブルクリックして、Twilio 開発者アカウントを開いたときに取得した無料電話番号を入力します。 4. Transform カードの一番下にある ​**\[Script (スクリプト)\]**​ タブをクリックします。 5. 項目をマップするのではなく、別の方法で変換を作成します。次の DataWeave スクリプトを、スクリーンショットに示されている ​**\[Transformation script (変換スクリプト)\]**​ パネル内の位置に貼り付けます。 ```none Body: "Order for " ++ vars.OppDetails.Name ++ " has been placed. Details: " ++ "OrderID: " ++ payload.OrderID as String ++ ", Tracking: " ++ payload.TrackingNo ++ ", ETA:" ++ payload.ETA as Date ``` ![transform second script panel](/mulesoft/current/ja-jp/design-center/_images/transform-second-script-panel.png) DataWeave スクリプトは、入力項目を出力項目にマップするための代替手段です。​**\[Mappings (マッピング)\]**​ タブをクリックして、スクリプトの指定によって項目がどのようにマップされているかを確認します。 ![transform second mappings panel](/mulesoft/current/ja-jp/design-center/_images/transform-second-mappings-panel.png) **結果:**​ ​**\[Preview (プレビュー)\]**​ ペインは、Transform カードが Twilio カードに送信する JSON メッセージの例を表示します。 ## [](#アプリケーションのテスト)アプリケーションのテスト いよいよ Mule アプリケーションをテストする準備ができました。その前に、フローにエラーがないことを確認しましょう。エラーが見つかった場合は、キャンバスの一番下にある ​**\[Problems (問題)\]**​ ペインを開いて説明を読みます。エラーをクリックすると、プロジェクト内の該当箇所に移動します。 エラーがなく、Flow Designer の右上隅にある ​**\[Run (実行)\]**​ ボタンが有効になっていたら、​**\[Run (実行)\]**​ ボタンをクリックしてアプリケーションを実行します。その後、次のステップを実行します。 1. Salesforce カードで使用したログイン情報で Salesforce インスタンスにログインします。 2. ブラウザーウィンドウの左上隅にあるアプリケーションスイッチャー (下図) から Sales アプリケーションを開きます。 ![salesforce app switcher](/mulesoft/current/ja-jp/design-center/_images/salesforce-app-switcher.png) 3. **\[商談\]**​ に移動し、ビューを ​**\[すべての商談\]**​ に変更します。 4. `Closed Won`​ フェーズではない商談を探します。 5. その商談を開いて編集し、​`Stage`​ の値を ​`Closed Won`​ に変更します。 6. 金額を $100,000 より大きな値に変更して ​**\[保存\]**​ をクリックします。 7. Flow Designer で Mule アプリケーションに戻ります。各カードに緑の線が表示されていれば、フローがトリガーされ、注文の詳細を示すテキストメッセージが携帯電話に送信されたことを意味します。 ## [](#お疲れ様)お疲れ様! テキストメッセージを受信したら、オフィスの同僚の前でアプリケーションを何度も実行して見せて称賛の嵐を巻き起こしましょう。同僚からの称賛には謙虚に明るく応じて、Flow Designer の仕組みを説明してください。アプリケーションで使用するカードとは何か、コネクタとは、そしてコンポーネントとは何かを、指でフローを追いながらデータの流れと共に説明するのです。アプリケーションがデザイン環境の外でも利用できるようになったことを示せば、同僚はさらに褒めてくれるでしょう。 さて、いよいよ最後のステップに移ります。​[Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/design-center/promote-app-prod-env-design-center)​です。このチュートリアルでは説明しませんが、リンクをクリックすれば必要なステップが表示されますので、Mule アプリケーションのデプロイが必要であれば行ってください。 このチュートリアルが非常に簡単で分かりやすい一方で、Flow Designer を現実のシナリオで役立てるのに十分な情報を提供できたことを祈るばかりです。では、フローデザインをお楽しみください! # Flow Designer のエラーメッセージ:page-support-status: eolScheduled エラーメッセージは Flow Designer の 2 箇所に表示されます。 - 画面の右下隅の赤いボックスにエラーメッセージが表示されます。 この場所にエラーメッセージが表示され、エラーを解決できない場合は、Flow Designer のサポートケースを開いて、サポートケースにメッセージのコンテンツを貼り付けてください。 - 画面の右上隅の ​**\[Run (実行)\]**​ ボタンと ​**\[Deploy (デプロイ)\]**​ ボタンの間にもエラーメッセージが表示されます。 この場所に表示されるすべてのエラーメッセージと、それぞれのエラーを解決するために実行するアクションを下表に示します。
メッセージ 説明 実行するアクション

Can’t Connect to Mule (Mule に接続できません)

Flow Designer が Runtime Manager エージェントに接続できません。

画面の左下隅にある ​[Log (ログ)]​ をクリックして、プロジェクトのログを確認してください。エラーの原因を示すエラーメッセージが記録されています。Runtime Manager のサポートケースを開いて、サポートケースにエラーメッセージのコンテンツを貼り付けてください。

Can’t Retrieve App (アプリケーションを取得できません) (CloudHub)

現在の組織でアプリケーションを取得する権限がないか、またはアプリケーションが削除されています。

Runtime Manager でアプリケーションが動作しているかどうかを確認してください。動作していない場合は、Flow Designer のサポートケースを開いてください。

Can’t Retrieve App (アプリケーションを取得できません) (Project Manager)

Flow Designer がプロジェクトの情報を取得できませんでした。

Flow Designer のサポートケースを開いてください。サポートケースでプロジェクトの名前を指定します。

Cloudhub Internal Error (CloudHub の内部エラー)

CloudHub が要求を処理できませんでした。

CloudHub のサポートケースを開いてください。

Deployment Failed (デプロイに失敗しました)

プロジェクトを CloudHub ワーカーにデプロイできませんでした。

画面の左下隅にある ​[Log (ログ)]​ をクリックして、プロジェクトのログを確認してください。エラーの原因を示すエラーメッセージまたは問題の解決方法 (あるいはその両方) が記録されています。

Flow Can’t Be Empty (フローは空にはできません)

Mule アプリケーションのフローのうち、少なくとも 1 つにトリガーがありません。

トリガーがないフロー (1 つまたは複数) を見つけて、それぞれにトリガーを追加してください。

Mule Agent Internal Error (Mule エージェントの内部エラー)

Flow Designer が Mule Runtime で Mule アプリケーションのデプロイまたは停止に失敗しました。

画面の左下隅にある ​[Log (ログ)]​ をクリックして、プロジェクトのログを確認してください。エラーの原因を示すエラーメッセージまたは問題の解決方法 (あるいはその両方) が記録されています。

Not Enough Permissions (十分な権限がありません)。

対象環境の CloudHub でアプリケーションを作成するのに必要な権限がありません。

ユーザー ID に ​Design Center 開発者​と ​CloudHub 管理者​のロールが割り当てられている必要があります。

Not Enough Workers (ワーカーが不足しています)

対象環境のワーカーが不足しています。

Anypoint Platform 組織の管理者に連絡して、Mule アプリケーションのデザインに必要なリソースの再割り当てや追加を依頼してください。

Not Ready to Run (実行準備ができていません)

フローが実行可能な状態まで完成していないか、またはフローにエラーがあります。

すべてのフローにトリガーがあり、各トリガーの後に最低 1 つのカードがあることを確認してください。また、カードにエラーインジケーターが表示されていないことを確認してください。

Operation Failed (操作が失敗しました)

Mule Runtime が (起動または停止中に) 要求の処理に失敗しました。

画面の左下隅にある ​[Log (ログ)]​ をクリックして、プロジェクトのログを確認してください。エラーの原因を示すエラーメッセージまたは問題の解決方法 (あるいはその両方) が記録されています。

Packaging Failed (パッケージ処理に失敗しました)

Flow Designer が Mule アプリケーションパッケージの構築に失敗しました。Flow Designer は、アプリケーションの実行プロセスの一環としてパッケージを構築します。

画面の左下隅にある ​[Log (ログ)]​ をクリックして、プロジェクトのログを確認してください。エラーの原因を示すエラーメッセージまたは問題の解決方法 (あるいはその両方) が記録されています。

Service unavailable (サービスを利用できません)

Flow Designer が状況を取得したときに​「503 Service Unavailable」 (503 サービスを利用できません)​ が返されました。計画的なメンテナンスであれば、503 エラーは短時間で解消します。

status.mulesoft.com​ で計画的なメンテナンスが実施中であるかどうかを確認してください。

Undeployed (デプロイされていません)

アプリケーションが CloudHub で動作していません。アプリケーションが CloudHub にワークスペースを持っていない、CloudHub ワーカーがクラッシュした、誰かが Runtime Manager でアプリケーションを停止した、などの理由が考えられます。

アプリケーションを再デプロイするには ​[Run (実行)]​ をクリックします。(注意: [Deploy (デプロイ)]​ ボタンをクリックすると、アプリケーションが別の環境で実行されます。​[Run (実行)]​ ボタンにより、アプリケーションがデザイン環境にデプロイされ、そこで実行します。)

Unknown (不明)

Flow Designer が状況を取得したときに不明なワーカー状態が返されました。

Flow Designer のサポートケースを開いてください。サポートケースには、プロジェクト名と CloudHub でのアプリケーション名の両方を記入してください。

Workspace Creation Failed (ワークスペースの作成に失敗しました)

ワーカーの作成中に不明なエラーが発生しました。

画面の左下隅にある ​[Log (ログ)]​ をクリックして、プロジェクトのログを確認してください。エラーの原因を示すエラーメッセージまたは問題の解決方法 (あるいはその両方) が記録されています。Runtime Manager でもログを確認できます。

いずれの場合でも、エラーを解決できないときは Flow Designer のサポートケースを開いてください。サポートケースには、画面に表示されたメッセージのテキストと、プロジェクトのログに記録されているエラーメッセージのテキストを含めてください。 ## [](#関連情報)関連情報 - [Mule アプリケーションのデプロイ (Flow Designer)](https://docs.mulesoft.com/jp/design-center/promote-app-prod-env-design-center) # Flow Designer:page-support-status: eolScheduled

Flow Designer はサービス終了になる予定です。

引き続きインテグレーションの構築、テスト、デプロイを行うには、​プロジェクトを Studio 7 に移行​することができます。

Flow Designer で、システムをワークフローに統合するための Mule アプリケーションを作成します。これを、1 つ以上のフローを含むプロジェクトとして作成します。1 つのプロジェクトには、1 つの Mule アプリケーション用のフローが含まれます。​_フロー_​は一連の​_カード_​で構成され、各カードは 1 つのコアコンポーネント、コネクタ、モジュール、または API を表します。各カードは入力データを受け取り、入力データを使用する特定のタスクを実行して、そのタスクからの出力データをフローの次のカードに送ります。フローの最後のカードは、通常は Mule アプリケーションがタスクを完了したことを通知するか、またはデータを送信します。 ## [](#はじめに)はじめに チュートリアル​[「Flow Designer での最初の Mule アプリケーションの作成」](https://docs.mulesoft.com/jp/design-center/salesforce-to-twilio)​で、サンプル Mule アプリケーションを作成して Flow Designer について学ぶことができます。このチュートリアルでは、商談成立時点で会社の販促品を自動的に一括で発注し、注文の状況や ETA (到着予定) を SMS で顧客に知らせる Mule アプリケーションを作成できます。 Mule アプリケーションの作成を開始する方法 - 最も簡単なオプションを試します。つまり、Anypoint Exchange から Flow Designer にテンプレートをインポートします。​[「テンプレートからの Mule アプリケーションの迅速な作成」](https://docs.mulesoft.com/jp/design-center/import-template)​を参照してください。 - Design Center で新しい Mule アプリケーションプロジェクトを作成し、自動的に開いたウィザードに従って、トリガーカードと対象カードでフローのスキャフォールディングを作成します。 - 新しい Mule アプリケーションプロジェクトを作成し、ウィザードで ​**\[Go straight to the canvas (キャンバスに直接移動)\]**​ をクリックして、空白のキャンバスからフローの構築を開始します。 ## [](#関連情報)関連情報 - [Mule アプリケーションのフローの要素](https://docs.mulesoft.com/jp/design-center/fd-elements-of-flows) - [Flow Designer ツアー](https://docs.mulesoft.com/jp/design-center/fd-tour) - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # Flow Ref によるフローから別のフローの参照 (Flow Designer):page-support-status: eolScheduled フローに Flow Ref コアコンポーネントを配置することで、同じアプリケーション内の 1 つのフローから別のフローを実行することができます。フローで Flow Ref に達すると、参照先のフローがトリガーされます。参照先のフローが実行されると、Mule イベントオブジェクトを元のフローに返し、Flow Ref コンポーネントの後から元のフローの実行が再開されます。Flow Ref は、同じ Mule アプリケーション内でコンポーネントのグループを再利用するのに便利です。 ![fd flow ref](/mulesoft/current/ja-jp/design-center/_images/fd-flow-ref.png) Figure 1. メインフローから 1 つのフローを参照する Flow Ref カード 1. トリガーカードによりメインフローが開始されます。 2. Flow Ref カードは、2 番目のカードからの出力を、参照先のフローの 1 番目のカードに渡して、そのフローをトリガーします。 3. 参照先のフローの最後のカードは、その出力を、メインフローの Flow Ref カードの次のカードに渡します。 4. このカードは入力を処理し、独自の出力を作成して、メインフローを続行します。 ## [](#2-番目のフローの作成および参照手順)2 番目のフローの作成および参照手順 1. 2 番目のフローを作成するには、次の手順を実行します。 1. **\[Project (プロジェクト)\]**​ ペインの ​**\[Flows (フロー)\]**​ の右にあるプラス記号をクリックします。 ![add flow](/mulesoft/current/ja-jp/design-center/_images/flows-plus.png) 2. **\[Let’s get started (はじめよう)\]**​ ウィザードの左下隅にある ​**\[Go straight to the canvas (キャンバスに直接移動)\]**​ をクリックします。ウィザードは、トリガーから始まるフローを作成します。ただし、Flow Ref カードを使用して参照するフローをトリガーで始めることはできません。Flow Ref カードがそのトリガーになります。 3. フロー名を変更します。 ![rename flow](/mulesoft/current/ja-jp/design-center/_images/rename-flow.png) 2. **\[Project (プロジェクト)\]**​ ペインの ​**\[Flows (フロー)\]**​ で、最初のフローの名前をクリックして最初のフローに戻ります。 3. フロー内の他のフローを実行する位置に Flow Ref カードを追加します。カードの ​**\[Flow (フロー)\]**​ 項目で 2 番目のフローを選択します。次に ​**\[Go (実行)\]**​ をクリックします。 4. 2 番目のフローにカードを追加します。ただし、トリガーカードを追加しないでください。このフローの最後のカードが、メインフローの Flow Ref カードの次のカードの入力として使用される出力を生成することを確認します。メインフローの次のカードで使用できるように出力を変換する必要がある場合、Flow Ref カードの後で Transform カードを使用します。 # GitHub Synchronization API 仕様設計者の多くは、複数のオーサリングツールやバージョン管理ツールを使用しています。この結果、複数の異なる仕様バージョンの管理が必要になることがあります。 GitHub Synchronization は、複数の場所に存在する API 仕様を管理するためのバージョン管理ツールです。GitHub Synchronization を使用すると、API Designer と自分の GitHub リポジトリの間での双方向同期を実現し、API プロジェクトへの変更を自動的に捕捉して、同期対象として選択してある GitHub リポジトリに変更を送信することができます。また、同期対象の GitHub リポジトリでの変更を自動的に API プロジェクトに伝播します。 この双方向フローにより、信頼できる唯一の情報源が常に GitHub であるコラボレーション環境で API Designer を活用できます。制限から解放された設計者は、同じコンテンツを共有して、同じコンテンツに貢献できます。 GitHub Synchronization と API Designer を併用することで、以下の作業が可能になります。 - 既存の API プロジェクトと同期した GitHub リポジトリを作成する。 - 新規 GitHub リポジトリと同期した新規 API プロジェクトを作成する。 - 既存のリモート新規 GitHub リポジトリと同期した新規 API プロジェクトを作成する。 プル要求のオープン、分岐の差分の表示、同期状況の表示など、GitHub 特有のアクションを実行するには、GitHub UI を使用します。 ## [](#関連情報)関連情報 - [GitHub Synchronization のインストールと認証](https://docs.mulesoft.com/jp/design-center/design-ghs-install-authorize) - [新規 GitHub リポジトリと同期した新規プロジェクトの作成](https://docs.mulesoft.com/jp/design-center/design-ghs-new-project-new-repo) - [既存の GitHub リポジトリと同期した新規プロジェクトの作成](https://docs.mulesoft.com/jp/design-center/design-ghs-new-project-existing-repo) - [既存のプロジェクトと同期した新規 GitHub リポジトリの作成](https://docs.mulesoft.com/jp/design-center/design-ghs-new-repo-existing-project) # GitHub Synchronization のインストールと認証 API Designer から組織のリポジトリにアクセスできるようにするための第一歩は、GitHub Synchronization アプリケーションをインストールすることです。 GitHub Synchronization アプリケーションは、GitHub ユーザーインターフェースでインストールします。このアクションは、GitHub 組織のシステム管理者または GitHub ユーザーとして実行します。その後、API Designer 内で最初に GitHub Synchronization アクションを実行するときに、アプリケーションを認証します。同期アクションとしては、既存 API 仕様にと同期させる新規 GitHub リポジトリの作成や、既存の GitHub リポジトリと同期させる新規 API 仕様の作成などがあります。 ## [](#github-組織のシステム管理者としての-github-synchronization-アプリケーションのインストール)GitHub 組織のシステム管理者としての GitHub Synchronization アプリケーションのインストール まず、GitHub Synchronization アプリケーションは、GitHub ユーザーインターフェースでインストールします。 ### [](#始める前に)始める前に GitHub 組織のシステム管理者として GitHub Synchronization アプリケーションをインストールするには、次の要件を満たす必要があります。 - GitHub アカウント - アプリケーションをインストールする GitHub 組織のメンバーシップ - GitHub 組織にアクセスするための (GitHub アカウント設定で付与された) 管理者権限
  • GitHub アカウントで IP 許可リストを使用している場合は、GitHub Synchronization をインストールして使用することはできません。

  • GitHub Synchronization で使用する GitHub アカウントのメール設定で ​[Keep my email addresses private (メールアドレスを非公開にする)]​ を選択した場合は、​[Block command line pushes that expose my email (メールを公開するコマンドラインプッシュをブロック)]​ を選択しないでください。ブロック設定により、同期プロジェクトでのコミットがプッシュされなくなります。

### [](#github-synchronization-アプリケーションをインストールする)GitHub Synchronization アプリケーションをインストールする 1. [GitHub Synchronization アプリケーションページ](https://github.com/apps/mulesoft-github-integration)​に移動します。 2. **\[Install (インストール)\]**​ をクリックします。 3. **\[Install MuleSoft GitHub Integration (MuleSoft GitHub インテグレーションをインストール)\]**​ ダイアログで、アプリケーションをインストールする組織を選択します。 4. **\[All repositories (すべてのリポジトリ)\]**​ をクリックして、すべてのリポジトリを使用できるようにするか、または ​**\[Only select repositories (選択したリポジトリのみ)\]**​ をクリックして個別のリポジトリを指定します。 5. **\[Install (インストール)\]**​ をクリックします。 GitHub とのインテグレーションを完了するには、アプリケーションを API Designer で認証する必要があります。​[「API Designer で GitHub Synchronization アプリケーションを認証する」](#authorize-the-github-synchronization-application-in-api-designer)​を参照してください。 ## [](#github-ユーザーとしての-github-synchronization-アプリケーションのインストール)GitHub ユーザーとしての GitHub Synchronization アプリケーションのインストール GitHub ユーザーアカウントで GitHub Synchronization アプリケーションをインストールすることで、自分の GitHub ユーザーリポジトリとの同期が可能になります。 ### [](#始める前に-2)始める前に GitHub ユーザーとして GitHub Synchronization アプリケーションをインストールするには、次の要件を満たす必要があります。 - GitHub アカウント - アプリケーションをインストールする GitHub 組織のメンバーシップ
GitHub Synchronization で使用する GitHub アカウントのメール設定で ​[Keep my email addresses private (メールアドレスを非公開にする)]​ を選択した場合は、​[Block command line pushes that expose my email (メールを公開するコマンドラインプッシュをブロック)]​ を選択しないでください。ブロック設定により、同期プロジェクトでのコミットがプッシュされなくなります。
### [](#github-synchronization-アプリケーションをインストールする-2)GitHub Synchronization アプリケーションをインストールする 1. [GitHub Synchronization アプリケーションページ](https://github.com/apps/mulesoft-github-integration)​に移動します。 2. **\[Install (インストール)\]**​ をクリックします。 3. **\[Install MuleSoft GitHub Integration (MuleSoft GitHub インテグレーションをインストール)\]**​ ダイアログで、GitHub ユーザーアカウント (通常は表示されたリストの上の方に表示されます) を選択します。 4. **\[All repositories (すべてのリポジトリ)\]**​ をクリックして、すべてのリポジトリを使用できるようにするか、または ​**\[Only select repositories (選択したリポジトリのみ)\]**​ をクリックして個別のリポジトリを指定します。 5. **\[Install (インストール)\]**​ をクリックします。 GitHub とのインテグレーションを完了するには、アプリケーションを API Designer で認証する必要があります。​[「API Designer で GitHub Synchronization アプリケーションを認証する」](#authorize-the-github-synchronization-application-in-api-designer)​を参照してください。 ## [](#api-designer-で-github-synchronization-アプリケーションを認証する)API Designer で GitHub Synchronization アプリケーションを認証する GitHub Synchronization アプリケーションを認証するには、自分のユーザー ID に「Design Center Developer (Design Center 開発者)」権限が付与されている必要があります。 1. Anypoint Platform にサインインします。 2. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで、​**\[Create + (作成 +)\]**​ をクリックします。 3. **\[New API Specification (新しい API 仕様)\]**​ を選択します。 4. **\[New API Specification (新規 API 仕様)\]**​ パネルで、​**\[Authorize the MuleSoft app now to get started (これから開始する MuleSoft アプリケーションを認証する)\]**​ をクリックします。 5. **\[Authorize (認証)\]**​ をクリックします。 6. 次に表示されるダイアログで、​**\[Authorize MuleSoft GitHub Integration (MuleSoft GitHub インテグレーションを認証)\]**​ をクリックします。 API Designer にリダイレクトされ、​**「Authorized Successfully (正常に認証されました)」**​のメッセージが表示されます。これで、このアプリケーションの認証をトリガーしたプロセスを完了できるようになります。 ## [](#github-synchronization-アプリケーションのインストールのトラブルシューティング)GitHub Synchronization アプリケーションのインストールのトラブルシューティング GitHub Synchronization アプリケーションの認証中にエラーが発生した場合は、認証を取り消してから、認証を再び試みてください。 1. GitHub ユーザーインターフェースで (​**\[Settings (設定)\]**​ > ​**\[Applications (アプリケーション)\]**​ > ​**\[Authorized GitHub Apps (認証済み GitHub アプリケーション)\]**​ に移動して) ​**\[Revoke (取り消し)\]**​ をクリックします。 2. [GitHub Synchronization アプリケーションを認証します](#authorize-the-github-synchronization-application-in-api-designer)​。 空のリストが表示された場合は、同期アクションを実行する前に、アプリケーションを GitHub 組織または GitHub ユーザーアカウントにインストールしてあることを確認してください。 ## [](#github-インテグレーションの無効化)GitHub インテグレーションの無効化 組織のシステム管理者は、Github インテグレーションを無効化できます。 1. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで、​**\[Settings (設定)\]**​ をクリックします。 2. **\[Integrations (インテグレーション)\]**​ で、​**\[Enable Github Integration (GitHub インテグレーションを有効化)\]**​ をオフにします。 3. 確認ダイアログボックスが表示されます。 4. **\[Disable GitHub (GitHub を無効化)\]**​ をクリックします。 これで、インテグレーションが無効になります。 組織にサブ組織がある場合、組織のシステム管理者は必要に応じてサブ組織ごとにインテグレーションを有効または無効にできます。
このアクションにより、組織のすべてのユーザーとプロジェクトのソースの同期が無効になります。インテグレーションが有効になると、GitHub にまだリポジトリが存在していても、過去のすべての同期が失われます。
# GitHub と同期したプロジェクトの管理 API Designer and Design Center で、GitHub と同期したプロジェクトを管理して操作できます。 Design Center の ​**\[Projects (プロジェクト)\]**​ リストにある ​**\[Details (詳細)\]**​ ペインには、GitHub との同期状況とリポジトリの URL の両方が表示されているため、接続の問題をトラブルシューティングするのに便利です。​**\[Details (詳細)\]**​ ペインでは、GitHub との同期を無効化することもできます (GitHub との同期は ​**\[Publish (パブリッシュ)\]**​ オプションメニューからも無効化できます)。 ## [](#api-designer-での-branch-selector-コンポーネントの使用)API Designer での \[Branch Selector\] コンポーネントの使用 \[Branch Selector\] コンポーネントにアクセスするには、コードパネルの一番上にある (現在の GitHub 分岐名が含まれる) プロジェクトのタイトルをクリックします。 \[Branch Selector\] コンポーネントを使用すると、自分の GitHub リポジトリページにアクセスして次の操作を行うことができます。 - 分岐の選択 最初に現在の GitHub 分岐が (コミットハッシュと共に) 表示され、その後に、以前に作成された機能分岐のリストが続きます。分岐名をクリックすると、その分岐に切り替わります。 - 分岐の差分の表示 他の分岐と現在の分岐との差分を表示するには、​**\[View Diff (差分を表示)\]**​ をクリックします。
GitHub と同期されていないプロジェクトでは、​[View in GitHub (GitHub で表示)]​ ボタン、​[View Diff (差分を表示)]​ ボタン、コミットハッシュは表示されません。
- デフォルトの分岐の表示 デフォルトの分岐はデフォルトアイコンで示されます。 - 分岐の削除 分岐を削除するには、​**\[Delete branch (分岐を削除)\]**​ ボタン (​**\[X\]**​) をクリックします。 - プル要求のオープン プル要求を開くには、分岐 (メイン分岐以外) に切り替えて、分岐コンポーネントセレクターを開いてから、​**\[Open Pull Request (プル要求を開く)\]**​ をクリックします。 - 分岐名の変更 分岐名を変更するには、鉛筆アイコンをクリックし、新しい名前を入力してから、​**\[Rename (名前の変更)\]**​ をクリックします。 - 新しい分岐の作成 現在の分岐から新しい機能分岐を作成します。​**\[Create Branch (分岐を作成)\]**​ テキスト項目に新しい分岐名を入力して、分岐作成ボタン (​**\[+\]**​) をクリックします。API Designer が新しい分岐に切り替わり、テキストエディターが開きます。コードパネルの上には新しい分岐名が表示されます。 ## [](#design-center-の-projects-プロジェクト-ページと-details-詳細-ペインの使用)Design Center の \[Projects (プロジェクト)\] ページと \[Details (詳細)\] ペインの使用 Design Center の ​**\[Projects (プロジェクト)\]**​ リストにあるプロジェクトの ​**\[Details (詳細)\]**​ ペインでは、次の作業を行うことができます。 - プロジェクトが GitHub と同期しているかどうかの判断 Design Center の ​**\[Projects (プロジェクト)\]**​ ページには、仕様、フラグメント、アプリケーションのリストが表示されます。GitHub と同期しているプロジェクトでは、​**\[Name (名前)\]**​ 列に GitHub アイコンが表示されます。 - GitHub リポジトリ URL の表示 選択したプロジェクトの ​**\[Details (詳細)\]**​ ペインには GitHub リポジトリ URL が表示されます。​**\[Copy (コピー)\]**​ ボタンをクリックすると、URL がクリップボードにコピーされます。 - GitHub 同期状況の表示 選択したプロジェクトの ​**\[Details (詳細)\]**​ ペインには GitHub との同期状況が表示されます。自分の GitHub アカウントでまだ GitHub Synchronization アプリケーションが認証されていないか、または GitHub と同期された認証済みの GitHub 組織のメンバーではない場合は、​**\[Not Available (利用不可)\]**​ と表示されます。どちらの場合も、API Designer では参照のみとしてプロジェクトが表示されます。 [「GitHub Synchronization のインストールと認証」](https://docs.mulesoft.com/jp/design-center/design-ghs-install-authorize)​を参照してください。 - 新規プロジェクトのデフォルト分岐名の変更 新規プロジェクトのデフォルト分岐を変更するには、管理者権限が必要です。\[Projects (プロジェクト)\] ページでプロジェクトを開き、​**\[Settings (設定)\]**​ をクリックして分岐名を変更します。この変更は、新規プロジェクトにのみ適用され、既存のプロジェクトには影響しません。GitHub Synchronization を使用している場合は、デフォルトの分岐名は GitHub によって指定されます。 - 既存プロジェクトのデフォルト分岐の変更 既存プロジェクトのデフォルト分岐を変更するには、\[Projects (プロジェクト)\] ページでプロジェクトを開き、​**\[Settings (設定)\]**​ > ​**\[Branch Settings (分岐設定)\]**​ をクリックして、新しい分岐を選択します。GitHub Synchronization を使用している場合は、デフォルトの分岐名は GitHub によって指定されます。 - GitHub Synchronization の無効化 GitHub Synchronization を無効化するには、選択したプロジェクトの ​**\[Details (詳細)\]**​ ペインで ​**\[Disable Sync (同期を無効化)\]**​ ボタンをクリックします。 **\[Disable GitHub Sync (GitHub Sync を無効化)\]**​ ダイアログで、プロジェクトと GitHub との同期を無効化することを確認します。確認用のテキスト項目にプロジェクト名を入力して、​**\[Disable Sync (同期を無効化)\]**​ をクリックします。このアクションは元に戻せません。 ## [](#関連情報)関連情報 - [分岐のマージ](https://docs.mulesoft.com/jp/design-center/design-ghs-merge-branches) # JAR ファイルを使用した Runtime Manager から CloudHub への Mule アプリケーションのデプロイ:page-support-status: eolScheduled 組織で適切な権限を持つ人でなければ Runtime Manager から Mule アプリケーションをデプロイできない場合は、自分のプロジェクトのコピーを JAR ファイルとしてその人物と共有できます。 エクスポートされる JAR ファイルには、ユーザー名、パスワード、セキュリティトークンなどの重要な接続情報は含まれません。したがって、アプリケーションのコネクタで使用されているすべての設定にその情報を追加するために、JAR ファイルを編集して再パッケージする必要があります。 ## [](#flow-designer-での手順)Flow Designer での手順 1. プロジェクトにエラーがないことを確認します。 2. キャンバスの右上隅にある 3 つのドットをクリックし、​**\[Export (エクスポート)\]**​ を選択してプロジェクトをエクスポートします。 **\[Export (エクスポート)\]**​ オプションは、キャンバスの右上隅にあります。 ![「Exported (エクスポート)」 オプションの場所](/mulesoft/current/ja-jp/design-center/_images/fd-location-of-export-option.png)
13 つのドットは、下矢印の表示ラベルが付いたボタンの右側にあります。
2[Export (エクスポート)]​ オプションはメニューの一番下にあります。
1. **\[Export mule application (Mule アプリケーションをエクスポート)\]**​ を選択して ​**\[Export (エクスポート)\]**​ をクリックします。 Mule アプリケーションのコピーが含まれる JAR ファイルがコンピューターのデフォルトの場所にダウンロードされます。 ## [](#jar-ファイルを-runtime-manager-にインポートする前に実行する手順)JAR ファイルを Runtime Manager にインポートする前に実行する手順 1. JAR ファイルのコンテンツを抽出します。 2. JAR ファイルから抽出したフォルダーでファイル ​`mule-artifact.properties`​ を開き、接続情報に関連するキーの値を入力します。 3. `mule-artifact.properties`​ を保存します。 ## [](#runtime-manager-での手順)Runtime Manager での手順 1. アプリケーションのデプロイ先となる CloudHub 環境に切り替えます。 2. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ ページで ​**\[Choose File (ファイルを選択)\]**​ > ​**\[Upload File (ファイルをアップロード)\]**​ を選択して JAR ファイルをアップロードします。 4. [「CloudHub へのデプロイ」](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)​の手順に従います。 ## [](#関連情報)関連情報 - [環境](https://docs.mulesoft.com/jp/access-management/environments) - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [MuleSoft ヘルプセンター](https://help.mulesoft.com) # JSON スキーマで必須項目を指定する場合のよくある間違い Design Center は、JSON スキーマの Draft 3 と Draft 4 をサポートします。項目を ​`required`​ (必須) として指定する方法は、Draft 3 と Draft 4 では異なります。API 仕様で間違ったドラフトの宣言を混同して使用するとエラーとなります。 Draft 3 では、次のように各項目の定義中で ​`required`​ と指定します。 { "$schema": "http://json-schema.org/draft-03/schema#", "type": "object", "properties": { "pageNum": { "type": "integer", "title": "Page number", "description": "...", "default": 1, "required": true }, "pageSize": { "type": "integer", "title": "Page size", "description": "...", "required": true, "default": 50, "enum": \[ 10, 20, 30, 40, 50 \] } ... Draft 4 では、次のように項目の定義と同じレベルで配列を作成することによって ​`required`​ と指定します。 { "$schema": "http://json-schema.org/draft-4/schema#", "type": "object", "properties": { "pageNum": { "type": "integer", "title": "Page number", "description": "...", "default": 1 }, "pageSize": { "type": "integer", "title": "Page size", "description": "...", "default": 50, "enum": \[ 10, 20, 30, 40, 50 \] }, "required": \[ "pageNum", "pageSize" \] }, ... Draft 4 の方法の別の例です。 { "$schema": "http://json-schema.org/draft-4/schema#", "type": "object", "properties": { "address": { "type": "object", "properties": { "streetAddress": { "type": "string" }, "city": { "type": "string" }, "required": \[ "streetAddress", "city" \] }, "phoneNumber": { ... スキーマで Draft 4 を使用すると宣言した後で Draft 3 の方法を使用した場合 (またはその逆の場合) には、単純にスキーマの宣言を変更するだけで通常は問題が解決します。たとえば、スキーマで Draft 3 を使用すると宣言してから Draft 4 の方法を使用してしまった場合は、スキーマの宣言を Draft 4 を参照するように変更します。 # Logger を使用した実行時のフロー情報のログ記録 (Flow Designer):page-support-status: eolScheduled 1 つ以上の Logger コアコンポーネントをフローに追加して、実行時のフローからの情報をログに記録します。情報のログは、トラブルシューティングや、フローの特定ポイントでの出力の確認に役立ちます。式を使用してログメッセージを作成することもできます。次の表にいくつかの例を示します。
式 説明

payload

ペイロードのコンテンツ全体。

payload.user.id

ペイロードの「user」の子要素である「id」の値

attributes.myAttribute

「myAttribute」という名前の属性の値

myVariable

「myVariable」という名前の変数の値

"要求を送信するユーザーの ID" ++ payload.user.id

固定テキストに「id」の値を連結。

upper(payload.user.name)

ペイロードの「user」の子要素である「name」の値を大文字に変換した文字列。

ログを表示するには、Flow Designer の一番下にある領域を展開します。 ![log view](/mulesoft/current/ja-jp/design-center/_images/log-view.png) 1. Logger コアコンポーネントをフローに追加します。 2. 式を使用するには、\[Message (メッセージ)\] で \[Function (関数)\] ![logger task design center 0a147](/mulesoft/current/ja-jp/design-center/_images/logger-task-design-center-0a147.png) をクリックします。 固定テキストのみをログに記録する場合は、\[Function (関数)\] はクリックしないでください。テキストのみを入力します。 3. 式を入力します。次に例を示します。 **payload** 4. デフォルトのログレベルである DEBUG を受け入れるか、他の設定を選択してログに記録する情報を減らします。たとえば、INFO を選択します。 5. \[Run (実行)\] をクリックします。 6. モック要求を送信してフローを実行します。 7. 画面の一番下にある ​**\[Logs (ログ)\]**​ タブを展開します。 ![to debug a flow designer project 30b5a](/mulesoft/current/ja-jp/design-center/_images/to-debug-a-flow-designer-project-30b5a.png) \[Info (情報)\] の後に Mule メッセージペイロードのコンテンツが表示され、プロジェクトで Logger コンポーネントが生成した .logs とアプリケーションの実行やデプロイに関連するメッセージが表示されます。 # Mule アプリケーションのデプロイ:page-support-status: eolScheduled Mule アプリケーションをデプロイするために使用できる方法は 2 つあります。 [Flow Designer からの Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/design-center/promote-app-prod-env-design-center)​ Flow Designer を使用して作成するすべての Mule アプリケーションはデザイン環境に作成されます。作成した Mule アプリケーションを本番に移行する準備が整ったら、Mule アプリケーションを別の環境にデプロイできます (これを組織が許可している場合)。 [Runtime Manager からの Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/design-center/fd-deploy-app-from-rm)​ アプリケーションを Flow Designer から直接デプロイすることが許可されていない場合があります。組織は、適切な権限を持つユーザーが Runtime Manager からアプリケーションをデプロイすることを要求する場合があります。アプリケーションをデプロイするための ​`.jar`​ ファイルとして、プロジェクトのコピーをこのユーザーと共有することができます。 # Mule アプリケーションのフローの要素 (Flow Designer):page-support-status: eolScheduled フロー内の各カードはコアコンポーネント、コネクタの操作、モジュール、または API を表します。 コアコンポーネント コアコンポーネントを使用して、フローにロジックを追加したり、いくつかのタスクを実行したりできます。コアコンポーネントが提供する機能の例を次に示します。 - サブフローの初期化 - ログ記録 - ペイロードの設定 - データの変換 - エラーをキャッチして対応するためのフローでの Try スコープの作成 たとえば、Choice ルーターはメッセージコンテンツを評価する DataWeave 式のセットに従ってフローを経由するメッセージを動的にルーティングするコンポーネントです。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の if/then/else コードブロックのような条件付き処理がフローに追加されます。 コネクタ コネクタを使用して、アプリケーションは SaaS やオンプレミスアプリケーション、システム、サービスに接続できます。 - Salesforce Connector を使用すると、アプリケーションは Salesforce 内の多くの操作を実行できます。 - Database Connector を使用すると、アプリケーションはデータベース内の操作を実行できます。 - HTTP Connector を使用すると、アプリケーションは HTTP 要求を受信し、HTTP 応答を送信できます。 モジュール モジュールは、作成された複数の操作をまとめてアプリケーションの柔軟性を高めます。モジュールを使用すると、アプリケーションは値の集約やデータの圧縮ができるほか、Java 機能を使用したり、JSON を処理するための追加機能を使用したりできます。モジュールによって提供される機能は、従来のアプリケーションコーディングのレベルではさらに増えます。 たとえば、XML Module には XML ドキュメントからデータを抽出して処理できるコンポーネントが用意されています。 API Anypoint-Platform 組織のユーザーが API Designer から API 仕様を Exchange にパブリッシュすると、Exchange はその仕様に基づく REST API を作成します。この API を、組織で作成されたアプリケーションで使用できます。 ## [](#関連情報)関連情報 - [Flow Designer ツアー](https://docs.mulesoft.com/jp/design-center/fd-tour) - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # Mule アプリケーションプロジェクトでの連動関係の更新 (Flow Designer):page-support-status: eolScheduled 連動関係とは、Mule とは独立してバージョン設定されるコネクタと他のフロー部分との関係です。たとえば、Sharepoint Connector 3.1.1 をフローと Mule 4.1.5 で使用している場合、コネクタのバージョンを変更しても、Mule 4.1.5 を使い続けることができます。コネクタの最新バージョンの機能を Mule アプリケーションで使用したい場合などに、バージョンを切り替えます。 バージョンを切り替えても、プロジェクトは、コネクタ用に作成されている再利用可能な設定を削除しません。ただし、切り替えた先のバージョンに設定の変更を含むような更新がある場合には、コネクタ設定の編集が必要になることもあります。編集が必要かどうかは、コネクタのリリースノートで確認してください。

新バージョンの Mule Runtime がリリースされた後で既存の Mule アプリケーションプロジェクトを開くと、アプリケーションはその新バージョンを使用します。Flow Designer はアプリケーションをすぐに更新し、デザイン環境でのみ再起動します。Flow Designer はアプリケーションを更新できない場合、アプリケーションを再起動しません。

このプロセスにより、Mule アプリケーションは常に最新バージョンの Mule Runtime を使用していることが保証されます。

更新により、アプリケーションで使用しているコネクタの更新が必要になる場合があります。その場合は、コネクタを更新するまでアプリケーションを再デプロイすることはできません。

## [](#手順)手順 1. 連動関係アイコン: ![manage dependency versions design center d96c7](/mulesoft/current/ja-jp/design-center/_images/manage-dependency-versions-design-center-d96c7.png) をクリックします。 **結果:**​ プロジェクトのすべての連動関係のリストが表示されます。 2. 連動関係にカーソルを置きオプションアイコン: ![manage dependency versions design center 018a5](/mulesoft/current/ja-jp/design-center/_images/manage-dependency-versions-design-center-018a5.png) をクリックします。 3. **\[Change version (バージョンを変更)\]**​ を選択して、バージョンを選択します。 ## [](#次のステップ)次のステップ アプリケーションが期待どおりに動作するように、アプリケーションを新バージョンでテストします。 # Mule アプリケーションプロジェクトのエラーのリスト表示とエラー箇所への移動:page-support-status: eolScheduled **\[Problems (問題)\]**​ ペインには、プロジェクトに含まれるエラーのリストと、それぞれの説明が表示されます。 Flow Designer のエラーは 4 種類に大別されます。 カードのエラー これらのエラーは、カードに値がない場合、不正な値が指定されている場合、またはコネクタカードが表すシステムに Flow Designer が接続して認証する方法が設定されていない場合に発生します。​**\[Problems (問題)\]**​ ペインでこの種類のエラーをクリックすると、Flow Designer はエラーが含まれるカードを開きます。 設定のエラー これらのエラーは、保存済み設定にエラーが含まれる場合に発生します。保存済み設定とは、Flow Designer が 1 つまたは複数のカードによって表されたシステムに接続するために必要な情報の集まりです。保存済み設定により、1 つのカードでこの情報を設定しておき、プロジェクトのフローに同じ種類のカードを追加するたびに同じ情報を再利用できます。​**\[Problems (問題)\]**​ ペインでこの種類のエラーをクリックすると、Flow Designer はエラーが含まれる保存済み設定を開きます。 カードや設定に制限されないフローのエラー これらのエラーは、フローにトリガーがない場合や、トリガーの後にカードが 1 つもない場合に発生します。​**\[Problems (問題)\]**​ ペインでこの種類のエラーをクリックすると、Flow Designer はエラーが含まれるフローを開きます。 プロジェクトに関連するエラー これらのエラーは、たとえば Mule アプリケーションの起動に問題があったり、Flow Designer のサービスである Datasense が起動できなかったりする場合に発生します。この種類のエラーはプロジェクトの特定部分ではなくプロジェクト全体に影響するため、​**\[Problems (問題)\]**​ ペインでエラーをクリックしても何も表示されません。 ## [](#手順)手順 1. キャンバスの右下隅にある ​**\[Problems (問題)\]**​ をクリックして ​**\[Problems (問題)\]**​ ペインを開きます。 ![view problems](/mulesoft/current/ja-jp/design-center/_images/view-problems.png) **結果:**​ キャンバスの一番下に ​**\[Problems (問題)\]**​ ペインが開きます。プロジェクトにエラーがある場合は、このペインにエラーのリストが表示されます。リストの各項目には説明が付いています。 2. 次の画像に示すように、いずれかの項目をクリックします。 ![view problems select](/mulesoft/current/ja-jp/design-center/_images/view-problems-select.png) **結果:**​ Flow Designer はエラーの場所を表示します。次の画像では、Email Connector の設定がセットアップされていないためにエラーとなっています。この設定とは、Mule アプリケーションがシステムに接続するために必要な設定情報の集まりです。このケースのシステムは SMTP サーバーです。 ![view problems email config](/mulesoft/current/ja-jp/design-center/_images/view-problems-email-config.png) # Mule アプリケーションへのシステムの統合:page-support-status: eolScheduled Mule アプリケーションを作成する目的は、自動化されたワークフロー内でさまざまなシステムを統合し、結果を達成することです。たとえば、Flow Designer テンプレート「Slack message to Twilio (Twilio への Slack メッセージ)」は、Slack と Twilio の両方を統合し、特定の Slack チャネルに新しいメッセージがある場合にテキストメッセージを送信します。 Flow Designer では、多種多様なシステムの統合と、各システム内での複数の操作がサポートされています。たとえば、Slack Connector では次の操作がサポートされます。 - On New Message - Channels - Info - Channels - INvite - Channels - List - Channels - Rename - Channels - Set Purpose - Channels - Set Topic - Chat - Post Message - Chat - Update Message - Dialog - Open - File - Upload - Groups - Info - Groups - List - Groups - Rename - Groups - Set Purpose - Groups - Set Topic - IM - List - IM - Open - Unauthorize - User - Info - User - List 一部のコネクタでは 100 を超える操作がサポートされています。つまり、Flow Designer で作成した Mule アプリケーションを使用して自動化できるタスクの数はほぼ無制限です。 Mule アプリケーションでコネクタを使用する場合にコネクタに提供する必要がある情報の種類を理解するために必要な情報を含め、コネクタとその操作に関するドキュメントは、​[「コネクタとモジュール (Mule 4) について」](https://docs.mulesoft.com/connectors/)​を参照してください。 コネクタに関するドキュメントは、Flow Designer と Anypoint Studio の両方のユーザー向けに記述されています。Studio でのコネクタの使用に関する情報は無視してください。また、XML を使用する例についても無視して構いません。XML を形式として使用するカスタムデータ型を定義していない限り、Flow Designer を使用しているときに、XML 形式で記述する必要はありません。 # MuleSoft 接続エコシステムの API 仕様 独立系ソフトウェアベンダー (ISV) であれば、REST API 仕様からコネクタを自動的に生成することで、MuleSoft 接続エコシステムに参加できます。以下の手順では、API 仕様を Anypoint Platform で準備して、MuleSoft BD カウンターパートで残りの作業を行う方法を説明します。 1. Anypoint Platform で、次の手順で API 仕様を準備します。 1. Anypoint Platform にサインアップします。 [https://anypoint.mulesoft.com/login/#/signup](https://anypoint.mulesoft.com/login/#/signup) 2. Anypoint Platform にログインし、​**\[Design Center\]**​ をクリックします。 3. 右上隅にある ​**\[+Create new (+新規作成)\]**​ をクリックし、​**\[New API Specification (新規 API 仕様)\]**​ をクリックして、新しい API 仕様プロジェクトを作成します。 4. **\[New API Specification (新しい API 仕様)\]**​ ウィンドウで、プロジェクトの名前を指定し、​**\[I’m comfortable designing it on my own (自分でデザインします)\]**​ を選択して、仕様の言語を選択します。次に ​**\[Create API (API を作成)\]**​ をクリックします。 5. 名前にカーソルを置くと自動的に生成されるファイルを削除するには、右側にある 3 つのドットをクリックして ​**\[Delete (削除)\]**​ を選択します。 6. 画面の左側で、ファイルリストの一番上にあるアクションメニュー (3 つのドットのアイコン) をクリックして、​**\[Import (インポート)\]**​ を選択します。URL の場所にある RAML または ​`.oas`​ ファイル、​`.zip`​ ファイル、あるいは仕様をインポートできます。 7. インポート後に、API をテストして期待どおりに動作することを確認します。 1. 画面の右上隅でモッキングサービスをオンにします。 2. ファイルリストから自分の API 仕様を選択します。 3. 画面の右側にある \[API summary (API の概要)\] で、自分のリソース用のメソッドが表示されるまで ​**\[Resources (リソース)\]**​ エントリを展開します。 4. いずれかのメソッドをクリックします。 5. メソッドの情報を確認します。 6. **\[Try It (試す)\]**​ をクリックします。 7. エンドポイントでパラメーターが必要な場合は値を指定します。 8. **\[Send (送信)\]**​ をクリックします。 画面の右側の ​**\[Send (送信)\]**​ ボタンの下にテストの結果が表示されます。 2. API 仕様の準備ができたら、GitHub や Bitbucket などの Git 互換リポジトリに保存します。 3. MuleSoft BD カウンターパートにアクセスして以下の手順を実行します。 1. テクノロジーパートナー契約 (MuleSoft BD カウンターパートが提供します) に同意します。 2. Anypoint Platform のトライアル期限の延長を申し込みます。 3. 接続アセット用のセルフサービス認定ツールである Connectivity Assets Manager ツールへの招待を申し込み、その招待に基づいて新しい Anypoint Platform アカウントを作成します。 4. MuleSoft があなたの API の概要と Anypoint Platform での動作を理解できるようにするための短いデモをスケジュール設定します。 # OAS 3.0 での表示されるドキュメントの違い API Designer のテキストエディターの右側のペインには、API 仕様に書き込まれるドキュメントが表示されます。ドキュメントは、RAML または OAS 2.0 で作成された REST API 仕様と同様に表示されます。OAS 3.0 に書き込まれる API 仕様のドキュメントには、複数のサーバー定義や、リンクおよびコールバックが含まれることがあります。 ## [](#複数サーバーの定義のドキュメント)複数サーバーの定義のドキュメント OAS 3.0 では、​`servers`​ 項目を使用してサーバーを定義できます。サーバーは仕様の最上部でグローバルに定義したり、エンドポイントやメソッドでローカルに定義したりできます。ローカル定義は、仕様の階層の次に高いレベルで設定された定義を上書きします。メソッドでローカルに設定された定義は、エンドポイントで設定された定義やグローバルに設定された定義を上書きます。エンドポイントでローカルに設定された定義は、グローバルに設定された定義を上書きます。 次の API 仕様の例は、サーバー定義を設定するさまざまな方法 (1 ~ 10 のコールアウト) を示しています。API 仕様の例の後に、API の各コールアウトの部分のドキュメントがスクリーンショットと共に記載されています。 openapi: '3.0.2' info: title: Multi-server Cemo API version: '1.0' servers: **(1)** - url: https://{customerId}.saas-app.com:{port}/v2 variables: customerId: default: demo description: Customer ID assigned by the service provider port: enum: - '443' - '8443' default: '443' - url: https://{region}.api.company.com variables: region: default: westus enum: - westus - eastus2 - westcentralus - westeurope - southeastasia - url: https://api.company.org/data/2.5/ description: Production server - url: http://beta.api.company.org/data/2.5/ description: Beta server paths: /default:**(2)** description: A default path to the API get:**(3)** summary: "The get method for /default" responses: 200: description: Successful response /duplicated:**(4)** description: Has some of the default servers servers: - url: https://api.company.org/data/2.5/ description: Production server - url: http://beta.api.company.org/data/2.5/ description: Beta server get:**(5)** summary: "The get method for /duplicated" responses: 200: description: Successful response /files:**(6)** description: File upload and download operations servers: - url: https://files.example.com description: Override base path for all operations with the /files path get:**(7)** summary: "The get method for /files" responses: 200: description: Successful response /ping:**(8)** servers: - url: https://endpoint.example.com description: Override base path servers get:**(9)** servers: - url: https://echo.example.com description: Override base path for the GET /ping operation - url: https://echo2.example.com description: Also overrides base path for the GET /ping operation summary: "The get method for /ping" responses: 200: description: Successful response post:**(10)** summary: "The post method for /ping" responses: 201: description: Successful create 1. この API のドキュメントの \[Summary (概要)\] ページには、次の ​`servers`​ 項目で定義されている 4 つのサーバーがリストされています。 ![apid apic oas 3 summary](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-summary.png) 2. `/default`​ エンドポイントは、API の最上部のベース ​`servers`​ 定義を上書きしません。エンドポイントの \[Overview (概要)\] ページでは、サーバーを選択して、そのサーバーのこのエンドポイントの URI を確認できます。 ![apid apic oas 3 default](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-default.png) 3. `/default`​ エンドポイントの GET メソッドは、ベース ​`servers`​ 定義の 4 つのサーバーも継承します。このメソッドのページでは、サーバーを選択して、そのサーバーのこのメソッドの URI を確認できます。 ![apid apic oas 3 default get](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-default-get.png) 4. `/duplicated`​ エンドポイントは、ベース ​`servers`​ 定義を上書きします。そのローカル ​`servers`​ 定義には、元の 4 つのサーバーのうち最後の 2 つのサーバーのみが含まれます。エンドポイントの \[Overview (概要)\] ページでは、サーバーを選択して、そのサーバーのこのエンドポイントの URI を確認できます。 ![apid apic oas 3 duplicated](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-duplicated.png) 5. `/duplicated`​ エンドポイントの GET メソッドは、ローカル ​`servers`​ 定義の 2 つのサーバーを継承します。このメソッドのページでは、サーバーを選択して、そのサーバーのこのメソッドの URI を確認できます。 ![apid apic oas 3 duplicated get](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-duplicated-get.png) 6. `/files`​ エンドポイントは、ベース ​`servers`​ 定義を上書きします。そのローカル ​`servers`​ 定義には、1 つのサーバーのみが含まれます。このエンドポイントの \[Overview (概要)\] ページには、前の 2 つのエンドポイントのように選択するサーバーがありません。 ![apid apic oas 3 files](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-files.png) 7. `/files`​ エンドポイントの GET メソッドは、ローカル ​`servers`​ 定義の 1 つのサーバーを継承します。このメソッドのページには、選択するサーバーのリストはありません。 ![apid apic oas 3 files get](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-files-get.png) 8. `/ping`​ エンドポイントは、ベース ​`servers`​ 定義を上書きします。そのローカル ​`servers`​ 定義には、1 つのサーバーのみが含まれます。このエンドポイントの \[Overview (概要)\] ページには、選択するサーバーがありません。 ![apid apic oas 3 ping](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-ping.png) 9. `/ping`​ エンドポイントの ​`GET`​ メソッドは、ベース ​`servers`​ 定義と ​`/ping`​ エンドポイントのローカル ​`servers`​ 定義の両方を上書きします。​`GET`​ メソッドのローカル ​`servers`​ 定義には、2 つのサーバーが含まれます。このメソッドのページでは、サーバーを選択して、そのサーバーのこのメソッドの URI を確認できます。 ![apid apic oas 3 ping get](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-ping-get.png) 10. `/ping`​ エンドポイントの POST メソッドは、​`/ping`​ エンドポイントのローカル ​`servers`​ 定義の 1 つのサーバーを継承します。このエンドポイントの \[Overview (概要)\] ページには、選択するサーバーのリストがありません。 ![apid apic oas 3 ping post](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-ping-post.png) ## [](#リンクとコールバックのドキュメント)リンクとコールバックのドキュメント OAS 3.0 では、リンクとコールバックを定義できます。これらの機能については、\\https://swagger.io/ の openAPI 3.0 の仕様を参照してください。 次の API 仕様の例は、リンクとコールバックの設定方法を示しています。コールアウトは、後に続くスクリーンショットのドキュメントとして表示される API 仕様の部分を示しています。 openapi: 3.0.0 info: version: 1.0.0 title: Callback Demo API servers: - url: https://{customerId}.saas-app.com:{port}/v2 variables: customerId: default: demo description: Customer ID assigned by the service provider port: enum: - '443' - '8443' default: '443' components: requestBodies: callbackMessage1: description: Callback message \`1\` required: true content: application/json: schema: $ref: '#/components/schemas/Clb1' callbackMessage2: description: Callback message \`2\` required: true content: application/json: schema: $ref: '#/components/schemas/Clb2' callbackMessage3: description: Callback message \`3\` required: true content: application/json: schema: $ref: '#/components/schemas/Clb3' schemas: Clb1: title: Event 1 type: object properties: text: type: string description: Message text Clb2: title: Event 2 type: object properties: productId: type: string description: Order product id Clb3: title: Event 3 type: object properties: eventId: type: string description: Event internal ID triggerAuthor: type: string description: A person triggered the event paymentRequest: title: Payment type: object properties: token: type: string description: Payment token generated for this request amount: type: number description: The payment amount. paths: /subscribe: post: requestBody: content: application/json: schema: type: object properties: inProgressUrl: type: string failedUrl: type: string successUrl: type: string responses: '200': description: OK links:**(1)** unsubscribeOp: operationId: unsubscribeOperation parameters: Id: $response.body#/subscriberId otherOp: parameters: one: $response.body#/one two: $response.body#/two 402: description: Not OK. Payment is required content: application/json: schema: $ref: '#/components/schemas/paymentRequest' links:**(2)** paymentUrl: parameters: paymentUrl: $response.body#/info.paymentUri paymentToken: $response.body#/info.token callbacks: inProgress: '{$request.body#/inProgressUrl}':**(3)** post: requestBody: $ref: '#/components/requestBodies/callbackMessage1' responses: '200': description: OK '{$request.body#/failedUrl}':**(4)** post: requestBody: $ref: '#/components/requestBodies/callbackMessage2' responses: '200': description: OK '{$request.body#/successUrl}':**(5)** post: requestBody: $ref: '#/components/requestBodies/callbackMessage3' responses: '200': description: OK /unsubscribe: post: operationId: unsubscribeOperation parameters: - in: query name: Id required: true schema: type: string responses: '200': description: OK 1. `/subscribe`​ エンドポイントの ​`POST`​ メソッドの 200 応答のリンクは、メソッドのドキュメントの最下部に表示されます。 ![apid apic oas 3 links 1](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-links-1.png) 2. `/subscribe`​ エンドポイントの ​`POST`​ メソッドの 402 応答のリンクは、メソッドのドキュメントの最下部に表示されます。 ![apid apic oas 3 links 2](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-links-2.png) コールアウト 3 ~ 5 のドキュメントは、​`/subscribe`​ エンドポイントの ​`POST`​ メソッドのドキュメントの ​**\[Callbacks (コールバック)\]**​ セクションに表示されます。 ![apid apic oas 3 callbacks](/mulesoft/current/ja-jp/design-center/_images/apid-apic-oas-3-callbacks.png) # RAML 0.8 API 仕様のよくある問題 次のセクションでは、RAML 0.8 で API 仕様を作成するときの作成者による一般的なエラーと、それらを解決するためのヒントについて説明します。 ## [](#parser\*invalid-type-definition)スキーマで予約済みの名前が使用されている 予約済み名前をスキーマ名として使用すると、エディターは次のメッセージを表示します。 ‘schemaName’ cannot be used to name a custom schema 予約済みの名前としては、​`string`​、​`integer`​、​`number`​、​`object`​ などがあります。RAML 仕様で使用されている名前は、いずれもスキーマ名としては使用できません。 たとえば、次の API 仕様に対してエディターはメッセージを表示します。 #%RAML 0.8 title: Example API Spec schemas: string: type: string この問題を解決するには、スキーマ宣言で別の名前を使用します。 #%RAML 0.8 title: Example API Spec schemas: customString: type: string [\[先頭に戻る\]](#先頭に戻る)​ ## [](#parser\*example-validation-error)例の検証時の問題 ### [](#ブール列挙の例で文字列データ型を使用していない)ブール列挙の例で文字列データ型を使用していない ブール列挙が文字列またはブール値のどちらであっても、例は文字列型でなければなりません。この違反の具体例として、次の API 仕様では例で間違ったデータ型を使用しています。 #%RAML 0.8 title: ExampleRAML /nob: head: responses: 204: headers: X-NOB-Exists: enum: \[true, false\] example: true RAML 0.8 では、列挙値で文字列のみをサポートし、ブール値はサポートしません。また、上の RAML の例では、列挙のデータ型が宣言されていません。RAML 0.8 では、データ型が宣言されていない場合は ​`string`​ であると見なされます。 したがって、上の間違った例では、列挙の値を引用符で囲む必要があります。その理由は、例のデータ型を、例の対象となる要素と同じデータ型にする必要があるためです。 上の RAML 例の最後の 2 行は次のように記述しなければなりません。 ... enum: \["true", "false"\] example: "true" [\[先頭に戻る\]](#先頭に戻る)​ ### [](#必須プロパティを定義するスキーマの例でそのプロパティを使用していない)必須プロパティを定義するスキーマの例で、そのプロパティを使用していない 必須プロパティを定義するスキーマの例では、そのプロパティを使用する必要があります。この問題の例で、次の API 仕様では、エンドポイント ​`/order/{id}`​ に対する応答を定義しています。この定義には ​`get_order_response_schema.json`​ と ​`get_order_response.json`​ という 2 つのファイルが含まれています。 #%RAML 0.8 title: ExampleRAML version: 1.0 ... /order: displayName: Orders API /create: ... /{id}: displayName: Get Order by OrderId description: This operation will get an order by order ID from Salesforce. get: description: This operation returns the order from Salesforce by Fulfillment Order ID, not by the Salesforce unique ID. responses: 200: body: application/json: schema: !include get\_order\_response\_schema.json example: !include get\_order\_response.json `get_order_response_schema.json`​ ファイルでは ​`sfOrderId`​ プロパティを必須プロパティとして定義しています。 { "type":"object", "$schema": "http://json-schema.org/draft-03/schema", "id": "http://com.mulesoft.demo.orders.get.json.order", "required":false, "properties":{ ... "sfOrderId": { "type":"string", "id": "http://com.mulesoft.demo.orders.create.json.get.sfOrderId", "required":true }, ... スキーマの例は ​`get_order_response.json`​ に記述されています。しかしながら、必須プロパティの名前が ​`sOrderId`​ と間違っています。 { "orderId": 14523, "sOrderId": "fadfead3524523", "sfAccountId": "fedfes3653635", "orderName": "Order From Manufacturing-Company, Inc.", "total": 174.92, "orderType": "E-Commerce Order", "description": "8 widgets", "orderDate": "04-03-2018" } [\[先頭に戻る\]](#先頭に戻る)​ ### [](#スキーマの例でスキーマが定義するデータ型を使用していない)スキーマの例でスキーマが定義するデータ型を使用していない たとえば、次の API 仕様のスキーマでは ​`title`​ プロパティのデータ型をオブジェクトとして定義していますが、スキーマの例では配列が使用されています。 #%RAML 0.8 title: ExampleRAML schemas: - presentation: | { "$schema": "http://json-schema.org/draft-03/schema", "type": "object", "properties": { "title": { "type": "string" } } } /presentations: &presentations type: { typedCollection: { schema: presentation } } get: responses: 200: body: application/json: example: | \[ { "title": "Presentation Video" }, { "title": "Environment Spec Report" } \] [\[先頭に戻る\]](#先頭に戻る)​ ### [](#ブールの例で値に-0-や-1-を使用している)ブールの例で値に 0 や 1 を使用している ブールの例で使用できる値は「true」または「false」です。次の API 仕様では、フォームパラメーター ​`is_public`​ の例で使用されている値が間違っています。 #%RAML 0.8 title: ExampleRAML /upload: post: description: | Upload a photo body: multipart/form-data: formParameters: title: description: The title of the photo. is\_public: type: boolean example: 1 ### [](#例にプロパティが含まれていない)例にプロパティが含まれていない 例に対象となる型のプロパティが含まれていないと、エディターは違反メッセージを表示します。 should have required property 'property name' 次の API 仕様では、​`age`​ プロパティが例に含まれていません。 #%RAML 0.8 title: Example API Spec /clients: get: responses: 200: body: application/json: schema: | { "$schema": "http://json-schema.org/draft-03/schema", "properties": { "firstName": { "type": "string" }, "lastName": { "type": "string" }, "age": { "type": "number", "required": true } }, "required": false, "type": "object" } example: firstName: John lastName: Smith 例にプロパティを追加するか、または型宣言でプロパティを省略可能として宣言してください。 次のケースでは、プロパティが例に追加されています。 #%RAML 0.8 title: Example API Spec /clients: get: responses: 200: body: application/json: schema: | { "$schema": "http://json-schema.org/draft-03/schema", "properties": { "firstName": { "type": "string" }, "lastName": { "type": "string" }, "age": { "type": "number", "required": true } }, "required": false, "type": "object" } example: firstName: John lastName: Smith age: 30 次のケースでは、プロパティが省略可能として宣言されています。 #%RAML 0.8 title: Example API Spec /clients: get: responses: 200: body: application/json: schema: | { "$schema": "http://json-schema.org/draft-03/schema", "properties": { "firstName": { "type": "string" }, "lastName": { "type": "string" }, "age": { "type": "number", "required": false } }, "required": false, "type": "object" } example: firstName: John lastName: Smith [\[先頭に戻る\]](#先頭に戻る)​ [\[先頭に戻る\]](#先頭に戻る)​ ## [](#parser\*WebAPI-name-minLength)`title`​ ノードの値がない `title`​ ノードでは、次のように値を省略することはできません。 #%RAML 0.8 title: [\[先頭に戻る\]](#先頭に戻る)​ ## [](#要素の例で-raml-要素のデータ型を使用していない)要素の例で RAML 要素のデータ型を使用していない すべてのケースにおいて、例のデータ型は、例の対象となる要素と同じでなければなりません。 次の間違った API 仕様では、クエリパラメーターを文字列として定義していますが、例では整数が使用されています。 #%RAML 0.8 title: ExampleRAML /books: get: queryParameters: publicationYear: type: string example: 2016 [\[先頭に戻る\]](#先頭に戻る)​ ## [](#parser\*unresolved-reference)JSON スキーマ内部の参照パスが無効である JSON スキーマで ​`$ref`​ キーワードを使用する場合、指定するパスはスキーマのルートから始まっていなければなりません。たとえば、次のスキーマで ​`input2`​ プロパティに対して使用されている ​`$ref`​ キーワードでは、​`input`​ プロパティを参照するためのパスが間違っています。 #%RAML 0.8 title: ExampleRAML version: v1 schemas: - authCodeResponse : | { "$schema": "http://json-schema.org/draft-04/schema", "properties": { "input": { "type": "string" }, "input2": { "$ref": "input" } }, "type": "object" } パスはスキーマのルートレベルから始まり、ツリー構造を下がって行かなければなりません。次のスキーマの例では、同じ ​`$ref`​ キーワードで正しいパスが使用されています。 { "$schema": "http://json-schema.org/draft-04/schema", "properties": { "input": { "type": "string" }, "input2": { "$ref": "#/properties/input" } }, "type": "object" } [\[先頭に戻る\]](#先頭に戻る)​ ## [](#parser\*unused-base-uri-parameter)使用されない URI パラメーターを宣言している API 仕様で宣言した URI パラメーターが仕様内で使用されていない場合、エディターは次の警告メッセージを表示します。 unused uri parameter “parameter” ベース URI パラメーターとして宣言されているパラメーターが使用されていない場合は、エディターは次の警告メッセージを表示します。 unused base uri parameter “parameter” たとえば、次の API 仕様により 2 つの警告メッセージが表示されます。 unused uri parameter "unusedParam" unused base uri parameter "unusedUriParam" #%RAML 0.8 title: test baseUri: http://param.raml/a/{baseUriParam1}/{nonExists}/{baseUriParam2} baseUriParameters: baseUriParam1: type: string baseUriParam2: type: string unusedParam: type: string /endpoint/{uriParam1}/{nonExistsUri}: uriParameters: uriParam1: type: string unusedUriParam: type: string 警告メッセージは、単純にこれらのパラメーターを宣言している行を削除するだけで表示されなくなります。 #%RAML 0.8 title: test baseUri: http://param.raml/a/{baseUriParam1}/{nonExists}/{baseUriParam2} baseUriParameters: baseUriParam1: type: string baseUriParam2: type: string /endpoint/{uriParam1}/{nonExistsUri}: uriParameters: uriParam1: type: string [\[先頭に戻る\]](#先頭に戻る)​ ## [](#parser\*Payload-mediaType-minCount)ペイロードのメディア種別を宣言していない ペイロードの宣言でメディア種別が宣言されていないと、エディターは次のメッセージを表示します。 Payload media type is mandatory たとえば、次の API 仕様に対してエディターはこのメッセージを表示します。 #%RAML 0.8 title: Example API Spec /media: get: responses: 200: body: type: string この問題の解決法は 2 つあります。 - ペイロード宣言でメディア種別をローカルに宣言する。 #%RAML 0.8 title: Example API Spec /media: get: responses: 200: body: application/json: type: string - API 仕様でデフォルトのメディア種別をグローバルに指定する。 #%RAML 0.8 title: Example API Spec mediaType: application/json /media: get: responses: 200: body: type: string 次の例では、グローバル宣言とローカル宣言の両方を使用しています。このケースでは、​`mediaType`​ ノードは ​`application/json`​ と ​`application/xml`​ を受け入れ可能なメディア種別として定義しています。最初の種別である ​`Person`​ は、どちらのメディア種別であっても構わずに本文を返します。2 番目の種別である ​`Another`​ は、ローカル宣言でグローバル宣言を上書きし、JSON の本文のみを返します。 #%RAML 0.8 title: New API mediaType: \[ application/json, application/xml \] schemas: Person: Another: /list: get: responses: 200: body: Person /send: post: body: application/json: schema: Another [\[先頭に戻る\]](#先頭に戻る)​ ## [](#include-タグを使用してフラグメントを参照していない)`!include`​ タグを使用してフラグメントを参照していない API 仕様で ​`uses`​ キーを使用してフラグメントを参照していると、エディターは次のメッセージを表示します。 Fragments must be imported by using '!include' [\[先頭に戻る\]](#先頭に戻る)​ ## [](#uses-キーを使用してライブラリを適用していない)`uses`​ キーを使用してライブラリを適用していない API 仕様で ​`!include`​ タグを使用してライブラリを適用していると、エディターは次のメッセージを表示します。 Libraries must be applied by using 'uses' [\[先頭に戻る\]](#先頭に戻る)​ ## [](#parser\*syaml-error)構文の問題 ### [](#無効な-json-を含むスキーマが含まれている)無効な JSON を含むスキーマが含まれている `schemas`​ プロパティの値に含まれるファイルには、有効な JSON が必要です。 最初の例には ​`appSwitcher.json`​ というスキーマが含まれています。しかし、2 番目の例では、JSON にエラーがあり、最後の値の末尾が引用符であるべきところがカンマになっています。 #%RAML 0.8 title: ExampleRAML schemas: - appSwitcher: !include schemas/appSwitcher.json { "appMenuItems" : \[ { "type" : "Tabset" , "content" : null , "icons" : null , "colors" : null , "label" : "Call Center" , "url" : "/home/home.jsp?tsid=02uxx00000056Sr" } , { "type" : "Tabset" , "content" : null , "icons" : null , "colors" : null , "label" : "Community" , "url" : "/home/home.jsp?tsid=02uxx00000056Sw" } , { "type" : "Tabset" , "content" : null , "icons" : null , "colors" : null , "label" : "App Launcher" , "url" : "/app/mgmt/applauncher/appLauncher.apexp?tsid=02uxx00000056Sx, } \] } [\[先頭に戻る\]](#先頭に戻る)​ ### [](#json-スキーマの例で無効な-json-を使用している)JSON スキーマの例で無効な JSON を使用している 次の API 仕様では JSON スキーマの例が間違っていますが、有効な JSON を使用しなければなりません。 #%RAML 0.8 title: ExampleRAML ... /api: get: responses: 200: body: application/json: schema: { "type": "object", "required": true, "$schema": "http://json-schema.org/draft-03/schema", "properties": { "a": { "type": "boolean", "required": true } } } example: { "a: { "a": "" } [\[先頭に戻る\]](#先頭に戻る)​ ### [](#ファセットが-yaml-マップを必要としている場合に-yaml-マップを提供していない)ファセットが YAML マップを必要としている場合に YAML マップを提供していない 値としてマップが必要であるとして RAML 0.8 仕様でファセットが記述されており、API 仕様でマップが提供されていない場合、エディターにメッセージ「​`YAML map expected`​」が返されます。 次に、エラーの例を示します。 #%RAML 0.8 title: Test version: 1.0 securitySchemes: basic: type: Basic Authentication settings: エラーの修正方法は 2 つあります。 - マップを値として提供する。 #%RAML 0.8 title: Test version: 1.0 securitySchemes: basic: type: Basic Authentication settings: requestTokenUri: https://api.mysampleapi.com/1/oauth/request\_token - マップを必要とするファセット (この場合は ​`settings`​) を削除する。 #%RAML 0.8 title: Test version: 1.0 securitySchemes: basic: type: Basic Authentication [\[先頭に戻る\]](#先頭に戻る)​ ## [](#parser\*closed-shape)サポートされないプロパティを使用している このエラーは未定義のファセットを使用した場合に発生します。 エラーメッセージの例 `Property invalidfacet not supported in a RAML 0.8 webApi node`​。​`invalidfacet`​ は、RAML 仕様で定義されていないファセットの名前です。 このエラーが生成される例を次に示します。
Table 1. 間違った例と正しい例
間違い 正しい
#%RAML 0.8
title: Test
invalidfacet:
version:
#%RAML 0.8
title: Test
version:
[\[先頭に戻る\]](#先頭に戻る)​ ## [](#parser\*unresolved-parameter)未定義の型をヘッダーで宣言している このエラーは、存在しない型がヘッダーで指定されている場合に発生します。 エラーメッセージ `Cannot declare unresolved parameter`​ 次の間違った例では、ヘッダー ​`myHeader`​ の値に入力ミスがあります。​`string`​ ではなく ​`strang`​ と指定されています。
Table 2. 間違った例と正しい例
間違い 正しい
#%RAML 0.8
title: test

/endpoint:
  post:
    headers:
      myHeader: strang
#%RAML 0.8
title: test

/endpoint:
  post:
    headers:
      myHeader: string
[\[先頭に戻る\]](#先頭に戻る) # RAML 1.0 API 仕様のよくある問題 次のセクションでは、RAML 1.0 で API 仕様を作成するときの作成者による一般的なエラーと、それらを解決するためのヒントについて説明します。 ## [](#parser\*schema-deprecated)`type`​ または ​`types`​ キーワードではなく ​`schema`​ または ​`schemas`​ を使用している RAML 1.0 の仕様では、キーワードの ​`schema`​ と ​`schemas`​ が ​`type`​ と ​`types`​ に置き換えられました。​`schema`​ または ​`schemas`​ を使用すると、エディターは次のいずれかの警告メッセージを表示します。 ‘schema' keyword it's deprecated for 1.0 version, should use 'type' instead 'schemas' keyword it's deprecated for 1.0 version, should use 'types' instead たとえば、次の API 仕様により両方の警告メッセージが表示されます。 #%RAML 1.0 title: Incorrect API with schema and schemas schemas: User: type: object properties: firstname: string lastname: string age: number /users/{id}: get: responses: 200: body: application/json: schema: User 問題を解決するには、​`schema`​ と ​`schemas`​ を ​`type`​ と ​`types`​ に置き換えます。 #%RAML 1.0 title: Correct API with type and types types: User: type: object properties: firstname: string lastname: string age: number /users/{id}: get: responses: 200: body: application/json: type: User [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*invalid-type-definition)型で予約済みの名前を使用している 予約済み名前を型名として使用すると、エディターは次のメッセージを表示します。 ‘typeName’ cannot be used to name a custom type 予約済みの名前としては、​`string`​、​`object`​、​`integer`​、​`number`​、​`object`​ などがあります。RAML 仕様で使用されている名前は、いずれも型名としては使用できません。 たとえば、次の API 仕様に対してエディターはメッセージを表示します。 #%RAML 1.0 title: Example API Spec types: string: type: string この問題を解決するには、型宣言で別の名前を使用します。 #%RAML 1.0 title: Example API Spec types: customString: type: string [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*named-example-used-inlined-example)例と RAML NamedExample フラグメントに関するよくある誤解 名前付きの例を ​`!include`​ タグで参照する際のよくある問題を回避するには、次の 2 つのガイドラインに従ってください。 - 次に示すように、API 仕様では ​`examples`​ ファセットを使用し、​`!include`​ タグを 1 つだけ使用してください。 #%RAML 1.0 title: test types: A: properties: a: string b: integer examples: !include fragment.raml - フラグメントでは、次のフラグメントのように、各例が各プロパティの名前と値で構成されるようにしてください。 fragment.raml #%RAML 1.0 NamedExample myExample1: a: "b1" b: 1 myExample2: a: "b2" b: 2 名前付きの例の使用方法についての詳細は、​[「RAML 1.0 での例の定義に関するガイド」](https://docs.mulesoft.com/jp/design-center/design-named-examples)​を参照してください。 [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*invalid-fragment-ref)`!include`​ ステートメントのファイル名にハッシュ記号付きの参照を付加している 名前付きファイルでは、ファイル名の後にハッシュ記号と場所への参照を付加することはできません。次のケースでは、​`IncrementType.raml#increment`​ は無効なリンクです。 #%RAML 1.0 DataType type: object properties: startValue: integer endValue: integer exclusiveEndValue: boolean range: type: array items: !include IncrementType.raml#increment API 仕様にこの違反があり、実際にはコメントを付加しようとしていた場合には、# 記号の前にスペースを入れてください。ファイル内の要素を参照しようとしていた場合には、このような参照は許可されません。内部要素への参照は、XSD スキーマと JSON スキーマでのみ有効です。 [\[先頭に戻る\]](#先頭に戻る) ## [](#json-の例における中括弧と大括弧の使い方が正しくない)JSON の例における中括弧と大括弧の使い方が正しくない 中括弧と大括弧の間違った使い方はたくさんあります。次にその一例を示します。JSON キー/値ペアグループの配列が不適切に中括弧で括られています。 #%RAML 1.0 title: ExampleRAML ... /rooms: displayName: rooms get: description: get all rooms responses: 200: body: application/json: example: | { \[{ "Name": "Superior King", "Number": "201", "Property": "SE030", "Status": "Clean" }, { "Name": "Junior Suite", "Number": "202", "Property": "NO131", "Status": "Clean" }\] } この例をオブジェクトとして定義するつもりであれば、キーが必要です。 #%RAML 1.0 title: ExampleRAML ... /rooms: displayName: rooms get: description: get all rooms responses: 200: body: application/json: example: { "some\_key": \[ { "Name": "Superior King", "Number": "201", "Property": "SE030", "Status": "Clean" }, { "Name": "Junior Suite", "Number": "202", "Property": "NO131", "Status": "Clean" } \] } この例を配列として定義するつもりであれば、外側の中括弧を削除する必要があります。 #%RAML 1.0 title: ExampleRAML ... /rooms: displayName: rooms get: description: get all rooms responses: 200: body: application/json: example: \[ { "Name": "Superior King", "Number": "201", "Property": "SE030", "Status": "Clean" }, { "Name": "Junior Suite", "Number": "202", "Property": "NO131", "Status": "Clean" } \] [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*expected-module)`type`​ ノードを使用してライブラリを適用している RAML 1.0 仕様で説明したように、ライブラリは ​`uses`​ ノードで適用する必要があります。 > \["main"\] RAML または RAML フラグメントファイルのルートにおいてのみ、省略可能な ​`uses`​ ノードを使用してライブラリをいくつでも適用できます。​`use`​s ノードの値は、キー/値ペアのマップです。キーはライブラリ名または名前空間として扱われ、値は RAML ライブラリファイルの場所 (通常は外部の RAML ライブラリフラグメントドキュメント) でなければなりません。 `type`​ ノードを使用してライブラリを適用すると、エディターは次のメッセージを表示します。 Libraries must be applied by using 'uses' したがって、​`financeDetail.raml`​ ファイルがライブラリであるとすると、次の API 仕様は間違いになります。 #%RAML 1.0 title: ExampleRAML ... /claims: /{claim-id}: patch: body: application/json: type: !include financeDetail.raml 正しくは次のようになります。 #%RAML 1.0 title: ExampleRAML uses: lib: financeDetail.raml /claims: /{claim-id}: patch: body: application/json: type: lib.myType [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*example-validation-error)例の検証時の問題 ### [](#例にプロパティが含まれていない)例にプロパティが含まれていない 例に対象となる型のプロパティが含まれていないと、エディターは違反メッセージを表示します。 should have required property 'property name' 次の API 仕様では、​`age`​ プロパティが例に含まれていません。 #%RAML 1.0 title: Example API Spec types: User: type: object properties: firstName: string lastName: string age: integer example: firstName: John lastName: Smith 例にプロパティを追加するか、または型宣言でプロパティを省略可能として宣言してください。 次のケースでは、プロパティが例に追加されています。 #%RAML 1.0 title: Example API Spec types: User: type: object properties: firstName: string lastName: string age: integer example: firstName: John lastName: Smith age: 49 次のケースでは、プロパティが省略可能として宣言されています。 #%RAML 1.0 title: Example API Spec types: User: type: object properties: firstName: string lastName: string age?: integer example: firstName: John lastName: Smith [\[先頭に戻る\]](#先頭に戻る) ### [](#列挙のデータ型と一致しない列挙値を指定している)列挙のデータ型と一致しない列挙値を指定している エディターは YAML 仕様に従って厳格な解析を行っているため、宣言されているデータ型に値を自動的にはキャストしません。この違反の具体例として、列挙の無効な宣言を示します。 type: string enum: \[1,2,3\] 列挙のデータ型は ​`string`​ ですが、値はすべて整数です。エディターは YAML 仕様に従って厳格な解析を行うため、自動的に整数を ​`string`​ 値にはキャストしません。したがって、このケースでは型の宣言が間違っているため ​`integer`​ に直すか、または列挙値を引用符で囲む必要があります。 次の宣言も無効です。 type: string enum: \[ "a", "b", "c", false, 3.0 \] 値 ​`false`​ は ​`boolean`​ 型ですが、値 ​`3.0`​ は ​`float`​ 型です。エディターはどちらの値も ​`string`​ 値には変換しません。 次の 3 つの宣言は有効です。 type: string enum: \["1","2","3"\] type: integer enum: \[1,2,3\] type: string enum: \[ "a", "b", "c", "false", "3.0" \]
=== この違反は列挙だけではなく、​string​ 値が期待される状況で ​integer​、​nil​、または他のデータ型の値が指定されている場合に発生します。 ===
[\[先頭に戻る\]](#先頭に戻る) ### [](#形式が指定されている場合に数値型の例で型に対して正しくない形式を使用している)形式が指定されている場合に、数値型の例で型に対して正しくない形式を使用している 数値型の例は、​`format`​ ノードで指定されている制限に準拠しなければなりません。この違反の具体例では、数値型 ​`collection`​ の形式として int8 が指定されています。しかしながら、例では 127 を超える値が使用されています。 #%RAML 1.0 title: ExampleRAML types: collection: type: integer format: int8 /search: /code: get: body: application/json: type: collection example: 22342342 [\[先頭に戻る\]](#先頭に戻る) ### [](#additionalproperties-が-false-に設定されている状態で宣言されていないプロパティが例に含まれている)additionalProperties が ​`false`​ に設定されている状態で、宣言されていないプロパティが例に含まれている 型の例に型宣言で記述されていない 1 つまたは複数のプロパティが含まれていると、エディターは次のメッセージを表示します。 should NOT have additional properties たとえば、次の API 仕様に対してエディターはこのメッセージを表示します。 #%RAML 1.0 title: Example API Spec types: User: type: object additionalProperties: false properties: firstName: string lastName: string example: firstName: John lastName: Smith age: 49 この問題の解決法は 3 つあります。 - 例から余分なプロパティを削除する #%RAML 1.0 title: Example API Spec types: User: type: object additionalProperties: false properties: firstName: string lastName: string example: firstName: John lastName: Smith - 型宣言にプロパティを追加する。 #%RAML 1.0 title: Example API Spec types: User: type: object additionalProperties: false properties: firstName: string lastName: string age: integer example: firstName: John lastName: Smith age: 49 - `additionalProperties`​ の値を ​`true`​ に変更するか、または ​`additionalProperties`​ の行を削除する (​`additionalProperties`​ はデフォルトで ​`true`​ であるため)。 #%RAML 1.0 title: Example API Spec types: User: type: object properties: firstName: string lastName: string additionalProperties: true example: firstName: John lastName: Smith age: 49 [\[先頭に戻る\]](#先頭に戻る) ### [](#ペイロードで-nil-として定義されている型は無効)ペイロードで ​`nil`​ として定義されている型は無効 データ型が ​`nil`​ の型はペイロードで使用できません。 #### [](#例-1)例 1 次の例では、​`type`​ の値は ​`nil`​ ではなく ​`string`​ にする必要があります。 ```none #%RAML 1.0 title: test types: MyType: type: nil example: “test” ``` #### [](#例-2)例 2 次の例では、JSON スキーマで ​`MyType`​ を ​`string`​ として定義する必要があります。ただし、スキーマは空になります。 ```none #%RAML 1.0 title: test types: MyType: type: !include schema.json # schema.json is an empty file example: “test” ``` このような場合のエラーメッセージは ​`should be null at …​`​ になります。 [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*WebAPI-name-minLength)`title`​ ノードの値がない `title`​ ノードでは、次のように値を省略することはできません。 #%RAML 1.0 title: [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*unused-base-uri-parameter)使用されない URI パラメーターを宣言している API 仕様で宣言した URI パラメーターが仕様内で使用されていない場合、エディターは次のメッセージを表示します。 unused uri parameter “parameter” ベース URI パラメーターとして宣言されているパラメーターが使用されていない場合は、エディターは次の警告メッセージを表示します。 unused base uri parameter “parameter” たとえば、次の API 仕様により 2 つの警告メッセージが表示されます。 unused uri parameter "unusedParam" unused base uri parameter "unusedUriParam" #%RAML 1.0 title: test baseUri: http://param.raml/a/{baseUriParam1}/{nonExists}/{baseUriParam2} baseUriParameters: baseUriParam1: type: string baseUriParam2: type: string unusedParam: type: string /endpoint/{uriParam1}/{nonExistsUri}: uriParameters: uriParam1: type: string unusedUriParam: type: string 警告メッセージは、単純にこれらのパラメーターを宣言している行を削除するだけで表示されなくなります。 #%RAML 1.0 title: test baseUri: http://param.raml/a/{baseUriParam1}/{nonExists}/{baseUriParam2} baseUriParameters: baseUriParam1: type: string baseUriParam2: type: string /endpoint/{uriParam1}/{nonExistsUri}: uriParameters: uriParam1: type: string [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*Payload-mediaType-minCount)ペイロードのメディア種別を宣言していない ペイロードの宣言でメディア種別が宣言されていないと、エディターは次のメッセージを表示します。 Payload media type is mandatory たとえば、次の API 仕様に対してエディターはこのメッセージを表示します。 #%RAML 1.0 title: Example API Spec /media: get: responses: 200: body: type: string この問題の解決法は 2 つあります。 - ペイロード宣言でメディア種別をローカルに宣言する。 #%RAML 1.0 title: Example API Spec /media: get: responses: 200: body: application/json: type: string - API 仕様でデフォルトのメディア種別をグローバルに指定する。 #%RAML 1.0 title: Example API Spec mediaType: application/json /media: get: responses: 200: body: type: string 次の例では、グローバル宣言とローカル宣言の両方を使用しています。このケースでは、​`mediaType`​ ノードは ​`application/json`​ と ​`application/xml`​ を受け入れ可能なメディア種別として定義しています。最初の種別である ​`Person`​ は、どちらのメディア種別であっても構わずに本文を返します。2 番目の種別である ​`Another`​ は、ローカル宣言でグローバル宣言を上書きし、JSON の本文のみを返します。 #%RAML 1.0 title: New API mediaType: \[ application/json, application/xml \] types: Person: Another: /list: get: responses: 200: body: Person\[\] /send: post: body: application/json: type: Another [\[先頭に戻る\]](#先頭に戻る) ## [](#include-タグを使用してフラグメントを参照していない)`!include`​ タグを使用してフラグメントを参照していない API 仕様で ​`uses`​ キーを使用してフラグメントを参照していると、エディターは次のメッセージを表示します。 Fragments must be imported by using '!include' [\[先頭に戻る\]](#先頭に戻る) ## [](#uses-キーを使用してライブラリを適用していない)`uses`​ キーを使用してライブラリを適用していない API 仕様で ​`!include`​ タグを使用してライブラリを適用していると、エディターは次のメッセージを表示します。 Libraries must be applied by using 'uses' [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*syaml-error)構文の問題 ### [](#応答例に無効な-json-が含まれている)応答例に無効な JSON が含まれている 応答メッセージの例として JSON ファイルが含まれている場合、ファイルの JSON は有効でなければなりません。次の違反のケースでは、応答コード 200 の応答例に ​`!include`​ ステートメントが含まれています。また、含まれているファイルの JSON では、最後のキー/値ペアの最後にカンマがあります。 #%RAML 1.0 title: ExampleRAML ... /resume: description: "Gets candidate's resume." get: queryParameters: ... headers: ... responses: 200: body: application/json: example: !include exampleResumeData-200.json 500: ... { ... "assessments.characteristic.focusofattention.data"= "", } [\[先頭に戻る\]](#先頭に戻る) ### [](#ファセットが-yaml-マップを必要としている場合に-yaml-マップを提供していない)ファセットが YAML マップを必要としている場合に YAML マップを提供していない 値としてマップが必要であるとして RAML 1.0 仕様でファセットが記述されており、API 仕様でマップが提供されていない場合、エディターはメッセージ「​`YAML map expected`​」を返します。 次に、エラーの例を示します。 #%RAML 1.0 title: Test version: 1.0 securitySchemes: basic: type: Basic Authentication settings: エラーの修正方法は 2 つあります。 - マップを値として提供する。 #%RAML 1.0 title: Test version: 1.0 securitySchemes: basic: type: Basic Authentication settings: requestTokenUri: https://api.mysampleapi.com/1/oauth/request\_token - マップを必要とするファセット (この場合は ​`settings`​) を削除する。 #%RAML 1.0 title: Test version: 1.0 securitySchemes: basic: type: Basic Authentication [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*unresolved-reference)使用する型を定義していない 使用する型を最初に定義していない場合、エディターはメッセージ「​`Unresolved reference`​」を返します。 このエラーの例では、型 ​`mytype`​ が定義されていません。 #%RAML 1.0 title: test /path: post: responses: 200: body: application/json: type: mytype この問題を解決するには、使用する型を定義します。 #%RAML 1.0 title: test types: mytype: string /path: post: responses: 200: body: application/json: type: mytype [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*closed-shape)サポートされないプロパティを使用している このエラーが発生するのは、特定のプロパティセットを持つとしてファセットまたはデータ型が定義されており、API 仕様でそのセットにないプロパティでファセットが定義されている場合です。このエラーは未定義のファセットを使用した場合も発生する可能性があります。 エラーメッセージの例: \* `Property minimum not supported in a RAML 1.0 stringScalarShape node`​。​`minimum`​ は、サポートされていないプロパティの名前です。​`string`​ に最小値はありません。 \* `Property invalidfacet not supported in a RAML 0.8 webApi node`​。​`invalidfacet`​ は、RAML 仕様で定義されていないファセットの名前です。 このエラーが生成される例を次に示します。
Table 1. 間違った例と正しい例
間違い 正しい
#%RAML 1.0
title: Test
types:
  top:
    type: string
    minimum: 1
#%RAML 1.0
title: Test
types:
  top:
    type: string
    minLength: 1
間違い 正しい
#%RAML 1.0
title: Test
invalidfacet:
version:
#%RAML 1.0
title: Test
version:
間違い 正しい
#%RAML 1.0
title: Test
types:
  Prop:
    type: string
    required: false

  Obj:
    type: object
    properties:
      prop:
        type: Prop
#%RAML 1.0
title: Test
types:
  Prop:
    type: string

  Obj:
    type: object
    properties:
      prop:
        type: Prop
        required: false
[\[先頭に戻る\]](#先頭に戻る) ## [](#resolution\*invalid-type-inheritance)無効な型の継承 type-inheritance エラーは主に、2 つの型を間違った方法でマージしている場合とサブタイプで弱い制約を定義している場合に発生します。 ### [](#2-つの型を間違った方法でマージしている)2 つの型を間違った方法でマージしている この種類のエラーは、次のいずれかのアクションを実行しようとした場合に発生します。 - 定義済みの型を未定義の型とマージする - 2 つの未定義の型をマージする また、誤った構文でマージを実行しようとした場合もこのエラーが発生します。 エラーメッセージの例 `Resolution error: Incompatible types [class amf.plugins.domain.shapes.models.ScalarShape, class amf.plugins.domain.shapes.models.NodeShape]` 次の例は 2 つの未定義の型をマージしようとしており、間違ったマージ構文を使用しています。エラーを解決するには、マージの前に型を定義し、マージ構文で括弧やカンマではなくパイプを使用します。
Table 2. 間違った例と正しい例
間違い 正しい
#%RAML 1.0
title: test
types:
  Device:
    type: [ Phone , Notebook ]
  Phone: string
  Notebook:
    type: object
    properties:
      manufacturer:
        type: string
#%RAML 1.0
title: test
types:
  Phone: string
  Notebook:
    type: object
    properties:
      manufacturer:
        type: string
  Device:
    type: Phone | Notebook
[\[先頭に戻る\]](#先頭に戻る) ### [](#サブタイプで弱い制約を定義している)サブタイプで弱い制約を定義している 親型で定義されている制約よりも弱い制約を定義しているサブタイプは無効です。 次の例では、親型 MyType1 ですでに ​`name`​ プロパティが必須として定義されているにもかかわらず、サブタイプ MyType2 で省略可能なプロパティ ​`name`​ が文字列として定義されています。 ```none #%RAML 1.0 title: test types: MyType1: properties: name: string MyType2: type: MyType1 properties: name?: string #invalid ``` このような場合のエラーメッセージは ​`Resolution error: sub type has a weaker constraint for minItems than base type for minItems.`​ になります。 [\[先頭に戻る\]](#先頭に戻る) ## [](#parser\*unresolved-parameter)未定義の型をヘッダーで宣言している このエラーは、存在しない型がヘッダーで指定されている場合に発生します。エラーを修正するには、RAML 仕様で定義された型を指定します。 エラーメッセージ `Cannot declare unresolved parameter` 次の間違った例では、ヘッダー ​`myHeader`​ の値に入力ミスがあります。​`someType`​ ではなく ​`someTypo`​ と指定されています。
Table 3. 間違った例と正しい例
間違い 正しい
#%RAML 1.0
title: test
types:
  SomeType: string
/endpoint:
  post:
    headers:
      MyHeader: someTypo
#%RAML 1.0
title: test
types:
  SomeType: string
/endpoint:
  post:
    headers:
      MyHeader: someType
[\[先頭に戻る\]](#先頭に戻る) ## [](#uri-パラメーターでスラッシュを使用している)URI パラメーターでスラッシュを使用している スラッシュ (/) が含まれている URI パラメーターは無効です。 次の例では、URI パラメーター ​`transaction-Date`​ の ​`example`​ が原因でパーサーにエラーメッセージが表示されます。 ```none #%RAML 1.0 title: test /endpoint: uriParameters: transaction-Date: example: 01/02/2018 ``` このような場合のエラーメッセージは ​`Value '01/02/2018' of uri parameter must not contain '/' character.`​ になります。 [\[先頭に戻る\]](#先頭に戻る) ## [](#datetime-型の形式が無効)`datetime`​ 型の形式が無効 「rfc3339」または「rfc2616」が使用されていない ​`datetime`​ 型の形式は無効です。 次の例では、パーサーにエラーメッセージが表示されます。 ```none #%RAML 1.0 title: test types: MyType: type: datetime format: "rfc3338" ``` このような場合のエラーメッセージは ​`Invalid format value for datetime, must be ‘rfc3339’ or ‘rfc2616’.`​ になります。 [\[先頭に戻る\]](#先頭に戻る) ## [](#raml-フラグメントプロジェクトの絶対パス)RAML フラグメントプロジェクトの絶対パス `(!include /examples/200.json)`​ のように、RAML フラグメントプロジェクトの絶対パスを使用して連動関係を追加すると、​`「Resource /examples/200.json not found (リソース /examples/200.json が見つかりません)」`​という検証エラーが発生します。 `(!include ../examples/200.json)`​ のように、必ず RAML フラグメントプロジェクトの相対パスを使用する必要があります。 [\[先頭に戻る\]](#先頭に戻る) # RAML 1.0 での例の定義に関するガイド RAML 1.0 API 仕様内の型、特性、およびリソース種別の例を外部ファイルで定義する場合、次のルールに従います。 - 1 つの例の場合、​`example`​ ファセットを使用して yaml ファイルを含めるか、​`examples`​ ファセットを使用して .raml NamedExample フラグメントファイルを含めます。 - 複数の例の場合、必ず ​`examples`​ ファセットを使用して、次のいずれかの操作を行います。 - それぞれで個々の.yaml ファイルを参照する複数の例を定義する (ファイルごとに 1 つの例が含まれる) - 1 つの NamedExample フラグメントで定義された 2 つ以上の例のある raml ファイルを含める ## [](#yaml-ファイルにある-1-つの例の使用).yaml ファイルにある 1 つの例の使用 仕様で、​`example`​ ファセットを使用してファイルを含めます 。yaml ファイルで、例がルートレベルにあることを確認します。 次の api.raml および fragment.yaml ファイルは、.yaml ファイルにある 1 つの例を使用する正しい方法を示しています。 api.raml #%RAML 1.0 title: test types: A: properties: givenName: string familyName: string example: !include fragment.yaml fragment.yaml givenName: ”Chiaki” familyName: "Mukai" ## [](#raml-namedexample-フラグメントファイルにある-1-つの例の使用).raml NamedExample フラグメントファイルにある 1 つの例の使用 仕様で、​`example`​ ファセットを使用してファイルを含めます。NamedExample フラグメントで、例がファイルのルートレベルにないことを確認します。フラグメントには、例の名前であるキーが含まれている必要があります。 次の api.raml および fragment.raml ファイルは、.raml ファイルにある 1 つの例を使用する正しい方法を示しています。 api.raml #%RAML 1.0 title: test types: A: properties: givenName: string familyName: string examples: !include fragment.raml fragment.raml #%RAML 1.0 NamedExample fullName: givenName: ”Chiaki” familyName: "Mukai" 次のようなフラグメントは使用しないでください。 fragment.raml #%RAML 1.0 NamedExample givenName: ”Chiaki” familyName: "Mukai" この場合、API Designer ではヘッダーが無視されて例が使用されますが、他の RAML プロセッサーと、1 つの例のみが定義されている NamedExample フラグメントを使用して仕様を検証する場合、RAML 1.0 仕様に従ってエラーが生成されます。 ## [](#yaml-ファイルにある-2-つの例の命名).yaml ファイルにある 2 つの例の命名 仕様で、​`examples`​ ファセットを使用してファイルを含め、各例に名前を付けます 。yaml ファイルで、例がルートレベルにあることを確認します。 次の api.raml、fragment1.yaml、fragment2.yaml ファイルは、.yaml ファイルにある 2 つの例を使用する正しい方法を示しています。 api.raml #%RAML 1.0 title: test types: A: properties: givenName: string familyName: string examples: fullName: !include fragment1.yaml otherFullName: !include fragment2.yaml fragment1.yaml givenName: ”Chiaki” familyName: "Mukai" fragment2.yaml givenName: "Kyung-won" familyName: "Park" ## [](#namedexample-フラグメントにある-2-つの例の命名)NamedExample フラグメントにある 2 つの例の命名 仕様で、​`examples`​ ファセットを使用してファイルを含めます。NamedExample フラグメントで、どの例もファイルのルートレベルにないことを確認します。フラグメントには、例の各名前である 2 つのキーが含まれている必要があります。 次の api.raml および fragment.raml ファイルは、.raml ファイルにある 2 つの例を使用する正しい方法を示しています。 api.raml #%RAML 1.0 title: test types: A: properties: givenName: string familyName: string examples: !include fragment.raml fragment.raml #%RAML 1.0 NamedExample fullName: givenName: ”Chiaki” familyName: "Mukai" otherFullName: givenName: "Kyung-won" familyName: "Park" # RAML 1.0 仕様として OAS 3.0 API 仕様を共有する OAS 3.0 API 仕様は、Anypoint Exchange で RAML API 仕様として共有できます。その後、他の開発者は RAML バージョンをダウンロードして、Anypoint Studio やサードパーティ IDE で使用したり、API Manager で実装したりできます。 1. OAS 3.0 API 仕様を API Designer にインポートします。 2. **\[Files (ファイル)\]**​ ペインでファイル名の横にある 3 つのドットをクリックして ​**\[Duplicate (複製)\]**​ を選択します。 3. **\[Duplicate As (形式を指定して複製)\]**​ ダイアログで、​**\[RAML\]**​ を選択します。 4. プロジェクトのルートファイルを API 仕様の RAML バージョンに設定します。 5. プロジェクトを Anypoint Exchange にパブリッシュします。

OAS 2 で OAS 3.0 仕様を共有する場合、API Designer から OAS 3.0 仕様をそのままダウンロードし、APIMatic トランスフォーマーなどのツールを使用して OAS 2.0 に変換します。

# Studio または Flow Designer で作業するユーザーとのコラボレーション:page-support-status: eolScheduled Mule アプリケーションを設計しているときに、Anypoint Studio で作業している Anypoint Platform 組織の他のユーザー (開発者など) や、他の Anypoint Platform 組織で Flow Designer にアクセスできるユーザーからのサポートが必要になる場合があります。プロジェクトを Flow Designer から JAR ファイルとしてエクスポートして、その相手と JAR ファイルを共有できます。相手は、その JAR ファイルをプロジェクトとして Studio または Flow Designer にインポートできます。 エクスポートされる JAR ファイルには、ユーザー名、パスワード、セキュリティトークンなどの重要な接続情報は含まれません。そのため、受け取った側は、ファイルをプロジェクトとして Studio または Flow Designer にインポートした後で、アプリケーション内のコネクタで使用するすべての設定に接続情報を追加する必要があります。 他のユーザーがプロジェクトに対して作業を行うと、変更が Flow Designer 内のプロジェクトにオンラインで適用されます。他のユーザーが作業を終了したら、プロジェクトを Flow Designer で開き、他のユーザーが中断した場所を選択できます。 ## [](#flow-designer-でプロジェクトをエクスポートするための手順)Flow Designer でプロジェクトをエクスポートするための手順 Flow Designer で、以下の手順に従ってプロジェクトを JAR ファイルとしてエクスポートします。 1. プロジェクトにエラーがないことを確認します。 2. キャンバスの右上隅にある 3 つのドットをクリックし、​**\[Export (エクスポート)\]**​ を選択してプロジェクトをエクスポートします。 **\[Export (エクスポート)\]**​ オプションは、キャンバスの右上隅にあります。 ![「Exported (エクスポート)」 オプションの場所](/mulesoft/current/ja-jp/design-center/_images/fd-location-of-export-option.png)
13 つのドットは、下矢印の表示ラベルが付いたボタンの右側にあります。
2[Export (エクスポート)]​ オプションはメニューの一番下にあります。
1. プロジェクトのソースファイルのみを共有するように ​**\[Export project sources (プロジェクトソースをエクスポート)\]**​ を選択し、​**\[Export (エクスポート)\]**​ をクリックします。 Mule アプリケーションプロジェクトのコピーが含まれる JAR ファイルがコンピューターのデフォルトの場所にダウンロードされます。 ## [](#anypoint-studio-でプロジェクトをインポートするための手順)Anypoint Studio でプロジェクトをインポートするための手順 共有相手が Anypoint Studio を使用している場合は、その相手に提供する JAR ファイルを作成し、アプリケーションの実行に必要なすべての接続情報を提供してから、以下の手順を実行するように依頼してください。 1. **\[Preferences (プリファレンス)\]**​ > ​**\[Anypoint Studio\]**​ > ​**\[Authentication (認証)\]**​ を選択し、Studio が Anypoint Platform の組織にアクセスできるようにします。 2. **\[File (ファイル)\]**​ > ​**\[Import (インポート)\]**​ を選択し、​**\[Anypoint Studio\]**​ > ​**\[Packaged Mule Application (.jar) (パッケージ化された Mule アプリケーション (.jar))\]**​ を選択して、JAR ファイルを Studio インポートします。 Studio でプロジェクトが開きます。 3. プロジェクトでファイル ​`src/main/resources/mule-artifact.properties`​ を開き、接続情報に関連するキーの値を入力します。 4. `src/main/resources/mule-artifact.properties`​ を保存します。 ## [](#flow-designer-からエクスポートされたプロジェクトをインポートするために-flow-designer-で実行する手順)Flow Designer からエクスポートされたプロジェクトをインポートするために Flow Designer で実行する手順 共有相手が別の Anypoint Platform 組織で Flow Designer を使用している場合は、その相手に提供する JAR ファイルを作成し、アプリケーションの実行に必要なすべての接続情報を提供してから、以下の手順を実行するように依頼してください。 1. Design Center を開き、​**\[Create New (新規作成)\]**​ をクリックし、​**\[Create a Mule Application (Mule アプリケーションの作成)\]**​ の下にある ​**\[Import Application (アプリケーションをインポート)\]**​ をクリックして、Flow Designer で新しい Mule アプリケーションプロジェクトを作成します。 2. **\[Import Application (アプリケーションをインポート)\]**​ ダイアログで JAR ファイルを選択して ​**\[Import (インポート)\]**​ をクリックします。 3. プロジェクトのコネクタが使用する設定に接続情報を追加します。 Flow Designer でプロジェクトを開くと、コネクタを表す各カードの右上隅に赤の円が表示されます。Flow Designer が JAR ファイルに含めなかった接続情報を追加する必要があります。 1. キャンバスの左側にある ​**\[Project (プロジェクト)\]**​ ペインで ​**\[Reusable Configurations (再利用可能な設定)\]**​ を展開します。 コネクタで使用されているすべての設定が赤の円でマークされています。 ![fd location of red circles on configs](/mulesoft/current/ja-jp/design-center/_images/fd-location-of-red-circles-on-configs.png)
1[プロジェクト (プロジェクト)]​ ペインを開くためにクリックするアイコン。
2フローにエラーがあることを示す赤の円。プロジェクト内の設定には接続情報が含まれていないため、コネクタを含む各フローの横に赤の円が表示されます。
3プロジェクトのコネクタとコアコンポーネントが使用している設定の一覧を示す ​[Reusable Configurations (再利用可能な設定)]​ セクション。
4リストされている設定の横にある赤の円。
1. 設定をクリックします。 2. ダイアログが開いたら、設定で使用されている接続の 3 つのドットをクリックして、​**\[Edit (編集)\]**​ を選択します。 設定で使用されている接続とは、Flow Designer がダイアログを開いたときに選択されていた選択です。 3. 必要な接続情報を指定します。 4. 赤の円でマークされている各設定に対して上記の 3 つの手順を繰り返します。

Anypoint Studio からエクスポートされた JAR ファイルは、Flow Designer にインポートしないでください。Flow Designer は、Anypoint Studio でサポートされる Mule アプリケーションのすべての機能をサポートしているわけではありません。

## [](#関連情報)関連情報 - [Flow Designer でのトラブルシューティング](https://docs.mulesoft.com/jp/design-center/fd-troubleshooting) - [MuleSoft ヘルプセンター](https://help.mulesoft.com) # Transform カードツアー (Flow Designer):page-support-status: eolScheduled Transform カードには、データのマッピングを容易にするためのさまざまな機能が含まれます。 ## [](#transform-カードの静的機能)Transform カードの静的機能 Transform カードには、​**\[Configuration (設定)\]**​、​**\[Input (入力)\]**​、​**\[Output (出力)\]**​、​**\[Notes (メモ)\]**​ の 4 つのセクションがあります。\[Configuration (設定)\] セクション以外の 3 つのセクションはすべてのカードで共通です。​**\[Notes (メモ)\]**​ セクションは、Transform カードで実行した作業を説明したり、このアプリケーションをテンプレートとして使用する可能性がある他のユーザー向けに手順を記述したりするのに非常に便利ですが、このカードの ​**\[Input (入力)\]**​ セクションと ​**\[Output (出力)\]**​ セクションは使用しません。 ![fd tour of the transform card static](/mulesoft/current/ja-jp/design-center/_images/fd-tour-of-the-transform-card-static.png) Figure 1. **\[Configuration (設定)\]**​ セクションのどのペインが開いているかにかかわらず、常に表示されている Transform カードの機能 1. カードの種別と名前。他のカードと同様に、カードの名前をデフォルト名 ​`DataWeave`​ から目的に合った任意の名前に変更できます。 2. このバナーは、Flow Designer にマッピング提案があるかどうかを示します。提案がある場合、バナーは次のように表示されます。 ![fd automapper banner true](/mulesoft/current/ja-jp/design-center/_images/fd-automapper-banner-true.png) Flow Designer でどのような場合にマッピング提案が作成されるかについての詳細は、​[「変換用のデータ型のマッピングに関する推奨事項の入手」](https://docs.mulesoft.com/jp/design-center/get-mapping-recommendations)​を参照してください。 3. **\[Input (入力)\]**​ ペインには、前のカードからの出力が表示されます。Transform カードには、出力の 3 つの部分 (ペイロード、属性、変数) が表示されます。ペイロードが 1 つのシンプルデータ型ではない場合、ペイロードで使用するデータ型を指定する必要がある場合があります。同じ操作を属性、変数、またはその両方でも実行しなければならない場合があります。 サポートされるシンプルデータ型 Boolean、Date、DateTime、Integer、Number、String サポートされる他のデータ型 CSV、JSON、Object、XML データ型を指定するには、​`payload`​ または ​`vars`​ の右にある 3 つのドットをクリックして、​**\[Data Type Actions (データ型のアクション)\]**​ メニューを開きます。 ![fd transform payload menu](/mulesoft/current/ja-jp/design-center/_images/fd-transform-payload-menu.png) Figure 2. **\[Input (入力)\]**​ ペイン内にあるペイロード、属性、および変数のデータ型を設定するためのメニュー 必要なデータ型を作成するか、すでに作成している場合はそれを選択できます。詳細は、​[データ型](https://docs.mulesoft.com/jp/design-center/about-data-types)​についての説明を参照してください。 4. ここでは、Transform カードのセクション名をクリックしてセクションを切り替えることができます。(​**\[Notes (メモ)\]**​ セクションの名前は画像には表示されていません)。 5. ここでは、​**\[Configuration (設定)\]**​ セクションのペインを切り替えることができます。画像では、​**\[Mappings (マッピング)\]**​ ペインが選択され、開かれています。 6. **\[Preview (プレビュー)\]**​ ペインには、Transform カードの出力のプレビューが表示されます。プレビューを表示できるようにするには、Transform カードの入力を出力にマップする必要があります。使用可能なプレビューがまだない場合、ペインは次のように表示されます。 ![fd empty preview pane](/mulesoft/current/ja-jp/design-center/_images/fd-empty-preview-pane.png) ## [](#mappings-マッピング-ペイン)**\[Mappings (マッピング)\]**​ ペイン このペインでは、データをマップするための 1 つの方法が提供されます。​**\[Input (入力)\]**​ ペインの要素を ​**\[Output (出力)\]**​ ペインの要素にドラッグできます。 ![fd tour of the transform card](/mulesoft/current/ja-jp/design-center/_images/fd-tour-of-the-transform-card.png) Figure 3. Transform カードの ​**\[Configuration (設定)\]**​ セクションの ​**\[Mappings (マッピング)\]**​ ペイン 1. **\[Output (出力)\]**​ ペインには、Transform カードの出力のペイロードに含まれ、フロー内の次のカードに渡される要素が表示されます。通常、Flow Designer は、フロー内の次のカードで必要とされるデータ構造を検出することで、このペインに入力します。 入力の要素へのマッピングでは取得できないデータが出力のいずれかの要素で必要とされる場合、そのデータを文字列、数値、または DataWeave 式で指定できます。要素をダブルクリックすると、要素の値を編集するための次の小さなダイアログが開きます。 ![fd output expression dialog](/mulesoft/current/ja-jp/design-center/_images/fd-output-expression-dialog.png) Figure 4. 出力の要素をダブルクリックすると開くダイアログ デフォルトでは、値は ​`null`​ です。必要な値をダイアログに直接入力して指定できます。 ![fd output expression dialog number](/mulesoft/current/ja-jp/design-center/_images/fd-output-expression-dialog-number.png) Figure 5. 電話番号への値の変更 **\[OK\]**​ をクリックすると、​`f(x)`​ 記号とゴミ箱アイコンの両方が要素の左に表示されます。​`f(x)`​ 記号は、値が文字列、数値、または DataWeave 式に手動で設定されたことを示します。ゴミ箱アイコンをクリックすると、値は削除されますが、要素は削除されません。 ![fd output expression dialog fx](/mulesoft/current/ja-jp/design-center/_images/fd-output-expression-dialog-fx.png) フロー内の次のカードで必要とされるデータ構造を Flow Designer で検出できない場合、​**\[Output (出力)\]**​ ペインは次のように表示されます。 ![fd output pane empty](/mulesoft/current/ja-jp/design-center/_images/fd-output-pane-empty.png) Figure 6. Transform カードの後のカードで必要とされるデータ型を Flow Designer で検出できない場合の ​**\[Output (出力)\]**​ ペイン ペイロードで使用するデータ型を作成または指定できます。 2. この領域では、Transform カードへの入力のどの要素が出力のどの要素にマップされているかが示されます。複数の要素を一緒にマップする場合、入力の 1 つの要素をクリックして出力の 1 つの要素にドラッグします。あるいは、要素をマップする DataWeave スクリプトを作成することもできます。これは ​**\[Script (スクリプト)\]**​ ペインで行うことができます。 ## [](#script-スクリプト-ペイン)**\[Script (スクリプト)\]**​ ペイン **\[Mappings (マッピング)\]**​ ペインでマップすると、Transform カードは、対応する DataWeave スクリプトをこのペインに生成します。DataWeave スクリプトの知識があれば、マッピングをカスタマイズできます。​**\[Mappings (マッピング)\]**​ ペインの使用をスキップして、代わりに独自の DataWeave スクリプトを記述することもできます。DataWeave についての詳細は、​[「DataWeave 言語」](#4.2@mule-runtime::dataweave.adoc)​を参照してください。 ![fd tour of the transform card script](/mulesoft/current/ja-jp/design-center/_images/fd-tour-of-the-transform-card-script.png) Figure 7. Transform カードの ​**\[Configuration (設定)\]**​ セクションの ​**\[Script (スクリプト)\]**​ ペイン ## [](#sample-data-サンプルデータ-ペイン)**\[Sample Data (サンプルデータ)\]**​ ペイン 次の 3 つの条件に該当する場合、このペインを使用して、前のカードの出力で使用されるデータ型の使用例を提供できます。 - Transform カードの出力のプレビューを表示する。 - 前のカードの出力で使用されるデータ型がシンプル型ではない。シンプル型は String、Number、Integer、Boolean、Date、DateTime です。 - 前のカードの出力で使用されるデータ型が例ではなくスキーマで定義されている。 ![fd tour of the transform card sample](/mulesoft/current/ja-jp/design-center/_images/fd-tour-of-the-transform-card-sample.png) Figure 8. Transform カードの ​**\[Configuration (設定)\]**​ セクションの ​**\[Sample data (サンプルデータ)\]**​ ペイン ## [](#関連情報)関連情報 - [カードの出力を次のカードの必須入力にマップ](https://docs.mulesoft.com/jp/design-center/fd-transform) - [Transform カードを使用したマッピングの例](https://docs.mulesoft.com/jp/design-center/fd-mapping-examples) - [変換用のデータ型のマッピングに関する推奨事項の入手](https://docs.mulesoft.com/jp/design-center/get-mapping-recommendations) # Transform カードを使用したマッピングの例 (Flow Designer):page-support-status: eolScheduled チュートリアル​[「Flow Designer での最初の Mule アプリケーションの作成」](https://docs.mulesoft.com/jp/design-center/salesforce-to-twilio)​の手順を実行したユーザーは、すでに 2 回のマッピングを行っています。この両方のマッピングをもう一度見てみましょう。 ## [](#最初の例)最初の例 初回は、Choice カードの出力を、NTO Order API で必要とされる入力にマップする必要がありました。
Table 1. Choice カードで出力されるデータ型と NTO Order API で必要とされるデータ型
Choice カードで出力されるデータ型 NTO Order API で入力として必要とされるデータ型
Product Information (製品情報) データ型
[
  {
    "productID": string,
    "category": string,
    "SKU": string,
    "productName": string,
    "inventory": string
  }
]
Salesforce Opportunity (Salesforce 商談) データ型
{
  "Amount": number,
  "Id": string,
  "CloseDate": string,
  "Name": string
}
Order Information (注文情報) データ型
{
  "OppId": string,
  "OrderAmount": number,
  "orderdate": string,
  "productInfo": {
     "productID": string,
     "category": string,
     "SKU": string,
     "productName": string,
     "inventory": number
     }
}
マッピングを行うため、Transform カードを使用して、​**\[Input (入力)\]**​ 側の要素をクリックして ​**\[Output (出力)\]**​ 側の要素にドラッグしました。(Transform カードの「入力」と「出力」は Transform カード自体を基準とする相対的な用語です。Transform カードへの「入力」は Choice カードの出力であり、Transform カードの「出力」は Order API への入力です)。 ![transform first final](/mulesoft/current/ja-jp/design-center/_images/transform-first-final.png) Figure 1. Choice カードの出力を、API で必要とされる入力にマップする Transform カード Order API (POST メッセージの送信先の REST API) は Choice カードの出力に含まれる一部のデータを必要としなかったため、マッピングを行う必要がありました。また、API で必要とされるデータの一部の要素の名前が、Choice カードの出力内の対応する要素とは異っていました。
Table 2. Choice カードのデータを Order API のデータにマッピングするための要件
Choice カードの要素 マップ先の Order API の要素

productID

productID​

category

category​

SKU

SKU​

productName

productName​

inventory

inventory​

Amount

OrderAmount​

Id

OppId​

CloseDate

orderDate​

## [](#2-番目の例)2 番目の例 チュートリアルの 2 回目のマッピングでは、Twilio カードの入力に対してデータ型を明示的に設定する必要はありませんでした。Twilio カードで必要とされるデータ構造を Transform カードで判別することができました。また、データ要素もマップしませんでした。代わりに、Transform カードの出力で DataWeave スクリプトを使用して、Transform カードの入力から、顧客に送信するメッセージにデータを取り込みました。また、​`To`​ および ​`From`​ 項目の値を特定の電話番号に明示的に設定しました。これは、Transform カードの ​**\[Script (スクリプト)\]**​ ペインで確認できます。 ![transform second script panel](/mulesoft/current/ja-jp/design-center/_images/transform-second-script-panel.png) Figure 2. Transformation カードへの入力のデータを使用する DataWeave スクリプトと、​`To`​ および ​`From`​ 項目の電話番号が示されている Transform カードの ​**\[Script (スクリプト)\]**​ ペイン **\[Mappings (マッピング)\]**​ ペインには次のビューが表示されました。 ![transform second mappings panel](/mulesoft/current/ja-jp/design-center/_images/transform-second-mappings-panel.png) Figure 3. マッピングのビューが表示されている Transform カードの ​**\[Mappings (マッピング)\]**​ ペイン 出力ペイロードの 3 つの項目に付けられた ​`f(x)`​ マーカーは、これらの項目に、文字列または DataWeave 式を介して提供された値が入力されていることを示します。入力ペイロードの ​`OrderID`​、​`TrackingNo`​、および ​`ETA`​ が出力ペイロードの ​`Body`​ にすべてマップされています。これは、​`Body`​ のスクリプトがこの 3 つのペイロード要素を参照するためです。 ## [](#関連情報)関連情報 - [カードの出力を次のカードの必須入力にマップ](https://docs.mulesoft.com/jp/design-center/fd-transform) - [Transform カードツアー](https://docs.mulesoft.com/jp/design-center/fd-tour-transform-card) - [変換用のデータ型のマッピングに関する推奨事項の入手](https://docs.mulesoft.com/jp/design-center/get-mapping-recommendations) # Try を使用したエラーの処理 (Flow Designer):page-support-status: eolScheduled エラーを起こしやすいフロー部分は Try 内に配置できます。Try 内のフロー部分でエラーが発生すると、Try はエラーをキャッチして修正を適用するか、または代替コードを実行します。エラーは種別によって異なる方法で処理できます。 Try 内にコネクタコンポーネントを配置した場合は、エラーの発生時の処理を制御でき、エラーメッセージの送信や修正の実行など、フロー内で実行できる処理であれば何でも指定できます。 1. フローに Try を追加します。 ![error handling task design center eff90](/mulesoft/current/ja-jp/design-center/_images/error-handling-task-design-center-eff90.png) 2. Try 内で ​![「add to Try (Try に追加)」](/mulesoft/current/ja-jp/design-center/_images/arrange-cards-flow-design-center-e256e.png)​ をクリックします。 3. コンポーネント (Database Insert 操作など) を追加して設定します。 4. Type の値を設定します。値を入力するか、または Try 内のコンポーネントで発生しうるすべてのエラーのリストから選択します。 5. エラー種別の右側にある ​![「add to Try (Try に追加)」](/mulesoft/current/ja-jp/design-center/_images/arrange-cards-flow-design-center-e256e.png)​ をクリックしてコンポーネントを追加します。これらのコンポーネントは、特定のエラーが発生した場合に実行されます。 ## [](#エラー種別を追加する)エラー種別を追加する 1. 既存の Try スコープ内で \[Options (オプション)\] をクリックします。 2. 新しいエラー種別を追加するには、\[Add Above (上に追加)\] または \[Add Below (下に追加)\] をクリックします。 ![try options](/mulesoft/current/ja-jp/design-center/_images/try-options.png) エラー条件は上から下へと評価され、最初に一致した条件のみが考慮されます。エラー種別の ​`ANY`​ を追加する場合は、必ず最後に追加してください。 3. Try にエラー種別とコンポーネントを追加します。 ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/mule-runtime/latest/about-components) - [Try スコープについて](#4.1@mule-runtime::try-scope-concept.adoc) - [エラー処理](#4.1@mule-runtime::error-handling.adoc) # カードの出力のすべてまたは一部を変数に保存 (Flow Designer):page-support-status: eolScheduled Set Variable カードを使用して変数を作成し、前のカードからの出力のすべてを保存したり、出力の一部を保存したり、DataWeave 式で関数を使用して出力を操作したりすることができます。その後、変数を使用して後のカードで値を再利用できます。 通常、次の図の最初のフローで示されているように、カードが出力したデータ全体を同じフローの次のカードが受け取ります。 ![fd regular variables](/mulesoft/current/ja-jp/design-center/_images/fd-regular-variables.png) Figure 1. 通常のフローと、Set Variable カードを使用するフローとの比較 最初のフローでは次の手順が実行されます。 1. Card A が出力を生成します。 2. Card B は Card A からの出力全体を受け取ります。 ただし、Set Variable カードを使用して変数を作成した場合、2 番目のフローで示されているように、変数と、前のカードからの出力の両方がフローの次のカードに渡されます。 1. Card A が出力を生成します。 2. Set Variable カードは変数を作成し、Card A からの出力のすべてを保存したり、出力の一部を保存したり、DataWeave 式で関数を使用して出力を操作したりします。 3. Card B は Card A からのデータセット全体 (ペイロードと属性) と変数を受け取ります。Card B は独自のデータセットと変数を出力します。Card A からの出力は、変数に保存された部分を除き、フローの一部ではなくなります。 4. Card C は Card B からのデータセット全体と変数を受け取ります。 たとえば、チュートリアル​[「Flow Designer での最初の Mule アプリケーションの作成」](https://docs.mulesoft.com/jp/design-center/salesforce-to-twilio)​では、トリガーカードのペイロードを保存できるようにトリガーカードの後で Set Variable カードを使用しました。これは、Choice router を使用した後でこのペイロードからの情報を使用する必要があったが、Choice router からの 3 つの可能な出力にはその情報が保持されなかったためです。 ![fd set var oppdetails](/mulesoft/current/ja-jp/design-center/_images/fd-set-var-oppdetails.png) Figure 2. チュートリアルでの Set Variable カード Choice router に続く Transform カードで ​`OppDetails`​ と名付けた変数を使用しました。 ![fd set var transform](/mulesoft/current/ja-jp/design-center/_images/fd-set-var-transform.png) Figure 3. 変数 ​`OppDetails`​ が強調表示された、Choice router に続く Transform カード ただし、​`OppDetails`​ はフローの後半でも使用できます。これは、次のように、フローの最後のカードである Twilio カードで確認できます。 ![fd set var twilio](/mulesoft/current/ja-jp/design-center/_images/fd-set-var-twilio.png) Figure 4. `OppDetails`​ 変数が強調表示された Twilio カード 変数をこの Twilio カード (または、Transform カードを除く、変数を使用できる任意のカード) で使用するには、単に変数を項目にドラッグします。 変数を 1 回以上使用した後、その変数をそれ以上使用する必要がないと考えられる場合は、変数を最後に使用するカードの後に Remove Variable カードを追加します。 ## [](#手順)手順 カードからのデータに基づく値を保存する手順は、次のとおりです。 1. 保存する値の基礎となるデータを出力するカードの後のプラスアイコンをクリックします。 2. Set Variable カードを追加します。 3. 変数の名前を指定します。名前には、数字、文字、およびアンダースコアのみを含めることができます。 4. 変数の値を指定します。 - 文字列値を指定する場合、​**\[Value (値)\]**​ 項目の右側に ​**f(x)**​ ボタンが表示されていることを確認します。このボタンがある場合、この項目は関数モードではなく、文字列モードであることを意味します。​**\[Value (値)\]**​ 項目に直接入力できます。また、文字列内に文字列を指定する場合を除いて、引用符を使用する必要はありません。 ![fd set var value field smode](/mulesoft/current/ja-jp/design-center/_images/fd-set-var-value-field-smode.png) Figure 5. Set Variable カード内で強調表示された文字列モードの ​**\[Value (値)\]**​ 項目 - DataWeave 式を指定する場合は、​**\[Value (値)\]**​ 項目の右側に ​`f(x)`​ が表示されていることを確認します。​`f(x)`​ がある場合、この項目は式モードであることを意味します。この項目内をクリックすると、​**\[Custom Expression (カスタム式)\]**​ ダイアログが開きます。このダイアログで、右側の ​**\[Add data (データの追加)\]**​ ペインと ​**\[Add functions (関数の追加)\]**​ ペインを使用して式を作成できます。 ![fd set var value field fmode](/mulesoft/current/ja-jp/design-center/_images/fd-set-var-value-field-fmode.png) Figure 6. Set Variable カード内で強調表示された式モードの ​**\[Value (値)\]**​ 項目 ![fd set var custom expression dialog](/mulesoft/current/ja-jp/design-center/_images/fd-set-var-custom-expression-dialog.png) Figure 7. \[Custom Expression (カスタム式)\] ウィンドウとそのペイン

[Add data (データの追加)]​ ペインを表示するには、前のカードの少なくとも 1 つで ​Default​ 以外のデータ型を出力する必要があります。

[Add functions (関数の追加)]​ ペインに表示される DataWeave 関数についてのドキュメントは、「DataWeave 関数リファレンス」の​「Core」​を参照してください。

**\[Custom Expression (カスタム式)\] ウィンドウのスクリーンショットに基づく例:**​ ペイロードのエラーメッセージを変数に保存する場合、​`error_message`​ をクリックします。これで、​**\[Expression (式)\]**​ 項目に式 ​`error_message`​ が含まれます。次に ​**\[OK\]**​ をクリックします。 値を入力することもできます。たとえば、ペイロード全体を変数に保存する場合、​**\[Custom Expression (カスタム式)\]**​ 項目に「​`payload`​」と入力できます。 5. **\[Custom Expression (カスタム式)\]**​ ダイアログで ​**\[OK\]**​ をクリックし、キャンバスをクリックしてカードを閉じます。 ## [](#例)例 前のカードからのペイロードを保存するには、変数の値を ​`payload`​ に設定します。 前のカードからの属性を保存するには、変数の値を ​`attributes`​ に設定します。 フローの現在の時点のデータセット全体を保存するには、変数の値を ​`message`​ に設定します。 ブール値を保存するには、変数の値を ​`true`​ または ​`false`​ に設定します。 ## [](#関連情報)関連情報 - [フロー内でのデータの保存および再利用](https://docs.mulesoft.com/jp/design-center/fd-store-data-top) # カードの出力全体を変数に保存 (Flow Designer):page-support-status: eolScheduled カードの出力に基づく値 (つまり、出力全体、出力の一部、または操作した出力) を保存し、その変数を前のカードからの出力と共に次のカードに渡すことができます。 通常、図の最初のフローで示されているように、カードは入力として受け取ったデータとは異なるデータを出力します。 ![fd target variables](/mulesoft/current/ja-jp/design-center/_images/fd-target-variables.png) Figure 1. 通常のフローと、対象変数への出力を行うカードを含むフローとの比較 最初のフローでは次の手順が実行されます。 1. Card A が出力を生成します。 2. Card B は Card A からの出力全体を受け取ります。 ただし、対象変数を作成した場合、図の 2 番目のフローで示されているようにフローが変わり、次の手順が実行されます。 1. Card A が出力を生成します。 2. Card B は Card A からの出力全体を受け取ります。Card B は独自の出力を変数に保存し、その変数と Card A からの出力を Card C に渡します。 3. Card C は Card A からの出力と、Card B の出力を含む変数を受け取ります。 変数が必要な場合、変数はフロー内の後のカードに表示されます。たとえば、チュートリアル​[「Flow Designer での最初の Mule アプリケーションの作成」](https://docs.mulesoft.com/jp/design-center/salesforce-to-twilio)​のフローを使用するには、変数 ​`OppDetails`​ をフローの前半で作成します。この変数は、フローの最後のカードである Twilio カードでも使用できます。 ![fd set var twilio](/mulesoft/current/ja-jp/design-center/_images/fd-set-var-twilio.png) Figure 2. `OppDetails`​ 変数が強調表示された Twilio カード 変数をこの Twilio カード (または、Transform カードを除く、変数を使用できる任意のカード) で使用するには、単に変数を項目にドラッグします。

OppDetails​ は、Set Variable カードで作成されたものですが、カードの ​[Target (対象)]​ 項目や ​[Target Value (対象値)]​ 項目を使用して作成された変数と同じ方法でアクセスし、使用できます。

## [](#手順)手順 1. 出力を変数に挿入するカードを開きます。 2. カードの左側にある ​**\[Advanced (詳細)\]**​ をクリックします。すべてのカードの \[Advanced (詳細)\] ページに、対象変数を作成するための項目が配置されているとは限りません。また、すべてのカードが出力を対象変数に挿入できるとも限りません。 3. **\[Target (対象)\]**​ 項目で変数の名前を指定します。名前には、数字、文字、およびアンダースコアのみを含めることができます。 4. **\[Target Value (対象値)\]**​ 項目内をクリックし、​**\[Custom Expression (カスタム式)\]**​ ダイアログを開いて、DataWeave 式を指定します。このダイアログでは、右側の ​**\[Add data (データの追加)\]**​ ペインと ​**\[Add functions (関数の追加)\]**​ ペインを使用して式を作成できます。 ![fd set var custom expression dialog](/mulesoft/current/ja-jp/design-center/_images/fd-set-var-custom-expression-dialog.png) Figure 3. \[Custom Expression (カスタム式)\] ウィンドウとそのペイン

[Add data (データの追加)]​ ペインを表示するには、前のカードの少なくとも 1 つで ​Default​ 以外のデータ型を出力する必要があります。

[Add functions (関数の追加)]​ ペインに表示される DataWeave 関数についてのドキュメントは、「DataWeave 関数リファレンス」の​「Core」​を参照してください。

**\[Custom Expression (カスタム式)\] ウィンドウのスクリーンショットに基づく例:**​ ペイロードのエラーメッセージを変数に保存する場合、​`error_message`​ をクリックします。これで、​**\[Expression (式)\]**​ 項目に式 ​`error_message`​ が含まれます。次に ​**\[OK\]**​ をクリックします。 値を入力することもできます。たとえば、ペイロード全体を変数に保存する場合、​**\[Custom Expression (カスタム式)\]**​ 項目に「​`payload`​」と入力できます。 5. **\[Custom Expression (カスタム式)\]**​ ダイアログで ​**\[OK\]**​ をクリックし、キャンバスをクリックしてカードを閉じます。 ## [](#例)例 前のカードからのペイロードを保存するには、変数の値を ​`payload`​ に設定します。 前のカードからの属性を保存するには、変数の値を ​`attributes`​ に設定します。 フローの現時点のデータセット全体を保存するには、変数の値を ​`message`​ に設定します。 ブール値を保存するには、変数の値を ​`true`​ または ​`false`​ に設定します。 ## [](#関連情報)関連情報 - [フロー内でのデータの保存および再利用](https://docs.mulesoft.com/jp/design-center/fd-store-data-top) # コネクタからシステムへの接続:page-support-status: eolScheduled コネクタを表すカードをフローに追加する場合、Flow Designer では、Mule アプリケーションが実行時にコネクタの対象であるシステムにどのように接続できるかを指定する必要があります。 たとえば、Database Connector のインスタンスを表すカードを追加する場合、Flow Designer で ​**\[Database Configuration (データベース設定)\]**​ ダイアログが開きます。このダイアログでデータベースへの既存の接続を選択するか、接続を作成できます。 Flow Designer で使用する用語としての​_接続_​は、Mule アプリケーションがアプリケーションの実行時にシステムに接続するために必要とする保存された情報セットを意味します。この接続は、アプリケーションとシステム間の開かれた通信チャネルではありません。これは、システムとの通信チャネルを開くためにアプリケーションで使用する必要がある情報です。 ![Flow Designer で使用する用語としての意味での「接続」と、開かれた通信チャネルの意味での「接続」](/mulesoft/current/ja-jp/design-center/_images/fd-connection.png) Figure 1. Flow Designer で作成する接続は、Mule アプリケーションがシステムに接続するために使用する必要がある情報セットです。
1Flow Designer で使用する用語としての意味での接続: Mule アプリケーションがシステムとの通信チャネルを開くために必要とする情報セット。
2より一般的な意味での接続: 2 つのエンティティ間の開かれた通信チャネル。
接続はコネクタの設定で使用されます。​_設定_​は接続を含む保存されたデータセットであり、設定には、対象のコネクタの種別に応じてさまざまな種別の情報を指定します。Mule アプリケーションプロジェクトで使用するコネクタの種別ごとに 1 つ以上の設定を作成して保存できます。接続、設定、コネクタ間の関係を次の図で表します。 ![接続、設定、コネクタ間の関係を表している図。](/mulesoft/current/ja-jp/design-center/_images/fd-connections-configs-connectors.png) Figure 2. 接続 (この場合はデータベース接続) は設定で使用され、設定自体は Database Connector のインスタンスで使用されます。
1コネクタの種別ごとに接続プールを作成できます。この図には 3 つの接続のプールがありますが、省略記号 (「…​」) は、このプールに他の接続が含まれている可能性があることを示しています。
2コネクタの種別ごとに設定プールを作成できます。設定ごとに 1 つの接続を使用します。この図では、設定 Config 1 で接続 Conn B が使用され、設定 Config 2 で接続 Conn A が使用されています。 省略記号は、より大きな設定プールがある可能性があることを示しています。
3コネクタ種別のインスタンスごとに 1 つの設定を使用します。この図では、Config 2 も使用可能ですが、Database Connector のインスタンスでは Config 1 のみが使用されています。また、たとえば、Mule アプリケーションに Salesforce Connector の 2 つのインスタンスがあるとします。各インスタンスで同じ設定または異なる設定を使用できます。通常は、コネクタ種別の 2 つの設定でそれぞれ異なる接続を使用します。
次の 2 つの種別の接続があります。 - 1 つのプロジェクト内でのみ使用できる接続。 - 複数のプロジェクトおよびユーザーと共有できる接続。 接続を作成または編集するときに ​**\[Share this connection with my business group (この接続をビジネスグループと共有)\]**​ チェックボックスをオンにして、後者の種別を作成します。 ![「Share this connection with my business group (この接続をビジネスグループと共有)」 チェックボックスの場所](/mulesoft/current/ja-jp/design-center/_images/fd-connection-checkbox.png) Figure 3. **\[Share this connection with my business group (この接続をビジネスグループと共有)\]**​ チェックボックスは ​**\[Configure Connection (接続を設定)\]**​ ダイアログ内にあります。 このチェックボックスをオンにすると、自分とビジネスグループ内の他のユーザーが他のプロジェクトで接続を使用できるようになります。接続の作成者とビジネスグループのシステム管理者のみが接続を編集または削除できます。 たとえば、あなたがシステム管理者であり、特定のシステムに接続するアプリケーションをビジネスグループ内の複数のユーザーが作成できるようにする必要がある場合、共有接続を作成することをお勧めします。これらのユーザーは、同じレベルの権限を持つ、システム管理者により管理される 1 つのログイン情報セットを使用して接続できます。 接続を作成または編集するときに ​**\[Share this connection with my business group (この接続をビジネスグループと共有)\]**​ チェックボックスをオンにしない場合、接続が作成されたプロジェクト内でのみ接続を使用できます。ただし、そのプロジェクト内では接続を複数回使用できます。たとえば、Salesforce Connector のインスタンスをフローに追加するとします。これを行う場合、コネクタを介して Salesforce に接続するための接続を作成します。その後、Salesforce Connector の 2 番目のインスタンスをフローに追加します。2 番目のインスタンスでは、1 番目のインスタンスで作成した接続と同じ接続を使用できます。 # コネクタの設定への接続の追加:page-support-status: eolScheduled _接続_​は、実行中の Mule アプリケーションがコネクタを介して特定のシステムに接続するときに使用する必要のある保存済みの情報セットです。コネクタをフローに追加するときに接続を作成する場合もあります。 ![Mule アプリケーションプロジェクトへのコネクタの追加に関するフローチャート](/mulesoft/current/ja-jp/design-center/_images/fd-flowchart-configuration.png) Figure 1. このフローチャートは、コネクタを Mule アプリケーションプロジェクトに追加するステップを示しています。これらのステップに接続の作成が含まれる場合もあります。
1コネクタをフローに追加するときに、​設定​ (接続が含まれる情報セット) を作成します。使用できる設定が存在する場合、その設定を選択できます。ただし、コネクタ設定がまだ存在していない場合や、既存の設定がユースケースに適していない場合、設定を作成する必要があります。
2設定を作成する部分では、Mule アプリケーションの実行時にシステムに接続するためにコネクタで使用する必要のある接続を指定します。
3このコネクタ種別にすでに接続が存在している場合、設定を作成するためのダイアログが開いたときに接続のリストが表示されます。ダイアログでは、接続を作成することもできます。たとえば、Database Connector のインスタンスを追加する場合、Flow Designer で ​[Database Configuration (データベース設定)]​ ダイアログが開きます。このコネクタ種別にすでに接続が存在している場合、このダイアログにデータベースへの接続のリストが表示されます。ダイアログでは、データベースへの接続を作成することもできます。
4[Add connection (接続を追加)]​ ボタンをクリックして接続を作成します。
5コネクタの設定ダイアログに戻り、必要に応じて ​[Advanced (詳細)]​ セクションの項目の値を指定します。
接続に関するオプションが表示される設定ダイアログの部分は次のようになります。 ![リストとオプションの場所](/mulesoft/current/ja-jp/design-center/_images/fd-connection-add.png) Figure 2. **\[Database Configuration (データベース設定)\]**​ ダイアログの部分には、データベースへの接続のリストと、データベースへの接続を作成するためのオプションが表示されます。
1既存の各接続には、接続が作成されたおおよそのタイミングと作成者のユーザー ID が表示されます。
2[Add connection (接続を追加)]​ オプションでは、接続を作成できます。
設定を編集する場合や、コネクタの追加設定を作成する場合でも、接続を作成できます。 ![接続を追加する場所](/mulesoft/current/ja-jp/design-center/_images/fd-edit-switch-configs.png) Figure 3. コネクタの設定ダイアログを開いたり、接続を追加したりできる場所。
1コネクタの設定が少なくとも 1 つある場合、コネクタカードの上部はこのようになります。設定を編集したり、別の設定に切り替えたりできます。設定を編集する場合、設定ダイアログが開き、接続を作成できます。
2別の設定に切り替えるオプションを選択すると、カードの上部がこのように変わります。​[Add (追加)]​ をクリックしてコネクタの設定ダイアログを開き、接続を作成できます。
## [](#コネクタの設定に接続を追加する)コネクタの設定に接続を追加する 1. フローに追加したコネクタの設定ダイアログで ​**\[Add connection (接続を追加)\]**​ をクリックします。 2. 接続にわかりやすい一意の名前を付けます。 3. 接続を自分やビジネスグループの他のユーザーが他のプロジェクトで使用できるようにするには、​**\[Share this connection with my business group (この接続をビジネスグループと共有)\]**​ チェックボックスをオンにします。 ![「Share this connection with my business group (この接続をビジネスグループと共有)」 チェックボックスの場所](/mulesoft/current/ja-jp/design-center/_images/fd-connection-checkbox.png) Figure 4. **\[Share this connection with my business group (この接続をビジネスグループと共有)\]**​ チェックボックスは、​**\[Connector Name (コネクタ名)\]**​ 項目の後にあります。 4. 作成する接続の種別を選択します。 項目については、Mule アプリケーションプロジェクトに追加するコネクタのドキュメントを参照してください。 5. **\[Save (保存)\]**​ をクリックします。 コネクタの設定ダイアログに戻ります。追加した接続が、使用する設定の接続として選択されます。 6. **\[Save (保存)\]**​ をクリックしてキャンバスに戻ります。

設定ダイアログで誤って ​[Cancel (キャンセル)]​ をクリックした場合でも、作成した接続は削除されません。設定ダイアログを再度開き、新しい接続を選択できます。

## [](#関連情報)関連情報 - [コネクタからシステムへの接続](https://docs.mulesoft.com/jp/design-center/fd-connections) - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # コレクションの要素の処理:page-support-status: eolScheduled For-Each コンポーネントまたは Parallel For-Each コンポーネントのインスタンスにペイロードで渡すコレクションの要素を処理できます。各コンポーネントでスコープが設定されます。このスコープ内で他の種別のコンポーネントのほか、コネクタやモジュールを追加して各要素を処理できます。 ![2 つの簡単な例: For-Each の使用例と Parallel For-Each の使用例](/mulesoft/current/ja-jp/design-center/_images/fd-iterators-example.png) Figure 1. For Each コンポーネントと Parallel For Each コンポーネントでは、コレクションの要素を処理するためのスコープが設定されます。
1この例の For-Each コンポーネントでは、各要素をデータベースに 1 つずつ挿入します。各要素は、おそらく SQL INSERT ステートメントで使用できる文字列です。
2この例の Parallel For-Each コンポーネントでは、各要素を Set Payload コンポーネントに送信し、そのコンポーネントで式を使用して要素を変更し、フローのペイロードに追加します。
どちらの種別のコンポーネントでも、あらゆるコレクションを処理できます。 ## [](#for-each-コンポーネントでデータを処理してフローを続行する方法)For-Each コンポーネントでデータを処理してフローを続行する方法 For-Each コンポーネントは、コレクションの各要素を順次処理した後、For-Each コンポーネントに渡された元のペイロードを使用してフローを続行するために使用されます。 ![For-Each コンポーネントで実行されるアクションを示している図](/mulesoft/current/ja-jp/design-center/_images/fd-foreach.png) Figure 2. 次の図は、For-Each コンポーネントを使用しているフローを表しています。角丸長方形はカードです。
1あるカードでフローのペイロードを For-Each コンポーネントに渡します。ペイロードは要素のコレクションで構成されます。
2For Each コンポーネントはコレクションを個別の要素に分割します。次に、スコープ内にある最初のコンポーネント、コネクタ、またはモジュールに各要素を順次送信します。各要素はスコープ内のペイロードとして処理されます。このため、スコープ内のコネクタが ​payload​ に対してアクションを実行したり、スクリプトを使用して ​payload​ を処理したりするように設定されている場合、ペイロードは、For-Each コンポーネントで受け取ったペイロードではなく、そのコンポーネントで処理している要素になります。
3最後の要素が処理されると、For-Each コンポーネントは、フローの前のカードから受け取ったペイロードを次のカードに渡します。
4フローの次のカードは For-Each コンポーネントが受け取ったペイロードと同じペイロードを受け取り、フローが続行されます。
## [](#parallel-for-each-コンポーネントでデータを処理してフローを続行する方法)Parallel For-Each コンポーネントでデータを処理してフローを続行する方法 Parallel For-Each コンポーネントは、コレクションの各要素を処理した後、結果をフローの次のカードに渡すために使用されます。 ![Parallel For-Each コンポーネントで実行されるアクションを示している図](/mulesoft/current/ja-jp/design-center/_images/fd-parallel-foreach.png) Figure 3. 次の図は、Parallel For-Each コンポーネントを使用しているフローを表しています。角丸長方形はカードです。
1あるカードでフローのペイロードを Parallel For-Each コンポーネントに渡します。ペイロードは要素のコレクションで構成されます。
2Parallel For-Each コンポーネントはコレクションを個別の要素に分割します。次に、スコープ内にある最初のコンポーネント、コネクタ、またはモジュールに要素を同時に送信します。一度に処理する要素の最大数を指定できます。各要素はスコープ内のペイロードとして処理されます。このため、スコープ内のコネクタが ​payload​ に対してアクションを実行したり、スクリプトを使用して ​payload​ を処理したりするように設定されている場合、ペイロードは、Parallel For-Each コンポーネントで受け取ったペイロードではなく、そのコンポーネントで処理している要素になります。
3すべての要素が処理されると、Parallel For-Each コンポーネントは、そのスコープ内で実行された処理の結果を集約して渡します。この結果により、フローの次のカードに渡されるペイロードが形成されます。
4フローの次のカードは Parallel For-Each コンポーネントから結果を受け取り、フローが続行されます。
結果の順序は、元のペイロード内の要素の順序に対応します。たとえば、Parallel For-Each コンポーネントに渡されるペイロードが ​`["Apple","Banana","Cherry"]`​ であるとします。コンポーネントのスコープ内に、各要素を個別のコンポーネントとして処理する Set Payload コンポーネントがあります。Set Payload コンポーネントは DataWeave 式 ​`payload ++ '-result'`​ を使用して各ペイロードを処理します。Parallel For-Each コンポーネントは結果 ​`["Apple-result","Banana-result","Cherry-result"]`​ をフローの次のカードに渡します。

Parallel For-Each コンポーネントのスコープ内では、各要素の処理順序が、コレクションに含まれている各要素の順序であることは保証されません。したがって、いずれかのコネクタが特定の順序で要素を要求する場合 (たとえば、Database Connector を使用して特定の順序でデータベーステーブルを更新する場合)、代わりに For-Each コンポーネントを使用する必要があります。

また、Parallel For-Each コンポーネントのスコープ内で接続する API またはサービスに、許容される同時接続数の制限があるかどうかに注意する必要があります。ある場合、Parallel For-Each コンポーネントの最大同時プロセス数を指定する必要があります。

## [](#一括処理)一括処理 For-Each コンポーネントを使用すると、コレクションをバッチに分割することで処理時間を短縮できます。各バッチは、個別の Mule メッセージとして処理されます。たとえば、コレクションに 200 個の要素があり、\[Batch Size (バッチサイズ)\] を 50 に設定すると、For Each コンポーネントは 50 個の要素から成る 4 つのバッチをそれぞれ個別の Mule メッセージとして反復処理します。 一括処理は Parallel For-Each コンポーネントではサポートされません。 ## [](#変数)変数 For Each コンポーネント内の各反復で、前の反復で使用した変数を使用できます。1 つの要素の処理中に作成された新しい変数や、既存の変数に加えられた変更は、別の要素の処理中に参照できます。変数へのこれらの変更は、引き続き For-Each スコープの外部で使用できます。 たとえば、For-Each コンポーネントのスコープの直前で Set Variable コンポーネントを使用するとします。Set Variable コンポーネント内で変数 ​`NumOfElements`​ を 0 に設定します。次に、For-Each スコープ内で Set Variable コンポーネントを使用して、同じ変数を使用します。このコンポーネントでは、コールされるたびに値を 1 ずつ増加する DataWeave スクリプトが指定されています。処理されるコレクションの別の要素を For-Each コンポーネントが送信するたびに、値が増加して ​`NumOfElements`​ に保存されます。すべての要素が処理されると、​`NumOfElements`​ の値は、コレクションに含まれていた要素の数になります。この値をフローの後続のカードが For-Each スコープの外部で使用できます。 Parallel For-Each コンポーネントの場合、スコープに入る変数の値は、各変数の処理の開始時点では同じです。1 つの要素の処理中に作成された新しい変数や、既存の変数の変更は、別の要素の処理中に参照できません。また、Parallel For-Each コンポーネントのスコープ内での変数の変更は、フローの後続のカードで使用できません。 たとえば、前述の例と同様に、Parallel For-Each コンポーネントのスコープの直前で Set Variable コンポーネントを使用するとします。Set Variable コンポーネント内で変数 ​`NumOfElements`​ を 0 に設定します。次に、Parallel For-Each スコープ内で Set Variable コンポーネントを使用して、同じ変数を使用します。このコンポーネントでは、コールされるたびに値を 1 ずつ増加する DataWeave スクリプトが指定されています。コンポーネントにより実行される各並列プロセスで、​`NumOfElements`​ が到達する最高値は 1 です。また、フローの後続のカードで ​`NumOfElements`​ を使用している場合、Parallel For-Each コンポーネントでコレクションの処理が終了した後、その初期値は 0 になります。これは、Parallel For-Each コンポーネントの開始前の値と同じです。 ## [](#エラー処理)エラー処理 For Each コンポーネントと Parallel For Each コンポーネントでは、要素が原因でスコープ内のコンポーネント、コネクタ、またはモジュールが例外をスローした場合、コレクションの処理が停止します。また、Parallel For-Each コンポーネントでは、並列プロセスのいずれかがシステムへの開かれた接続を待機している間にタイムアウトした場合、コレクションの処理が停止します。並列プロセスで待機できる最大時間を設定できます。 例外が原因でコレクションの処理が停止した場合、Flow Designer では、例外をスローしたカードに赤の円が表示されます。タイムアウトが原因でコレクションの処理が停止した場合、Flow Designer では、Parallel For-Each コンポーネントのカードに赤の円が表示されます。​**\[Logs (ログ)\]**​ ペインを開くと、エラーメッセージを参照できます。 ## [](#for-each-コンポーネントの設定)For-Each コンポーネントの設定 このコンポーネントを設定する場合、以下の項目に値を指定する必要があります。 Collection (コレクション) Java コレクション、オブジェクト配列、マップ、または DOM ノードを返す式。デフォルト値は ​`payload`​ です。 Batch Size (バッチサイズ) 指定された数の要素のサブコレクションにコレクションを分割します。たとえば、コレクションに 200 個の要素があり、バッチサイズを 50 個の要素に設定すると、コンポーネントは 50 個の要素から成る 4 つのバッチを処理します。 Root Message Variable Name (ルートメッセージ変数名) フローの前のカードから For-Each コンポーネントに渡されたメッセージ全体 (ペイロード、変数、および属性) を保存する変数の名前。 Counter Variable Name (カウンター変数名) 処理中の要素のインデックスを保存する変数の名前、たとえば、コレクションが ​`['a','b','c']`​ の場合、​`a`​ のインデックスは 0、​`b`​ のインデックスは 1、​`c`​ のインデックスは 2 です。For-Each コンポーネントで 2 番目の要素を処理している場合、変数の値は 1 です。 ## [](#parallel-for-each-コンポーネントの設定)Parallel For-Each コンポーネントの設定 このコンポーネントを設定する場合、以下の項目に値を指定する必要があります。 Collection (コレクション) 並列で処理する部分のコレクションを定義する式を指定します。デフォルト値は ​`payload`​ です。 Timeout (タイムアウト) コレクションの要素の処理を完了するために Parallel For-Each コンポーネントのスコープ全体でかけることができる最大時間 (ミリ秒) を指定します。 たとえば、スコープ内に HTTP Request コンポーネントを配置し、GET 要求をサービスおよび Database Connector のインスタンスに送信して値をデータベースに挿入するとします。コレクションの各要素では、GET 要求で何を要求するかを指定します。​**\[Timeout (タイムアウト)\]**​ の値には、要求された情報がサービスから返され、Database Connector のインスタンスによって情報がデータベースに挿入されるまで待機する時間 (ミリ秒) を指定します。 Max Concurrency (最大同時実行) 実行可能な並列プロセスの最大数を指定します。実際に開始される並列プロセスの数は、実行されている場所でリソースが Mule Runtime によってどのように割り当てられるかに応じて異なります。 - 値を 40 に設定し、最大 4 個のプロセスを並列実行するのに十分なリソースのみが Mule Runtime によって割り当てられた場合、最大 4 個のプロセスのみを並列実行できます。 - 値を 2 に設定し、最大 4 個のプロセスを並列実行するのに十分なリソースが Mule Runtime によって割り当てられた場合、最大 2 個のプロセスのみを並列実行できます。 このコンポーネントを設定する場合、以下の項目に値を指定することができます (必須ではありません)。 Target (対象) コレクションのすべての要素の処理結果を保存するために使用する変数を指定します。デフォルトでは、出力はフローのペイロードに保存されます。 Target Value (対象値) 操作の出力値に対して評価する式を指定します。この式の結果は対象変数に保存されます。デフォルトでは、これは操作の出力値と同じです。 # シミュレーションする API コールへの動作ヘッダーの追加 動作ヘッダーにより、モッキングサービスの動作を変更できます。API 仕様への要求をシミュレーションする場合、通常は別の種別のヘッダーを指定する場所で動作ヘッダーを使用します。 ## [](#ms2-delay)MS2-Delay MS2-Delay では、要求が応答に要する時間 (ミリ秒) を指定します。このヘッダーを使用して、サーバーの負荷やネットワークのレイテンシーをシミュレートできます。 このヘッダーの値は、整数または整数の範囲として指定できます。範囲を指定する場合、値の形式を ​`min-max`​ にする必要があります。たとえば、​`500-1000`​ の値を指定した場合、要求には 500 ~ 1000 ミリ秒のランダムな時間がかかります。

ネットワークのレイテンシーによっては、単一の整数値または範囲の上限値よりもレイテンシーが長くなる可能性があります。

MS2-Delay は 10000 ミリ秒 (ms) の最大値を取り、次の動作に従います。 - 値が 10000 ms 未満に設定されている場合、モッキングサービスは最大 5000 ms の遅延を追加する。 - 値が 10000 ms より大きい値に設定されている場合、モッキングサービスは最大 10000 ms の遅延を追加する。 例: \* 値が 5000 ~ 9000 ms の範囲に設定されている場合、モッキングサービスは最大 5000 ~ 9000 ms の遅延を追加します。 \* 値が 9000 ~ 20000 ms に設定されている場合、モッキングサービスは最大 9000 ~ 10000 ms の遅延を追加します。 \* 値が 20000 ~ 30000 ms の範囲に設定されている場合、モッキングサービスは次のエラーメッセージを返します。 { "code": "INVALID\_HEADER\_VALUE", "message": "Invalid value for header MS2-Delay. Requested range is higher than the max value allowed: 10000 ms" } ## [](#ms2-example)MS2-Example MS2-Example ヘッダーにより、エンドポイントで 1 つの状況コードに対して複数の例を定義している場合に特定の応答例を選択できます。 MS2-Example を使用して、応答内で複数の例を指定できます。次の例では、状況コード 200 に対する 3 つの例を示しています。 /examples: get: responses: 200: body: application/json: examples: one: prop1: something prop2: 30 two: prop1: another prop2: 31 three: prop1: anything prop2: 33 ここで、ヘッダーに使用可能な値は ​`one`​、​`two`​、および ​`three`​ です。要求の一環として値 ​`one`​ を送信すると、ペイロード ​`something`​ および ​`30`​ が返されます。​`one`​、​`two`​、​`three`​ 以外の値を送信するとエラーメッセージが返されます。 ## [](#ms2-error-level)MS2-Error-Level MS2-Error-Level は、モッキングサービスで使用するエラー状況コードをどの範囲に制限するかを示します。次の 3 つの値 (大文字と小文字を区別) のいずれかを指定できます。 - `REQUEST_ONLY`​: モッキングサービスは 4XX コードのみを使用します。 - `SERVER_ONLY`​: モッキングサービスは 5XX コードのみを使用します。 - `ALL`​: モッキングサービスは 4XX コードと 5XX コードの両方を使用できます。これがデフォルト値です。 ## [](#ms2-error-rate)MS2-Error-Rate MS2-Error-Rate は、応答としてエラー状況コードを取得する確率を示します。このヘッダーの値は 0 ~ 1 の小数値である必要があります。 このヘッダーは MS2-Status-Code、MS2-Error-Level、またはこの両方と共に同時に動作します。
Table 1. MS2-Error-Rate を使用する場合にモッキングサービスがどの状況コードで応答するかを決定する方法
MS2-Error-Rate と共に使用される他のヘッダー モッキングサービス (MS) がエラーコードで応答する モッキングサービス (MS) がエラーコードで応答しない

MS2-Status-Code

MS は MS2-Status-Code で指定されたエラーコードを使用します。

MS は MS2-Status-Code で指定された、エラー以外の状況コードを使用します。

MS2-Error-Level

MS は、メソッドで定義されたエラー状況コードのうち、MS2-Error-Level で指定された範囲内の最初のエラー状況コードを使用します。

MS は、メソッドで定義された、エラー以外の最初の状況コードを使用します。

MS2-Error-Level and MS2-Status-Code

MS は、メソッドで定義されたエラー状況コードのうち、MS2-Error-Level で指定された範囲内の最初のエラー状況コードを使用します。

MS は MS2-Status-Code で指定された、エラー以外の最初の状況コードを使用します。

なし

MS は、メソッドで定義された最初のエラー状況コードを使用します。

MS は、メソッドで定義された、エラー以外の最初の状況コードを使用します。

## [](#ms2-randomize)MS2-Randomize MS2-Randomize を ​`true`​ に設定すると、モッキングサービスはペイロード応答の例が定義されていない場合にペイロード応答を自動生成します。 たとえば、API 仕様に次の型の定義が含まれているとします。 types: Person: properties: id: integer name: string 例を提供せずに、​`true`​ に設定されたヘッダー MS2-Randomize をモッキングサービスで使用した場合、返されるメッセージのペイロードには、このデータ型に一致するランダムな値を含む次のような例が含まれます。 { "id": 98358, "name": "OVCKr" } また、ヘッダーではさらに詳細な型定義がサポートされます。たとえば、型定義を次のように変更できます。 types: Person: properties: id: type: integer minimum: 3 maximum: 30 multipleOf: 3 name: string MS2-Randomize を ​`true`​ に設定した場合、モッキングサービスからの応答のペイロードは次のようになり、​`id`​ の値は制限に準拠します。 { "id": 9, "name": "rul68" } ## [](#ms2-status-code)MS2-Status-Code MS2-Status-Code では、返すメッセージに対してモッキングサービスが選択できる状況コードを指定します。このヘッダーは、メソッドで定義された状況コードのリストの検索条件として動作します。たとえば、エラー以外の複数の状況コードがメソッドで定義されているとします。モッキングサービスでこの状況コードの 1 つのみを使用して応答する場合、その状況コードをこのヘッダーで指定します。

このヘッダーを MS2-Error-Rate と共に使用する場合、エラー以外の状況コードとエラー状況コードの両方を指定する必要があります。この 2 つの状況コードをカンマで区切ります。たとえば、モッキングサービスでエラーがない場合に 201 メッセージを返し、エラーがある場合に 401 状況コードを返すとします。この場合、値に ​201,401​ を指定します。

## [](#ms2-status-code-selection)MS2-Status-Code-Selection デフォルトでは、モッキングサービスは要求に応答するときに、対応するメソッドで定義されている最も小さい状況コードを選択します。たとえば、状況コード 201、400、409、500 の応答を定義するエンドポイントに対して POST 要求を実行する場合、デフォルトでは、モッキングサービスは状況コード 201 で定義されている応答メッセージを送信します。MS2-Status-Code-Selection ヘッダーを使用すると、このデフォルトの動作またはモッキングサービスを変更できます。 MS2-Status-Code-Selection と MS2-Error-Level は併用できます。モッキングサービスは、MS2-Error-Level で指定されたエラー状況コードの範囲内にある状況コードを数値の昇順で並び替え、MS2-Status-Code-Selection で指定された戦略に応じてその範囲からエラー状況コードを返します。 MS2-Status-Code-Selection の使用可能な値は次のとおりです。 `FIRST`​ モッキングサービスは、状況コードのリストを数値の昇順で並び替え、最も小さい状況コードを返します。たとえば、仕様で POST メソッドの状況コードが 500、409、400、200 の順に定義されている場合、モッキングサービスは状況コード 200 の応答を返します。 `RANDOM`​ モッキングサービスは、いずれかの状況コードをランダムに選択して返します。たとえば、仕様で POST メソッドの状況コード 500、409、400、200 が定義されている場合、モッキングサービスはいずれかの応答を返します。 ## [](#ms2-strict-model-validation)MS2-Strict-Model-Validation このヘッダーは、2019 年 1 月 10 日に API Designer がより厳格なパーサーに切り替えられる前に記述された仕様を含む API へのコールをシミュレーションする場合に役立つ可能性があります。 このヘッダーを ​`false`​ に設定した場合、API 仕様にエラーが含まれていてもモッキングサービスを使用できます。 このヘッダーを ​`true`​ に設定した場合、モッキングサービスは応答する前に仕様を検証します。仕様にエラーがある場合、モッキングサービスはそのエラーで失敗します。それ以外の場合、モッキングサービスは通常どおりに機能します。 ## [](#関連情報)関連情報 - [API コールのシミュレーション](https://docs.mulesoft.com/jp/design-center/design-mocking-service) # テキストエディターでの API 仕様の作成 API Designer のテキストエディターを使用して、RAML 0.8、RAML 1.0、OAS 2.0、OAS 3.0、AsyncAPI 2.0 で直接 API 仕様を作成できます。OAS および AsyncAPI API 仕様は、JSON または YAML ファイルとして作成できます。 ## [](#始める前に)始める前に Anypoint Platform で、自分のユーザー ID に ​_Design Center 開発者_​権限を割り当てておく必要があります。 ## [](#手順)手順 1. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで、​**\[Create new (新規作成)\]**​ をクリックします。 2. **\[New API Specification (新しい API 仕様)\]**​ を選択して REST API を作成するか、​**\[New AsyncAPI (新しい AsyncAPI)\]**​ を選択して AsyncAPI を作成します。 3. **\[New API Specification (新しい API 仕様)\]**​ または ​**\[New AsyncAPI (新しい AsyncAPI)\]**​ ダイアログで、プロジェクトに名前を付けます。 名前は後で必要に応じて変更できます (拡張子は変更できません)。 4. REST API 仕様の作成を開始します。 1. **\[I’m comfortable designing it on my own (自分でデザインします)\]**​ オプションを選択します。 2. RAML または OAS 仕様を選択します。 選択した仕様の型とバージョンを使用して、API Designer によって API 仕様のスタブが作成されます。 デフォルトでは、API Designer によって RAML 1.0 ファイルが作成されます。プロジェクトが作成された後でファイルを RAML 0.8 または OAS に変更できます。API 仕様を作成するプロジェクトでは、RAML、OAS、その他の種類のファイルを混在させることができます。 5. AsyncAPI 仕様の作成を開始します。 - プロジェクト言語として YAML または JSON を選択します。 テキストエディターが開きます。 API Designer テキストエディターは以下のパネルに分かれています。 - 左側のパネルには、プロジェクトのファイルと連動関係のリストが表示されています。 スタブ仕様ファイルがリストされ、プロジェクトのルートファイルとして設定されます。仕様名の横にあるオーバーフローメニューアイコン (​![manage dependency versions design center 018a5](/mulesoft/current/ja-jp/design-center/_images/manage-dependency-versions-design-center-018a5.png "オーバーフローメニューアイコンのスクリーンショット")​) をクリックして ​**\[Rename (名前変更)\]**​ を選択すると、このファイルの名前を変更できます (拡張子は変更できません)。 左側のパネルには、​`exchange.json`​ ファイルもリストされます。このファイルには、プロジェクトを Anypoint Exchange にパブリッシュするときに Exchange から要求されるメタデータが含まれます。このファイルは参照のみです。

1 つのプロジェクトで複数の API 仕様や関連ファイルを作成できます。[Files (ファイル)] パネルでプラス記号をクリックして、新しいファイルを作成します。

複数の仕様ファイルを作成する場合、いずれかをプロジェクトのルートファイルとして指定する必要があります。

Exchange 連動関係の追加についての詳細は、このトピックの最後にある​**「関連情報」**​セクションにリンクがある「API 仕様プロジェクトへの連動関係の追加」を参照してください。 - 中央のパネルには、API 仕様を作成するためのエディターがあります。プロジェクトの作成時や新しい API 仕様の開始時には、プロジェクト作成時に選択した仕様の種別に応じて、API 仕様ファイルの最初の 2 行が表示されています。RAML から OAS、またはその逆に切り替えたい場合は、これらの行 (およびファイル名拡張子) を変更できます。 - 右側のパネルには、中央のパネルに表示されている API 仕様に含まれる型やリソースのリストが表示されます。 - 下部のパネルを展開すると、プロジェクトエラーが表示されます。API Governance を使用しており、編集中の API 仕様に連動関係としてルールセットが適用されている場合、​**\[Project Errors (プロジェクトエラー)\]**​ には API 仕様の機能エラーと準拠メッセージが表示されます。 ## [](#エディター)エディター エディターでの作業中には、多くのコマンドを使用して API 仕様内を移動したり、API 仕様のコンテンツを操作したりできます。​**F1**​ キーを押すと、これらのコマンドのリスト、およびほとんどのコマンドのキーボードショートカットが表示されます。 以下のタスクも実行できます。 - **プロジェクトへのファイルおよび API フラグメントのインポート**​ ファイルは 1 つずつ、または .zip ファイルにまとめてインポートできます。コンピューター上のローカルファイルを指定するか、またはファイルがオンラインで保存されている場合は URL を指定できます。 ファイルのインポートについての詳細とインポート手順は、このトピックの最後にある​**「関連情報」**​にリンクがある「API プロジェクトへのファイルのインポート」を参照してください。 プロジェクトへの API フラグメントの追加についての詳細は、このトピックの最後にある​**「関連情報」**​にリンクがある「API 仕様プロジェクトへの連動関係としての RAML API フラグメントの追加」を参照してください。 - **API コールのシミュレーション**​ REST API 仕様を作成するときに、指定されたエンドポイントへのコールをシミュレーションできます。 詳細については、このトピックの最後にある​**「関連情報」**​にリンクがある「API コールのシミュレーション」を参照してください。 - **API プロジェクトまたは仕様のエクスポート** プロジェクトはいつでも ZIP ファイルとしてエクスポートできます。テキストエディターの右上隅にある歯車アイコンをクリックして ​**\[Download Project (プロジェクトをダウンロード)\]**​ を選択します。 - **ファイルのダウンロード**​ ファイル名の右側にあるドットをクリックして ​**\[Download (ダウンロード)\]**​ を選択します。 - **別の形式でのファイルのダウンロード**​ 仕様のファイル名の右側にあるドットをクリックして ​**\[Download as (名前を付けてダウンロード)\]**​ を選択します。仕様は、サポートされている他の形式のいずれかでダウンロードできます。仕様が RAML 形式であれば、OAS YAML または OAS JSON 形式でダウンロードできます。仕様が OAS 形式であれば、RAML 0.8 または RAML 1.0 形式でダウンロードできます。 このオプションを使用してダウンロードしたファイルが有効である保証はありません。このオプションの目的は、新しい仕様の開発の基礎を提供すること、または新しい形式で元の仕様の開発を継続できるようにすることです。 ## [](#次のステップ)次のステップ API 仕様が完成したら、Exchange にパブリッシュすることができます。​[「API 仕様のパブリッシュ」](https://docs.mulesoft.com/jp/design-center/design-publish)​を参照してください。 ## [](#関連情報)関連情報 - [API プロジェクトへのファイルのインポート](https://docs.mulesoft.com/jp/design-center/design-import-files) - [API 仕様プロジェクトへの連動関係としての RAML API フラグメントの追加](https://docs.mulesoft.com/jp/design-center/design-add-api-dependency) - [API コールのシミュレーション](https://docs.mulesoft.com/jp/design-center/design-mocking-service) - [テキストエディターのプロジェクトのルートファイル](https://docs.mulesoft.com/jp/design-center/design-change-root-file) - [API 仕様のパブリッシュ](https://docs.mulesoft.com/jp/design-center/design-publish) - [オープンプロジェクトの名前の変更](https://docs.mulesoft.com/jp/design-center/design-rename-project) - [プロジェクトの削除](https://docs.mulesoft.com/jp/design-center/design-delete-project) - [API Governance ドキュメント](https://docs.mulesoft.com/api-governance/) # テキストエディターでのプロジェクトのフォーク 分岐を利用することで、プロジェクトの以前の反復と新しい反復を分離することができます。 ## [](#このタスクについて)このタスクについて 新しい分岐はプロジェクトのフォークとなり、メイン分岐に再びマージすることはできなくなります。プロジェクトにアクセスできるユーザーであれば、だれでも分岐を作成できます。 プロジェクトにフォークがある場合でも、プロジェクトをエディターで開くとメイン分岐が表示されます。作業途中だったフォークに戻るには、そのフォークを改めて選択する必要があります。 API 仕様の任意のフォークを Anypoint Exchange にパブリッシュすることができます。 ## [](#手順)手順 - プロジェクトをフォークする手順: 1. プロジェクトを開きます。 2. テキストエディターの一番上にある分岐の名前をクリックします。 3. \[Search (検索)\] 項目に名前を入力して ​**Enter**​ キーを押します。 **結果:**​ テキストエディターは自動的に新しいフォークに切り替わります。 - プロジェクトのフォークを編集する手順: 1. プロジェクトを開きます。 2. テキストエディターの一番上にある分岐の名前をクリックします。 3. 作業するフォークの名前を選択します。 # テキストエディターの便利な機能 テキストエディターを使用すると、以下の作業を簡単に実行できます。 - 宣言可能なオブジェクトの名前を変更する - 宣言可能なオブジェクトの名前を強調表示して見つける - 定義が参照されている場所を見つける - コード範囲を選択する - 記号に移動する - 要素を宣言に抽出する ## [](#宣言可能なオブジェクトの名前を変更する)宣言可能なオブジェクトの名前を変更する 1 つのアクションのみを使用して、プロジェクトで使用されるすべての場所で宣言可能なオブジェクトの名前を変更できます。 宣言されている場所でオブジェクトの名前を右クリックし、​**\[Rename Symbol (シンボルの名前を変更)\]**​ を選択して、新しい名前を指定します。これにより、プロジェクトのルートファイルに関連付けられた現在のプロジェクトのすべてのファイルで使用されるすべての場所でオブジェクトの名前が変更されますが、言及されているだけの場所では名前が変更されません。 たとえば、次の例では、API 仕様 ​`product_name`​ は 5 行目のコールアウト 1 で種別として宣言され、コールアウト 2 で言及され、17 行目のコールアウト 3 で使用されています。コールアウト 1 の ​`product_name`​ を右クリックし、​**\[Rename Symbol (シンボルの名前を変更)\]**​ オプションを使用してその名前を変更すると、​`product_name`​ はコールアウト 3 でのみ変更されます。 #%RAML 1.0 title: Test Renaming types: product\_name: **(1)** type: object properties: name: string /test: get: responses: 200: description: product\_name **(2)** body: application/json: type: product\_name **(3)** ## [](#宣言可能なオブジェクトの名前を強調表示する)宣言可能なオブジェクトの名前を強調表示する ファイル内で使用されている宣言可能なオブジェクトの名前を強調表示できます。 オブジェクトが使用されるファイル内のすべての場所を表示するには、そのオブジェクトが宣言されている場所でオブジェクトの名前にカーソルを置いてクリックします。 たとえば、次のサンプル API 仕様では、5 行目の最初のコールアウトで種別 ​`person`​ が宣言されています。その後、この種別は 16 行目の 2 番目のコールアウトで使用されます。5 行目の ​`person`​ をクリックすると、テキストエディターで 16 行目の ​`person`​ が強調表示されます。 #%RAML 1.0 title: Test Highlighting types: person: **(1)** type: object properties: name: string /test: get: responses: 200: body: application/json: type: person **(2)** この強調表示は、種別、セキュリティスキーム、リソース種別、特性など、宣言可能なすべてのオブジェクトで機能します。 強調表示は、オブジェクトが使用される場所でのみ表示され、その名前が表示されるすべての場所で表示されるわけではありません。たとえば次の例では、API 仕様 ​`person`​ は、5 行目のコールアウト 1 で種別として宣言され、14 行目のコールアウト 2 で言及され、17 行目のコールアウト 3 で使用されています。コールアウト 1 の ​`person`​ をクリックすると、コールアウト 3 の ​`person`​ のみが強調表示されます。 #%RAML 1.0 title: Test Highlighting types: person: **(1)** type: object properties: name: string /test: get: responses: 200: description: person **(2)** body: application/json: type: person **(3)** ## [](#定義が参照されている場所を見つける)定義が参照されている場所を見つける 特定の定義が参照されている場所に移動するには、定義を右クリックし、​**\[Go to References (参照に移動)\]**​ を選択します。 たとえば、次のサンプル API 仕様では、5 行目の最初のコールアウトで種別 ​`person`​ が宣言されています。その後、この種別は 14 行目の 2 番目のコールアウトと 22 行目の 3 番目のコールアウトで使用されます。 #%RAML 1.0 title: Test References uses: lib: library.raml types: person: **(1)** description: this is person's description properties: firstname: string manager: type: lib.manager Alertable: manager | person **(2)** /person: get: responses: 200: body: application/json: type: person\[\] **(3)** 5 行目の ​`person`​ を右クリックし、​**\[Go to References (参照に移動)\]**​ を選択すると、​`person`​ の場所 (コールアウト 2 とコールアウト 3) のリストが表示されます。リストされた場所をダブルクリックすると、関連する行に移動します。 **\[Go to References (参照に移動)\]**​ では、以下もサポートされます。 - RAML リソース種別および特性 - RAML 型の式 - ライブラリの別名 - JSON パスナビゲーションでリンクされている参照 - `annotationTypes`​、​`securitySchemes`​、​`resourceTypes`​、​`traits`​ などのマクロを適用するノードへの参照 ## [](#コード範囲を選択する)コード範囲を選択する \[Selection Ranges (選択範囲)\] により、コードブロックを選択したり、その選択を拡張したりできます。 範囲を選択するには、要素をクリックして、Control + Shift + \[左矢印 | 右矢印\] を押します。右矢印キーは範囲を増やします。左矢印キーは範囲を減らします。 たとえば、次のコードの ​`body:`​ をクリックして、Control + Shift + 右矢印を押すと、​`body:`​ のみが含まれる選択範囲が作成されます。 ![30%](/mulesoft/current/ja-jp/design-center/_images/apid-helpful-text-editor-1.png) Control + Shift + 右矢印をもう一度押すと、次のような選択範囲になります。 ![30%](/mulesoft/current/ja-jp/design-center/_images/apid-helpful-text-editor-2.png) Control + Shift + 左矢印を押すと、選択範囲がなくなり、再度 ​`body:`​ のみが選択された状態になります。 ## [](#記号に移動する)記号に移動する ドキュメントの任意の場所を右クリックして、​**\[Go to Symbol (記号に移動)\]**​ を選択すると、定義された記号のリストが表示されます。 ![75%](/mulesoft/current/ja-jp/design-center/_images/apid-helpful-text-editor-3.png) 記号を選択すると、ドキュメントのその場所に移動します。 ## [](#要素を宣言に抽出する)要素を宣言に抽出する リファクタリングヘルパーを利用して、設計の継続的な改善を容易に行うことができます。そのようなヘルパーにより、宣言可能なインライン要素を最上位の宣言に抽出して、再利用できるようになります。 宣言可能なインライン要素と一致する範囲を選択すると、要素の左側にアイコンが表示されます。 ![37%](/mulesoft/current/ja-jp/design-center/_images/apid-helpful-text-editor-4.png) アイコンをクリックして、​**\[Extract to Declaration (宣言に抽出)\]**​ を選択すると、ドキュメントに次の 2 つの変更が加えられます。 ![37%](/mulesoft/current/ja-jp/design-center/_images/apid-helpful-text-editor-5.png) 最初のコールアウトは、​`type: lib.manager`​ が ​`type: newtype`​ に置き換わったことを示しています。(2 番目のコールアウトで示されているように) ​`newtype`​ 宣言が ​`manager`​ スコープの外側に配置され、​`newtype`​ を再利用できるようになります。 抽出された宣言名は、元の名前に基づきます。名前がすでに同じ種類の別の宣言で使用されている場合、自動的に名前の最後に増分番号が追加されます。宣言の名前は変更できます。 `types`​ 宣言と共に、​`resourceTypes`​ 宣言と ​`traits`​ 宣言も抽出できます。 # テキストエディターの複数のタブでの編集 API Designer のテキストエディターで、複数のファイルを同時に開くことができます。各ファイルは、独自のタブで開くことができます。 ## [](#新しいタブでファイルを開く)新しいタブでファイルを開く 新しいタブでファイルを開くには、次の 4 つの方法があります。 - 右側の 3 つのドットをクリックして、ファイルツリー内のファイルのコンテキストメニューを開き、​**\[Open In New Tab (新しいタブで開く)\]**​ を選択する。 - Command キー (MacOS) または Ctrl キー (Windows) を押して、ファイルツリー内のファイルの名前をクリックする。 +\[注意\] これらのキーのいずれかを最初に押さずにファイルツリー内のファイル名をクリックすると、現在のタブで開いているファイルが置き換えられます。 - RAML の ​`include`​ タグや OAS の ​`$ref`​ キーワードなど、ファイル参照内のファイルの名前にカーソルを置く。 その後、Command キー (MacOS) または Ctrl キー (Windows) を押して、ファイル名をクリックします。 - 画面下部のエラービューの ​**\[Location (場所)\]**​ 列でファイル名をクリックする。 ## [](#別のタブへの移動)別のタブへの移動 タブバーは、少なくとも 2 つのファイルが開いている場合にのみ、エディターの上部に表示されます。 現在開いているタブの左側にあるタブに切り替えるには、次のいずれかの手順を実行します。 \* Option + Shift + Tab キー (MacOS) または Alt + Shift + Tab キー (Windows) を押す。 \* 省略記号をクリックしてタブバーのメニューを開き、​**\[Previous Tab (前のタブ)\]**​ を選択する。 現在開いているタブの右側にあるタブに切り替えるには、次のいずれかの手順を実行します。 \* Option + Tab キー (MacOS) または Alt + Tab キー (Windows) を押す。 \* 省略記号をクリックしてタブバーのメニューを開き、​**\[Next Tab (次のタブ)\]**​ を選択する。 ## [](#タブを閉じる)タブを閉じる 1 つのタブを閉じるには、そのタブに表示されている X アイコンをクリックします。 現在開いているタブ以外のすべてのタブを閉じるには、タブバーの右側にある省略記号をクリックし、​**\[Close All Other Tabs (他のすべてのタブを閉じる)\]**​ を選択します。 # テンプレートからの Mule アプリケーションの迅速な作成:page-support-status: eolScheduled Flow Designer で最も簡単に開始する方法は、テンプレートを使用することです。 テンプレートはカスタマイズ可能な事前作成済みのインテグレーションです。 Anypoint Exchange に移動して、最も一般的なインテグレーションユースケース用のテンプレートを参照します。Flow Designer ではテンプレートを参照のみモードで開いて確認できます。必要な Mule アプリケーションを作成するのにテンプレートが役立つと考えられる場合、そのテンプレートから新しいプロジェクトを作成し、カスタマイズして、アプリケーションのテストとデプロイができます。 ## [](#手順)手順 1. Exchange で、使用するテンプレートを探します。 1. 画面の左側にある ​**\[All assets (すべてのアセット)\]**​ で ​**\[Provided by MuleSoft (MuleSoft による提供)\]**​ をクリックします。 2. 検索バーの左にあるドロップダウンリストで ​**\[Templates (テンプレート)\]**​ を選択します。 3. 用語を検索し、テンプレートのリストを絞り込みます。 4. テンプレートをクリックして詳細を表示します。詳細は次のとおりです。 - テンプレートの機能の概要 - 使用するための前提条件のリスト - 設定するための手順 5. 詳細ページの右上隅にあるオプション ​**\[Open flow (フローを開く)\]**​ を探します。このボタンが存在する場合、テンプレートは Flow Designer と互換性があることを示します。オプションが ​**\[Download (ダウンロード)\]**​ のみの場合、テンプレートは Anypoint Studio とのみ互換性があります。 2. **\[Open flow (フローを開く)\]**​ をクリックします。 **結果:**​ Flow Designer でテンプレートが参照のみモードで開きます。参照のみモードでは、どのコネクタと操作が使用されているか、フローを通過する過程でデータがどう変化しているか、システムにどのような接続設定がセットアップ済みかを確認できます。 3. テンプレートがニーズに合うと思われる場合は、Flow Designer の右上隅にある ​**\[Use this template (このテンプレートを使用)\]**​ をクリックします。 **結果:**​ ダイアログボックスで、テンプレートに基づいて新しいプロジェクトに名前を付けて、作成先の環境を選択するように要求されます。​**\[Create (作成)\]**​ をクリックすると、プロジェクトが編集モードで開きます。カードの上の赤いドットは、アプリケーションを実行する前に項目に入力する必要がある場所を示します。たとえば、カードで表されているシステムを認証するためのログイン情報を入力する必要があります。 4. 必須情報を入力します。 1. 画面の一番下にある ​**\[Problems (問題)\]**​ タブをクリックして、問題のリストを表示します。 2. リスト内の問題をクリックすると、情報を入力する必要があるアプリケーション内の場所に移動します。カードにどのような情報を入力する必要があるかについてのガイダンスは、​**\[Notes (メモ)\]**​ タブをクリックしてそのカードのメモを参照してください。 3. 問題がなくなるまで、問題のリストに引き続き対処します。 **結果:**​ カードの上にあった赤いドットがすべてなくなります。この時点でアプリケーションを実行できます。ただし、まず、特定のユースケースに合わせてアプリケーションをカスタマイズしなければならない場合があります。これは、次のステップで実行できます。 たとえば、フローに Slack Connector のカードがあり、フローで Slack チャネルにメッセージを投稿する場合、メッセージを入力する必要があります。また、チャネルのデフォルト名は ​`general`​ です。この名前を、フローでの実際の投稿先のチャネル名に一致するように変更する必要もあるでしょう。 5. 各カードを開き、その項目の値を確認して、ユースケースで必要であると思われる値をカスタマイズします。 カスタマイズ中のガイダンスについては、各カードの ​**\[Notes (メモ)\]**​ セクションを参照してください。 6. 準備が整ったら、​**\[Run (実行)\]**​ をクリックし、アプリケーションを一時的に実行して、テストします。アプリケーションの実行中にそのフローをトリガーし、データがフローを適切に通過していることを確認できます。​**\[Run (実行)\]**​ をクリックした後、アプリケーションに変更を加えない限り、アプリケーションは継続的に 60 分間実行されます。変更を加えると、アプリケーションは実行を停止します。 7. アプリケーションに満足したら、​**\[Deploy (デプロイ)\]**​ ボタンをクリックして、アプリケーションを Sandbox 環境または本番環境で実行します。 ## [](#関連情報)関連情報 [Mule アプリケーションのデプロイ (Flow Designer)](https://docs.mulesoft.com/jp/design-center/promote-app-prod-env-design-center) # ビジュアル API エディターでの API 仕様の作成 API Designer のビジュアル API エディターを使用して、RAML 1.0、OAS 2.0 または 3.0 (JSON) で API 仕様をスキャフォールディングできます。これを行うには、言語に依存しないフォームを入力します。 ## [](#始める前に)始める前に Anypoint Platform で、自分のユーザー ID に ​_Design Center 開発者_​権限を割り当てておく必要があります。 ## [](#このタスクについて)このタスクについて ビジュアル API エディターは 3 つのパネルに分かれています。 ### [](#左側のパネル)左側のパネル このパネルには、開発している API 仕様の名前が表示されます。また、提供されているコントロールを使用して、リソース、データ型、およびセキュリティスキームを作成することもできます。これらのコンポーネントは仕様の本文内にすべて含まれ、個別のファイルとして作成されません。 ### [](#中央のパネル)中央のパネル このパネルには、仕様のコンポーネントのプロパティを指定するためのフォームがあります。エディターを初めて開くと、仕様の主要なプロパティを指定し、仕様をドキュメント化するためのフォームが表示されます。左側のパネルで項目の名前をクリックすると、そのフォームが中央のパネルで開きます。 ### [](#右側のパネル)右側のパネル このパネルには、RAML Viewer と OAS Viewer が表示されています。これらは共に参照のみです。パネルの下部にあるタブをクリックすると、これらが切り替わります。これらのビューアーには、仕様の現在のドラフトが RAML 1.0 または OAS 3.0 形式で表示されます。中央のパネルに表示されたフォームに値を入力すると、ドラフトがその値で更新されます。 また、このパネルでは、モッキングサービスを実行して、セットアップしたエンドポイントをテストすることもできます。 ## [](#手順)手順 1. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで、​**\[Create new (新規作成)\]**​ をクリックします。 2. **\[New API Specification (新しい API 仕様)\]**​ を選択します。 3. **\[New API Specification (新しい API 仕様)\]**​ ダイアログで、プロジェクトに名前を付けます。 名前は後で必要に応じて変更できます。 4. **\[Guide me through it (手順に従って操作)\]**​ オプションを選択して、ビジュアル API エディターを使用します。 5. **\[Create API Spec (API 仕様を作成)\]**​ をクリックします。 _結果:_​ ビジュアル API エディターが開きます。 作業中は、モッキングサービスを実行して、API 仕様のコールをシミュレートできます。詳細については、このトピックの最後にある​**「関連情報」**​にある「API コールのシミュレーション」を参照してください。 仕様を直接編集またはカスタマイズする (RAML フラグメントをインポートするなど) 必要がある場合は、​**\[Edit RAML (RAML を編集)\]**​ または ​**\[Edit OAS (OAS を編集)\]**​ をクリックすると、いつでも API エディターに切り替えることができます。ただし、一度切り替えた後は、ビジュアル API エディターに戻って API 仕様の作成を継続することはできません。 ## [](#次のステップ)次のステップ API 仕様が完成したら、RAML 1.0 形式で Exchange にパブリッシュすることができます。​[「API 仕様のパブリッシュ」](https://docs.mulesoft.com/jp/design-center/design-publish)​を参照してください。 また、​**\[Edit RAML (RAML を編集)\]**​ または ​**\[Edit OAS (OAS を編集)\]**​ をクリックして、API エディターで仕様をカスタマイズできます。 ## [](#関連情報)関連情報 - [API コールのシミュレーション](https://docs.mulesoft.com/jp/design-center/design-mocking-service) - [API 仕様のパブリッシュ](https://docs.mulesoft.com/jp/design-center/design-publish) - [オープンプロジェクトの名前の変更](https://docs.mulesoft.com/jp/design-center/design-rename-project) - [プロジェクトの削除](https://docs.mulesoft.com/jp/design-center/design-delete-project) # フローでのデータ型の定義および使用 (Flow Designer):page-support-status: eolScheduled フローの各カードには特定の型の入力データが必要です。また、各カードは特定の型のデータを出力します。フローを構築する場合、カードが入力として必要とするデータ型と、カードが出力として生成するデータ型を指定する必要があります。これにより、フローの各カードで必要とされるデータ型を把握できるため、作成するフローを容易に計画できます。 _データ型_​は、入力と出力に含まれるデータの形式と構造を Flow Designer に説明するものです。Flow Designer では、シンプルとカスタムの 2 つのカテゴリのデータ型がサポートされます。これらのカテゴリについての詳細は、次のトピックを参照してください。 - [Flow Designer でサポートされるシンプルデータ型](https://docs.mulesoft.com/jp/design-center/fd-supported-simple-data-types) - [Flow Designer でのカスタムデータ型](https://docs.mulesoft.com/jp/design-center/fd-custom-data-types) ## [](#手順)手順 データ型を定義および使用する方法はいくつかありますが、チュートリアル​[「Flow Designer での最初の Mule アプリケーションの作成」](https://docs.mulesoft.com/jp/design-center/salesforce-to-twilio)​で使用されている方法をお勧めします。 1. **\[Project (プロジェクト)\]**​ ペインの見出し ​**\[Data Types (データ型)\]**​ の右にあるプラス記号をクリックします。 2. **\[New Type (新しい型)\]**​ ダイアログでデータ型を定義します。 **結果:**​ ​**\[Project (プロジェクト)\]**​ ペインの ​**\[Data Types (データ型)\]**​ セクションに新しいデータ型が表示されます。 3. データ型を使用する必要があるフロー内の場所で、次の手順を実行します。 - カードへの入力のデータ型を使用するには、カードを開き、カードの上部にある ​**\[Input (入力)\]**​ タブを選択して、​**\[Data type (データ型)\]**​ ドロップダウンリストからデータ型を選択します。 - カードの出力のデータ型を使用するには、カードを開き、カードの上部にある ​**\[Output (出力)\]**​ タブを選択して、​**\[Data type (データ型)\]**​ ドロップダウンリストからデータ型を選択します。 ## [](#関連情報)関連情報 [入力データへの出力データのマッピング](https://docs.mulesoft.com/jp/design-center/fd-transform) # フローへのロジック、データ変換、エラーキャッチなどの追加 (Flow Designer):page-support-status: eolScheduled さまざまなタスクを実行するカードを追加して、フローの流れの変更、メッセージの記録、データの変換、変数またはペイロードの追加または削除などを行うことができます。これらのカードは Mule アプリケーションのコンポーネントを表すものであり、Mule Runtime によって提供されます。 コンポーネントを表すカードを追加する方法は、他のカードをフローに追加する方法と同じです。つまり、前のカードの後に表示されているプラスアイコンをクリックして、リストから新しいカードを選択します (次の画像を参照)。 ![fd supported core components](/mulesoft/current/ja-jp/design-center/_images/fd-supported-core-components.png) Figure 1. Flow Designer でサポートされるコンポーネント Flow Designer では次のコンポーネントがサポートされます。 Choice フローでデータを評価し、データの送信先のルートを複数のルートから決定する場合、Choice コンポーネントを使用します。 ![fd choice](/mulesoft/current/ja-jp/design-center/_images/fd-choice.png) Figure 2. フローで使用されている Choice カード 1. カードはその出力を Choice カードに渡します。カードは式を使用してデータを評価し、次のロジックに従います。 - データが ​_x_​ の場合、データを 1 つのサブフローにルーティングする。 - データが ​_y_​ の場合、データを別のサブフローにルーティングする。 - データが、カードに設定されたデフォルト値の場合、データをデフォルトのサブフローにルーティングする。 2. サブフローの出力は、Choice カードの後のカードに送信されます。 Flow Ref フローに Flow Ref コンポーネントを配置することで、同じアプリケーション内の 1 つのフローから別のフローを実行することができます。​[「Flow Ref によるフローから別のフローの参照」](https://docs.mulesoft.com/jp/design-center/reference-flow-task-design-center)​を参照してください。 For-Each For-Each コンポーネントは、ペイロードを要素に分割し、それらを 1 つずつ、スコープ内に配置したコンポーネントで処理します。​[「コレクションの要素の処理」](https://docs.mulesoft.com/jp/design-center/fd-iterating)​を参照してください。 Logger 1 つ以上の Logger カードをフローに追加すると、実行中の Mule アプリケーションを通過するデータの流れを監視できるほか、実行時の重要な情報 (エラーメッセージ、状況通知、ペイロードなど) を記録して Mule アプリケーションをデバッグできます。Logger カードはフローの任意の場所に配置できます。指定した文字列のほか、​**\[Custom Expression (カスタム式)\]**​ ダイアログを使用して作成した DataWeave 式の出力や、文字列と式の任意の組み合わせを記録できます。 Logger カードの出力は ​**\[Logs (ログ)\]**​ ペインに表示されます。このペインを開くには、Flow Designer の右下にある ​**\[Logs (ログ)\]**​ タブをクリックします。 Parallel For-Each Parallel For-Each コンポーネントは、ペイロードを要素に分割し、それらを同時に、スコープ内に配置したコンポーネントで処理します。​[「コレクションの要素の処理」](https://docs.mulesoft.com/jp/design-center/fd-iterating)​を参照してください。 Remove Variable Remove Variable コンポーネントは変数の名前を取得し、変数をフローから削除します。 Set Payload Set Payload コンポーネントを使用すると、フローの任意の時点で現在のデータのペイロードを変更できます。ペイロードを文字列に置き換えたり、DataWeave 式でペイロードを変更または置き換えたりできます。 Set Variable Set Variable コンポーネントを使用して変数を作成し、前のカードからの出力のすべてを保存したり、出力の一部を保存したり、DataWeave 式で関数を使用して出力を操作したりすることができます。その後、変数を使用して後のカードで値を再利用できます。​[「カードの出力のすべてまたは一部を変数に保存」](https://docs.mulesoft.com/jp/design-center/to-create-and-populate-a-variable)​を参照してください。 Transform Transform コンポーネントは、入力データを新しい出力構造または形式に変換します。 Try エラーを起こしやすい特定のフロー部分は Try カード内に配置できます。Try 内のフロー部分でエラーが発生すると、Try はエラーをキャッチして修正を適用するか、または代替コードを実行します。​[「Try を使用したエラーの処理」](https://docs.mulesoft.com/jp/design-center/error-handling-task-design-center)​を参照してください。 # フロー内のデータに基づく値の保存と再利用 (Flow Designer):page-support-status: eolScheduled 変数を使用して値を保存し、Mule アプリケーションのフロー内で使用できます。変数を作成したら、フロー内の後続のあらゆるカードでその変数を使用できます。 値を変数に保存する方法は 2 つあります。 [カードの出力のすべてまたは一部を変数に保存](https://docs.mulesoft.com/jp/design-center/to-create-and-populate-a-variable)​ Set Variable カードを使用して変数を作成し、カードの出力からのデータを保存または操作できます。その後、変数を使用して後のカードでデータを再利用できます。 [カードの出力全体を変数に保存](https://docs.mulesoft.com/jp/design-center/fd-store-reuse-output)​ 出力をフロー内の次のカードに渡すのではなく、カードの出力を保存できます。通常、カードは、入力として受け取ったデータとは異なるデータを出力します。ただし、対象変数を作成した場合、カードはその出力を (そのまま、削減して、または操作して) 対象変数に保存し、対象変数と、入力として受け取ったメッセージと同じメッセージを次のカードに渡します。 # プロジェクトでコネクタが使用する接続の切り替え:page-support-status: eolScheduled Mule アプリケーションプロジェクトのフローに含めるすべてのコネクタは、接続を使用して実行時にシステムに接続します。​_接続_​は、実行中の Mule アプリケーションがコネクタを介して特定のシステムに接続するときに使用する必要のある保存済みの情報セットです。たとえば、Salesforce への特定の接続を使用するには、Salesforce Connector を設定します。これは、データベースへの特定の接続を使用するための Database Connector のインスタンスです。 別の接続を使用するように設定を変更したり、別の接続を使用する設定を作成して使用したりできます。 たとえば、Database Connector のインスタンスをフローに追加するとします。そのインスタンスの設定 Config 1 を作成する場合、接続 MySQL を作成し、Mule アプリケーションが実行時に MySQL データベースに接続するために必要とする情報を指定します。ここで、Oracle データベースに対して Mule アプリケーションをテストします。 Oracle データベースの設定には個別の接続だけでなく別の追加情報も必要なため、設定 Config 2 と接続 Oracle を作成します。次に、Config 2 を使用するように切り替えます。 ![Database Connector の \[Advanced (詳細)\] セクション](_images/fd-config-advanced.png) Figure 1. コネクタに対して作成する設定ごとに、​**\[Advanced (詳細)\]**​ セクションを使用して、接続に加えて、使用する設定の情報を指定できます。
1[Advanced (詳細)]​ セクションを開くためにクリックするテキスト
2Database Connector のインスタンスに関する指定可能な追加情報
この図は Config 1 から Config 2 への切り替えを示しています。 ![設定の切り替えによる接続の切り替え](/mulesoft/current/ja-jp/design-center/_images/fd-connections-configs-connectors-switch-1.png) Figure 2. この図は、1 つの設定から別の設定に切り替えることで接続を切り替えることができることを示しています。 この図では、Database Connector のインスタンスは、接続 MySQL1 を使用する設定 Config 1 を使用しています。別の MySQL データベースに切り替える必要があり、そのデータベースに接続するのに、設定で提供されている情報を変更する必要がない場合、単に接続 MySQL2 を使用するように設定を変更できます。 ![設定での接続の切り替え](/mulesoft/current/ja-jp/design-center/_images/fd-connections-configs-connectors-switch-2.png) Figure 3. この図は、設定で接続を切り替えることができることを示しています。 **プロジェクトでコネクタが使用している接続を切り替える方法** - 接続を切り替える必要があり、設定に異なる追加情報を含める必要もある場合、切り替え先の接続を使用する設定を作成します。 1. 別の接続に切り替える必要があるコネクタを表すカードを開きます。 2. カードの上部にある ​**\[Switch configurations (設定を切り替え)\]**​ をクリックします。 3. **\[Add (追加)\]**​ をクリックします。 4. 新しい設定を作成し、使用する接続を選択するか作成して、​**\[Save (保存)\]**​ をクリックします。 **結果:**​ カードの ​**\[Connector configuration (コネクタ設定)\]**​ 領域で、新しい設定が選択されたことが示されます。また、キャンバスの左側にある ​**\[Project (プロジェクト)\]**​ ペインの ​**\[Reusable Configurations (再利用可能な設定)\]**​ セクションに設定がリストされます。​**\[Back (戻る)\]**​ をクリックします。 - 接続を切り替える必要があり、設定に異なる追加情報を含める必要がない場合、切り替え先の接続を使用するように設定を編集します。 1. キャンバスの左側にある ​**\[Project (プロジェクト)\]**​ ペインの ​**\[Reusable Configurations (再利用可能な設定)\]**​ セクションで、編集する設定をクリックします。 2. 使用する接続を選択するか作成します。 3. **\[Save (保存)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [コネクタの設定への接続の追加](https://docs.mulesoft.com/jp/design-center/fd-connection-create) # プロジェクトの削除 API 仕様プロジェクトや API フラグメントプロジェクトを削除できます。すでにパブリッシュしているプロジェクトを API Designer で削除しても、Anypoint Exchange から削除されません。

プロジェクトを削除すると、完全に削除されます。削除したプロジェクトは、​ゴミ箱​フォルダーに移動​しない​ため、気が変わってもプロジェクトを復元することはできません。

## [](#手順)手順 プロジェクトを削除するには、次のいずれかの方法を使用します。 - プロジェクトが開いていない場合、Design Center の ​**\[Projects (プロジェクト)\]**​ ページでプロジェクトを選択し、ページの右上隅にある削除アイコンをクリックします。 - プロジェクトが開いている場合、API Designer の右上隅にある歯車アイコンをクリックし、​**\[Delete (削除)\]**​ を選択します。 # プロジェクトの名前の変更 API 仕様プロジェクトや API フラグメントプロジェクトの名前を変更できます。すでにパブリッシュしているプロジェクトの名前を変更した場合、そのプロジェクトを再度パブリッシュしても Exchange に新しいアセットは作成されません。 ## [](#手順)手順 プロジェクトの名前を変更するには、次のいずれかの方法を使用します。 - プロジェクトが開いていない場合、Design Center の ​**\[Projects (プロジェクト)\]**​ ページでプロジェクトを選択し、ページの右上隅にある編集アイコンをクリックします。 - プロジェクトが開いている場合、API Designer の右上隅にある歯車アイコンをクリックし、​**\[Rename (名前変更)\]**​ を選択します。 # プロジェクトの変更内容の確認:page-support-status: eolScheduled Flow Designer でプロジェクトに対して行った変更の履歴を確認できます。 保存された状態が変更の日時ごとにリストされます。 保存された状態の名前は、プロジェクトを保存するときに実行したアクティビティに基づいています。 プロジェクトの保存された状態に復元できると、次の作業を行う場合に役立ちます。 - プロジェクトに対して誤って行った変更を取り消し、稼働状態に戻す。 - 他のユーザーがプロジェクトに対して行った変更を確認する。 - コネクタ設定の以前の値を取得する。 ## [](#手順)手順 プロジェクトの以前の状態に戻す手順は、次のとおりです。 1. キャンバスの左上にある ​**\[History (履歴)\]**​ をクリックし、右側の \[Project History (プロジェクト履歴)\] リストを開きます。 2. リストから保存された状態をクリックします。 保存された状態は、キャンバスのプロジェクトの各カードの参照のみビューです。 3. 任意のカードをクリックして、その設定の詳細を確認します。 これは、値を確認するのに便利です。 4. プロジェクトを戻す状態を選択したら、キャンバスの上部で ​**\[Restore (復元)\]**​ をクリックします。確認ダイアログが表示されます。 5. 選択した状態に復元してキャンバスに戻るには、​**\[Restore (復元)\]**​ をクリックします。復元された状態が履歴リストの最上部に移動します。 # プロジェクトの複製 API Designer でプロジェクトを複製できます。特定のプロジェクトのベースとなるプロジェクトを失うことなくそのプロジェクトに大幅な変更を加える必要がある場合は、プロジェクトを複製することをお勧めします。 元のプロジェクトにリストされている連動関係は、複製プロジェクトに保持されます。 ## [](#開始する前に)開始する前に - モッキングサービスが有効でないことを確認する。 - プロジェクトが参照のみモードでないことを確認する。 ## [](#手順)手順 1. プロジェクトを開きます。 2. エディターの右上隅にある歯車アイコンをクリックします。 3. **\[Duplicate (複製)\]**​ を選択します。 4. 複製オブジェクトに名前を付け、​**\[Duplicate (複製)\]**​ をクリックします。 ## [](#結果)結果 API Designer で、新しいブラウザータブが開き、新しいプロジェクトが表示されます。元のプロジェクトがテキストエディター内にある場合、複製プロジェクトはテキストエディターで開かれます。元のプロジェクトがビジュアルエディター内にある場合、複製プロジェクトはビジュアルエディターで開かれます。 元のプロジェクトがサブ分岐にあった場合、複製プロジェクトは同じサブ分岐に置かれます。 複製プロジェクトは Design Center のプロジェクトリストに含まれます。 # モッキングサービスを使用した API コールのシミュレーション API モッキングサービスにより、API 仕様の動作をシミュレーションできます。モッキングサービスには、API へのテストリンクが用意されています。モッキングサービスは、API 仕様で定義されている応答 (HTTP 状況コードとペイロード例の両方) を返すため、テストや API の動作確認に便利です。 エンドポイントを API 仕様に追加すると、API Designer によって自動的に API へのリンクが生成され、このリンクはブラウザーで使用できます。Anypoint Platform 外のユーザーと共有できる公開リンクを有効にすることもできます。 モッキングサービスは Anypoint Platform の機能の 1 つであり、継続的に実行されます。モッキングサービスは、テキストエディター、ビジュアルエディター、および Anypoint Exchange から実行できます。API コールのシミュレーションは、API 仕様を Exchange にパブリッシュする前であれば API Designer で、パブリッシュ後であれば Exchange で行うことができます。 ベース URI (RAML) またはベースパス (OAS) を指定した場合、API Designer では、API コールをシミュレーションするときにベース URI またはモッキングサービスのいずれかを使用できます。API Designer では、API に対する変更が行われません。 ## [](#始める前に)始める前に API Designer に API 仕様が含まれるプロジェクトがある必要があります。また、API 仕様内で 1 つ以上のエンドポイントを定義している必要があり、各エンドポイントには 1 つ以上のメソッドが必要です。 ## [](#内部-url-を使用して-api-へのコールをシミュレーションする)内部 URL を使用して API へのコールをシミュレーションする

内部 URL にアクセスするには、要求 URL の一部として認証ヘッダーを指定する必要があります。認証ヘッダーを指定せずに API をテストするには、このプロジェクト用のモッキングサービス公開 URL を生成します。

1. API Designer から、テストする API が含まれるプロジェクトを開きます。 テキストエディターまたはビジュアルエディターを使用できます。 2. プロジェクトのルートファイルを選択します。 3. 右側のツールバーの ​**\[Documentation (ドキュメント)\]**​ アイコンをクリックします。 4. ドロップダウンメニューから、​**\[Summary (概要)\]**​ を選択します。 5. エンドポイントの名前をクリックします。 6. API 仕様で ​`baseURL`​ を定義している場合、次の操作を実行します。 - **\[Select server (サーバーを選択)\]**​ ドロップダウンをクリックして、次のいずれかを選択します。 - `baseUri`​: API 仕様で定義されている baseUri を使用します。 - Mocking Service (モッキングサービス): API モッキングサービスを使用します。 7. API のメソッドのいずれかをクリックして、​**\[Try it (試す)\]**​ をクリックします。 8. (省略可能) テストするパラメーターを指定して照会します。 クエリパラメーターは名前と値のペアとして入力できます。 9. **\[Send (送信)\]**​ をクリックします。 API Designer に API で指定した HTTP 戻りコードが表示されます。または、​**要求 URL**​ をコピーして API をテストし、Web ブラウザーまたは Postman に貼り付けることができます。 モッキングサービスの内部 URL を使用する場合、URL の一部として認証ヘッダーを指定する必要があります。この状況を回避するには、モッキングサービス公開 URL を使用します。 ## [](#set-mocking-service-as-default)デフォルトサーバーとしてのモッキングサービスの設定 モッキングサービスは ​**\[Documentation (ドキュメント)\]**​ パネルで使用されるデフォルトサーバーとして設定できます。これは、​**\[Select server (サーバーを選択)\]**​ ドロップダウンに表示されるデフォルト値です。 1. **\[Mocking Service Configuration (モッキングサービス設定)\]**​ をクリックします。 2. **\[Select by Default (デフォルトで選択)\]**​ スライダーをクリックします。 ## [](#公開-url-を使用して-api-へのコールをシミュレーションする)公開 URL を使用して API へのコールをシミュレーションする 認証ヘッダーを指定することなく、公開 URL を使用して API へのコールをテストします。この方法は、API を Anypoint Platform 外のユーザーと共有する場合に便利です。 1. API Designer から、テストする API が含まれるプロジェクトを開きます。 テキストエディターまたはビジュアルエディターを使用できます。 2. プロジェクトのルートファイルを選択します。 3. 右側のツールバーの ​**\[Mocking Service Configuration (モッキングサービス設定)\]**​ アイコンをクリックします。 4. **\[Make Public (公開する)\]**​ スライダーをクリックします。 API Designer によって API の公開 URL が生成されます。公開 URL を無効化すると、このオプションは無効になります。このオプションを再有効化すると、異なる URL が生成されます。 5. (省略可能) 公開 URL の有効期限を設定します。 1. **\[Set expiration date for public link (公開リンクの有効期限を設定)\]**​ をクリックします。 2. 日付セレクターを使用して、公開リンクを期限切れにする日付を選択します。 ## [](#関連情報)関連情報 - [シミュレーションする API コールへの動作ヘッダーの追加](https://docs.mulesoft.com/jp/design-center/apid-behavioral-headers) # ユーザーアクセス権限の設定 Design Center には、アクセス管理をセットアップしてチーム間のコラボレーションを提供するための複数の方法があります。 組織の権限構造に応じて、​[チーム](https://docs.mulesoft.com/jp/access-management/teams)​機能、​[ロール](https://docs.mulesoft.com/jp/access-management/users#roles)​機能 (非推奨) を使用するか、​[個々のユーザー権限](https://docs.mulesoft.com/jp/access-management/users#grant-user-permissions)​を割り当てることで、権限を割り当てることができます。 ## [](#design-center-権限)Design Center 権限 ### [](#ビジネスグループ権限)ビジネスグループ権限 Design Center Developer (Design Center 開発者) ユーザーはビジネスグループ内のすべてのプロジェクトを表示、作成、および管理できます。この権限を使用して、特定のビジネスグループ内のすべてのプロジェクトの管理者をセットアップします。 Design Center Creator (Design Center 作成者) ユーザーは Design Center でナビゲーションパネルからプロジェクトを作成できるほか、作成したまたはユーザーと共有しているすべてのプロジェクトを表示できます。この権限を使用して、プロジェクトを作成、編集、維持するユーザーを招待します。 Design Center Viewer (Design Center 閲覧者) ユーザーはビジネスグループ内のすべての Design Center プロジェクトを表示し、モッキングサービスを使用してプロジェクトをテストできます。この権限を持つユーザーは、新しいプロジェクトの作成、既存のプロジェクトの編集または名前変更、他のユーザーとのプロジェクトの共有を行うことはできません。特定のビジネスグループのプロジェクトをコンシュームするユーザーにこの権限を割り当てます。 ### [](#プロジェクトレベルの権限)プロジェクトレベルの権限 Project Administrator (プロジェクト管理者) ユーザーはビジネスグループ内の Design Center プロジェクトを管理および共有できます。この権限を使用して、特定のビジネスグループ内のすべてのプロジェクトの管理者をセットアップします。 Project Editor (プロジェクト編集者) ユーザーはビジネスグループ内の Design Center プロジェクトを編集できます。この権限を使用して、プロジェクトを作成、編集、維持するユーザーを招待します。 Project Viewer (Project 閲覧者) ユーザーはビジネスグループ内の Design Center プロジェクトを表示し、モッキングサービスを使用してプロジェクトをテストできます。この権限を持つユーザーは、新しいプロジェクトの作成、既存のプロジェクトの編集または名前変更、他のユーザーとのプロジェクトの共有を行うことはできません。特定のビジネスグループのプロジェクトをコンシュームするユーザーにこの権限を割り当てます。
組織およびプロジェクトの権限を付与する場合、最高の権限レベルは、その特定のプロジェクトに適用される権限レベルになります。
## [](#プロジェクトビュー)プロジェクトビュー Design Center のホームページから 3 種類のプロジェクトリストのビューを選択できます。 **API Projects (すべてのプロジェクト)**​: 自分がアクセスできるすべてのプロジェクトがリストされます。 **Shared with me (自分と共有)**​: 他のユーザーが自分と共有しているプロジェクトのみがリストされます。 **Mule flows (Mule フロー)**​: 自分が作成した Mule アプリケーションがリストされます。このビューは、「Design Center Developer (Design Center 開発者)」権限がある場合のみ使用できます。 ## [](#design-center-からのプロジェクトの共有)Design Center からのプロジェクトの共有
Mule アプリケーションは共有できません。
プロジェクトの共有および対応する権限の追加を Design Center から直接行う手順は、次のとおりです。 1. Design Center のホームページで、プロジェクトを選択します。 2. **\[Share project (プロジェクトを共有)\]**​ アイコンをクリックするか、​**\[Toggle project details (プロジェクトの詳細を切り替え)\]**​ アイコンをクリックして、​**\[Change access (アクセス権を変更)\]**​ をクリックします。 1. **\[Share project (プロジェクトを共有)\]**​ ダイアログボックスで、アクセス権を付与する、組織のユーザーまたはチームの名前を入力します。 2. ドロップダウンリストから権限レベルを選択します。使用可能なオプションは、\[Viewer (閲覧者)\]、\[Editor (編集者)\]、および \[Admin (管理者)\] です。 3. **\[Save (保存)\]**​ をクリックして、​**\[Close (閉じる)\]**​ をクリックします。
このアクションにより、プロジェクトがユーザーと共有されたことを通知するメールがユーザーに送信されます。
## [](#api-designer-からのプロジェクトの共有)API Designer からのプロジェクトの共有 プロジェクトの共有および対応する権限の追加を API Designer から直接行う手順は、次のとおりです。 1. Design Center のホームページから、プロジェクト名のリンクをクリックしてプロジェクトを開きます。 2. **\[Share (共有)\]**​ ボタンをクリックします。 1. **\[Share project (プロジェクトを共有)\]**​ ダイアログボックスで、アクセス権を付与する、組織のユーザーまたはチームの名前を入力します。 2. ドロップダウンリストから権限レベルを選択します。使用可能なオプションは、\[Viewer (閲覧者)\]、\[Editor (編集者)\]、および \[Admin (管理者)\] です。 3. **\[Save (保存)\]**​ をクリックして、​**\[Close (閉じる)\]**​ をクリックします。
このアクションにより、プロジェクトがユーザーと共有されたことを通知するメールがユーザーに送信されます。
## [](#design-center-からプロジェクトの所有者を変更する)Design Center からプロジェクトの所有者を変更する プロジェクトオーナーまたは組織のシステム管理者であれば、プロジェクトのオーナーを変更できます。Design Center から直接プロジェクトのオーナーを変更する手順は、次のとおりです。 1. Design Center のホームページで、プロジェクトを選択します。 2. **\[Share project (プロジェクトを共有)\]**​ アイコンをクリックするか、​**\[Toggle project details (プロジェクトの詳細を切り替え)\]**​ アイコンをクリックして、​**\[Change access (アクセス権を変更)\]**​ をクリックします。 1. **\[Share project (プロジェクトを共有)\]**​ ダイアログボックスで、プロジェクトのオーナーにする、組織のユーザーの名前を入力します。 2. ドロップダウンリストから ​**\[Transfer Ownership (オーナーを変更)\]**​ を選択します。 3. **\[Save (保存)\]**​ をクリックして、​**\[Close (閉じる)\]**​ をクリックします。 _結果_​: 新しいオーナーがプロジェクトの詳細に表示され、前のオーナーには「Project administrator (プロジェクト管理者)」権限が付与されます。これは、プロジェクトごとに 1 人のオーナーしか指定できないためです。 ## [](#api-designer-からプロジェクトのオーナーを変更する)API Designer からプロジェクトのオーナーを変更する プロジェクトオーナーまたは組織のシステム管理者であれば、プロジェクトのオーナーを変更できます。API Designer から直接プロジェクトのオーナーを変更する手順は、次のとおりです。 1. Design Center のホームページから、プロジェクト名のリンクをクリックしてプロジェクトを開きます。 2. **\[Share (共有)\]**​ ボタンをクリックします。 1. **\[Share project (プロジェクトを共有)\]**​ ダイアログボックスで、プロジェクトのオーナーにする、組織のユーザーの名前を入力します。 2. ドロップダウンリストから ​**\[Transfer Ownership (オーナーを変更)\]**​ を選択します。 3. **\[Save (保存)\]**​ をクリックして、​**\[Close (閉じる)\]**​ をクリックします。 _結果_​: 新しいオーナーがプロジェクトの詳細に表示され、前のオーナーには「Project administrator (プロジェクト管理者)」権限が付与されます。これは、プロジェクトごとに 1 人のオーナーしか指定できないためです。 ## [](#プロジェクトからのアクセス権の削除)プロジェクトからのアクセス権の削除 1. API Designer または Design Center から ​**\[Share project (プロジェクトを共有)\]**​ ダイアログを開きます。 2. アクセス権を削除するユーザーまたはチームのドロップダウンリストから ​**\[Remove Access (アクセス権を削除)\]**​ を選択します。 3. **\[Close (閉じる)\]**​ をクリックします。 # 一般的なフローデザインタスク (Flow Designer) フローのトリガーを選択して設定したら、次はモジュールと API のリストから選択してフローに追加します。リストは、モジュールのみまたは API のみを表示するように絞り込むことができます。 ![コンポーネントの選択](/mulesoft/current/ja-jp/design-center/_images/select-component.png) Design Center のトピックには、いくつかのモジュールが関与するタスクがあります。 ## [](#関連情報)関連情報 - [データのログ (Flow Designer)](https://docs.mulesoft.com/jp/design-center/logger-task-design-center) - [フローからの別のフローの参照 (Flow Designer)](https://docs.mulesoft.com/jp/design-center/reference-flow-task-design-center) - [エラーの処理 (Flow Designer)](https://docs.mulesoft.com/jp/design-center/error-handling-task-design-center) # 作成しているアプリケーションに関するランタイム情報の表示:page-support-status: eolScheduled Flow Designer でアプリケーションを実行すると、Runtime Manager の実行中アプリケーションのリストに表示されます。Flow Designer から Runtime Manager に移動して、アプリケーションに関するランタイム情報 (使用している Mule Runtime のバージョン、使用している vCore の数など) を表示できます。 1. キャンバスの上にあるツールバーの状況メッセージが ​`Ready to Run`​ である状態で ​**\[Run (実行)\]**​ をクリックします。 2. **\[Deploy (デプロイ)\]**​ ボタンの左側にある 3 つのドットのアイコンをクリックします。 3. **\[View in Runtime Manager (Runtime Manager で表示)\]**​ を選択します。 ## [](#関連情報)関連情報 - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) # 入力データへの出力データのマッピング (Flow Designer):page-support-status: eolScheduled フローのカードが、受信するデータに特定のカスタムデータ型の使用を要求する場合があります。前のカードの出力が別のカスタムデータ型を使用している場合、前のカードのカスタムデータ型の要素を、次のカードで必要とされるカスタムデータ型の要素にマップする必要があります。 たとえば、フローに Card A と Card B があり、Card B が Card A に続くとします。Card B の入力で必要とされるカスタムデータ型と同じカスタムデータ型が Card A の出力で使用されている場合、Card A の出力を Card B の入力にマップする必要はありません。 ![fd transform parent topic match](/mulesoft/current/ja-jp/design-center/_images/fd-transform-parent-topic-match.png) Figure 1. Card A から出力されたカスタムデータ型が Card B で必要とされるカスタムデータ型に一致するため、フロー内で Card B を Card A の直後に続けることができます。 一方、この 2 つのカスタムデータ型が一致しない場合、Transform カードを使用して、Card A から出力されたカスタムデータ型の要素を Card B で必要とされるカスタムデータ型の要素にマップする必要があります。 ![fd transform parent topic nomatch](/mulesoft/current/ja-jp/design-center/_images/fd-transform-parent-topic-nomatch.png) Figure 2. Card A から出力されたカスタムデータ型が Card B で必要とされるカスタムデータ型に一致しないため、Transform カードを使用して、Card A の出力の要素を Card B で必要とされる入力の要素にマップする必要がある

両方のカードでシンプルデータ型が使用されている場合、次の 2 つのシナリオのいずれかが考えられます。

  • Card A が、シンプルデータ型 (String、Number、Date など) を使用するデータを出力し、Card B が同じシンプルデータ型のデータを必要とする場合、マッピングは必要ありません。

  • Card A が、シンプルデータ型を使用するデータを出力し、Card B が別のシンプルデータ型のデータを必要とする場合、Card B を Card A に続けることはできません。これらのデータ型間のマッピングは不可能です。

一方のカードのみがシンプルデータ型を使用し、もう一方のカードがカスタムデータ型を使用している場合、次の 2 つのシナリオが考えられます。

  • シンプルデータ型を使用するデータを Card A が出力し、カスタムデータ型を使用するデータを Card B が必要とする場合、Card B のカスタムデータ型に同じシンプルデータ型の 1 つの要素のみが含まれている場合を除き、マッピングは不可能です。

    たとえば、Card A が String 型のデータを出力し、Card B が次のカスタムデータ型の入力を必要とするとします。

    例 1
    {
      "a": <string>
    }

    この場合、Card A から出力された String 型の出力を Card B で必要とされるカスタムデータ型の要素 ​a​ にマップすることができます。

    では、Card B のカスタムデータ型が次の 2 つのデータ型のいずれかであったとしたらどうなるでしょう。

    例 2
    {
      "a": <number>
    }
    例 3
    {
      "a": <string>,
      "b": <number>
    }

    例 2 では、カスタムデータ型の唯一の要素が ​number​ データ型を使用しています。​string​ は ​number​ にマップできません。

    例 3 のカスタムデータ型には 2 つの要素があります。Card A からの ​string​ は要素 ​a​ にのみマップできるため、要素 ​b​ は値なしのままになります。Card B はこのカスタムデータ型を必要とするため、そのすべての要素にデータが含まれている必要があります。したがって、Card A からの ​string​ をこのカスタムデータ型にマップすることはできませんでした。

  • Card A がカスタムデータ型を出力し、Card B が、シンプルデータ型を使用するデータを必要とする場合、カスタムデータ型からの要素をシンプルデータ型にマップできることがあります。この要素は同じシンプルデータ型を使用する必要があります。

    たとえば、Card A が、例 3 のカスタムデータ型を使用するデータを出力するとします。Card B が ​string​ の入力データを必要とする場合、要素 ​a​ を Card B の入力にマップできます。Card B が ​number​ の入力データを必要とする場合もマッピングは可能です。

    ただし、Card B が ​date​ または他のシンプルデータ型の入力データを必要とする場合、マッピングは不可能です。

[Transform カードを使用したマッピングの例](https://docs.mulesoft.com/jp/design-center/fd-mapping-examples)​ チュートリアル​[「Flow Designer での最初の Mule アプリケーションの作成」](https://docs.mulesoft.com/jp/design-center/salesforce-to-twilio)​の手順を実行したユーザーは、すでに 2 回のマッピングを行っています。この両方のマッピングをもう一度見てみましょう。 [Transform カードツアー](https://docs.mulesoft.com/jp/design-center/fd-tour-transform-card)​ Transform カードには、データのマッピングを容易にするためのさまざまな機能が含まれます。 [変換用のデータ型のマッピングに関する推奨事項の入手](https://docs.mulesoft.com/jp/design-center/get-mapping-recommendations)​ Transform カードでは、入力データ型のデータ要素から出力データ型のデータ要素への推奨されるマッピングが表示されます。推奨されるマッピングがニーズに合う場合は、マッピングを保存してカードで使用できます。 # 共有された接続の監査ログの表示:page-support-status: eolScheduled 共有接続のオーナーのみが共有接続を編集または削除できますが、誰かがログイン情報を不正に取得して 1 つ以上の共有接続を編集または削除している可能性があります。また、誰かが悪意を持って別のユーザーのログイン情報を使用して共有接続を作成し、未承認のシステムにデータを吸い上げている可能性もあります。 このようなシナリオの特定に役立つように、共有接続がビジネスグループ内で作成、変更、削除されるたびに Flow Designer は監査ログメッセージを作成します。各メッセージに次の情報が含まれます。 - アクションの日時 - アクションが実行された製品 (つまり、Flow Designer) - 監査対象のオブジェクトの種別 (常に ​**\[Connection (接続)\]**​)。 - アクションの種別: \[Create (作成)\]、\[Edit (編集)\]、または \[Delete (削除)\] - 接続の名前 - アクションの実行に使用されたユーザー ID。 監査ログにエンティティのペイロードをダウンロードすることもできます。接続の作成、変更、削除のペイロードには、接続の ID、接続を作成したユーザーの ID、接続の作成の対象であるコネクタの種別などの情報が含まれます。 ## [](#手順)手順 1. Anypoint Platform で、\[Access Management (アクセス管理)\] を開きます。 2. 左側のペインで ​**\[Audit Logs (監査ログ)\]**​ を選択します。 3. **\[Audit Logs (監査ログ)\]**​ ページの ​**\[Products (製品)\]**​ 検索条件で ​**\[Flow Designer\]**​ を選択し、​**\[Types (種別)\]**​ 検索条件で ​**\[Connector (コネクタ)\]**​ を選択します。 # 分岐のマージ 分岐をマージすることで、対象の分岐に、分岐前のソース分岐 (​_「機能分岐」_​と呼ばれます) からの変更を組み合わせることができます。対象分岐にはこれらの変更が反映され、ソース分岐は変更されません。分岐のマージは、API Designer インターフェース内で行うことができます。 ## [](#分岐をマージする)分岐をマージする 1. Design Center の ​**\[Projects (プロジェクト)\]**​ リストで、プロジェクト名をクリックしてテキストエディターを開きます。\[Branch Selector\] コンポーネントボタンの隣に ​**\[Merge (マージ)\]**​ ボタンが表示されます (すでに分岐が作成済みである場合)。 2. \[Merge (マージ)\] をクリックします。 3. **\[Merge branch (分岐をマージ)\]**​ ダイアログで、分岐のドロップダウンリストから対象分岐を選択します。 4. **\[Advanced Settings (詳細設定)\]**​ を展開します。 5. **\[Squash commits (コミットをスカッシュ)\]**​ を選択します。 コミットをスカッシュすることで、ソース分岐のコミットがマージに向けて単一のコミットに圧縮され、対象分岐のコミット履歴が簡潔明瞭に保たれます。 6. マージ後にソース分岐を自動的に削除するには、​**\[Delete branch (分岐を削除)\]**​ を選択します。 7. **\[Merge (マージ)\]**​ をクリックします。 マージ後は、対象分岐が現在の分岐になります。 ## [](#マージの競合の解決)マージの競合の解決 ソース分岐または対象分岐のどちらかに他方には含まれない変更 (コミット) が存在すると、マージの競合が発生します。マージの競合が発生した場合は、どちらの分岐が有効であるかを選択する必要があります。ソース分岐または対象分岐のどちらでも指定できます。 # 変換用のデータ型のマッピングに関する推奨事項の入手:page-support-status: eolScheduled Transform カードでは、入力データ型のデータ要素から出力データ型のデータ要素への推奨されるマッピングが表示されます。推奨されるマッピングがニーズに合う場合は、マッピングを保存してカードで使用できます。 ## [](#このタスクについて)このタスクについて Transform カードは、1 つ前のカードからのメッセージを、次のカードがコンシュームできる出力メッセージに変換します。メッセージは、ペイロード、属性、および変数で構成されます。次の画像では、HTTP Listener カードと HTTP Request カードの間に Transform カードが配置されています。Transform カードは、HTTP Listener カードから (JSON または他の形式のデータを含む) メッセージを受け取り、HTTP Request カードが受け取るように設定されているメッセージに変換します。 ![simple flow](/mulesoft/current/ja-jp/design-center/_images/simple-flow.png) カードには \[Script (スクリプト)\] ビューと \[Mappings (マッピング)\] ビューの 2 つの異なるビューがあり、入力メッセージを出力メッセージに変換する方法を指定できます。 \[Script (スクリプト)\] ビューでは、DataWeave スクリプトを作成できます。DataWeave に詳しくない場合は \[Mappings (マッピング)\] ビューを使用してください。 このビューは、入力メッセージと出力メッセージの予想される構造を表示します。これら 2 つのツリーの間のマッピングは、入力項目と出力項目をつなぐ線で表されます。入力項目から出力項目へのマッピングは、入力から出力まで項目をドラッグアンドドロップすることによって行います。 ![simple transform card example](/mulesoft/current/ja-jp/design-center/_images/simple-transform-card-example.png) 入力データ型を出力データ型にマップする方法が分からない場合は、Transform カードに推奨マッピングを提案させることができます。 ## [](#制限事項)制限事項 - カードは、入力属性から出力属性、または入力変数から出力変数への推奨マッピングは提案しません。 - それ自身が配列の要素である配列の要素は、推奨では無視されます。たとえば、次のデータ型では ​`d`​ と ​`e`​ は両方とも無視されます。 { "a": \[ "b": 1, "c": \[ "d": 2, "e": 3 \], \] } 次のデータ型では ​`e`​ と ​`f`​ は両方とも無視されます。 { "a": \[ "b": 1, "c": { "d": \[ "e": 2, "f": 3 \], }, "g": 4 \], } - また、異なるデータ型の間ではカードはマッピングを作成しません。たとえば、入力データ型の要素が整数である場合、カードは別の整数にのみマップし、文字列や他のデータ型にはマップしません。 ## [](#始める前に)始める前に Anypoint Platform で、組織の自動マッピング機能が有効であることを確認します。 1. Anypoint Platform で、\[Access Management (アクセス管理)\] を開きます。 2. 画面の左側にある ​**\[Settings (設定)\]**​ で ​**\[Flow Designer\]**​ をクリックします。 3. **\[Flow Designer General Settings (Flow Designer の一般設定)\]**​ ページで、​**\[Enable (有効化)\]**​ 列の円をクリックします。
推奨システムは、CloudHub を使用している Flow Designer のすべてのユーザーからの匿名データを収集して分析します。この機能を有効にすると、推奨の精度を高めるために、匿名データが収集されます。匿名データであっても共有することに懸念がある場合は、この機能を有効にしないでください。
## [](#手順)手順 1. Transform カードの 1 つ前にあるカードで出力データ型を設定します。 2. Transform カードの 1 つ後ろにあるカードで入力データ型を設定します。 3. \[Configuration (設定)\] セクションの \[Mappings (マッピング)\] ペインで Transform カードを開きます。 4. ペインの一番上にある ​**\[Preview (プレビュー)\]**​ ボタンをクリックします。 ## [](#結果)結果 入力データ型から出力データ型への推奨マッピングがオレンジ色で表示されます。 ## [](#次のステップ)次のステップ 推奨マッピングがニーズに合っている場合は、\[Mappings (マッピング)\] ペインの一番上にある ​**\[Apply (適用)\]**​ ボタンをクリックします。 推奨マッピングがニーズに合っていない場合は、​**\[Discard (破棄)\]**​ をクリックします。推奨マッピングがペインから削除されます。推奨マッピングを再び表示したい場合は、Transform カードを閉じてから再び開いて ​**\[Preview (プレビュー)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [カードの出力を次のカードの必須入力にマップ](https://docs.mulesoft.com/jp/design-center/fd-transform) - [Transform カードを使用したマッピングの例](https://docs.mulesoft.com/jp/design-center/fd-mapping-examples) - [Transform カードツアー](https://docs.mulesoft.com/jp/design-center/fd-tour-transform-card) # 外部ファイルからの API 仕様またはフラグメントの作成とパブリッシュ API Designer を使用して既存の外部ファイルから新しい API 仕様または API フラグメントを作成します。API Designer では、JSON ファイル、RAML ファイル、または YML ファイルからのインポートがサポートされます。既存のプロジェクトから API 仕様とフラグメントをインポートすることもできます。 ## [](#手順)手順 1. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで ​**\[Create (作成)\]**​ ボタンをクリックし、​**\[Import from File (ファイルからインポート)\]**​ をクリックします。 2. インポートするプロジェクトに付ける名前を指定します。 3. **\[Choose file (ファイルを選択)\]**​ をクリックしてから、インポートするプロジェクトのファイルシステムを参照します。 次のファイルの種類から新しいプロジェクトを作成できます。 - JSON - RAML - YAML - 既存のプロジェクトが含まれる ZIP ファイル。 4. **\[Import as…​ (名前を付けてインポート)\]**​ をクリックして ​**\[API Specification (API 仕様)\]**​ または ​**\[API Fragment (API フラグメント)\]**​ を選択します。 API Designer でテキストエディターを使用して API 仕様またはフラグメントが新しいプロジェクトで開きます。API Designer ではプロジェクトの各ファイルに既存の名前が使用されます。これらの名前は必要に応じて変更できます。 ## [](#api-仕様またはフラグメントの変更)API 仕様またはフラグメントの変更 エディターでの作業中には、仕様内を移動したり、仕様の内容を操作したりできます。F1 キーを押すと、いつでもこれらのリストが表示されます。このリストには、大半のコマンドのキーボードショートカットも表示されます。 以下のタスクも実行できます。 プロジェクトへのファイルと API フラグメントのインポート ファイルを 1 つずつ、または ZIP ファイルにまとめてインポートできます。RAML 1.0 ファイル、JSON ファイル、OpenAPI Specification (OAS) 2.0 または 3.0 ファイル (JSON または YAML) がサポートされています。コンピューター上のローカルファイルを指定するか、またはファイルがオンラインで保存されている場合は URL を指定できます。 ファイルのインポートについての詳細とインポート手順は、このトピックの最後にある​**「関連情報」**​にリンクがある「API プロジェクトへのファイルのインポート」を参照してください。 プロジェクトへの API フラグメントの追加についての詳細は、このトピックの最後にある​**「関連情報」**​にリンクがある「API 仕様プロジェクトへの連動関係としての RAML API フラグメントの追加」を参照してください。 API コールのシミュレーション API 仕様の作成中であっても、以下を指定したエンドポイントへのコールをシミュレートすることができます。 - API が成功時に返す HTTP ステータスコード - 実際の実装が返すデータの例 詳細は、​[「API コールのシミュレーション」](https://docs.mulesoft.com/jp/design-center/design-mocking-service)​を参照してください。 API プロジェクトまたは仕様のエクスポート プロジェクトはいつでも ZIP ファイルとしてエクスポートできます。テキストエディターの右上隅にある歯車アイコンをクリックして ​**\[Download Project (プロジェクトをダウンロード)\]**​ を選択します。 ファイルのダウンロード ファイル名の右側にあるドットをクリックして ​**\[Download (ダウンロード)\]**​ を選択します。 別の形式でのファイルのダウンロード 仕様のファイル名の右側にあるドットをクリックして ​**\[Download as (名前を付けてダウンロード)\]**​ を選択します。仕様は、サポートされている他の形式のいずれかでダウンロードできます。仕様が RAML 形式であれば、OAS YAML または OAS JSON 形式でダウンロードできます。仕様が OAS 形式であれば、RAML 0.8 または RAML 1.0 形式でダウンロードできます。 このオプションを使用してダウンロードしたファイルが有効である保証はありません。このオプションの目的は、新しい仕様の開発の基礎を提供すること、または新しい形式で元の仕様の開発を継続できるようにすることです。 ## [](#次のステップ)次のステップ API 仕様が完成したら、Exchange にパブリッシュすることができます。​[「API 仕様のパブリッシュ」](https://docs.mulesoft.com/jp/design-center/design-publish)​を参照してください。 # 実行時に変化する値のカードへの入力:page-support-status: eolScheduled ペイロード項目、属性、および変数をプレーンテキスト項目にドラッグアンドドロップして、テキストと組み合わせるか、または単独で使用することで、静的な値ではなく動的な値を指定できます。値は、Mule アプリケーションを実行してフローがトリガーされた時点で代入されます。 ## [](#このタスクについて)このタスクについて フローを構成するカードには、いくつかの異なる種類の項目があります。 - ユーザーが選択するオプションを提供する項目 - DataWeave 式を作成するための関数項目 - 通常は静的で変化しない値を提供するプレーンテキスト項目 Design Center では、通常の項目で静的値の代わりに動的値を指定することができます。このロガーカードの画像に示すように、前に別のカードがあるすべてのカードは、1 つ前のカードからのペイロードのすべての属性と要素のリストを表示します (ここでは青色の枠で強調表示されています)。 ![logger with list](/mulesoft/current/ja-jp/design-center/_images/logger-with-list.png) このリストには、フローに追加されている以前のカードからのすべての変数も含まれます。必要な操作は、追加するペイロード項目、属性、および変数をテキスト項目にドラッグアンドドロップするだけです。項目では、追加されている文字列にこれらが連結されます。 ## [](#始める前に)始める前に カードのリストに表示されるペイロード項目、変数、および属性は、1 つ前のカードから渡されます。デフォルトのペイロードと (属性がある場合は) 属性は、常に要求するアクションなしで表示されます。ただし、メッセージのペイロードの要素を表示するためには、1 つ前のカードで出力ペイロードのカスタムデータ型を定義しておく必要があります。(1 つ前のカードが Set Variable カードである場合は、さらに 1 つ前のカードで出力ペイロードのカスタムデータ型を定義する必要があります。)変数をリストに表示するには、前のカードで変数を定義しておく必要があります。 たとえば、HTTP リスナーの出力ペイロードを解析してペイロードデータを含むメッセージをログに記録するためのロガーが必要だとします。そのため、​`/example`​ を HTTP リスナーのエンドポイントとして、次のシンプルなフローをセットアップします。 ![simple flow before you begin](/mulesoft/current/ja-jp/design-center/_images/simple-flow-before-you-begin.png) Logger カードのリストは、次の画像で青色で強調表示されたリストのようになります。 ![logger initial list](/mulesoft/current/ja-jp/design-center/_images/logger-initial-list.png) HTTP リスナーはデフォルトのペイロードを使用しているため、受信するデータが特定の形式であるとは期待されません。リストエントリの ​`payload`​ を ​**\[Message (メッセージ)\]**​ 項目にドラッグアンドドロップした場合、ロガーは、HTTP リスナーから受信したすべてのペイロード全体をこのログファイルに記録しようとします。 次に、HTTP リスナーがロガーに送信するペイロード部分を制限したいとします。JSON 例を使用して HTTP リスナーの出力ペイロードのカスタムデータ型を作成することで、HTTP リスナーが受信したペイロードから ​`firstName`​ 要素と ​`lastName`​ 要素のみを送信することができます。 ```JSON { "firstName": "Ian", "lastName": "Stewart" } ``` Design Center がフローのカスタムデータ型を認識するまで少しの間を置いて、Logger カードを再び開くと、リストの ​`payload`​ エントリが ​`firstName`​ と ​`lastName`​ に置き換わっています。 ![logger with list](/mulesoft/current/ja-jp/design-center/_images/logger-with-list.png) 下記の例では、HTTP Listener カードでカスタムデータ型を作成し、Logger カードで動的メッセージを作成して、Mule アプリケーションを実行することで動的メッセージをログに記録する手順を説明しています。 Logger カードの式で変数を使用する場合は、その直前に Set Variable カードを追加します。この例では、Set Variable カードで ​`firstNameBasis`​ 変数を定義して Logger カードに渡しています。 ![first name basis](/mulesoft/current/ja-jp/design-center/_images/first-name-basis.png) ## [](#手順)手順 - カードの右側にあるリストから、1 つまたは複数のペイロード項目、属性、または変数をカードのテキスト項目までドラッグアンドドロップします。リストエントリをドラッグすると、ドロップ先として選べる項目の境界線が強調表示されます。エントリを項目にドロップすると、そのエントリは​_データ要素_​となります。 項目は、項目内の文字列値とエントリを連結します。たとえば、Logger カードの ​**Messages**​ 項目で次のエントリを指定したとします。 ![hello firstname](/mulesoft/current/ja-jp/design-center/_images/hello-firstname.png) データ要素の矢印をクリックすると、値に適用できる関数のリストが表示されます。関数は、選択した順序で適用されます。 関数を適用するかどうかに関係なく、値のプレビューを表示することもできます。アプリケーションが実行されていない場合は、データ型を定義したときに指定したサンプルデータを使用してプレビューが表示されます。アプリケーションが実行中であれば、ライブデータでプレビューが表示されます。 ![hello firstname expanded](/mulesoft/current/ja-jp/design-center/_images/hello-firstname-expanded.png) ロガーは、​`firstName`​ 要素を含むペイロードを受信すると、次の形式でログにメッセージを追加します。 "Hello, Ian." ペイロードの ​`firstName`​ データ要素の後に ​`lastName`​ データ要素があり、その間にスペースが入っている場合、ロガーは次の形式でログにメッセージを記録します。 "Hello, Ian Stewart."

DataWeave 言語を理解しているのであれば、単純な値を DataWeave 式と組み合わせることができます。リストエントリの ​Custom Expression​ をテキスト項目にドラッグしてください。そして、ダブルクリックして開きます。

- 項目からデータ要素を削除するには、その項目の直後の項目をクリックして、Delete キーまたは Backspace キーを押します。 ## [](#例-シンプルな動的式の作成)例: シンプルな動的式の作成 この例では、HTTP リスナーが JSON ペイロードを含む POST 要求を受け取るフローを使用します。HTTP リスナーは、ペイロードをロガーに渡します。このペイロードには、人物の名前と名字が含まれています。 ### [](#手順-2)手順 1. 新しい Mule アプリケーションプロジェクトで、新しいフローのトリガーに HTTP Listener カードを追加します。 2. カードを開いてパスを ​`/example`​ に設定します。 3. このカードの出力用のデータ型をセットアップします。 1. **\[Output (出力)\]**​ セクションに移動します。 2. **\[Data Type (データ型)\]**​ ドロップダウンメニューの横にある ​**\[Add (追加)\]**​ をクリックします。 3. **\[Name (名前)\]**​ 項目で、データ型の名前を指定します。 4. **\[Format (形式)\]**​ ドロップダウンメニューから ​**\[JSON\]**​ を選択します。 5. **\[Type (型)\]**​ 項目で ​**\[From Example (例から)\]**​ を選択して、ペイロード用に次の JSON 例を貼り付けます。 ```JSON { "firstName": "Sancho", "lastName": "Panza" } ``` 6. **\[Save (保存)\]**​ をクリックします。 4. HTTP Listener カードの後ろに Logger カードを追加して開きます。 **結果:**​ ペイロードの要素である ​`payload.firstName`​ と ​`payload.lastName`​、および HTTP リスナーからの属性が、カードの右側のリストに表示されます。キャンバスの一番上にある ​**\[Run (実行)\]**​ ボタンの隣に「Creating…​ (作成中…​)」というメッセージが表示されている場合は、このメッセージが変わってから要素のリストが表示されます。 5. ペイロードを受信したときにロガーがログに記録するメッセージを指定します。 1. **\[Message (メッセージ)\]**​ 項目で ​`` `Hello,` ``​ と入力します。 2. ペイロード項目の ​`payload.firstName`​ をクリックして、​**\[Message (メッセージ)\]**​ 項目までドラッグします。 6. キャンバスの一番上にある ​**\[Run (実行)\]**​ ボタンをクリックしてアプリケーションを実行します。 7. **\[Run (実行)\]**​ ボタンの隣にあるアプリケーションの URL をクリックしてコピーします。 8. Postman または cURL で、HTTP Listener カードで指定したのと同じ形式を使用して、​`/example`​ エンドポイントに JSON メッセージを投稿します。 ### [](#結果)結果 メッセージを投稿したら、Design Center のフローに戻り、ログを開いてメッセージを確認します。 ### [](#次のステップ)次のステップ HTTP Listener カードの後に Set Variable カードを追加してみてください。カードからデータが出力される場合、データを変数に保存することをお勧めします。これで、後でデータをフローで使用することができます。​`payload.firstName`​ の値を保存する変数を作成し、ペイロード項目の代わりに変数を使用するようにロガーのメッセージを変更します。Logger カードでは、右側のリストに変数が表示されます。メッセージからペイロード項目を削除して、変数をドラッグします。 ## [](#関連情報)関連情報 - [変数の作成について (Flow Designer)](https://docs.mulesoft.com/jp/design-center/to-create-and-populate-a-variable) # 接続の削除:page-support-status: eolScheduled 特定のコネクタ種別で使用されているまたは使用できる接続を削除できます。たとえば、Database Connector のインスタンスで使用できる接続を削除できます。 接続を削除するには、接続の作成に使用したユーザー ID で Anypoint Platform にログインする必要があります。 ビジネスグループと共有している接続を削除する場合、ビジネスグループのすべての Mule アプリケーションプロジェクトと実行中の Mule アプリケーションのその種別の全コネクタに影響します。 - Mule アプリケーションプロジェクトで接続が使用されている場合、コネクタを表すカードにエラーインジケーターが表示されます。エラーインジケーターは、接続を使用する設定を再度開いたとき、プロジェクトを再度開いたとき、ユーザーが同じコネクタ種別の新しい設定を追加しようとしたとき、ユーザーがプロジェクトで ​**\[Test (テスト)\]**​ をクリックしたときに表示されます。 - デプロイ済み Mule アプリケーションで接続が使用されている場合、アプリケーションで引き続き使用されます。Mule アプリケーションを変更した場合、Mule アプリケーションを再デプロイする前に別の接続に切り替える必要があります。 **接続を削除する手順は、次のとおりです。** 1. 接続を削除するコネクタ種別が含まれる Mule アプリケーションプロジェクトを開きます。 2. コネクタ種別を表すカードをクリックします。 3. カードの上部で、​**\[Edit (編集)\]**​ をクリックします。 4. 使用可能な接続のリストで接続を見つけます。 その接続が正しいことを確認します。選択した接続を本当に削除するかどうかを尋ねる確認ダイアログは表示されません。 5. 接続の名前の右側にある 3 つのドットをクリックして ​**\[Delete (削除)\]**​ をクリックします。 6. **\[Save (保存)\]**​ をクリックします。 7. **\[Cancel (キャンセル)\]**​ または ​**\[Save (保存)\]**​ をクリックして、コネクタの設定ダイアログを閉じます。 どちらのボタンをクリックしても問題ありません。​**\[Connection configuration (接続設定)\]**​ ダイアログで ​**\[Save (保存)\]**​ をクリックすると、接続が完全に削除されます。 ## [](#関連情報)関連情報 - [コネクタからシステムへの接続](https://docs.mulesoft.com/jp/design-center/fd-connections) - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # 接続の編集:page-support-status: eolScheduled 特定のコネクタ種別で使用されているまたは使用できる接続を編集できます。 接続を編集するには、接続の作成に使用したユーザー ID で Anypoint Platform にログインする必要があります。ログインするときに使用したユーザー ID で作成されていない接続は編集できません。 共有している接続を変更する場合、ビジネスグループのすべてのプロジェクトのその種別の全コネクタに影響します。 **接続を編集する手順は、次のとおりです。** 1. 接続を使用できるコネクタ種別が含まれる Mule アプリケーションプロジェクトを開きます。 2. コネクタ種別を表すカードをクリックします。 3. カードの上部で、​**\[Edit (編集)\]**​ をクリックします。 4. 使用可能な接続のリストで接続を見つけます。 5. 接続の名前の右側にある 3 つのドットをクリックして ​**\[Edit (編集)\]**​ をクリックします。 6. 変更を行います。 7. **\[Save (保存)\]**​ をクリックします。 8. **\[Cancel (キャンセル)\]**​ または ​**\[Save (保存)\]**​ をクリックして、コネクタの設定ダイアログを閉じます。 どちらのボタンをクリックしても問題ありません。前のダイアログで ​**\[Save (保存)\]**​ をクリックすると、接続の変更が保存されます。 ## [](#関連情報)関連情報 - [コネクタからシステムへの接続](https://docs.mulesoft.com/jp/design-center/fd-connections) - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # 新規 GitHub リポジトリと同期した新規プロジェクトの作成 API Designer プロジェクトを作成するときに、GitHub リポジトリも作成して、リポジトリをプロジェクトと同期させることができます。 ## [](#始める前に)始める前に プロジェクトを作成して同期させる前に、次の準備が整っていることを確認します。 - Anypoint Platform 内での「Design Center Developer (Design Center 開発者)」権限があること - GitHub Synchronization アプリケーションが​[インストールされて認証されていること](https://docs.mulesoft.com/jp/design-center/design-ghs-install-authorize)​ - GitHub にサインインしていること ## [](#新規プロジェクトを同期させる)新規プロジェクトを同期させる 1. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで、​**\[Create new (新規作成)\]**​ をクリックします。 2. **\[New API Spec (新しい API 仕様)\]**​ を選択します。 3. **\[New API Spec (新しい API 仕様)\]**​ ダイアログで、API のタイトルを指定します。 4. **\[I’m comfortable with designing it on my own (自分でデザインします)\]**​ を選択します。 5. **\[Sync this project with an external GitHub repository (このプロジェクトを外部 GitHub リポジトリと同期させる)\]**​ チェックボックスをオンにします。 6. 展開したダイアログで、​**\[GitHub Organization (GitHub 組織)\]**​ リストから組織を選択します。
GitHub Synchronization アプリケーションがインストールされていない場合は、​[GitHub Organization (GitHub 組織)]​ リストは空のままです。
7. 必要に応じて、リポジトリの新しい名前を指定します。 8. **\[Create API Spec (API 仕様を作成)\]**​ をクリックします。 新規プロジェクトのテキストエディターが開きます。 API 仕様を作成するときに GitHub リポジトリと同期させるだけではなく、フラグメントを作成したり API をインポートしたりするときに新しい GitHub リポジトリと同期させることもできます。 ## [](#関連情報)関連情報 - [テキストエディターでの API 仕様の作成](https://docs.mulesoft.com/jp/design-center/design-create-publish-api-raml-editor) - [テキストエディターの便利な機能](https://docs.mulesoft.com/jp/design-center/design-helpful-features-text-editor) - [API 仕様のパブリッシュ](https://docs.mulesoft.com/jp/design-center/design-publish) # 既存の GitHub リポジトリと同期した新規プロジェクトの作成 新規 API Designer プロジェクトを作成して、既存の GitHub リポジトリと同期させることができます。 ## [](#始める前に)始める前に プロジェクトを作成して同期させる前に、次の準備が整っていることを確認します。 - Anypoint Platform 内での「Design Center Developer (Design Center 開発者)」権限があること - GitHub Synchronization アプリケーションが​[インストールされて認証されていること](https://docs.mulesoft.com/jp/design-center/design-ghs-install-authorize)​ - GitHub にサインインしていること ## [](#新規プロジェクトを同期させる)新規プロジェクトを同期させる 1. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで、​**\[Create new (新規作成)\]**​ をクリックします。 2. **\[Sync from existing GitHub Repo (既存の GitHub リポジトリから同期)\]**​ を選択します。 3. **\[New Project (新規プロジェクト)\]**​ ダイアログで、​**\[Project Name (プロジェクト名)\]**​ 項目に名前を入力します。 4. 新規プロジェクトを同期させる組織とリポジトリを選択します。
[GitHub Organization (GitHub 組織)]​ ドロップダウンリストには、GitHub Synchronization アプリケーションがインストールされている GitHub 組織が表示されます。アプリケーションがインストールされていなければ、組織やリポジトリは表示されません。
5. **\[Import As (次としてインポート)\]**​ をクリックします。 6. 同期させる API プロジェクトの種別として ​**\[API Specification (API 仕様)\]**​ または ​**\[API Fragment (API フラグメント)\]**​ を選択します。 新規プロジェクトのテキストエディターが開きます。 ## [](#関連情報)関連情報 - [テキストエディターでの API 仕様の作成](https://docs.mulesoft.com/jp/design-center/design-create-publish-api-raml-editor) - [テキストエディターの便利な機能](https://docs.mulesoft.com/jp/design-center/design-helpful-features-text-editor) - [API 仕様のパブリッシュ](https://docs.mulesoft.com/jp/design-center/design-publish) # 既存の Mule アプリケーションからの Mule アプリケーションの作成の開始 (Flow Designer):page-support-status: eolScheduled 既存の Mule アプリケーションから Mule アプリケーションの作成を開始する方法は 2 つあります。 - [\[既存の Mule アプリケーションプロジェクトを複製する\]](<#既存の Mule アプリケーションプロジェクトを複製する>) - [\[既存の Mule アプリケーションプロジェクトをインポートする\]](<#既存の Mule アプリケーションプロジェクトをインポートする>) ## [](#bookmark-a)既存のプロジェクトの複製 既存の Mule アプリケーションプロジェクトに基づいて、新しい Mule アプリケーションプロジェクトを作成できます。新しいプロジェクトには、既存のプロジェクトに含まれるほぼすべてのものが含まれ、既存のプロジェクトで定義されたカスタムデータ型やサンプルデータもすべて含まれます。 ### [](#手順)手順 1. Design Center のプロジェクトのリストで既存の Mule アプリケーションプロジェクトを選択します。 2. 次のような ​**\[Clone (複製)\]**​ アイコンをクリックします。 ![to create a mule application project cfeff](/mulesoft/current/ja-jp/design-center/_images/to-create-a-mule-application-project-cfeff.png) 3. 新しいプロジェクトに名前を付けます。 ### [](#結果)結果 新しいプロジェクトが開きます。赤い丸は、認証情報を入力する必要があることを示します。これにより、Flow Designer は、カードで表されているシステムに接続できます。キャンバスの左側にある ​**\[Project (プロジェクト)\]**​ ペインの ​**\[Reusable Configurations (再利用可能な設定)\]**​ リストのエントリをクリックします。設定が開き、ユーザーからの情報を必要とする各項目の両側に赤い境界線が表示されます。 このような項目を見つけるもう 1 つの方法は、Flow Designer 画面の右下隅にある ​**\[Problems (問題)\]**​ タブをクリックして ​**\[Problems (問題)\]**​ ペインを開くことです。ペインでエントリをクリックすると、それに対応する項目が表示されます。 ### [](#次のステップ)次のステップ 必須情報を入力したら、アプリケーションを自由に変更して他の Mule アプリケーションと同様に開発することができます。 ## [](#bookmark-b)既存のプロジェクトのインポート **\[Download source (ソースをダウンロード)\]**​ オプションを使用して Flow Designer からエクスポートした Mule アプリケーションプロジェクトをインポートできます。この機能は 2 つの異なるシナリオをサポートします。 - 同じ組織内の異なる環境からエクスポートされたプロジェクトのインポート - 異なる組織の環境からエクスポートされたプロジェクトのインポート

エクスポートされたプロジェクトには、プロジェクトが元の場所でリンクされていた項目は含まれません。 インポートされたプロジェクトには、プロジェクトが元の場所で含めたドライバーや他のライブラリは含まれません。インポートしたプロジェクトに、ライブラリを必要とするコネクタが含まれる場合には、これらのコネクタを開いて必要なライブラリをセットアップする必要があります。

たとえば、プロジェクトに Database Connector が含まれる場合、そのコネクタ用のデータベースドライバーは、エクスポートされたプロジェクトには含まれません。プロジェクトをインポートしたら、Database Connector を開き、データベースドライバーの場所に移動して、ドライバーを選択してください。 また、インポートしたプロジェクトに Database Connector が含まれる場合、そのコネクタ用のデータベースドライバーはプロジェクトには含まれません。Database Connector を開いてドライバーをセットアップする必要があります。

### [](#手順-2)手順

プロジェクトを JAR ファイルからインポートするには、アカウントに Mule アプリケーションを作成する権限が必要です。この権限を持っていない場合、jar ファイルをインポートするオプションが ​[Import from File (ファイルからインポート)]​ ダイアログに表示されません。

1. Design Center の ​**\[Projects (プロジェクト)\]**​ ページで ​**\[Create new (新規作成)\]**​ ボタンをクリックし、​**\[Import from File (ファイルからインポート)\]**​ をクリックします。 2. インポートするプロジェクトに付ける名前を指定します。 3. **\[Choose file (ファイルを選択)\]**​ をクリックしてから、プロジェクトが含まれる JAR ファイルのファイルシステムを参照します。 4. **\[Import and Create project (プロジェクトをインポートして作成)\]**​ をクリックします。 ### [](#結果-2)結果 新しいプロジェクトが開きます。

プロジェクトで参照されているコネクタ、コンポーネント、またはモジュールがカスタム開発されたもので、インポート先の環境には存在しない場合は、次のようなメッセージが表示されてインポートが失敗します。

Unable to resolve dependency 2bacbe78-4300-965a-39fce81ee15d:mule-plugin-americanflights:jar:mule-plugin:1.0.0
Where
2bacbe78-4300-965a-39fce81ee15d is the Maven groupI for the artifact
Mule-plugin-americanflights is the Maven artifact ID
jar is the type of the Maven artifact
mule-plugin is the classifier of the Maven artifact
1.0.0 is the version of the Maven artifact.

このようなエラーが発生した場合は、アセットのオーナーに ​Maven を使用して Exchange にパブリッシュするように​依頼してください。

### [](#次のステップ-2)次のステップ アプリケーションを自由に変更して他の Mule アプリケーションと同様に開発できます。 # 既存のプロジェクトと同期した新規 GitHub リポジトリの作成 新規 GitHub リポジトリを作成して、既存の API Designer プロジェクトと同期させることができます。 ## [](#始める前に)始める前に 新規リポジトリとプロジェクトを同期させる前に、次の準備が整っていることを確認します。 - Anypoint Platform 内での「Design Center Developer (Design Center 開発者)」権限があること - GitHub Synchronization アプリケーションが​[インストールされて認証されていること](https://docs.mulesoft.com/jp/design-center/design-ghs-install-authorize)​ - GitHub にサインインしていること ## [](#新規リポジトリとプロジェクトの同期)新規リポジトリとプロジェクトの同期 1. Design Center の​ **\[Projects (プロジェクト)\]**​ リストで、GitHub と同期させるプロジェクトがあるテーブル行をクリックします。 2. \[Details (詳細)\] ペインで、​**\[Sync with GitHub (GitHub と同期)\]**​ ボタンをクリックします。 3. **\[Enable Sync with GitHub (GitHub との同期を有効化)\]**​ ダイアログで、​**\[GitHub Organization (GitHub 組織)\]**​ ドロップダウンリストから組織を選択します。
GitHub Synchronization アプリケーションがインストールされていない場合は、​[GitHub Organization (GitHub 組織)]​ リストは空のままです。​「GitHub Synchronization のインストールと認証」​を参照してください。
4. 新しいリポジトリの名前を指定します。 5. **\[Sync (同期)\]**​ をクリックします。 Design Center の ​**\[Projects (プロジェクト)\]**​ ページに移動します。​**\[Details (詳細)\]**​ ペインに、​**\[Sync Status (同期状況)\]**​ インジケーターと、GitHub リポジトリの管理や同期の無効化のためのボタンが表示されます。 ## [](#関連情報)関連情報 - [テキストエディターでの API 仕様の作成](https://docs.mulesoft.com/jp/design-center/design-create-publish-api-raml-editor) - [テキストエディターの便利な機能](https://docs.mulesoft.com/jp/design-center/design-helpful-features-text-editor) - [API 仕様のパブリッシュ](https://docs.mulesoft.com/jp/design-center/design-publish) # 異なるプロセスの実効と結果のギャザー:page-support-status: eolScheduled Scatter-Gather カードを使用すると、同時に複数のカードセットを使用してメッセージを送信し、各セットから結果を収集して、結果を (元のメッセージと一緒に) フロー内の次のカードに渡すことができます。 ![フロー内の Scatter-Gather カード](/mulesoft/current/ja-jp/design-center/_images/fd-sg.png) Figure 1. この概略図は、2 つ以上のルートを含む Scatter-Gather カードを示しています。
1どのカードからでも Scatter-Gather カードにメッセージを渡すことができます。現在のフローのトリガーや、フロー内の他のいずれのカードでもメッセージを渡すことができます。
2Scatter-Gather カードは、大きな長方形内に表示されます。この長方形は、カードの​スコープ​と呼ばれます。このスコープ内に 2 つ以上のカードのセットがあり、各セットは​ルート​と呼ばれます。Scatter-Gather カードは、すべてのルートを同時に処理し、ルートはすべて互いに独立しています。各ルートには 1 つ以上のカードがあります。
3すべてのルートでデータの処理が完了すると、各ルートからの結果が元のメッセージのペイロードに含められます。更新されたメッセージは、フローの次のカードに渡されます。
フロー内を移動するメッセージの一般的な構造は次のとおりです。 payload attributes vars 2 つのルートを含む Scatter-Gather カードから渡されるメッセージには、各ルートからのサブペイロードが含まれます。 payload 0 payload 1 payload attributes vars ## [](#2-つの-salesforce-組織からの取引先責任者の集約例)2 つの Salesforce 組織からの取引先責任者の集約例 この例では、HTTP リスナーが要求を受け取ると、フローをトリガーします。Scatter-Gather カードは、2 つの Salesforce 組織から取引先責任者のリストを受け取るための 2 つのルートを開始します。Scatter-Gather カードは、Salesforce 用 Anypoint Connector (Salesforce Connector) の各インスタンスからのペイロードを 1 つのペイロードに組み合わせます。このペイロードは、2 つのクエリの結果を連結する変数に格納されます。最後に、連結された結果の項目がデータ型にマップされ、このデータ型から CSV ファイルが作成されます。 ![この例のフロー](/mulesoft/current/ja-jp/design-center/_images/fd-sg-1-entire-flow.png) Figure 2. 2 つの Salesforce 組織からの取引先責任者を集約した CSV ファイルを作成するフローは次のようになります。
1フローをトリガーする HTTP リスナーカード。
2各ルートが Salesforce Connector のインスタンスで構成される 2 つのルートを持つ Scatter-Gather カード。これらのインスタンスはそれぞれ異なる Salesforce 組織に対してクエリを実行します。
3Scatter-Gather カードからの連結されたクエリの結果を変数に格納する Set Variable カード。
4変数の項目を CSV ファイルの項目にマップする Transform カード。
まず、カスタムデータ型を次のように作成します。 ![カスタムデータ型を作成するためのダイアログ。](/mulesoft/current/ja-jp/design-center/_images/fd-sg-6-custom-type.png) Figure 3. **\[Edit Custom Type (カスタム型を編集)\]**​ ダイアログでは、カスタムデータ型を作成できます。
1[Format (形式)]​ 項目は ​[CSV]​ に設定します。
2[Type (方)]​ 項目は ​[From schema (スキーマから)]​ に設定します。
3スキーマは次のとおりです。
#%RAML 1.0 DataType type: array items: properties: Name: type: string ID: type: string Email: type: string 次に、​**\[Path (パス)\]**​ 項目で指定したパスをリッスンする HTTP リスナーカードを追加します。パスの名前は、コンピューターにダウンロードされる CSV ファイルに付けられます。 ![「Path (パス)」 項目の場所](/mulesoft/current/ja-jp/design-center/_images/fd-sg-2-http-listener.png) Figure 4. **\[Path (パス)\]**​ 項目は ​**\[General (一般)\]**​ 設定にあります。 この例では HTTP リスナーカードを使用していますが、Scatter-Gather カードにはどのカードからでもデータを送信できます。 次に、Scatter-Gather カードを追加して、2 つのルートのそれぞれに Salesforce Connector のインスタンスを配置します。Salesforce Connector のインスタンスは、異なる Salesforce 組織に接続するため、異なる設定を使用します。したがって、異なる接続情報が必要です。 このクエリは、各インスタンスの ​**\[Salesforce Query (Salesforce クエリ)\]**​ 項目に指定します。 ![「Salesforce Query (Salesforce クエリ)」 項目のクエリと場所](/mulesoft/current/ja-jp/design-center/_images/fd-sg-3-sf-query.png) Figure 5. **\[Salesforce Query (Salesforce クエリ)\]**​ 項目は ​**\[General (一般)\]**​ 設定にあります。 Scatter-Gather カードから渡されるメッセージには、以下の部分が含まれます。 payload 0 payload Name ID Email 1 payload Name ID Email attributes vars Scatter-Gather カードからのペイロードには、カードの各ルートからのペイロードが 1 つずつ、合計 2 つのサブペイロードがあります。​`0`​ の下にあるサブペイロードはカードの最初のルートからのペイロードで、​`1`​ の下にあるサブペイロードはカードの 2 番目のルートからのペイロードです。 フローのこの時点で、DataWeave スクリプトを使用して 2 つのサブペイロードを 1 つの CSV ファイルに組み合わせることができます。ただし、DataWeave スクリプトを作成しない場合は、2 つのサブペイロードを 1 つのペイロードに連結して変数に格納し、1 つのペイロードの項目を CSV ファイルの項目にマップできます。 Set Variable カードには 1) 変数名と 2) ​**\[Value (値)\]**​ 項目の式が含まれます。2 つのサブペイロードを連結するための (3 の) 式は次のようになります。 payload\["0"\]\["payload"\] ++ (payload\["1"\]\["payload"\]) この式を作成するには、カードの右側から ​**\[Custom Expression (カスタム式)\]**​ ピルを ​**\[Value (値)\]**​ 項目までドラッグし、ピル内の矢印をクリックしてから ​**\[Expand (展開)\]**​ をクリックします。その後、最初の ​**\[Payload (ペイロード)\]**​ ピルをテキストボックスまでドラッグし、2 つのプラス記号を入力してから、2 番目の ​**\[Payload (ペイロード)\]**​ ピルをテキストボックスまでドラッグします。 ![fd sg 4 set variable](/mulesoft/current/ja-jp/design-center/_images/fd-sg-4-set-variable.png) Figure 6. **Set Variable**​ カードは次のようになります。
1指定された変数名
2[Custom Expression (カスタム式)]​ を ​[Value (値)]​ 項目にドラッグすることで作成されるピル
3クエリ結果を連結する式
Transform カードが Set Variable カードから受け取るメッセージには、次の部分が含まれています。 payload 0 payload Name ID Email 1 payload Name ID Email attributes vars SG\_payload Name ID Email 変数 ​`SG_payload`​ の項目は、CSV 形式を使用するカスタムデータ型の項目にマップできます。 ![変数の項目の出力へのマッピング](/mulesoft/current/ja-jp/design-center/_images/fd-sg-5-transform.png) Figure 7. 変数の項目をカスタムデータ型の項目にマップできます。
1[Input (入力)]​ ペインでの変数の場所
2変数の項目からカスタムデータ型の項目へのマッピング
`Name`​ 項目を入力ペインから出力ペインの ​`Name`​ 項目までドラッグします。​`ID`​ 項目と ​`Email`​ 項目についても同様の操作を行います。 結果は次のようになります。実際のコンテンツは、クエリを実行した Salesforce 組織によって異なります。最初の 12 件は組織 A からの取引先責任者で、ID はすべて ​`0036g000009C`​ で始まっています。残りは組織 B からの取引先責任者で、ID はすべて ​`0028t000001J`​ で始まっています。 Name,ID,Email Rose Gonzalez,0036g000009C4WwAAK,rose@edge.com Sean Forbes,0036g000009C4WxAAK,sean@edge.com Lauren Boyle,0036g000009C4X4AAK,lboyle@uog.com Babara Levy,0036g000009C4X5AAK,b.levy@expressl.net Josh Davis,0036g000009C4X6AAK,j.davis@expressl.net Jane Grey,0036g000009C4X7AAK,jane\_gray@uoa.edu Arthur Song,0036g000009C4X8AAK,asong@uog.com Ashley James,0036g000009C4X9AAK,ajames@uog.com Tom Ripley,0036g000009C4XAAA0,tripley@uog.com Liz D'Cruz,0036g000009C4XBAA0,ldcruz@uog.com Edna Frank,0036g000009C4XCAA0,efrank@genepoint.com Avi Green,0036g000009C4XDAA0,agreen@uog.com Alden Macfarlane,0028t000001J3BAB2,a.macfarlane@trundle.org Tiffani Davalos,0028t000001J3FAH1,t.davalos@trundle.org Elly Fenley,0028t000001J7JUp9,efenley@tripple.com Richie Fore,0028t000001J3HKJ0,rfore@tripple.com Ricarda Cieslak,0028t000001J3WLl9,rcieslak@tripple.com Rosaria Jorgensen,0028t000001J3BNM0,rosaria.jorgensen@huttrick.com Treasa Barbeau,0028t000001J3BNk3,treasa.barbeau@huttrick.com Dwayne Sgro,0028t000001J3EPO2,dsgro@sgroflo.com Maude Wilber,0028t000001J4UUy4,mwilber@zhipe.com Lashell Rouleau,0028t000001J3NIK6,lrouleau@zhipe.com Agnes Diehm,0028t000001J3TCX8,agnes.diehm@aipail.com Pamella Fite,0028t000001J1LOQ3,pamella.fite@aipail.com Kennith June,0028t000001J3POI0,kennith.june@aipail.com Keiko Woods,0028t000001J3SIL1,k.woods@fiephdom.org Natashia Horvat,0028t000001J3KSV0,n.horvat@fiephdom.org Margarita Ptak,0028t000001J3VVe5,ptakm@greelo.com Delena Hodgdon,0028t000001J3OSQ2,hodgdond@greelo.com Britt Lafferty,0028t000001J6HUT7,britt.lafferty@redooler.com Irving Bates,0028t000001J3IUe6,irving.bates@redooler.com Merle Cater,0028t000001J3PPl0,merle.cater@redooler.com ## [](#変数へのメッセージデータの保存)変数へのメッセージデータの保存 ルートでメッセージの一部のみを処理したい場合には、メッセージが Scatter-Gather カードまたはルートの先端に達する前に、ルートで処理するデータのみを変数に格納できます。 変数を複数のルートで使用する必要がある場合には、以下の設定が便利です。 ![複数のルートで使用するデータの保存](/mulesoft/current/ja-jp/design-center/_images/fd-sg-alt-1.png) Figure 8. データは、1 つ以上のルートが使用できる 1 つ以上の変数に保存できます。 この場合は、各ルートの最初のカードが同じメッセージを受け取りますが、Scatter-Gather カードの前に 2 つの変数を作成してある場合には、メッセージには以下の部分が含まれることがあります。 payload attributes vars var1 var2 必要であれば、両方の変数を両方のルートで使用できます。 変数を 1 つのルートのみで使用する必要がある場合には、以下の設定が便利です。 ![1 つのルートでのみ使用されるデータの保存](/mulesoft/current/ja-jp/design-center/_images/fd-sg-alt-2.png) Figure 9. 1 つのルートでのみ使用される変数にデータを保存できます。 最初のルートの先頭で ​`var1`​ を作成し、2 番目のルートの先頭で ​`var2`​ を作成するとします。そして、最初のルートの 2 番目のカードが、以下の部分を持つメッセージを受け取るとします。 payload attributes vars var1 さらに、2 番目のルートの 2 番目のカードが、以下の部分を持つメッセージを受け取るとします。 payload attributes vars var2 上のどちらの図でも、最後のカードが Transform カードであれば、DataWeave でのスクリプト作成が必要となる場合があります。最後のカードが別の Set Variable カードであれば、取引先責任者の集約の例で示したように、Scatter-Gather カードの各ルートからの結果を連結して、別のカード (Transform カードなど) に渡します。 ## [](#parallel-for-eachfor-eachscatter-gather-の違い)Parallel For-Each、For-Each、Scatter-Gather の違い For-Each は、1 つのルートで一度に 1 つの要素を処理しながら、要素のコレクションを反復処理します。 Parallel For-Each は、一度に複数の要素を処理しながら、要素のコレクションを ​_n_​ 回 (​_n_​ はコレクションの要素数以下の値) 処理します。たとえば、要素数が 10 で最大処理回数が 2 に設定されていれば、Parallel For-Each カードは、一度に 2 つの要素を処理し、合計 5 回の処理を実行します。 Scatter Gather は、​_ルート_​と呼ばれる 2 つ以上の並列プロセスを実行します。すべてのルートが終了すると、各ルートからの結果が新しいペイロードにギャザーされます。 ## [](#scatter-gather-カードの項目)Scatter-Gather カードの項目 Timeout (タイムアウト) 並列プロセスの結果が新しいペイロードにギャザーされて次のカードに送信されるまでの最大待ち時間 (ミリ秒)。0 または負の値は、タイムアウトが設定されていないことを意味します。デフォルト値は、64 ビット浮動小数点値の最大値である 9,223,372,036,854,776,000 ミリ秒です。 Max concurrency (最大同時実行) 並列に処理される最大ルート数。デフォルトでは、Scatter-Gather カードのインスタンスで作成したすべてのルートが並列に実行されます。 カードに表示されるデフォルト値は 2,147,483,647 です。デフォルト値がこの値になっている理由については気にする必要はありません。単に、この値を Scatter-Gather カードのスコープに含まれるルート数に設定しないと、スコープ内のルート数が実効値となることだけを理解しておいてください。 この値を 1 に設定すると、Scatter-Gather カードはペイロードの最初の要素を取って、各ルートでセットアップされている条件に対して評価し、条件を満足したルートで要素を送信します。ルートが要素の処理を完了すると、Scatter-Gather カードは次の要素をルート条件に対して評価し、ペイロードのすべての要素が処理されるまで同じ処理を繰り返します。 Scatter-Gather カードを設定する場合は、以下の項目に値を指定することができます (必須ではありません)。 Target (対象) ギャザーされたペイロードを保存するために使用する変数を指定します。デフォルトでは、出力はフローのペイロードに保存されます。 Target Value (対象値) 操作の出力値に対して評価する式を指定します。この式の結果は対象変数に保存されます。デフォルトでは、これは操作の出力値と同じです。 ## [](#関連情報)関連情報 - [フロー内でのデータの保存および再利用](https://docs.mulesoft.com/jp/design-center/fd-store-data-top) # 項目での DataWeave 式の作成 (Flow Designer):page-support-status: eolScheduled 式をテキストと混在した、または式を単独で使用した DataWeave 式をカードの項目内で作成し、実行時にフローがトリガーされた時点で動的な値を作成できます。新しいエディターには、式の作成を補助する機能があります。 ## [](#このタスクについて)このタスクについて フローの各カードは、右側にあるリストに対応します。リストの最初のエントリには ​`Custom Expression`​ というラベルが付いています。(リストの他のエントリは、カードの前に最低 1 つの他のカードが存在する場合に表示されます。ただし、このタスクで必要なのは ​`Custom Expression`​ エントリのみです。) ## [](#手順)手順 1. 項目に DataWeave 式を追加するカードを開きます。 2. カードの右側にあるリストで ​`Custom Expression`​ をクリックして、項目までドラッグします。

[Custom Expression (カスタム式)]​ 要素をドラッグすると、ドロップ先として選べる項目の境界線が強調表示されます。

3. `expression`​ エントリの矢印をクリックし、エントリの下に表示されるウィンドウで ​**\[Expand (展開)\]**​ をクリックします。 4. エディターの右側に表示されるヘルプを参照しながら仕置きを作成します。 - **\[Add Data (データの追加)\]**​ ペインで、式に追加するペイロード要素、属性、および変数を選択します。いずれかをクリックすると、式中のカーソル位置に挿入されます。 - **\[Add Functions (関数の追加)\]**​ ペインで、式に追加する DataWeave 関数を選択します。いずれかをクリックすると、式中のカーソル位置に挿入されます。関数をクリックすると、その説明も表示されます。 ## [](#関連情報)関連情報 - [DataWeave 言語](#4.1@mule-runtime::dataweave.adoc)