Проблема анализа сложности неструктурированного файла BizTalk

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

Чтобы легко объяснить проблему, я воспроизвел ее в гораздо меньшей схеме (фактически не связанной с Tradacoms).

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://Bidvest.Integration.Supplier.Schemas.TestSchema" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://Bidvest.Integration.Supplier.Schemas.TestSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:annotation>
    <xs:appinfo>
      <b:schemaInfo standard="Flat File" root_reference="Root" default_pad_char=" " pad_char_type="char" count_positions_by_byte="false" parser_optimization="complexity" lookahead_depth="0" suppress_empty_nodes="false" generate_empty_nodes="true" allow_early_termination="false" early_terminate_optional_fields="false" allow_message_breakup_of_infix_root="false" compile_parse_tables="false" />
      <schemaEditorExtension:schemaInfo namespaceAlias="b" extensionClass="Microsoft.BizTalk.FlatFileExtension.FlatFileExtension" standardName="Flat File" xmlns:schemaEditorExtension="http://schemas.microsoft.com/BizTalk/2003/SchemaEditorExtensions" />
    </xs:appinfo>
  </xs:annotation>
  <xs:element name="Root">
    <xs:annotation>
      <xs:appinfo>
        <b:recordInfo structure="delimited" preserve_delimiter_for_empty_data="true" suppress_trailing_delimiters="false" sequence_number="1" child_order="infix" child_delimiter_type="char" child_delimiter="+" />
      </xs:appinfo>
    </xs:annotation>
    <xs:complexType>
      <xs:sequence>
        <xs:annotation>
          <xs:appinfo>
            <b:groupInfo sequence_number="0" />
          </xs:appinfo>
        </xs:annotation>
        <xs:element name="Name" type="xs:string">
          <xs:annotation>
            <xs:appinfo>
              <b:fieldInfo justification="left" sequence_number="1" />
            </xs:appinfo>
          </xs:annotation>
        </xs:element>
        <xs:element minOccurs="0" name="Address">
          <xs:annotation>
            <xs:appinfo>
              <b:recordInfo sequence_number="2" structure="delimited" preserve_delimiter_for_empty_data="false" suppress_trailing_delimiters="false" child_order="infix" child_delimiter_type="char" child_delimiter=":" />
            </xs:appinfo>
          </xs:annotation>
          <xs:complexType>
            <xs:sequence>
              <xs:annotation>
                <xs:appinfo>
                  <b:groupInfo sequence_number="0" />
                </xs:appinfo>
              </xs:annotation>
              <xs:element minOccurs="0" name="Line1" type="xs:string">
                <xs:annotation>
                  <xs:appinfo>
                    <b:fieldInfo justification="left" sequence_number="1" />
                  </xs:appinfo>
                </xs:annotation>
              </xs:element>
              <xs:element minOccurs="0" name="Line2" type="xs:string">
                <xs:annotation>
                  <xs:appinfo>
                    <b:fieldInfo justification="left" sequence_number="2" />
                  </xs:appinfo>
                </xs:annotation>
              </xs:element>
              <xs:element minOccurs="0" name="Line3" type="xs:string">
                <xs:annotation>
                  <xs:appinfo>
                    <b:fieldInfo justification="left" sequence_number="3" />
                  </xs:appinfo>
                </xs:annotation>
              </xs:element>
              <xs:element minOccurs="0" name="Line4" type="xs:string">
                <xs:annotation>
                  <xs:appinfo>
                    <b:fieldInfo justification="left" sequence_number="4" />
                  </xs:appinfo>
                </xs:annotation>
              </xs:element>
              <xs:element minOccurs="0" name="Line5" type="xs:string">
                <xs:annotation>
                  <xs:appinfo>
                    <b:fieldInfo justification="left" sequence_number="5" />
                  </xs:appinfo>
                </xs:annotation>
              </xs:element>
              <xs:element minOccurs="0" name="PostCode" type="xs:string">
                <xs:annotation>
                  <xs:appinfo>
                    <b:fieldInfo justification="left" sequence_number="6" />
                  </xs:appinfo>
                </xs:annotation>
              </xs:element>
              <xs:element minOccurs="0" name="Country" type="xs:string">
                <xs:annotation>
                  <xs:appinfo>
                    <b:fieldInfo sequence_number="7" justification="left" />
                  </xs:appinfo>
                </xs:annotation>
              </xs:element>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Схема содержит элемент имени и запись адреса, которая сама имеет ряд дополнительных элементов.

Если я проверю экземпляр (щелкнув правой кнопкой мыши схему и т. Д.) С помощью тестового файла ниже

DAve+Line1:Line2:Line3:Line4:Line5:PostCode:Country

то я получаю результат ниже, как и ожидалось

