L'émission d'événement synchrone n'étant pas prise en charge par les points de capture du système, l'émission d'événement système ne peut donc pas être garantie.
Les événements synchrones peuvent être de type transactionnel ou non transactionnel, mais la récupérabilité du transport doit être correctement configurée dans chaque cas.
Tous les adaptateurs de traitement d'événement ne prennent pas en charge l'émission synchrone avec toutes les combinaisons de TRANSMODE. Pour plus d'informations, reportez-vous à la rubrique Adaptateurs de traitement d'événement.
Lorsque l'émission d'un événement échoue, l'adaptateur de traitement d'événement fournit des informations sur l'événement et sur la raison de l'échec, incrémente les statistiques correspondantes, et annule l'unité de travail de la transaction de capture.
Comprendre le fonctionnement de l'émission d'événement synchrone permet de savoir comment faire le meilleur usage de cette fonctionnalité. Les éléments à prendre en compte lors de l'utilisation de l'émission d'événement synchrone incluent la sécurité, les performances, le transport et les effets sur les applications.
La transaction de capture d'événement doit disposer des droits d'écriture sur le transport de l'événement (par exemple, la file d'attente WebSphere MQ pour l'adaptateur de traitement d'événement WebSphere MQ) pour les émissions synchrones ; le répartiteur de traitement d'événement ou la tâche d'adaptateur émettant les événements doit disposer des droits d'écriture pour les émissions asynchrones.
L'émission d'événement synchrone transactionnel est récupérable. Lorsque vous utilisez l'adaptateur de traitement d'événement CICS WebSphere MQ, les événements sont mis dans la file d'attente d'événement WebSphere MQ sous le point de synchronisation ; vous devrez donc peut-être revoir l'allocation d'espace réservée au fichier journal WebSphere MQ. Lorsque vous utilisez l'adaptateur de traitement d'événement de file d'attente TS CICS, l'utilisation de la file d'attente augmente ; vous devrez donc peut-être revoir la taille du flux de consignation et des attributs du journal CICS. L'utilisation d'événement transactionnels synchrones avec une tâche s'exécutant pendant un certain temps sans point de synchronisation peut entraîner la saturation du journal.
Lorsque vous utilisez l'émission synchrone, un adaptateur de traitement d'événement personnalisé doit respecter l'indicateur EPAP_RECOVER du conteneur DFHEP.ADAPTPARM. Pour plus d'informations, reportez-vous à la rubrique Custom EP adapter (Adaptateur EP personnalisé).
Le fait d'assurer l'émission des événements permet de créer des applications basées sur des événements métier critiques, et d'étendre les applications existantes d'une manière fiable. En contre-partie, le traitement synchrone indispensable pour assurer que les événements sont émis peut avoir un impact sur le temps de réponse des applications. Une utilisation judicieuse de l'émission synchrone d'événement réduit l'impact sur les applications. Pour plus d'informations sur les performances liées à l'émission assurée d'événement, reportez-vous à la rubrique Performances du traitement des événements.
Une seule unité de travail peut émettre de nombreux événements, certains transactionnels, et d'autres non. Si l'émission d'un événement synchrone par une transaction de capture échoue, l'unité de travail est annulée, avec tous les événements transactionnels qu'elle capture. Les événements non transactionnels peuvent toujours être émis.
L'adaptateur de traitement d'événement, ses ressources (par exemple, une file d'attente WebSphere MQ) et le consommateur d'événement doivent être configurés avec une capacité suffisante pour traiter le volume maximal attendu d'événements à émettre afin d'éviter l'échec de la transaction de capture.
Pour vous permettre de décider quand utiliser l'émission synchrone, voici quelques remarques relatives à l'émission asynchrone et à l'émission synchrone à prendre en compte.