- リリース ノート
- 概要
- 基本情報
- Marketplace ベンダー
- Marketplace のお客様
- パブリッシング ガイドライン
- すぐに使えるオートメーションのパブリッシング ガイドライン
- ソリューション アクセラレータの公開ガイドライン
- Integration Service コネクタの公開ガイドライン
- セキュリティと IP 保護
- その他の UiPath コンポーネント
- Node-RED
- セットアップ
- Teams
- Microsoft Teams Scope
- Create Team
- チームをグループから作成する
- Get Team
- Get Teams
- Channels
- チャンネルを作成
- Delete Channel
- Get Channel
- Get Channels
- Update Channel
- Chats
- Get Chat
- Get Chats
- Get Chat Members
- Messages
- Get Message
- メッセージを取得
- Get Message Replies
- Reply To Message
- メッセージを送信
- イベント
- イベント/予定を作成
- イベント/予定を削除
- Get Event
- Get Events
- ユーザー
- Get User Presence
- 動作のしくみ
- テクニカル リファレンス
- はじめに
- 概要
- セットアップ
- テクニカル リファレンス
- Azure Form Recognizer Scope
- アクティビティ
- Analyze Form
- Analyze Form Async
- Get Analyze Form Result
- Analyze Receipt
- Analyze Receipt Async
- Get Analyze Receipt Result
- Analyze Layout
- Analyze Layout Async
- Get Analyze Layout Result
- Train Model
- Get Models
- モデル のキーを取得
- Get Model Info
- Delete Model
- コネクタ
- How to Create Activities
- 連携の独自開発
高品質コンテンツの基準
Marketplace のすべてのコンポーネントは、以下の一般的なガイドラインを満たす必要があります。
ガイドライン | 詳細 |
高い再利用性 |
コネクタを作成するときは、複数のプロセスで使用でき、多数のユーザーがさまざまなケースに簡単に適応できるという意味で、再利用性が高い必要があることに注意してください。 統合固有の値が必要な場所でユーザー入力を求め、特定のビルドに固有の不要な値を含めないことが重要です。 ユーザー入力変数の一般的な領域は次のとおりです。
|
完全性 | コネクタは、エンドユーザーのターゲットユースケースを解決できるようにする必要があります。 このリストには、実装されているコネクタのユース ケースと機能が記載されています。 |
独自性 | UiPath の公式カタログに既に掲載されているコネクタの機能を重複させないことが重要です。 公式カタログで既に利用可能なコネクタの改善点や機能の拡張を提案したい場合は、お問い合わせください。 |
コンポーネントを UiPath Marketplace で公開するには、コンポーネントの説明に、コネクタが提供する機能の詳細とターゲット システムとの互換性に関する情報をすべて含める必要があります。
パートナーは、サードパーティからの明示的な承認なしに、サードパーティまたはサードパーティのアプリあるいは他のサードパーティ製品の名前を、UiPath Marketplace のコンポーネントまたは製品の説明のテキストに記載することはできません。
以下のすべてのチェックは、Marketplace に提出する前に、コネクタ パッケージのメタデータで対処する必要があります。
-
ID/パッケージの命名規則:
-
パッケージ名は、コネクタを構築するベンダー/システムを明確に識別する必要があります。
-
-
次の説明を指定する必要があります。
-
コネクタ
-
アクティビティ
-
フィールド
-
-
コネクタのパブリッシュに使用する関連カテゴリを必ず選択してください。
-
関連するタグが付加されていること。
-
選択したライセンスの種類に基づいて、ライセンスの URL が指定されておりライセンスへの同意についてのチェックボックスがオンになっていること。
-
パッケージの所有者が記述されていること。企業を代表して公開する場合は、企業名が追加されている必要があります。
-
アイコンは、コネクタを構築するベンダーのアイコン、またはコネクタがどのベンダー/システムのためであるかをユーザーが識別するのに役立つ適切な画像である必要があります。 権利のない画像は使用しないでください。
-
フィールドがオプションとしてマークされている場合でも、言語は指定されます。
-
コネクタとベンダー システムとの互換性が明確にリストされている (サポートされているベンダー システムのバージョン、制限事項など)。
-
アクティビティには、デバッグを容易にするためにコネクタ内で一意の名前が付けられます。
-
実行時に発生する可能性があるコーナー ケースを確認すること。
-
性能のボトルネックを確認すること。
-
最適化の余地を確認すること。
-
パスワードや機密情報は、コネクタによって公開または記録されるべきではありません。 接続ごとに異なる認証値を認証構成に格納しないでください。
-
OAuth 2.0 のコネクタは常に BYOA (例: ユーザー/顧客がOAuth 2.0アプリを構成し、クライアントID、クライアントシークレットなどの必要なパラメーターを提供する場合は、独自の認証を持ち込みます。
-
OAuth 2.0 を使用するコネクタの場合、クライアント ID とクライアント シークレットをコネクタ パッケージの一部としてハードコーディングしないでください。
-
アクティビティとフィールドについて、以下の要素が満たされていることを確認してください。
-
[アクティビティ タイトル]/[表示名] は常に
Title Case
にします (例: [チャンネルにメッセージを送信])。 -
アクティビティの説明は常に
Sentence Case
(例: 個々のユーザーにメッセージを送信する) -
[フィールド タイトル]/[表示名] は常に [
Sentence Case
] (例: ボットアイコン) -
アクティビティの説明は常に
Sentence Case
(例: ボットアイコン) -
コネクタのカテゴリは
Sentence Case
である必要があります(例:人工知能)
-
-
変更の影響を受けるベース URL をハードコーディングすることは避けてください (例: ベース URL にベンダー システムのバージョンが含まれています)。
-
ユーザーが判読できる表示名/説明を使用して
ENUMS
が追加されていることを確認します (拡張列挙型を使用)。 -
複数のアクティビティのフィールドに適切なデータ型が設定されていることを確認してください。 コネクタ内でのデータ型の不要な変換/変換を回避します。
-
トリガーには、意味のあるイベント データ フィルターが必要です。 たとえば、
IDs
やGUIDs
など、フィルター処理に使用できないフィールドは追加しないでください。