Logic Apps Standard CLI

Utilisez az logicapp comme interface principale pour les opérations de projet Standard, workflow, connexion, validation, runtime, diagnostic, test et packaging prises en charge. Ne recréez pas manuellement les fichiers ou les configurations Azure gérés par une commande supportée. La création manuelle de workflows, les fichiers d'espace de travail, les fichiers d'exclusion et l'infrastructure en tant que code restent appropriés lorsque la CLI ne possède pas cette opération.

Baseline examinée : extension 1.0.0b1. Il s'agit d'une préversion publique destinée à l'évaluation et au développement, non d'une revendication de disponibilité en production. Utilisez des ressources non-production pour l'évaluation. Les commandes existantes de gestion d'application, de paramètres d'application et de déploiement ZIP sont distinctes des commandes de préversion de l'extension, même si certaines pages de référence les étiquettent comme GA. Le support de plateforme déclaré ne constitue pas une qualification de runtime actif.

Routage des procédures obligatoires

Ce dossier est un package de compétence installable. Résolvez les fichiers groupés par rapport à ce SKILL.md, non au répertoire de travail du client. Installez/copiez l'ensemble du dossier. Ces références sont des procédures requises, non des lectures contextuelles optionnelles. Consultez le README du package pour les notes d'installation, de provenance et de maintenance.

Avant l'opération correspondante, lisez chaque référence applicable ci-dessous. Pour les tâches combinées, lisez chaque procédure requise avant sa phase. Si un fichier requis est manquant ou illisible, signalez cette opération comme bloquée. N'inventez pas de syntaxe, ne contournez pas ses prérequis et ne récupérez pas de substitut non examiné.

L'échafaudage local de base, la création d'espace de travail et la validation hors ligne sont spécifiés ici. Ne démarrez pas d'hôte, ne restaurez pas de packages, n'invoquez pas de workflows et ne mutez pas Azure uniquement parce que la compétence a été activée. Sélectionnez uniquement les procédures nécessaires pour la tâche demandée.

Règles non négociables

