Échec du functoid de script Biztalk

Question

Dans un mappage BizTalk, j'utilise un functoid de script à partir d'un assembly externe. La référence d'assemblage est ajoutée. Lorsque le mappage est utilisé, cependant, il provoque l'erreur suivante:

'ScriptNS0:DoSomething()' has failed.

Maintenant, cela pourrait signifier un certain nombre de choses qui ne va pas sur ce fonctoid de script. Cependant, même lorsqu'un bloc try-catch est placé autour de l'intégralité du code C# et que le catch lance une exception personnalisée, un nouveau déploiement correct génère la même erreur et non la nouvelle version personnalisée. Cela suggérerait que le mappage a été démarré et que quelque chose provoque une erreur dès qu'il touche le fonctoid de script, mais sans effectuer réellement la moindre action au sein de la fonction. En regardant le XSLT de la carte, cela semblait parfaitement bien. La référence à l'assemblage externe a été vérifiée à maintes reprises (ainsi que les références de cet assemblage externe). Tout a l'air bien et ressemble beaucoup à d'autres cartographies que j'ai vues, mais le résultat est toujours l'erreur ci-dessus. Je sais que c'est une question plutôt vague, mais est-ce que quelqu'un a une idée de ce qui se passe ici?

Answer 1

Vous devrez tester cela dans Visual Studio. Quelques points à garder à l'esprit:

1. Il est très possible que vos données réelles provoquent une exception (c'est un cas de bord ou d'angle que vous ne testez pas dans votre application de console).
2. Le lancement d'exceptions dans des assemblages externes ne se traduit pas toujours correctement dans une carte XSLT, en particulier lorsque vous le faites sur un port. IIRC il est manipulé légèrement plus gracieusement dans une orchestration.
3. Si vous ne pouvez pas reproduire cela dans un test Visual Studio ou un test unitaire, vous devez pouvoir attacher le débogueur Visual Studio au BtsNtSvc.exe ou BtsNtSvc64.exe (ou w3wp.exe s'il est exécuté dans IIS/hôte isolé). Définir un point d'arrêt à l'entrée de votre fonction personnalisée, passer à travers, voir ce qui se passe. Si vous êtes seulement capable de le reproduire dans un environnement non-dev, voyez si vous pouvez configurer le débogage à distance - mais vous feriez mieux d'améliorer la journalisation sur le fonctoid dans ce cas et de le redéployer si possible.

En général, j'essaie toujours de faire ce qui suit dans les scripts Functoid personnalisés:

• éviter de jeter des exceptions - les méthodes d'utilisation comme TryParse plutôt que Parse, et en cas d'échec pour analyser renvoyer une chaîne d'erreur ou un chaîne vide ou la chaîne d'origine (en fonction des exigences/tolérance du système de destination) plutôt que d'émettre une exception. Si vous lancez une exception, il est peu probable qu'elle soit gérée correctement et il est peu probable que le type ou le texte de l'exception revienne à un utilisateur/administrateur.
• Conservez plutôt la journalisation des erreurs dans ces scénarios, en utilisant généralement le journal des événements Windows (System.Diagnostics.EventLog.WriteEntry). Assurez-vous d'utiliser une source d'événements correctement enregistrée, idéalement une qui correspond au nom de votre application et qui est enregistrée par votre processus d'installation, mais au moins une qui existe sur l'ordinateur pour éviter de lancer une autre exception absurde! Cela permettra aux développeurs/administrateurs de mieux comprendre ce qui se passe la prochaine fois.