Ошибка функционального скриптинга Biztalk

Question

В сопоставлении BizTalk я использую скриптовый функционал из внешней сборки. Ссылка на сборку добавляется. Когда отображение используется, однако, вызывает следующее сообщение об ошибке:

'ScriptNS0:DoSomething()' has failed.

Теперь, это может означать любое количество вещей, что это неправильно об этом скриптовый functoid. Однако даже когда блок try-catch размещается вокруг всего кода C#, а catch выдает настраиваемое исключение, правильное новое развертывание дает ту же ошибку, а не добавленную пользовательскую.

Это предполагает, что отображение было начато и что что-то вызывает ошибку, как только она попадает в скриптовый функционал, но фактически не выполняет даже малейшего действия внутри функции. При взгляде на XSLT карты это выглядело прекрасно. Ссылка на внешнюю сборку проверялась снова и снова (и ссылки на эту внешнюю сборку также). Все выглядит прекрасно и очень похоже на многие другие сопоставления, которые я видел, но все же результатом является ошибка выше.

Я понимаю, что это довольно неопределенный вопрос, но кто-нибудь знает, что здесь происходит?

Answer 1

Вам придется протестировать это в Visual Studio. Несколько вещей, о которых следует помнить:

1. Очень возможно, что ваши фактические данные вызывают исключение (это краевой или угловой корпус, который вы не тестируете в консольном приложении).
2. Отбрасывание исключений во внешних сборках не всегда хорошо переносится на карту XSLT, особенно когда вы делаете это в порту. IIRC обрабатывается чуть более изящно в оркестровке.
3. Если вы не можете воспроизвести это при тестировании Visual Studio или модульном тесте, вы должны будете подключить отладчик Visual Studio к соответствующему BtsNtSvc.exe или BtsNtSvc64.exe (или w3wp.exe, если он запущен в IIS/изолированном хосте). Установите точку останова на входе в пользовательскую функцию, перейдите, посмотрите, что происходит. Если вы можете воспроизвести его только в среде, отличной от dev, см., Можно ли настроить удаленное отладочное решение, но в этом случае вам может быть лучше улучшить ведение журнала в functoid и, если возможно, перераспределить.

В общем, я всегда стараюсь сделать следующее в пользовательских сценариях functoid:

• Избегайте бросать исключения - использовать методы как TryParse, а не Parse, а в случае неудачи разбора вернуть строку ошибки или пустую строку или исходную строку (в зависимости от требований/допуска системы назначения), а не исключение. Если вы делаете исключение, маловероятно, чтобы его обрабатывали изящно и маловероятно, чтобы тип исключения или текст вернули его пользователю/администратору.
• Вместо этого регистрируется ошибка в этих сценариях - обычно используется журнал событий Windows (System.Diagnostics.EventLog.WriteEntry). Обязательно используйте правильно зарегистрированный источник событий, в идеале тот, который соответствует имени вашего приложения и зарегистрирован в процессе установки, но по крайней мере один, который существует на компьютере, чтобы избежать выброса другого бессмысленного исключения! Это позволит разработчикам/администраторам быстрее понять, что происходит в следующий раз.