Surveillance de la solution de gestion des processus d'entreprise à l'aide de l'analyse BAM

La solution contrôle les étapes de traitement des commandes à l'aide de l'API BAM (Business Activity Monitoring). Le processus d'entreprise fractionne les activités en plusieurs étapes. Les activités peuvent être recombinées pour créer une impression de processus continu. L'analyse BAM fournit également des données agrégées qui vous informent de la durée des systèmes principaux, du nombre de commandes exécutées et d'autres informations semblables.

Comme la solution orientée service, elle utilise le nouvel objet OrchestrationEventStream . Pour une présentation de l’objet OrchestrationEventStream , consultez « Qu’est-ce que l’objet OrchestrationEventStream » dans Surveillance de la solution orientée service avec BAM.

Pour plus d’informations générales sur BAM, consultez Utilisation de l’analyse de l’activité métier. Pour plus d’informations sur l’Éditeur de profil de suivi (TPE), consultez Éditeur de profil de suivi.

Classe enveloppante de l'objet OrchestrationEventStream

Comme la solution orientée service, la solution de gestion des processus métier encapsule l’objet OrchestrationEventStream . Par ailleurs, toutes les méthodes sont statiques de sorte que les orchestrations n'ont pas besoin de créer des instances des objets pour utiliser les méthodes. Ainsi, les objets utilisés dans le cadre du suivi n'ont pas besoin d'être sérialisés ou enregistrés si le moteur met une orchestration en attente. Toutefois, la solution de gestion des processus métier encapsule OrchestrationEventStream avec plusieurs objets dérivés d’un seul objet abstrait.

La classe abstraite est BasicActivity. Bien qu'elle soit abstraite, elle ne sert pas vraiment de modèle pour les classes dérivées. Elle fournit plutôt, via ses méthodes statiques, un ensemble de méthodes disponibles sans qualification dans une classe dérivée. Ceci vous offre quatre implémentations par défaut des méthodes. Les quatre méthodes statiques sont : CreateActivityId, BeginActivity, UpdateActivity et EndActivity.

La classe surcharge la méthode BeginActivity . Une de ses versions récupère un nom d'activité en tant qu'argument unique, crée un GUID à utiliser comme identificateur d'activité, puis appelle sa version qui récupère un nom d'activité et un identificateur d'activité, avant de renvoyer l'identificateur d'activité. Cette version d'argument unique est utile lorsqu'une commande peut avoir plusieurs identificateurs.

La méthode CreateActivityId prend une chaîne et un identificateur unique tel que l’identificateur de requête et retourne une chaîne les concaténant avec un trait de soulignement. Cette méthode, abondamment utilisée dans les classes dérivées, fournit un identificateur d'activité unique. Les méthodes BeginActivity, UpdateActivity et EndActivity appellent les méthodes BeginActiviy, UpdateActivity et EndActivityd’OrchestrationEventStream.

La solution dérive des classes de BasicActivity pour le répartiteur de commandes (CustomerOrderRequest), le gestionnaire de commandes (OrderManager) et les étapes de traitement (ServiceOrderRequest). Les classes individuelles correspondent à une activité. Chaque classe fournit une chaîne pour le nom d’activité à utiliser dans CreateActivityId pour créer l’identificateur d’activité ainsi que les méthodes spécialisées pour les jalons d’activité.

Comme le courtier de commandes remet la commande avant de recevoir une réponse , il inclut une méthode permettant de récupérer l'identificateur d'activité donné à l'identificateur de requête de la commande. Ceci permet au processus d'entreprise de continuer à suivre les derniers éléments du traitement de la commande.

Voir aussi

Développement d’une solution de gestion des processus métier