gifts2017

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

Опубликовал Роман Уничкин (unichkin) в раздел Управление - Техническое задание

В статье рассказывается о способе согласования состава 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 - да мало ли к какому. Просто важно понимать - в первую очередь разработчику - что необходимо иметь согласие с заказчиком в структуре данных: ведь программист только автоматизирует человеческий труд, а заменить его - невозможно. Программист пишет загрузку данных из ДБФ, или откуда угодно, чтобы кто-то не вбивал это руками - но принимающая сторона должна осознавать что "чего-то" из "ничего" не будет, и если в загружаемом файле каких-то данных нет - решение, что в этом случае делать - должно быть принято разработчиком и клиентом совместно. И согласование структуры данных обмена - это первый шаг к обоюдному пониманию ситуации. Ну, а если такого согласия нет - угадайте, кто будет виноват при сбое обмена?)

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

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Демонстрация описания структуры XML.docx
.docx 34,99Kb
12.06.15
16
.docx 34,99Kb 16 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Сергей (Che) Коцюра (CheBurator) 13.06.15 23:08
а разве
"Описание субтегов, и длина строки текста субтега.
Описание атрибутов каждого конкретного субтега, с указанием типа, квалификатора типа, и кратким комментарием
Описание иерархии субтегов внутри xml"
.
это по сути не есть xsd?
2. Роман Уничкин (unichkin) 13.06.15 23:32
(1) CheBurator, по-сути да. Но во-первых - не всегда (если XSD просто сформирован "по кнопке"- скорее всего все типы будут приведены к string, а квалификаторы - будут отсутствовать), во вторых.. Статья появилась в результате работы с людьми, у которых xml формируется из самописной системы (не 1С). Эти люди НЕ знали что такое XSD - я попытался объяснить, но нарвался на ТАКОЕ сопротивление, - со стороны программистов) - что бросил эту затею. Надо было упомянуть в статье, что она касается случаев, которые не решить (или очень трудно решить) с помощью XDTO. Объяснить людям, что при изменении структуры XML он - возможно - перестанет загружаться из-за различий в XSD схеме, которую нужно будет обновить для работы XDTO - ИМХО задача нереальная.
А в третьих: даже если есть XSD. Лично мне этот документ нужен еще и при разработке: я его распечатываю, приступаю к работе - и мне не нужно:
- смотреть переписки, что-то вспоминать - все под рукой;
- открывать доп. окна, чтобы посмотреть на xml - есть подробный (оформленный!) листинг;
- пытаться с забитой всякими делами головой держать в памяти структуру xml - она просто и нагляднейше описана и распечатана.
Качество и скорость разработки значительно увеличивается)
3. Антон Стеклов (asved.ru) 17.06.15 07:56
Никогда ничего не пытался объяснять. XSD прилагается к ТЗ и подписывается заказчиком. Если что-то меняется - ваш XML не соответствует схеме, утвержденной в составе ТЗ, что показывает любой валидатор. Доработать можем, но за отдельные деньги.
4. Антон Стеклов (asved.ru) 17.06.15 07:57
Обработка умеет работать (генерировать, импортировать) с XSD?
5. Андрей Овсянкин (Evil Beaver) 17.06.15 09:42
(3) asved.ru, а теперь суть задачи: заставить заказчика понять - что такое XSD и как ему его сделать, чтобы вам выдать и прикрепить к ТЗ.
6. Роман Уничкин (unichkin) 17.06.15 09:52
(3) asved.ru, это вам ОЧЕНЬ везло... с заказчиком.
(4) asved.ru, какая обработка??
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа