Проблемы с динамическим дизассемблером BizTalk - NULL

Я начал с решения здесь http://social.technet.microsoft.com/wiki/contents/articles/20547.biztalk-server-dynamic-schema-resolver-real-scenario.aspx которое идеально соответствует моему сценарию, за исключением отправки порт, но это не обязательно. Мне нужен порт приема, чтобы выбрать файл и применить схему для разборки. Из их оркестровки делает картирование, некоторые из них обычай и т. Д.

Я сделал все в этом уроке, но получаю следующую ошибку."Произошел сбой при выполнении конвейера приема... Часть тела имеет значение NULL"

Вещи, которые я не понимаю из учебника, но не верю, что они должны быть проблемой:

  1. Я создал новое решение и проект для создания компонента custompipeline (см. Рисунок 19) и, следовательно, файла dll. Это означает, что он находится в своем собственном пространстве имен. Однако, как видно из учебника, они создали проект в рамках основного решения biztalk (то есть, с конвейером и оркестровкой), и, таким образом, пространство имен имеет "TechNetWiki.SchemaResolver". в этом. Должен ли я сделать так, чтобы компонент custompipeline имел пространство имен моего основного решения? Я предполагаю, что это не должно иметь значения, потому что я должен иметь возможность использовать этот компонент в других решениях, так как он должен быть общим для бизнес-правил, связанных с приложением biztalk.

  2. Другая часть, которой у меня нет, это рисунок 15 под заголовком "THEN Action", в котором они соответствуют схеме назначения, к которой они хотели бы разобраться, но затем они помещают #Src1 в конце " http://technetwiki.schemaresolver.schemas.src1_ff/". Для чего нужен #Src1?

Источник

2 ответа

В примере, с которым вы связались, метод датчика компонента конвейера помещает первые 4 символа из имени файла в типизированное сообщение, которое затем передается в механизм правил. Это те 4 символа, которые соответствуют "SRC1" в примере.

string srcFileName = pInMsg.Context.Read("ReceivedFileName", "http://schemas.microsoft.com/BizTalk/2003/file-properties This link is external to TechNet Wiki. It will open in a new window. ").ToString();
srcFileName = Path.GetFileName(srcFileName);

//Substring the first four digits to take source code to use to call BRE API
string customerCode = srcFileName.Substring(0, 4);

//create an instance of the XML object
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.LoadXml(string.Format(@"<ns0:Root xmlns:ns0='http://TechNetWiki.SchemaResolver.Schemas.SchemaResolverBRE This link is external to TechNet Wiki. It will open in a new window. '>
    <SrcCode>{0}</SrcCode>
    <MessageType></MessageType>
    </ns0:Root>", customerCode));
//retreive source code in case in our cache dictionary
if (cachedSources.ContainsKey(customerCode))
{
   messageType = cachedSources[customerCode];
}
else
{
TypedXmlDocument typedXmlDocument = new TypedXmlDocument("TechNetWiki.SchemaResolver.Schemas.SchemaResolverBRE", xmlDoc);
Microsoft.RuleEngine.Policy policy = new Microsoft.RuleEngine.Policy("SchemaResolverPolicy");
                    policy.Execute(typedXmlDocument);

Таким образом, правило соответствия основано на первых 4 символах имени файла. Если одно не найдено, зонд возвращает ложное значение, то есть нераспознанное.

Последняя часть состоит в том, что тип сообщения помещается в возвращаемое сообщение - оно состоит из пространства имен и корневого узла схемы с разделителем #, поэтому ваш #src1 является корневым узлом.

Источник

  • Вам нужно реализовать IProbeMessage рядом с классом. Я забыл добавить IProbeMessage в код статьи. Это обновляется сейчас. но это есть в примере исходного кода

  • Src1 - это имя корневого узла схемы. Я упоминал, что в статье типом сообщения является TargetNamespace#Root

Я рекомендую скачать образец кода

Я надеюсь, что это поможет вам

Источник
Другие вопросы по тегам