Méthode d'action

La méthode d'action est un objet qui peut être utilisé pour définir la configuration en fonction de certains critères. Par exemple, lors du lancement d'un scénario de démarrage de service, le type de demande de service peut varier en fonction de la division SIC et de la classe client. Lorsqu'un utilisateur lance un processus de démarrage de service, le système peut lui demander des informations sur le client pouvant déterminer la division SIC et la classe client. Le système peut alors appeler un algorithme transmettant ces informations pour extraire le type de demande de service approprié à utiliser, tel que défini dans la méthode d'action. Dans cette section, le terme "critères" est utilisé pour identifier les informations servant à déterminer la configuration souhaitée et le terme "détails" ou "résultats" est utilisé pour identifier les informations de configuration en cours de détermination.

Si vous concevez un cas d'utilisation pour utiliser cette fonctionnalité, tenez compte des points suivants :

  • Quelles informations doivent être identifiées (les "détails"/ "résultats") ? L'exemple ci-dessus utilise un objet de configuration (type de demande de service). Toutefois, les informations que vous déterminez peuvent varier en fonction de certaines combinaisons d'attributs. Vous pouvez les utiliser pour déterminer l'algorithme de collecte à exécuter en fonction de critères. Ou le nombre de jours à attendre pour poursuivre un processus dans un cas d'utilisation donné.

  • Quand et où dois-je déterminer ces informations et que dois-je faire une fois que je les ai reçues ?

    • Sont-elles nécessaires dans le cadre d'une interaction utilisateur ?

    • Sont-elles nécessaires pour le traitement interne ?

  • Quels sont les critères nécessaires pour déterminer les informations souhaitées ? Est-ce que je dispose de ces informations au moment où j'en ai besoin ? Ou dois-je demander à un utilisateur de fournir ces informations ?

Le produit Framework fournit les objets génériques nécessaires pour prendre en charge ce type de fonctionnalité. Les implémentations ou produits intégrables individuels peuvent créer leurs cas d'utilisation à l'aide des outils fournis. Les rubriques de cette section décrivent plus en détail les fonctions fournies.

Rôle de méthode d'action

La fonctionnalité de méthode d'action est déterminée par le rôle de méthode d'action, qui représente un cas d'utilisation donné. Voici quelques exemples de rôles de méthode d'action pertinents dans un produit d'entreprise : "Démarrer le service", "Arrêter le service" et "Transférer le service". Les rôles de méthode d'action valides sont définis à l'aide d'une consultation avancée et référencés dans la méthode d'action. Une seule méthode d'action peut être définie pour un rôle de méthode d'action.

