Содержание
- Ключевые правила работы
- Кейс «Анализ объема»
- Кейс «Есть контакт!»
- Кейс «Не то, чем кажется»
- Кейс «Мистика»
- Выводы
Я Виктор, программист 1С. Свой путь в программировании начал в 1989 году. Сначала это был Pascal, и я участвовал в разработке программы по расчету заработной платы. В 2000 году «подсел» на 1С и уже больше 20 лет работаю в этой сфере.
Ключевые правила работы
Одна из часто встречающихся задач при работе с конфигурациями 1С – это разработка механизмов обмена с другими базами данных или приложениями. Способов выполнения этих задач существует огромное количество, и выбор конкретного зависит от того, с какой именно системой будет осуществляться обмен, с какой периодичностью и какой объем информации нужно отправлять (получать).
Участвуя в разработке таких механизмов, я вынес для себя несколько важных вещей:
- Обязательно производить тщательный анализ получаемых, отправляемых данных. Нужно точно определить минимально необходимый набор данных для обмена. Это позволяет сократить количество ресурсов: объем памяти, сетевой трафик и т.п. В то же время нельзя упускать абсолютно необходимые данные. Важно проверять возможность некорректной интерпретации данных, участвующих в обмене. Если этого не сделать, то при получении (обработке в контрагенте обмена) могут возникать, например, дубли объектов либо изначально разные объекты будут интерпретироваться как один и тот же объект и соответственно перезаписываться.
- Важен, а иногда просто необходим, контакт с коллегами, обслуживающими контрагента (систему) обмена и людьми, обеспечивающими работу «железа» (сеть, сервера и т.п.).
- Велика роль консультанта, который должен владеть навыками работы как в нашей БД, так и в системе-контрагенте. Если консультант хорошо знаком с обеими системами, это поможет избежать возможных ошибок при разработке обмена, так как практически всегда есть некие нюансы в работе систем и есть вещи, которые на самом деле являются не тем, чем кажутся на первый взгляд.
Кейс «Анализ объема»
Речь пойдет о разработке обмена между двумя базами 1С при помощи HTTP-сервиса.
Нужно было передавать по запросу из приемника сведения по договорам. На входе получаем список некоторых идентификаторов, а в ответ направляем данные о дате окончания договора и текущем сальдо.
Казалось бы, объем данных небольшой: на входе массив строк, каждая из которых длиной 9 символов, а на выходе та же строка + дата и число. Сервис был реализован и успешно протестирован в базах разработки, и все отлично работало, но…
Когда сервис был внедрен в базу разработки, то начались проблемы. Оказалось, кто количество договоров, по которым происходит обмен, исчисляется десятками тысяч. А кроме того, параллельно с этим обменом работает еще множество других. В результате контактов с людьми, ответственными за «железо», удалось определить оптимальный объем, который можно отправлять в одном пакете. Сервис был переделан и обмен был разбит на несколько потоков. Таким образом проблема была решена.
Кейс «Есть контакт!»
Необходимо было получить данные из сторонней БД (не 1С). Задача заключалась в том, чтобы запрашивать через web-сервис некоторую таблицу по определенным условиям. Было реализовано получение данных по API, но выяснилось, что при этом сервис не поддерживает отбор, а возвращает только всю таблицу.
Соответственно, скорость работы была очень низкой. На получение всех данных уходило 90% времени, еще около 5% на отбор нужных строк и только 5% приходилось на обработку полученных данных.
После общения с разработчиками сторонней системы нам с архитектором удалось убедить их в небольшой доработке сервиса. В результате время, затраченное на получение данных, уменьшилось примерно с 12 минут до 3-5 секунд и функционал стал работать без «тормозов».
Кейс «Не то, чем кажется»
В этом кейсе нужно было реализовать обмен с помощью обработки «Универсальный обмен данными в формате XML» с несколькими идентичными конфигурациями. Состав объектов: подразделения, сотрудники, кадровая история (только состояние сотрудника и где работает). Причем по сотрудникам нужны были только ФИО и табельный номер.
Правила обмена я написал в КД 2, протестировал на одной из баз и отдал на проверку консультанту.
Проблемы начались уже при проверке. После загрузки из нескольких баз часть подразделений «терялась». После безуспешных попыток найти ошибку в правилах совместно с консультантом решили проверить, а не совпадают ли в разных базах ссылки подразделений.
Выяснилось, что базы изначально были созданы копированием, и часть ссылок в них совпадают (подразделения). Хотя это были разные организации (филиалы), чтобы не плодить записи в справочнике подразделений, некоторые были просто изменены (переименованы). Соответственно, при последовательной загрузке из разных баз данные перезаписывались, так как был реализован самый правильный и надежный поиск объекта – по GUID’ам. Пришлось менять правила поиска. После чего проблема с подразделениями решилась и правила были отданы заказчику.
На этом эпопея с обменом не закончилась. После проверки заказчиком выяснилось, что несмотря на то, что филиалы находятся в разных городах, периодически происходят переводы сотрудников и необходимо, чтобы в базе-получателе не возникал «дубль» сотрудника и сохранялась вся его история переводов. Два элемента из разных баз с разными GUID'ами и кодами (табельными номерами) должны были интерпретироваться как один.
Поиск по наименованию (ФИО) тоже не подходил, так как тогда возникала проблема при смене фамилии. Другие поля, по которым можно было бы производить поиск (ИНН, СНИЛС), не могли участвовать в обмене, потому что содержат персональные данные. Пришлось вместе с консультантами искать косвенные данные (не из справочника сотрудников), которые бы помогли однозначно идентифицировать сотрудника и не относились к персональным. В результате решили использовать регистр, в котором хранится история смены ФИО.
Кейс «Мистика»
Ситуация возникла на тех же базах, о которых речь шла в первом кейсе. Также был создан HTTP-сервис. Он должен был формировать некоторые печатные формы (уведомления) при выполнении периодической обработки и передавать их в другую базу, из которой они по электронной почте направлялись контрагентам вместе с пакетом других документов.
Все было проверено на базах разработки и мной, и консультантом. Все работает, но…
Когда функционал был передан в рабочую базу, начались непонятные проблемы. ПФ то формировались, то нет,причем по непонятным причинам. При массовом их создании/передаче они не всегда формировались в базе-источнике. Но если по тем же данным (у того же объекта, в том же периоде) формировать их индивидуально, то все отрабатывало отлично. Весь код был проверен десятки раз, причем не только мной, но и архитектором – нет ошибок в реализации. Просил проверить его и других разработчиков – тот же результат. Все должно работать, но не работает. Проверялось и создание ПФ и отправка – проблему так и не смогли найти. К сожалению, потом меня перевели на другой проект у этого же заказчика, и я не знаю, чем закончилась история…
Выводы
При работе с обменами и интеграциями, как и при любой другой разработке, важны как хардскилы, так и софт. Если по вопросам технического характера мы можем найти нужную информацию в разных источниках, то в некоторых случаях отсутствие хорошего взаимодействия и взаимопонимания с людьми, с которыми мы вместе на проектах, может существенно увеличить время, потраченное на выполнение задач.
Главные выводы, которые я сделал, выполняя задачи по интеграции:
— анализ, анализ и еще раз анализ
— нужно больше общаться и обсуждать вопросы, которые возникают при решении задач. У каждого коллеги свои компетенции и этими знаниями он охотно поделится.
Всем хороших, интересных задач и дружелюбных коллег!
