Normes de qualité du contenu

Toutes les listes sur Marketplace doivent respecter les directives générales suivantes :

Directives	Détails (Details)
Haute réutilisation	Lors de la création de connecteurs, gardez à l'esprit qu'il doit être hautement réutilisable dans le sens où il peut être utilisé dans plusieurs processus et peut être facilement adapté à différents cas, par un grand nombre d'utilisateurs. Il est important de demander l'entrée de l'utilisateur là où des valeurs spécifiques à l'intégration sont nécessaires et de ne pas inclure de valeurs inutiles spécifiques à un build particulier. Les zones communes pour les variables d'entrée utilisateur comprennent Authentification (clé API, sous-domaine, ID client/clé secrète client) Paramètres de chemin d'accès (URL de base ou chemin d'accès à la ressource) Paramètres et champs de demande (ne fournissez pas de valeurs par défaut spécifiques à un build)
Intégralité	Le connecteur doit permettre de résoudre le cas d'utilisation cible pour un utilisateur final. La liste doit couvrir les cas d'utilisation et les fonctionnalités du connecteur qui sont implémentés.
Originalité	Il est important de ne pas dupliquer les fonctionnalités de connecteurs déjà disponibles dans le catalogue officiel UiPath. Veuillez nous contacter si vous souhaitez suggérer des améliorations ou étendre les fonctionnalités d'un connecteur qui est déjà disponible dans notre catalogue officiel.

Important :

Pour qu'une liste soit publiée sur UiPath Marketplace, vous devez inclure dans la Description de la liste tous les détails sur les capacités fournies par le connecteur et toute information sur la compatibilité avec les systèmes cibles.

Les partenaires ne peuvent pas inclure les noms de tiers ou d'applications de tiers ou d'autres produits tiers dans le texte de leur liste ou description de produit sur la place de marché UiPath sans l'autorisation expresse du tiers.

Normes pour les connecteurs

Toutes les vérifications ci-dessous doivent être traitées dans les métadonnées du package du connecteur avant de le soumettre sur Marketplace :

• Convention d'ID/nom de package :

  • Le nom du package doit clairement identifier le fournisseur/le système pour lequel vous créez le connecteur.

• Les descriptions doivent être spécifiées pour les éléments suivants :

  • Connecteur

  • Activités (Activities)

  • Champs

• Assurez-vous de choisir la catégorie pertinente sous laquelle le connecteur doit être publié.

• Les balises pertinentes sont ajoutées.

• L' URL de la licence (License URL) et la case à cocher Acceptation de la licence (License Acceptation) sont spécifiées en fonction du type de licence sélectionné.

• Le propriétaire du package est mentionné. Le nom de l'entreprise doit être ajouté dans le cas d'une publication au nom de l'entreprise.

• L'icône doit être celle du fournisseur pour lequel vous créez le connecteur ou une image appropriée qui aide les utilisateurs à identifier le fournisseur/le système auquel le connecteur appartient. Veuillez ne pas utiliser d'images pour lesquelles vous ne possédez pas le droit.

• La langue est spécifiée, même si le champ est marqué comme Facultatif (Optional).

• La compatibilité du connecteur avec le système du fournisseur est clairement indiquée (par exemple, quelles versions du système du fournisseur sont prises en charge, les limitations, etc.).

• Les activités ont des noms uniques dans un connecteur pour faciliter leur débogage.

• Recherchez les cas importants qui pourraient survenir pendant l’exécution.

• Vérifiez les goulots d’étranglement des performances.

• Vérifiez les opportunités d’optimisation.

• Les mots de passe ou les informations sensibles ne doivent pas être exposés ou enregistrés par le connecteur. Aucune valeur d'authentification différente selon la connexion ne doit être stockée dans la configuration de l'authentification.

• Les connecteurs avec OAuth 2.0 doivent toujours être ByOA (c'est-à-dire apportez votre propre authentification où l'utilisateur/client configure l'application OAuth 2.0 et fournit les paramètres nécessaires tels que l'ID de client, le secret de client, etc.).

• Pour les connecteurs utilisant OAuth 2.0, ne codez pas en dur l'ID client et la clé secrète du client dans le package du connecteur.

• Assurez-vous que les aspects suivants sont suivis pour les activités et les champs :

  • Le titre de l'activité/le nom d'affichage doit toujours être Title Case (par exemple Envoyer un message au canal)
  • La description de l'activité doit toujours être Sentence Case (par ex. Envoyer un message à un utilisateur individuel)
  • Le titre du champ/NomComplet doit toujours être Sentence Case (par ex. Icône de bot)
  • La description de l'activité doit toujours être Sentence Case (par ex. Icône de bot)
  • Les catégories de connecteurs doivent être au format Sentence Case (Eg aux informations artificielles)

• Évitez les URL de base à codage en dur susceptibles d'être modifiées (par ex. l'URL de base contient la version du système du fournisseur).

• Assurez-vous que les ENUMS sont ajoutés avec des noms complets/descriptions lisibles par l'utilisateur (à l'aide d'Enums améliorés).

• Assurez-vous que les types de données appropriés sont définis dans les champs pour toutes les activités. Évitez la transformation/conversion inutile de types de données dans le connecteur.

• Dans le cas des déclencheurs, assurez-vous d'avoir des filtres de données d'événement significatifs. Par exemple, n'ajoutez pas de champs tels que IDs, GUIDs , etc., qui ne peuvent pas être utilisés pour le filtrage.