У меня есть порт отправки BizTalk, вызывающий приложение логики Azure с использованием его URL-адреса триггера. URL-адрес содержит подпись общего доступа. Это генерируется Azure. Когда порт отправки активируется, он регистрирует ошибку, как показано ниже:
A message sent to adapter "HTTP" on send port "Send.Distribution.DHL.AS2.HTTP" with URI "https://prod-08.ukwest.logic.azure.com:443/workflows/44cc9abed61042fd90a7ea89522ead0d/triggers/manual/paths/invoke?api-version=2016-10-01&sp=The system cannot find the file specified.FtriggersThe system cannot find the file specified.FmanualThe system cannot find the file specified.Frun&sv=1.0&sig=c[signature redacted]&edi-partner=DHL" is suspended. Error details: The remote server returned an error: (502) Bad Gateway. MessageId: {F2450A9B-AD6E-47A3-8DD7-5AE57A2C63DD} InstanceID: {8A58DB8B-1B70-4E28-B7D4-C2A21899375D}
Bad Gateway - это справедливо, потому что посмотрите на URL: он несколько раз содержит строку The system cannot find the file specified.
там, где ее не должно быть. Здесь escape-последовательность% 2F находится в исходном URL-адресе. Похоже, что BizTalk каким-то образом пытается интерпретировать эту конкретную последовательность, ошибается и подставляет любое сообщение об ошибке, которое возвращается в URL-адрес, а затем пытается вызвать это, что по понятным причинам терпит неудачу. Я предполагаю, что он думает, что видит макрос и пытается его расширить.
Точно так же, как сообщение регистрируется в средстве просмотра событий (кроме отредактированной подписи); Я не ошибся при расшифровке.
Почему это делает BizTalk, и как я могу это остановить?
Единственный раз, когда я столкнулся с этой ошибкой, cdijkgraaf.wordpress.com/2016/07/29/… перезагрузка исправила ее.
Вы пробовали использовать скрипач в качестве прокси, чтобы узнать, что происходит с BizTalk, возможно, ошибка вводит в заблуждение. Также попробуйте использовать адаптер web-http