1. Inspectez avant de muter. Établissez la racine réelle du projet et l'étendue demandée. Inspectez les workflows affectés, la structure/les références de configuration, les fichiers d'exclusion, les espaces de travail et les modifications non commises. Ne videz pas les valeurs de paramètres secrets.
2. Préservez les conventions existantes. Ne restructurez pas les référentiels, ne convertissez pas les types de workflows, ne migrez pas l'authentification, ne normalisez pas les alias et ne remplacez pas les fichiers utilisateur sans autorisation.
3. Utilisez l'identité gérée par défaut. Pour les nouvelles connexions et la configuration d'application déployée, utilisez une autre méthode d'authentification uniquement si explicitement demandée par le client ou non supportée par le connecteur/l'opération sélectionné. L'échec d'authentification ne prouve pas le manque de support. Ne basculez jamais silencieusement vers des secrets.
4. Activez l'identité dans le cadre de la livraison d'un nouveau projet. Configurez le mécanisme de connexion basé sur l'identité local supporté. Pour le travail orienté déploiement, activez l'identité d'application via le processus de provisionnement/déploiement autorisé. Préservez une convention d'identité existante ; sinon, utilisez par défaut l'identité affectée au système. L'échafaudage local n'autorise pas la mutation Azure ; signalez explicitement les prérequis cloud non approuvés.
5. Vérifiez les principaux et les permissions distincts. Un processus local n'acquiert pas l'identité gérée d'une application déployée. Suivez le mécanisme local documenté du connecteur ; ne supposez pas que chaque connecteur utilise DefaultAzureCredential. Vérifiez séparément les principaux locaux et cloud, l'accès à la connexion et les rôles de plan de données avec privilèges minimaux.
6. Découvrez, ne devinez pas. Obtenez les ID de connecteur, les ID d'opération, les ensembles de paramètres et les formes d'entrée requises à partir du runtime réel ou du catalogue géré régional. Vérifiez le support d'authentification en utilisant les métadonnées et la documentation autorisée du connecteur.
7. Protégez les secrets et les sorties sensibles. Ne placez jamais les valeurs secrètes dans les arguments de commande, le contrôle de source, les exemples ou les journaux partagés. Traitez les définitions, les exports et les sorties du fournisseur existants comme potentiellement sensibles ; protégez-les et examinez-les avant de les partager. Utilisez l'entrée secrète stdin supportée et les références de paramètres. Le stockage local/runtime protégé requis est autorisé ; les paramètres locaux et les artefacts de test doivent être ignorés et exclus du déploiement.
8. Gardez les environnements configurables. Mettez les endpoints, les ID de ressources et les valeurs d'environnement spécifiques au déploiement dans les paramètres ou les paramètres, non dans les littéraux de workflow codés en dur.
9. Gardez les remplacements et la concurrence. Inspectez avant chaque création ; traitez la création comme non-idempotente. Utilisez --force uniquement pour un remplacement examiné. Exportez les workflows actifs avant remplacement/suppression, conservez les révisions et obtenez l'approbation pour les écritures non-atomiques. Ne contournez pas les conflits et ne réessayez pas aveuglément les mutations incertaines.
10. Autorisez les effets, pas seulement les cibles. Le démarrage des déclencheurs locaux et l'exécution du code de test/build peuvent contacter des systèmes réels. Établissez d'abord les effets autorisés. Obtenez une autorisation explicite pour les mutations Azure, l'annulation et la relecture ; l'aperçu n'est pas un bac à sable.
11. Gardez les preuves honnêtes. Lisez les résultats structurés même sur les sorties différentes de zéro. Distinguez les états configurés, autorisés, acceptés, observés et vérifiés. Un port ouvert, une invocation acceptée, un plan généré ou un rapport inspecté n'est pas une exécution de workflow réussie.
12. Validez sans fabriquer le succès. Validez progressivement ; exigez une validation complète stricte du projet avant l'empaquetage/déploiement de la version. Préservez la politique de référentiel plus stricte. Ne supprimez pas les avertissements, les assertions, les sorties ou les gardiens simplement pour obtenir un résultat réussi.
13. Possédez le nettoyage précisément. Arrêtez uniquement les runtimes appartenant à la tâche sauf demande de les laisser en cours d'exécution ; vérifiez l'arrêt et la propriété des dépendances partagées. Ne tuez jamais les processus par nom et n'arrêtez pas l'hôte/l'émulateur d'un autre utilisateur.
14. Préservez les limites de déploiement. Fusionnez les règles d'exclusion sans remplacer les entrées non liées ; inspectez l'archive réelle. Ne déployez pas les paramètres locaux, les tests, l'état, les fichiers d'éditeur, les journaux, les modèles de paramètres ou les packages générés.
15. Gardez la sémantique des connecteurs spécialisée. Utilisez les directives spécifiques au connecteur disponibles pour les garanties de livraison, la gestion des poisons et les tests spécifiques à l'opération. Si indisponible, utilisez la documentation autorisée du connecteur ; n'inventez pas de comportement spécialisé.

Valeurs par défaut et choix importants

Déduisez les chemins et les choix établis de la demande/du référentiel. Posez des questions uniquement sur les décisions manquantes et importantes. N'insistez pas sur trois questions d'échafaudage quand les réponses sont connues.

1. Vérifiez l'outillage et sélectionnez la cible

Inspectez d'abord ; ces commandes n'installent pas l'extension :

az version
az extension list --query "[?name=='logicapp'].{name:name,version:version}" --output table

Minimums pour la version examinée : Azure CLI 2.67.0 et son runtime Python 3.10. Si l'extension est absente et l'installation est autorisée, utilisez l'index d'extension public :

