Etka и Elsa (электронные каталоги запчастей и работ) умеют общаться с DMS (Dealer Management System, в нашем случае это 1С:Предприятие) посредством XML-сообщений, передаваемых по протоколу HTTP. Чтобы эти три системы могли общаться, нужен посредник — DMS-Backbone.DMS-Backbone — это некий маршрутизатор XML-сообщений. У него есть таблица адресов, и по этим данным службы (то есть Elsa, Etka, DMS) общаются между собой.
Описание форматов сообщений обычно импортер (VW-RUS) предоставляет совместно с дистрибутивом DMS-Backbone.
Для
подключения 1С:Предприятие к DMS-Backbone, нужен некий коннектор (в нашем случае мы написали скрипт для IIS, он называется V8Gate), который будет передавать сообщения между 1С и Etka/Elsa.
На стороне 1С:Предприятие реализован парсер XML-сообщений, получаемых от DMS-Backbone посредством V8Gate.
Таким образом 1С:Предприятие отвечает за такие службы, как наличие запчасти на складе, цена запчасти, получение информации об открытых заказ-нарядах, клиентах, автомобилях и передача заказа из Etka/Elsa в 1С:Предприятие.
Мы делали интеграцию с восьмой версией 1С:Предприятие. И V8Gate использует COM-интерфейс восьмёрки. У меня есть сомнения, что можно поступить аналогичным образом с версией 7.7. Нет уверенности что её COM-интерфейс поддерживает пул соединений. Возможно, легче будет работать напрямую с базой данных с использованием SQL.
Реализую взаимодействие нашей информационной системы с заводской программой, так называемой DMS-Backbone. Смысл состоит в написании механизма, который передавал бы XML-сообщения от DMS-Backbone серверу 1C:Предприятие и получал на них ответы. Сообщения эти DMS-Backbone отправляет посредством HTTP-протокола. Собственно, вся задача сводится к тому, чтобы заставить веб-сервер получать эти сообщения и перенаправлять нашему серверу приложений.
Покопавшись в примере реализации интерфейса, предложенным заводом, можно было примерно понять, как это всё функционирует. Нужно просто заставить этот пример на определённом этапе вызывать нужные функции посредством COM-соединения, передавая им параметры, и получая ответы от нашей информационной системы.
Сказано-сделано.
Добавил в примере вызов COM-соединения. Всё работает, данные передаются, обрабатываются сервером 1С:Предприятие и возвращаются. Но вот беда, установка соединения длится несколько секунд, то есть довольно тормознуто. Хотелось бы использовать одно соединение на всё время использования приложения. Что же делать?
Полез гуглить. Наткнулся на аналогичный вопрос на форуме SQL.RU. Там, к сожалению, нужного мне решения найти не удалось. Пытался хранить COM-соединение в сессии, но это оказалось ещё хуже: DMS-Backbone создаёт новую сессию при каждой отправке XML-сообщения и после нескольких нажатий кнопки F5 в браузере обнаруживаем кучу соединений на сервере 1С:Предприятие.
И вот сегодня, ковыряясь во встроенной справке 1С:Предприятия обнаружил замечательные свойства у V81.COMConnector: MaxConnections, PoolTimeout и PoolCapacity. Ура! То, что нужно!
В каталог с моими скриптами положил файлик global.asa со следующим содержимым:
<object runat="server" scope="application" id="objV81COMConnector" progid="V81.COMConnector"></object> <script language="vbscript" runat="server"> sub Application_OnStart objV81COMConnector.PoolCapacity = 2 objV81COMConnector.PoolTimeout = 60 objV81COMConnector.MaxConnections = 4 end sub </script>
И теперь, во время соединения с сервером приложений 1С:Предприятие, производится поиск уже существующего, и новое устанавливается только если подходящее соединение не найдено.
Dim V81Connection Dim V81ConnectionString V81ConnectionString = "Srvr=""appservername"";Ref=""dbname"";Usr=""username"";Pwd=""userpassword""" Set V81Connection = objV81COMConnector.Connect(V81ConnectionString)
Чувствую, предстоит мне сегодня веселый вечерок. Обновили зарплатную программу. В результате, данные из неё не выгружаются в старую версию бухгалтерской программы — тоже надо обновлять. Новая версия бухгалтерской программы не работает на старом сервере приложений — тоже надо обновлять. Старые клиентские приложения не смогут работать с новой версией сервера приложений — нужно обновлять ПО на всех клиентских рабочих местах. Корочи, веселуха.
Главный бухгалтер: какого хрена до сих пор документы по реализации за январь не проведены? Финдир: Чтобы к утрему было всё проведено!!!11 Мы: Нихрена не получается, будут проводиться ещё неделю, не меньше! Главный бухгалтир и финдир хором: Всех уволююююуууу! Ну мы такие: ну и увольняйте, нам же легче! А они такие: Ну сделайте хоть что-нибудь! А мы такие: Блин, нифига ничего не получается.
Но к вечеру нашли ведь способ. В общем, партионный учёт в бухгалтерии 8 — жууууутко тормозной! Один наш заказ-наряд, который в торговой базе проводится за секунды, при переносе его в бухгалтерию проведение занимает несколько минут! В общем отрубили мы ФИФО, заюзали поле «Себестоимость» в табличной части документа — и понеслось! Провели весь месяц за три часа. Круто-круто!
1C разрабатывает новую версию платформы — 8.2 На пользовательском разделе сайта выложена ознакомительная версия для скачивания. Судя по документации, планируется новый эволюционный этап развития, и это хорошо.
Вообще, довольно много вкусностей обещают. Вот, например:
Динамические списки
Отдельно следует сказать о новом подходе к отображению данных в динамических списках. Динамические списки в формах в управляемом приложении строятся на основе системы компоновки данных. Для динамического списка разработчик задает текст запроса, который будет использован для считывания данных, и указывает основную («ведущую») таблицу. Система автоматически выполняет считывание данных запроса порциями, по мере навигации пользователя по списку. При этом как разработчику, так и пользователю предоставляются богатые возможности системы компоновки данных по настройке отображаемой информации (отбор, упорядочивание, группировка, условное оформление).
Похоже, в недалёком будущем нас наконец ждёт полное и безоговорочное счастье и мир во всём мире.
Cегодня я расскажу как забавная фишка в 1Cv8, называемая «бизнес-процессы», нам строить и жить помогает отслеживать повторные ремонты автомобилей.
Почему нужно отслеживать повторные ремонты? Да потому что это следствие некачественной работы. Удовлетворённость клиента снижается, если ему приходится повторно обращаться в сервис. Ну и представительство нас дрючит за повторные ремонты, поскольку это прямым образом бьёт по степени доверия клиентов к марке.
В старые добрые времена, когда деревья были высокими, а у нас стояла 1Cv77, мы просто проверяли при открытии заказ-наряда, не было ли за определённый период ремонта этого-же автомобиля. И, буде таковой случался, предлагали мастеру-консультанту указать причину повтора из нескольких пунктов. Понятно, что мастер в 99% случаев просто выбирал пункт «другое» и не сильно заморачивался. Проанализировать причину повторов при этом было решительно невозможно.
И вот инженеры отдела контроля качества поморщили мозг и придумали регистрировать не причины повтора, а сами причины ремонта. Для этого нужно закодировать все возможные неисправности с помощью иерархического списка, например:
Двигатель
Работа
Вибрация
Трансмиссия
Работа
Вибрация
Шумы
Отопление/вентиляция/климатическая установка
Работа
Внешний вид
Во время приёма автомобиля в ремонт мастер-консультант выбирает причины ремонта из этого списка и получается заявка, в соответствии с которой автомобиль в дальнейшем диагностируют и ремонтируют. Выглядит это следующим образом:
Во время записи заявки на ремонт система проверяет все заказ-наряды на ремонт этого автомобиля за определённый промежуток времени. Если хоть одна из причин ремонта совпадает, то в отдел контроля качества отправляется подмётное письмо с подробной информацией кто, куды, чего и как.
Я нарисовал схему этого эпического процесса:
Всё! Как только появляется подозрение на повторный ремонт, система генерит электронное письмо и отправляет его куда следует.
А в следующий раз я расскажу как в 1Cv8 выцепить электронный адрес получателя из Active Directory.
Когда мы только запускали наш проект, для нас довольно серьезной проблемой оказалась необходимость установки программного обеспечения на множество клиентских компьютеров.
С одной стороны, дистрибутив программы распространяется в форме MSI-пакета. Это должно было снять любые проблемы с массовым развертыванием в среде Active Directory.
На деле же это проблем только добавило, так как по умолчанию для установки выбирается английский язык, и пользователь получает секси интерфейс вперемешку на русском и буржуйском языках. Увы, для многих наших сотрудников работа с нерусифицированным интерфейсом представляет некоторую сложность. А проблемы юзеров довольно скоро становятся и нашими проблемами.
Поэтому, большинство рабочих станций пришлось инсталлировать буквально в ручном режиме, обойдя каждое рабочее место и запуская программу установки с правами администратора.
Долго ли, коротко ли, с этой задачей мы справились, но прогресс не стоит на месте. 1С выпускает новые версии своего продукта. И обновление на эти версии представляется нетривиальным, ввиду некой особенности – версии серверного и клиентского программного обеспечения должны быть одинаковыми, иначе ничего не получится.
Вот тут пришлось вновь чесать репу, как же заставить MSI-пакет установить программу с правильными языковыми настройками. После неких исследований до наконец меня дошло, что нужно сделать некий transform (файл, модифицирующий MST-пакет и имеющий расширение MST), и указать его в настройках групповой политики.
Но как, точнее чем сделать этот файлик?
Гуглинг подсказал, что можно воспользоваться Microsoft Office Resource Kit. Там есть некий Custom Installation Wizard, который позволяет сгенерировать пресловутый transform. Но и здесь меня ждала неудача. Custom Installation Wizard замечательно работает с пакетами MS Office, но совершенно не годится для каких-либо других пакетов.
Пришлось дальше мучить Google, который выдавил из себя названия заветных программ:
Wise InstallTailor – ранее свободно предоставлялась на сайте разработчика, но теперь убрана во внутрь монструозного Wise Package Studio
WinINSTALL LE – также не удалось обнаружить. Вместо неё на сайте лежит такой же монструозный WinINSTALL MSI Packager Professional, который и поставить даже толком не удалось.
Наконец, одна добрая душа предложила скачать Windows Platform SDK, который содержит некую утилиту Orca, позволяющую редактировать MST и MSI-файлы.
Это просто кошмар, когда понимаешь, что выкачал 300 мегабайт ради файлика размером 2 мегабайта.
С помощью Orca я сделал нужный мне MST, поправил там кодовую страницу продукта, названия папок и кое-какие дополнительные опции. Протестировал групповую политику, проверил что всё работает как надо и в самый последний момент обнаружил, что Microsoft Installer хранит некий 1049.MST у себя в папке.
Оказалось, что InstallShield, с помощью которого собран дистрибутив 1С:Предприятие, генерирует этот так нужный мне MST, указывая там все языковые и прочие настройки, а потом скармливает этот файл модификации вместе с пакетом службе Windows Installer, который, в свою очередь, выполняет установку!
В итоге оказалось, что нужный мне файл размером всего 46 килобайт, всегда был у меня под носом, но найти его стоило около гигабайта трафика. Ужасно.
А вот, кстати. Информационный повод. Мы наш проект всё-таки запустили.
Знакомьтесь, система управления предприятием «Автодилер», powered by 1С:Предприятие 8.1
В октябре прошлого года руководство дало отмашку: переходим! Но, как говорится, скоро сказка сказывается… Пойди-ка перейди со всей этой кучей наработанного за семь лет существования старой системы функционала.
Здесь сразу вспоминается байка про русского программиста, который обещал за день всё переписать, потому что всё было сделано не так. Смешно, конечно, если бы не было правдой.
И вот мы в четыре руки, за шесть с половиной месяцев портировали из Предприятия 7.7 в «восьмёрку». Перетащили большинство функционала и все необходимые данные до того уровня, когда стало возможно осуществлять оперативную работу.
А потом применили патентованный метод Rock-n-roll. Это когда в один прекрасный день доступ к старой, хоть и тормозной, но удобной и функциональной системе, прекращается. Взамен этого пользователю предлагается новая, сырая и недостроенная система. Примерно вот так это выглядело:
Как бы то ни было, система шустро и стабильно функционирует, обеспечивая деятельность организации по трём направлениям: продажа автомобилей, послепродажное обслуживание и продажа запчастей. Ура!
Людмила Гурченко недавно обменяла свой Ауди А3 2.0 FSI на A4 2.0 CVT, получив неплохую скидку от представительства, так что сделка прошла баш-на-баш, без дополнительной оплаты.
Все было бы хорошо, если только сегодня наш диспонент не подошел ко мне и не поинтересовался, почему в отчетах этот автомобиль фигурирует как проданный в чистый минус, вообще без оплаты. Посмотрел — и правда, в отчете по выписанным автомобилям эта машинка продана со стопроцентной скидкой. Гы-гы.
Полез
выяснять дальше. Оказалось, что ваятель этого эпического отчета (то есть я на самом деле) даже не предполагал, что автомобиль, принятый по трейд-ин, может полностью окупить расходы на покупку нового автомобиля. Действительно, такое с нами — в первый раз.
Дабы не ковыряться во внутренностях отчета, ввели символическую предоплату в один рубль. После чего отчеты заработали как надо.
Словом, приходите к нам! Мы ваш старый автомобиль обменяем на новый, и денег не возьмем ;) Бизнес и ничего личного, как говорится.
Небольшая история в подтверждение «мифического человеко-месяца».
Примерно
год назад я разрабатывал поддержку продаж автомобилей в нашей управленческой базе данных. В рамках того проекта были написаны модули для приема звонков от клиентов, ведение договоров и отчетность. Справился я с этим делом неплохо, коль скоро этот модуль до сих пор активно используется.
Правда, разработку комплексного, центрового, отчета по продажам, руководитель проекта поручил моему коллеге. Честно говоря, мне было немного обидно: я столько усилий приложил к разработке, а сливки в виде отчетов теперь снимает другой.
Надо отдать должное, коллега решил задачу достойно — отчет был написан, отлажен и успешно внедрен. Но вот некоторые забавные особенности всплыли гораздо позднее, в процессе портирования системы на новую платформу.
В частности, выяснилось, что сведения, которые в этом отчете приходилось вытаскивать буквально через жопу, можно легко и непринужденно сформировать во время записи первичных данных. И теперь сотня строк в головоломных процедурах отчета заменяются на пять строк в модуле записи данных и десять строк строк в формировании запроса. Самое смешное, что отчет в этом случае формируется просто на порядки быстрее.
Почему эта идея не пришла в голову моему опытнейшему коллеге — ума не приложу.
Update: Идея в голову моему коллеге приходила, конечно. Вот только трансформировать некоторые таблицы в базе размером в несколько гигабайт занимает несколько часов. Поэтому приходилось извращаться.