L'enregistrement de rôle de méthode d'action peut référencer un script APT de rôle de méthode d'action, si le cas d'utilisation de ce rôle de méthode d'action implique une interaction utilisateur. Si nécessaire, ce script est chargé d'utiliser la valeur du rôle de méthode d'action, de déterminer la méthode d'action qui référence le rôle, d'identifier le script APT de traitement d'action plus spécifique (défini sur l'objet métier) et de transférer le contrôle vers ce script. Cette référence peut être utilisée à des fins d'audit ou d'information, selon la manière dont vous avez implémenté l'expérience utilisateur. Le script APT du rôle de méthode d'action est idéalement configuré sur une entrée de menu appropriée ou un bouton d'action sur une interface utilisateur spécifique liée à ce cas d'utilisation.

Si votre cas d'utilisation ne nécessite pas d'interaction utilisateur, un script APT de rôle de méthode d'action n'est pas nécessaire.

Objet métier Méthode d'action

L'objet métier de la méthode d'action est utilisé pour définir les informations à configurer à la fois pour les critères et les résultats. Pour l'exemple ci-dessus, l'objet métier d'un cas d'utilisation Démarrer le service définit une liste qui capture la division SIC et la classe client, ainsi que le type de demande de service à utiliser. Les informations sont configurées dans la zone de données XML pour la méthode d'action et la conception du schéma est dictée par les besoins métier. Par exemple, il se peut que votre cas d'utilisation impose une valeur par défaut pour les résultats (dans notre cas, le type de demande de service) plus des valeurs de remplacement basées sur une combinaison division/classe client.

Plug-in Obtenir les détails de méthode d'action

Outre la définition des informations de schéma pour la capture des critères et des résultats, l'objet métier définit l'algorithme qui doit être appelé pour extraire les résultats en fonction des critères.

L'emplacement de plug-in est Obtenir les détails de la méthode d'action. Son API est flexible dans les informations qu'elle reçoit et renvoie, de sorte que chaque cas d'utilisation de la méthode d'action peut concevoir l'algorithme en fonction de ses besoins métier.

L'algorithme reçoit une liste de "Données de critères" à l'aide de "nom" et jusqu'à 5 valeurs (pour gérer les clés primaires composées). En règle générale, seule la "valeur 1" est nécessaire pour chaque entrée. Le type d'algorithme conçu pour un objet métier de méthode d'action donné peut déterminer les informations reçues. Il se peut qu'il attende les éléments de critères définis dans la méthode d'action. Dans notre exemple, le type d'algorithme peut s'attendre à recevoir la division SIC et la classe client. Alternativement, le type d'algorithme peut être conçu pour recevoir une valeur qui peut être utilisée pour déterminer les critères nécessaires. Par exemple, il peut recevoir l'ID compte et utiliser ces informations pour déterminer la division SIC et la classe client.

L'algorithme renvoie un ou plusieurs résultats en tant que "Détails". Les informations renvoyées sont basées sur le cas d'utilisation. Dans notre exemple, le type de demande de service est renvoyé. Vos besoins métier peuvent utiliser le rôle de méthode d'action pour renvoyer plusieurs résultats, par exemple un type de demande de service et un type de flux de processus à appeler pour capturer toutes les informations nécessaires au démarrage du service.

Le produit fournit un service fonctionnel F1-RetrieveActionMethodDetails pour appeler l'algorithme pour une valeur de méthode d'action donnée.

APT de traitement d'action

Si vos besoins métier nécessitent une interaction utilisateur pour déterminer les critères à transmettre à l'algorithme Obtenir les détails de la méthode d'action ou pour utiliser les informations résultantes pour poursuivre une action en ligne, un APT de traitement d'action est nécessaire. Cet APT doit être conçu et lié à votre objet métier de méthode d'action en tant qu'option à l'aide du type d'option Script APT de traitement d'action.

La conception de cet APT dépend de vos besoins métier. Toutefois, il peut être nécessaire d'inviter l'utilisateur à fournir les informations nécessaires pour déterminer les critères associés aux détails de la méthode d'action, puis d'appeler le service fonctionnel F1-RetrieveActionMethodDetails pour exécuter l'algorithme de votre méthode d'action. Une fois les résultats renvoyés, le script passe à l'étape suivante du cas d'utilisation métier.

Remarque :
Si des informations supplémentaires doivent être collectées par le serveur avant ou après l'appel au service fonctionnel qui exécute l'algorithme, il est recommandé que le script APT appelle un script de service qui exécute toute la logique au niveau du serveur en une seule fois.

Objet métier Rôle de méthode d'action/Méthode d'action

Le rôle de méthode d'action définit le cas d'utilisation. L'objet métier est utilisé pour concevoir le schéma pour les critères et les résultats, et identifie l'APT de traitement d'action et le plug-in Obtenir les détails de la méthode d'action. Il peut justifier un objet métier unique pour chaque rôle de méthode d'action. Toutefois, il peut y avoir des cas où plus d'un rôle de méthode d'action et sa méthode d'action peuvent réutiliser le même objet métier. Par exemple, supposons qu'il existe différents types de demande de service pour Démarrer le service, Arrêter le service et Transférer le service, mais que dans tous les cas, la valeur valide soit déterminée par la division SIC et la classe client. Ces trois rôles de méthode d'action et méthodes d'action distincts peuvent réutiliser un objet métier commun définissant les critères de division SIC et de classe client qui déterminent le type de demande de service approprié.