Описание форматов xml-файлов

Сразу хочу оговориться: я знаю, что такое XDTO и XSD. Но практика показывает, что сторона заказчика об этом НЕ знает в 95% случаев. Как правило – дают некий xml-файл (один или несколько) и говорят: нам нужно по этим данным синхронизировать  такие-то Документы / Справочники / Записи РС и т. п. – и при такой постановке можно считать, что повезло – заказчик себе представляет, что будет на выходе. Такой вариант, к сожалению, тоже редкость. Чаще – постановка звучит примерно так: вот у нас есть файл, нам нужно делать приход. Что за документы нужно создать? Каким образом будет производится синхронизация? Эти, требующие решения вопросы – отдельная тема для обсуждения, здесь ее затрагивать не хочу – просто обозначу, что в большинстве случаев заказчик себе НЕ представляет  что ему нужно видеть в итоге. Цель этой статьи – копнуть немножко глубже: представим себе, что вопрос «Что же будет в итоге?» решен, и остается лишь написать код для загрузки XML. Обратим внимание на программиста.

Программисту дают xml, и говорят: сделай так, чтобы регламентно выполнялась загрузка из некоего источника (ftpкаталогапочты – не суть) – и создавались документы. Например, ПТИУ. Если программист неопытный, он говорит – да конечно, раз плюнуть. Через неделю будет готово.

Через две недели тот же программист оправдывается и рассказывает что в исходном xml не хватало данных (например, вместо наименования номенклатуры присутствует некий внутренний код ), или возникли коллизии строк (строка длиной в 100 прилетает в строковый реквизит длиной 50), или он все написал, – но – внезапно – заказчик стал пытаться загружать xml с другим составом атрибутов. В общем произошла ситуация, требующая неких решений, в том числе — со стороны заказчика, а заказчик «думает».  И «думает» он во время уже согласованной, практически реализованной — но неоплаченной задачи. Как показывает практика, «думать» он может долго, за ним приходится бегать, шевелить, спрашивать – «когда же решение будет принято?» , а он отвечает, мол, «не могу пока ничего сказать, у нас текучка большая, времени ни на что нет» и т.д. и т.п.

Инструмент для решения проблем такого характера я и предлагаю в этой статье. Дело в том, что когда приходит некий опыт разработки – нормальный программист никогда не скажет «легко, через неделю сделаю» просто глянув «по диагонали» на задачу. Понимание того, КАК будет решена задача, и за какой срок, приходит во время вдумчивого анализа присланного xml, на который может уйти от пары часов до пары дней. И, как минимум, прежде чем подписаться – сказать: да, я сделаю за 20 часов – необходимо структуру xml согласовать. Нужен документ,  в котором будут присутствовать описание следующих элементов xml:

• Описание субтегов, и  длина строки текста субтега.
• Описание атрибутов каждого конкретного субтега, с указанием типа, квалификатора типа, и кратким комментарием
• Описание иерархии субтегов внутри xml

Этот документ необходимо отдать на утверждение клиенту, и только ПОСЛЕ того, как клиент утвердит – приступать к следующему этапу: непосредственно кодингу, если задача небольшая, или написанию тех. задания, если нужно что-то большее, чем банальная регламентная загрузка одного файла.

И, разумеется, на создание подобного документа также должно выделяться время, которое оплачивает заказчик. Да, это увеличивает стоимость проекта. Но это также делает его прозрачным:  я могу отвечать только за то, что я вижу, что мне понятно. А не за сферического коня в вакууме, чего зачастую требуют клиенты, недовольные, что им нужно платить еще и за какое-то там описание. Вообще, ИМХО – задача убедить клиента в необходимости такого подхода, — это задача руководителя, или менеджера проекта. Я же лишь могу сказать, что это:

• дает четкое, прозрачное понимание задачи
• гарантирует, что на время разработки структура  xml  неизменна
• дает возможность еще на этапе проектирования разрешить коллизии типов, и принять решение, как это обойти

И  еще. ЭТО ЭКОНОМИТ ДЕНЬГИ КЛИЕНТА. Потому что дороже, чем решать ошибку, ее можно – и нужно – избежать. Просто надо вовремя принять решение, и все, и не надо бегать и объяснять, например – почему в пик загрузки в документах нет номенклатуры в табличной части из-за того, что длина входящего идентификатора, по которому идет синхронизация, оказалась больше длины строкового реквизита, идентифицирующего приемник. Это должно быть решено заранее.

В приложенном к статье файле находится демонстрационное описание xml следующего содержания (взял с потолка):

<Postuplenie Postavshik = «Твой ДОМ, ООО» SummaDok = «10000» IDDOC = «234823423749827» VAL = «РУБ»>

    вход. док. №155 от 01.04.14

    <Line CodeNom = «45345» Count = «2» Price = «2000» Discount = «0» Summa = «4000»>

        <DATANOM sh = «49384759834758347» EdIzm = «шт»/>

    </Line>

    <Line CodeNom = «9575677» Count = «5» Price = «1200» Discount = «0» Summa = «6000»>

        <DATANOM sh = «34534535434534534» EdIzm = «кг»/>

    </Line>

</Postuplenie>

p.s.

Хочу отметить, что не позиционирую данный метод как готовую таблетку от всех бед. Но это неплохой шаблон, и если есть какие-то неучтенные моменты — его вполне можно модернизировать под свою ситуацию. 
Также добавлю, что хоть все рассказано в контексте обменов с участием xml — все те же ситуации можно отнести к любому другому формату: dbf, xls, csv — да мало ли к какому. Просто важно понимать — в первую очередь разработчику — что необходимо иметь согласие с заказчиком в структуре данных: ведь программист только автоматизирует человеческий труд, а заменить его — невозможно. Программист пишет загрузку данных из ДБФ, или откуда угодно, чтобы кто-то не вбивал это руками — но принимающая сторона должна осознавать что «чего-то» из «ничего» не будет, и если в загружаемом файле каких-то данных нет — решение, что в этом случае делать — должно быть принято разработчиком и клиентом совместно. И согласование структуры данных обмена — это первый шаг к обоюдному пониманию ситуации. Ну, а если такого согласия нет — угадайте, кто будет виноват при сбое обмена?)

Спасибо за внимание, желаю вам приятной работы.