az extension add --name logicapp --version 1.0.0b1 --allow-preview true
az extension show --name logicapp --output json
az logicapp --help

Vérifiez la sortie après chaque commande ; ne continuez pas après une installation échouée. Si la version demandée est indisponible, signalez l'erreur d'index/réseau/version. Ne remplacez pas par une wheel privée, ne désactivez pas TLS et ne contournez pas la politique de package organisationnelle. Ne mettez pas à niveau automatiquement une extension installée. Pour une version installée différente, inspectez le --help de chaque commande affectée et les contrats officiels actuels avant l'exécution ; signalez les différences matérielles au lieu de supposer que cette baseline s'applique toujours.

Détectez le système d'exploitation et le shell avant d'utiliser les exemples. Les blocs azurecli sur une seule ligne évitent les continuations spécifiques au shell. App, Orders et les identifiants en majuscules sont des noms illustratifs : remplacez la cible inspectée, citez les chemins contenant des espaces et utilisez le séparateur de chemin du système d'exploitation hôte. Les guillemets de PowerShell/wrapper natif pour les expressions sont spécifiés dans la procédure de connexions.

Pour les commandes ciblant l'API, un --port explicite requiert --local. Un contexte nommé possède ses coordonnées : ne les mélangez pas avec les drapeaux de cible API explicites. Inspectez le --help spécifique à la commande pour les combinaisons de contexte de commande fichier ; ne supposez pas une règle de précédence universelle unique. Le travail cloud requiert la connexion Azure, le tenant, l'abonnement et les permissions visés. Vérifiez la sélection de compte indépendamment : les contextes enregistrés ne lient pas l'abonnement/le tenant. Évitez de changer la sélection de compte global ; préférez un --subscription explicite en automatisation.

2. Inspectez et générez localement

Classifiez la destination comme nouveau, un projet Standard existant ou un répertoire non vide non reconnu. La racine du projet/hôte contient host.json ; les répertoires de workflow sont ses enfants directs. La racine du référentiel peut elle-même être cette racine de projet.

Pour un projet existant, inspectez host.json, les fichiers de workflow, connections.json, parameters.json si présent, les noms/références de paramètres, les fichiers d'exclusion, les espaces de travail et les modifications non commises affectées. Préservez le contenu non lié et évitez d'exposer les valeurs locales.

Pour un nouveau projet, choisissez une disposition minimale de projet-à-racine ou un projet enfant solution/monorepo selon les exigences. Les répertoires de support tels que docs, requests, fixtures, tests, logs et artifacts sont optionnels et créés uniquement pour le travail réel. Préférez la sortie de package en dehors de la racine hôte. N'créez pas d'état runtime .azurelogicapps.

Après avoir inspecté la destination, générez en utilisant des chemins explicites :

az logicapp project create --path App --workflow Orders

Ajoutez --workflow-kind Stateless uniquement pour un choix Stateless intentionnel. Utilisez --adopt uniquement pour un répertoire non vide non reconnu examiné, non comme configuration de routine. Inspectez les fichiers host/paramètres/connexion/workflow générés avant de les étendre. Créez des workflows supplémentaires sans remplacer les existants :

az logicapp workflow create --path App --workflow Notify --kind Stateful

--file FILE accepte un fichier de workflow complet examiné ou une définition brute pour l'importation locale. La création est locale uniquement et non-idempotente. Ne l'utilisez pas pour ajouter un workflow cloud.

Avant d'écrire des paramètres locaux sensibles, confirmez les exclusions Git effectives. Fusionnez les règles par rapport aux racines réelles du référentiel et de l'hôte ; ne copiez jamais .gitignore sur .funcignore. Excluez toujours les paramètres/l'état locaux du contrôle de source et du déploiement. Si vous modifiez les exclusions de déploiement, lisez d'abord la procédure d'empaquetage et suivez ses règles concrètes.