<Root xmlns="http://Bidvest.Integration.Supplier.Schemas.TestSchema">
  <Name xmlns="">DAve</Name>
  <Address xmlns="">
    <Line1>Line1</Line1>
    <Line2>Line2</Line2>
    <Line3>Line3</Line3>
    <Line4>Line4</Line4>
    <Line5>Line5</Line5>
    <PostCode>PostCode</PostCode>
    <Country>Country</Country>
  </Address>
</Root>

Если я проверю экземпляр очень простым сообщением, как показано ниже

DAve+Line1

тогда я получаю следующий результат

<Root xmlns="http://Bidvest.Integration.Supplier.Schemas.TestSchema">
  <Name xmlns="">DAve</Name>
  <Address xmlns="">
    <Line4>Line1</Line4>
  </Address>
</Root>

Вы можете видеть, что Line1 был помещен в элемент Line4. Поскольку в приведенном выше примере сообщения в качестве первого значения перед разделителем указан текст «Line1», я ожидал, что приведенный выше XML будет Line1.

Здесь происходит что-то очень странное. Кто-нибудь может помочь? У меня эта проблема в BizTalk 2013 (CU3) и BizTalk 2013 R2.


biztalk biztalk-2013 biztalk-2013r2 biztalk-pipelines
person David Robinson    schedule 08.12.2015    source источник
comment
Действительно ли Line1 необязателен? например DAve + действительная запись? Если нет, удалите minOccurs 0 на нем, и он будет вести себя.   -  person Dijkgraaf    schedule 08.12.2015

Ответы (2)


arrow_upward
1
arrow_downward

Да, дизассемблер Flat File может очень запутаться, если у вас нет обязательных полей в начале записи. Вы сделали все элементы Address необязательными, и тогда результат может быть очень странным. Я обнаружил, что у вас всегда должно быть хотя бы одно обязательное поле в качестве первого поля, и у вас никогда не должно быть обязательного поля после необязательного.

Если вы удалите minOccurs = 0 на line1, он работает правильно, и вы получите следующее.

<Root xmlns="http://Bidvest.Integration.Supplier.Schemas.TestSchema">
    <Name xmlns="">DAve</Name>
    <Address xmlns="">
        <Line1>Line1</Line1>
    </Address>
</Root>

Он даже будет обрабатывать следующий ввод

DAve+

который получает следующий вывод

<Root xmlns="http://Bidvest.Integration.Supplier.Schemas.TestSchema">
    <Name xmlns="">DAve</Name>
    <Address xmlns="">
        <Line1/>
    </Address>
</Root>

Or

DAve

вывод

<Root xmlns="http://Bidvest.Integration.Supplier.Schemas.TestSchema">
    <Name xmlns="">DAve</Name>
</Root>
person Dijkgraaf    schedule 08.12.2015
comment
Спасибо, Дейкграаф, оценил. После того, как я разместил вопрос, я заметил точно такое же поведение, как вы предложили (честно говоря, заметил!), И я собирался прокомментировать сейчас. Но вы правы, изменение его на обязательное, безусловно, решает проблему. Причина, по которой это было обязательным, заключалась в том, что схема, для которой я ее реализую, представляет собой стандарт 20-летней давности, который я реализовывал из еще более старого руководства. В нем говорилось, что все необязательно, поэтому я просто следил за этим. С точки зрения того, что теперь это является обязательным, я добавлю некоторую логику в свою карту, чтобы учесть, что она может быть пустой. - person David Robinson; 09.12.2015
comment
Было бы интересно понять, почему он поместил его именно там, где он был необязательным ............... Почему не Line4 или Line2? Думаю, мы никогда не узнаем. - person David Robinson; 09.12.2015
comment
Аналогичная проблема была поднята здесь stackoverflow.com/questions/21990744/ - person Dijkgraaf; 09.12.2015

arrow_upward
0
arrow_downward

Возврат оптимизации парсера к скорости по умолчанию должен решить вашу проблему.

person Zee    schedule 08.12.2015
comment
Как он заявляет в своем вопросе, однако, поскольку в схеме много дополнительных элементов, мне нужно изменить оптимизацию парсера на сложность. Это может быть не вариант для него - person Dijkgraaf; 08.12.2015
comment
Ну, в этом случае. Возможно, ему стоит подумать о написании специального конвейера для обработки этого файла. Вместо того, чтобы наклеить этот дизассемблер плоского напильника. - person Zee; 08.12.2015
comment
Другой подход может заключаться в том, чтобы оставить все как есть, а затем использовать карту для настройки полей в правильное положение. Но этот подход предполагает, что эти поля имеют одинаковый или почти одинаковый тип данных. - person Zee; 08.12.2015