anisite / mess-asynchrone.net Goto Github PK

Lors d'un démarrage ou d'un arrêt les services Windows inscrivent "Service 1" au lieu de leur véritable nom, aussi, dans la liste des services, ceux-ci n'ont pas de descriptions, contrairement aux autres... Ce dernier constat est simplement "esthétique", mais pourrais éventuellement être bien.

Selon des tests effectués, il semble que pour 10 messages en convoi, l'ordre de traitement n'est pas respectée (du plus vieux au plus récent) est-ce parce que je n'inscrit pas les bonnes dates ? Quels champs sont utilisés?

À tester

Impossible pour le moment de savoir si c'est du côté du service Windows ou de mon "démarrer" à voir demain.

MCTTT

• CAC120SV01
• CAC120AF01
• CAC120DO01
• CAC.Asynchrone.Client (nuget)

C'est pas un 'bug' en sois, mais faut juste que ce soit changé d'ici la version UNITAIRE

Il faudrait regarder le cas de la demande "{9926c567-27e7-4440-b26a-8a5026378125}" qui se remet en reprise à l'infini depuis le 29 avril, sans tomber en suspendu. à voir!

Appel à CAC120SV01 au lieu du direct

La chaine MSE15 ne démarre pas, elle reste en "PRISE_EN_CHARGE" et le bouton reprise fini en erreur. Il va falloir déboguer ça!

GDI119

Lorsque le service asynchrone lance le traitement via le service web et la méthode "Démarrer" (du serveur applicatif) il semble que celui-ci ne fournisse pas le booléen "Reprise" à "true" dans le fichier XML (DemandeAsynchrone) donc le traitement ne se met pas en reprise.

Il faut que je regarde dans le code, pourquoi ... (mauvaise gestion des niveaux de suivi??)

• MCT317EL01.Web (02.05)
• MCT317EL01.LotDNA (quelques changements notamment le retrait du message "DC900043")
• MCT.Asynchrone
• MCT.Asynchrone.Affaire
• MCT.Service.Asynchrone