Содержание:
1. Исторический обзор обмена информации между базами 1С
2. Web-сервисы для обмена с SAP
Кому предназначена эта статья? Наверное, начинающим программистам веб-сервисов 1С. Хотя она и не даст ответы на все возникающие вопросы, в интернете легко найти информацию по более узким вопросам а-ля что такое пакет XDTO или SOAP UI. Сверхзадача этой статьи – морально подготовить читателя к тому, что не всё может зависеть от знаний, что не стоит расстраиваться из-за всяких глюков, а к ошибкам других людей нужно относиться с пониманием.
1. Исторический обзор обмена информации между базами 1С
Проблема обмена информации между базами 1С появилась одновременно с 1С и как только она не решалась! Самым распространенным в какое-то время стал (да так и остался) обмен xml-файлами. Плюсы этого подхода (гибкость и универсальность), общеизвестны, а о недостатках, как обычно, мало кто говорит.
Году так в 2010 у меня был проект по обмену с сайтом на битриксе, где файл обмена приближался по размеру к 2 ГБ. При его разборе успешно падал Microsoft парсер. В результате доработанный за два месяца обмен не прошел испытание объемом, а заказчик оставил меня без денег. Прошло уже 10 лет, но до сих пор 2ГБ остаются критичным размером для файлов обмена.
Можно ли сделать обмен по-другому? Да, и не слишком большими затратами! Зачастую бэкап всей базы средствами SQL занимает минуты, а по объему – те же гигабайты. Выгрузка данных в xml файл занимает часы, потому что каждую порцию данных надо завернуть в теги xml, которые и добавляют объема файлу выгрузки.
Поскольку способов обмена всегда было много, неизбежно должна была появиться идея обмена посредством протокола http, через web-сервисы. Предыдущие технологии обмена между базами 1С уже оставляли довольно большое наследство и при обмене web-сервисами ими просто грех было не воспользоваться.
2. Web-сервисы для обмена с SAP
В основе данного способа обмена лежит всё тот же обмен xml-файлами, но через http-протокол. Каждый xml файл древовидно описывает какой-то простой объект базы данных, обычно ему соответствует пакет XDTO. Как и следовало ожидать, многие объекты в 1С и SAP во многом похожи – и там и там есть товары, у которых есть единицы измерения, a поскольку xml позволяет довольно удобно описать любую структуру, то даже несовпадение внутреннего устройства объектов не создает особых неудобств. К тому же можно обмениваться данными по каждой номенклатуре и не сливать всё в один мегафайл.
Следующим уровнем является описание нескольких близких по смыслу объектов в одном месте – WSDL файле. WSDL файл описывает уже весь web-сервис.
Например, обмен по номенклатуре был реализован через web-сервис:
Он может принимать xml-файлы 4 видов:
Здесь:
· MATMAS06 – номенклатура;
· CLSMAS03 – вид номенклатуры;
· CLFMAS02 – дополнительные реквизиты номенклатуры;
· CHRMAS03 – значения дополнительных реквизитов номенклатуры; типы и структура этих объектов описаны в одноименных XDTO -пакетах
Почему на скриншоте к пакетам по номенклатуре добавился пакет AEAUD01? В этом пакете описывается ответ 1С для SAP после приема пакетов по номенклатуре. Он относится к другому web-сервису, но в списке пакетов XDTO все стоят рядом.
3. Публикация веб-сервиса
Итак, вы сделали свой web-сервис c модулем и пакетами XDTO, а теперь нужно, чтобы он заработал. Закавыка в том, что у 1С пока нет своего сервера. Поэтому приходится запускать web-сервисы 1С на самых распространенных web-серверах – IIS и Apache. Обычно этот процесс сопровождается некоторыми проблемами. Дружелюбный Апач можно взгромоздить куда угодно, хоть на свою домашнюю машину, но даже он может потребовать установки подходящей версии, потому что последняя именно с сервисами 1С может работать некорректно. Веб-сервер IIS обычно работает в связке со множеством других в разных компаниях: вы заходите на терминальный сервер, подключаетесь к серверу 1С, к хранилищу на другом сервере и обнаруживаете, что для веб сервера IIS есть еще один сервер. И конечно, на каждый сервер не так просто попасть, почти везде нужны административные права.
Попробуем опубликовать его:
Первая проблема при публикации веб-сервиса – требование административных прав. Даже если Вы всемогущий Администратор в 1С, системе Windows об этом не известно.
Тут может быть всего два варианта решения проблемы: получить права от заказчика, что бывает непросто, или же по несколько раз на дню публиковать Ваши сервисы администратору – а это трудно назвать решением проблемы даже с натяжкой.
Ну, допустим, Вы запустили 1С под правами администратор Windows. Дальше будьте готовы к новым испытаниям:
В целом понятно, чего хочет 1С, однако эти модули расширения, наверное, надо устанавливать на машину, где работает IIS. В нашем проекте на сервере c IIS пришлось устанавливать и 1С, и модули расширения веб-сервера 1С, чтобы просто опубликовать их для IIS. Для работы с 1С эта машина была слабой, а для веб-сервера – вполне нормальной.
Вам знакомо выражение «в конце концов, среди концов, найдешь конец ты наконец»? Вот-вот. Скриншот публикации нарисован для сервера Apache. Но зачем нам Apache, если мы работаем на IIS?
Скорее всего, пока вы получите доступ к череде серверов для публикации ваших веб-сервисов на IIS, вы успеете:
· скачать и установить на своей локальной машине Апач, запустить его и обрадоваться, что оно работает;
· опубликовать веб-сервис и убедиться, что он не работает;
· найти нужную версию апача, переустановить его и переопубликовать свой веб-сервис.
При первом запуске окна Публикация на web-сервере обычно включены все галки, нужно оставить то, что действительно необходимо.
4. Отладка веб-сервиса 1С 8.3
Программист 1С считается состоявшимся, если умеет копировать в буфер и извлекать из него, а также пользоваться отладчиком. При работе с web-сервисами ситуация отладки довольно пикантна – может отлаживаться программа, не имеющая отношения к 1С. Будьте уверены, что 1С будет мстить вам за такой подход и не будет отлаживаться до последнего. Настройками отладки довольно просто пользоваться – достаточно задать правильные параметры на закладке Прочие при публикации веб-сервисов:
Потом в Конфигураторе настроить подключение к отладке:
Можно попробовать настроить отборы предметов отладки:
А также параметры отладки:
Но даже это может оказаться бесполезным. В моем случае при отладке ничего не работало из-за того, что IIS использовал нестандартный порт. Так что даже с правильными настройками отладка может не запуститься. На ситуацию эту стоит смотреть с философской точки зрения – в конце концов все настройки станут понятными. Любая проблема решаема, даже если на первый взгляд это не так.
5. Что такое SOAP
Итак, мы закодировали и опубликовали веб-сервис, разобрались с настройками отладки и хотим показать заказчику, что всё работает. Прямо сразу показывать не советую, так как есть риск, что код не заработает корректно с первого раза, особенно когда его много.
Если бы наш запрос к веб-серверу был простым, через методы POST или GET, то данные такого запроса веб-сервису передал бы сам браузер. Для передачи пакетов XDTO нужна особая программа. К счастью, проблем с ней практически не возникает.
Эта программа называется SOAP UI и в алгоритме ее работы есть немало здравых идей.
Самая гениальная идея – всё описание веб-сервиса есть в wsdl-файле. Кстати, нам его дал заказчик вместе с тестовыми данными, что значительно ускорило весь процесс.
В SOAP UI мы можем сделать новый SOAP проект.
Загрузим в него wsdl-файл.
В проекте сразу будут шаблоны запроса к нашему веб-сервису.
Мы можем заполнить эти шаблоны вручную, а если повезет, то и содержимым тестовых файлов от заказчика. На скриншоте красным выделено место, с которого до закрывающего тега в конце просто вставляется содержимое тестового файла заказчика. Наградой за старания будет маленькая желтая стрелка слева в красном кружочке в конфигураторе 1С после отправки запроса из SOAP UI. Через непродолжительное время он даже посчитает, что запрос не удался, таймаут превышен, и никогда не узнает, что у вас просто заработала отладка!
Следует обратить внимание еще на два момента:
1. Нужно будет указать правильный url обращения к веб-сервису. Мой первый url был правильный с точностью до нестандартного порта IIS. Из-за этого в ответе была ошибка 500 – внутренняя ошибка веб-сервиса. Но именно из-за неё я был уверен, что дело не в моём коде, а в сервере IIS, так что обратился к администратору заказчика, который просто подсказал, как добавить нестандартный порт в url.
2. Потом была ошибка 401 – ошибка авторизации. Оказалось, для функционирования веб-сервиса нужен пользователь 1C с ролями «Полные права» и «Административные права». После сообщения SOAP UI этого пользователя и его пароля всё заработало. Естественно, что он был заведен на латинице, как и все url.
Если Вы дочитали, и даже допрограммировали до этого места, вам самим впору писать статьи про 1С. Как ни странно, программировать веб-сервисы довольно просто, особенно при наличии сделанного проекта перед этим. В них нет кучи кода и особо сложных запросов, похожих на написанные роботом. Узкие места в веб-сервисах, конечно, есть, но нам повезло, что мы просто адаптировали проект, где они уже были решены.
Если Вам удалось запустить отладчик, через некоторое время вы обнаружите, что всё идеально работает! Китайцы не зря советовали опасаться своих желаний, потому что когда они исполнятся, ребром станет вопрос – а что со всем этим делать? Например, оказалось, что гениальная схема SAP из 4 файлов для номенклатуры может подкинуть вам фокус в виде пришедшего файла с номенклатурой и файла с видом номенклатуры, но пустым видом номенклатуры в самой номенклатуре, потому что эта связка приходит в третьем файле, который вам не послали из SAP. С удивлением вы обнаружите, что SAP – это не только высокооплачиваемые специалисты, но и люди творческие и условно обязательные, которым не чуждо ничто человеческое. Бывает, они пришлют вам несвязанные данные, которые при Вашем идеальном коде всё равно будут недозаполненными. Понятно, что они это делают не специально – когда номенклатуры несколько тысяч позиций, то такие вещи неизбежны. Как же можно бороться с этим хаосом?
Давайте будем на каждый пришедший пакет делать файл лога. Идея замечательная, но первая же полная выгрузка справочника номенклатуры завалит вас кучей довольно больших файлов xml, смотреть которые довольно неудобно. И тогда придется писать просмотр логов, который из каждого файла находит ключевые элементы (обычно их немного – до 2-3). Тогда файл превращается в строчку табличного поля, из которой можно посмотреть номенклатуру и на которую можно наложить отбор, вывести всё табличное поле в файл Excell и т.д.
У обработки простейший дизайн – 4 табличных поля по числу файлов обмена:
Каждый вид файлов заполняется примерно так:
Именно эта обработка позволила практически в онлайн режиме отвечать на вопросы типа сколько данных пришло, какие были незаполненные и т.п. Она оказалась нужна для проверки больших объемов выгрузки. Почему не сделали вместо файлов лога какой-нибудь регистр? На это не было добра от заказчика, да и все эти проверки нужны только на период отладки и запуска. Может вам она даже и не понадобится. Просто знайте, что всего одна страница кода может сэкономить вам кучу нервов и времени.
Обычно на проекте сложности бывают программного характера, но оказалось, что могут быть и организационного.
Что можно сделать лучше на проекте с веб-сервисами?
1. С первого дня работы обеспечить нормальную среду разработчику:
I. работающее без больших задержек хранилище. (в нашем случае нужно было просто сделать новое);
II. работающую без больших задержек 1С. (в нашем случае нужно было добавить памяти в сервер, однако от этой процедуры слетают лицензии);
III. достаточное количество лицензий: на программиста может уходить 4-5 лицензий, поэтому несколько программистов могут создать их дефицит.
2. Обеспечить оперативную поддержку со стороны админов.
3. Иметь нормальное ТЗ. Впервые на этом проекте я столкнулся с тем, что выпрашивал себе работу. Нельзя сказать, что загрузки не было из-за того, что быстро кодировали, просто внимания РП на всех не хватало. С хорошим ТЗ сделали бы в два раза больше и быстрее.
4. Общаться с заказчиком по скайпу, а не через электронную почту. Ведь тогда можно оперативно получить ответ на свой вопрос, что-то показать по демонстрации экрана, да и вообще сделать взаимодействие быстрым и эффективным. Почему заказчик выбрал путь общения через E-Mail, непонятно, но, полагаю, из-за каких-то соображений политики безопасности, что тоже имеет смысл.
Все вышеперечисленные вещи очевидны, но потери от них у нас составили порядка 30 % от общего времени проекта.
Специалист компании ООО «Кодерлайн»
Добрыгин Михаил Васильевич
