Блог

Главная - Вопросы по программированию - BizTalk: не удалось найти спецификацию документа

BizTalk: не удалось найти спецификацию документа

#biztalk

#biztalk

Вопрос:

Добрый день всем,

У меня проблема с оркестровкой BizTalk, которая действительно странная.

Первая форма приема моей оркестровки завершается ошибкой со следующим сообщением:

 There was a failure executing the receive pipeline:
 "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines
Source: "XML disassembler"
Receive Port: "ReceiveCanonicalPort"
Reason: Finding the document specification by message type
"http://www.openapplications.org/oagis/9#ProcessInvoice" failed.
 Verify the schema deployed properly.

Я собрал тестовый документ с первыми несколькими строками, подобными этому:

 <?xml version="1.0" encoding="utf-8"?>
<ProcessInvoice
  xmlns="http://www.openapplications.org/oagis/9"
  releaseID="9.0"
  targetNamespace="http://www.openapplications.org/oagis/9"
  >

Что я уже проверил:

Я проверил схему: целевое пространство имен ‘http://www.openapplications.org/oagis/9 ‘ Корневым узлом является ‘ProcessInvoice’.

Схема проверяется.

Мой входной файл проверяется на соответствие схеме.

Я проверил, что схема развернута.

Я посмотрел, существует ли другая схема с повторяющимся пространством имен и корневым узлом.

Я перезапустил экземпляры хоста и несколько раз перераспределял их.

Я попытался установить для свойства xml-дизассемблера ‘разрешить нераспознанное сообщение’ значение true. Это приводит к тому, что вместо объекта не устанавливается исключение экземпляра. Что, по-видимому, указывает на то, что он не десериализует его.

Я молился великому богу Буги.

Есть еще идеи?

Спасибо

Ответ №1:

У вас должна быть другая версия этой схемы, определенная где-то в другой сборке.

Вы уверены, что проверили все возможные приложения (включая приложение BizTalk 1)?

Единственное, о чем я могу подумать, это, возможно, у вас есть перенаправление сборки в файле конфигурации, которое перенаправляет на версию, которая не существует, однако я не уверен, что вы даже получили бы свое наблюдаемое поведение, если бы это было так.

Другое дело — возможно, более старая версия схемы является GAC’d, и экземпляр хоста все еще владеет ею. Попробуйте перезагрузиться, чтобы убедиться.

Надеюсь, это поможет.

Комментарии:

1. Спасибо, я проверю это еще раз. Чтобы проверить наличие дубликата, я просмотрел раздел «<Все артефакты>» и отсортировал схемы по пространству имен.

2. Все артефакты должны были это сделать. У меня нет идей. Это очень странно. Как насчет того, может быть, более старая версия все еще загружена, и экземпляр хоста все еще висит на нем?

3. Я полагаю, что нашел это. В нем есть другая сборка с другой схемой, но с тем же пространством имен. Это приводит к двум разным схемам в двух сборках с одинаковыми именами. Схема, которую я не использую для этого проекта, имеет более поздний номер версии. Итак, я думаю, что другая схема скрывает эту из-за столкновения имен и номера версии.

4. Я также столкнулся с такой же проблемой, и это была проблема со сборкой. Я совершил глупую ошибку, не перезапустив экземпляры хоста, и я полагаю, что это относилось к более старой схеме в кэше (возможно, я здесь не прав). После перезапуска экземпляров хоста проблема была решена.