Applications
Applications
Markdown

Comment les applications fonctionnent ensemble

Connectez les workflows via des opérations déclarées, des événements et des services de plate-forme partagée.

contrats événements notifications composition Interopérabilité intégrations
Sur cette pageContexte partagé, connexions explicitesLes contrats demandent une opérationLes événements annoncent un changementLes notifications informent les gensLes vues actualisées réutilisent les opérations de lectureLes connexions externes sont une frontière séparéeExpliquer la tâche avec un exemple complet

Contexte partagé, connexions explicites

Opser apporte des applications dans un espace de travail avec un système d’identité et d’autorisation partagé. Chaque application possède toujours ses enregistrements et son comportement. Les applications fonctionnent ensemble en exposant les capacités et en déclarant celles qu’elles utilisent.

Cette distinction est importante lorsque vous demandez à un agent de connecter des flux de travail. Nommez la source, le déclencheur ou la demande, la destination et le résultat. L'agent peut inspecter les interfaces disponibles et identifier tout ce qui doit être construit.

Les contrats demandent une opération

Un contrat est une opération nommée qu'une application offre à une autre. Un fournisseur peut offrir « obtenir la disponibilité de l’équipement. » Une application demandeuse déclare qu’elle consomme cette opération, envoie les entrées requises et obtient un résultat.

La plateforme vérifie la relation déclarée entre le fournisseur et le consommateur. Les règles de ressources et l'autorité sous laquelle la demande s'exécute s'appliquent également. Une application ne peut pas simplement appeler une opération arbitraire dans une autre application parce que les deux sont installés.

Utilisez un contrat lorsqu’un flux de travail nécessite une réponse ou une action dès maintenant. Si le fournisseur est manquant, indisponible ou refuse l'accès, le flux de travail demandeur doit gérer ce résultat. Une application personnalisée utile explique le problème au lieu de présenter un résultat vide comme un succès.

Les événements annoncent un changement

Un événement décrit quelque chose qui s'est passé, comme un retour d'équipement enregistré. L'application émettrice déclare l'événement, et une application réceptrice déclare son abonnement et implémente la réponse.

Les événements permettent aux workflows de réagir sans que l’application d’origine n’effectue toutes les étapes en aval. Un système de demande pourrait réagir à un retour en vérifiant une liste d'attente. Cette connexion doit être implémentée ; un nom d'événement seul ne crée pas le comportement.

La livraison peut être rejugée, de sorte qu'un flux de travail de réception doit gérer le même événement plus d'une fois sans dupliquer son travail. Les événements sont livrés aux abonnements actifs lorsqu'ils sont émis. Un nouvel abonnement ne rejoue pas automatiquement le passé, et une livraison échouée n'est pas une garantie d'achèvement éventuel. Vérifiez les enregistrements résultants lorsqu'une action en aval est manquante.

Les notifications informent les gens

Une notification est un message pour une personne. Un événement est un signal pour un flux de travail. Le même changement d'entreprise peut produire les deux, mais ils ne sont pas interchangeables.

Les applications peuvent déclarer les types de notification qui apparaissent dans Paramètres → Notifications, avec les préférences de sonnerie et de courrier électronique lorsque prises en charge. La désactivation d'une notification par e-mail ne désactive pas l'événement commercial ou l'automatisation sous-jacent. Lisez Boîte de réception et notifications pour connaître les préférences de livraison.

Les vues actualisées réutilisent les opérations de lecture

Une application peut exposer explicitement une opération de lecture pour un tableau de bord ou une autre vue composée. Son entrée et sa sortie décrivent les données que la vue peut utiliser, et l'opération conserve la logique propre à l'application : la vue continue de fonctionner quand l'application modifie ses tables.

L'agent privilégie une telle opération lorsqu'elle existe. Sinon, un tableau de bord peut tout de même lire les tables des applications que vous pouvez ouvrir, en lecture seule, comme le fait l'outil de données de l'agent ; il n'affiche jamais une application que vous ne pouvez pas ouvrir. Voir Tableaux de bord et vues en direct.

Les connexions externes sont une frontière séparée

Les connexions d'agent autorisent un agent à utiliser un service externe. Une application peut déclarer sa propre intégration pour les données entrantes ou sortantes, avec des exigences d'installation et d'accès distinctes. Aucune connexion n'accorde un accès général à chaque enregistrement d'espace de travail.

Pour un flux de travail connecté, vérifiez le compte, les opérations autorisées, qui initie le travail et où le résultat est stocké. Lisez Connectez vos outils pour les connexions d'agent.

Expliquer la tâche avec un exemple complet

Lorsque l'équipement est retourné, vérifiez les demandes d'attente, identifiez la prochaine personne admissible et avisez le coordonnateur. N'approuvez pas automatiquement le prochain paiement. Montrez-moi comment un événement répété et une application de destination manquante sont gérés.

Passez en revue le chemin normal, une dépendance indisponible, un accès refusé et un événement répété. La connexion est terminée lorsque le comportement en aval fonctionne avec les autorisations prévues, et pas seulement lorsque l'action d'origine réussit.