Portail : Racine de projet correcte, types de workflow demandés, fichiers utilisateur préservés, exclusions de secret effectives et configuration basée sur l'identité ou un prérequis explicitement signalé.

3. Espace de travail et contexte optionnels

Un fichier .code-workspace est optionnel ; ouvrir le répertoire hôte est valide. Réutilisez un espace de travail existant. Quand un nouvel espace de travail multi-racine est demandé, utilisez les chemins relatifs aux dossiers réels et placez le projet hôte Logic Apps en premier. Ne créez pas de dossiers vides juste pour le remplir. Adaptez ce JSON à la disposition sélectionnée ; ce n'est pas un nom de fichier ou un schéma de dossier requis :

{
  "folders": [
    { "name": "Logic App", "path": "App" }
  ]
}

Préservez les paramètres et noms d'espace de travail existants. Ajoutez des racines docs/test uniquement quand utiles et présentes. Pour un espace de travail projet-à-racine, le chemin du projet est ".".

Les contextes enregistrés sont optionnels. Inspectez context list avant de choisir un nom unique spécifique au projet. Si demandé, créez un raccourci sans le sélectionner implicitement :

az logicapp context list --output table
az logicapp context create --name orders-local --path App --port 7071
az logicapp context show --name orders-local

Utilisez context use --name NAME ou la création --use uniquement quand la sélection active est autorisée. context update préserve les champs omis et ne sélectionne pas une cible ; modifier une cible active invite sauf si --yes est autorisé. Un changement de type requiert un chemin/port local explicite ou des coordonnées de groupe de ressources/application cloud. Inspectez son aide avant de changer le type. context delete supprime uniquement un raccourci ; supprimer le raccourci actif efface la sélection sans en choisir un remplacement. Les magasins suivent AZURE_CONFIG_DIR ; aucune credential ne leur appartient.

4. Créez et validez

Préservez la structure/le type de workflow. Utilisez des noms d'action/déclencheur stables. Implémentez le tri requis, la ramification, les retries, les timeouts et les chemins d'échec ; les chemins de succès/échec terminaux ne doivent pas s'exécuter ensemble. Utilisez les formes d'opération découvertes et les valeurs d'environnement configurables. Créez des fixtures non-sensibles représentatives uniquement si nécessaire.

Pour la découverte de connecteur intégré, lisez à la fois les procédures runtime local et connexions avant d'établir un démarrage d'hôte sûr et d'interroger le catalogue. Pour la validation appuyée par runtime, lisez la procédure runtime local et établissez la disponibilité d'abord. Les tests natifs peuvent plutôt utiliser des mocks créés sans démarrer d'hôte.

Validez le workflow en cours de développement actif :

az logicapp workflow validate --path App --workflow Orders

Pour la création de projet terminée et avant l'empaquetage/déploiement de version :

az logicapp workflow validate --path App --all --fail-on-warning

Quand la validation appuyée par runtime est requise, établissez d'abord la disponibilité de l'hôte :

az logicapp workflow validate --path App --all --fail-on-warning --with-runtime --local --port 7071

Ne démarrez pas d'hôte uniquement pour une édition/revue hors ligne. Évaluez les résultats et préservez la politique de référentiel ; signalez les échecs pré-existants non liés séparément sans affaiblir les portails de version. La validation statique, la validation de modèle runtime, les assertions natives et les vérifications d'intégration actives sont des preuves distinctes. Une réponse de validation runtime complétée est requise ; la validation asynchrone acceptée seule n'établit pas la complétion.

Preuves d'accomplissement

Appliquez uniquement les portails pertinents pour la tâche demandée ; ne transformez pas une inspection en déploiement.

Indiquez les permissions, dépendances, ressources, vérifications non exécutées, ressources conservées et effets incertains concrets manquants. N'appelez pas l'identité configurée autorisée, une demande acceptée terminée, une suite ignorée réussie ou un prérequis bloqué satisfait.