Я расскажу, как мы потрудились, создавая веб-инфраструктуру водоканалов на технологиях 1С, и что получилось в итоге. Надеюсь, из нашего кейса вы сможете узнать некоторые подходы и приемы для использования у себя на проектах.
Прежде всего, я хочу рассказать, что мы давно занимаемся автоматизацией водоканалов и теплосетей, работаем в узкоотраслевом направлении ЖКХ – это позволяет нам разговаривать с такими предприятиями на одном языке. У нас есть продукты для водоканалов и теплосетей по расчетам с населением и с предприятиями. «Водоканал: расчеты с населением», «Водоканал: расчеты с юрлицами», «Теплосети: расчеты с населением» и «Теплосети: расчеты с юрлицами» – это наши конфигурации. Конфигурации по расчетам с населением являются самостоятельными на основе БСП, конфигурации по расчета с юридическими лицами являются модулями к конфигурации "Бухгалтерии 3.0", что избавляет от необходимости перегружать данные по выписанным счетам и произведенным платежам абонентов, т.к. вся работа идёт в одной базе.
У нас на сайте есть карта, где представлена география водоканалов, которые работают с нашими продуктами, используют наши технологии, личные кабинеты и т.д. Для этих проектов характерно то, что наши выезды не требуются, мы все делаем удаленно.
О чем пойдет речь в этом кейсе?
Напомню, мы говорим о ЖКХ, где есть своя специфика. Мы рассмотрим, какие потребности возникают сейчас у этих предприятий, и какую функциональность они хотят видеть на своих сайтах.
Я расскажу о том, что мы делаем для наших клиентов и какие подходы и технологии при этом используем.
Также будет несколько слов о разработанном нами нативном мобильном приложении, которое работает с сайтом.
По терминологии:
- Программист 1С – это программист 1С;
- Вебер – это не фамилия, это тот, кто программирует веб.
Что касается специфики ЖКХ, то:
- Мы работаем с большим количеством абонентов. Абоненты – это мы с вами, потребители коммунальных услуг, нас очень много. Абоненты делятся на две части: население и предприятия. Мы работаем с абонентами на уровне региона – у нас около миллиона абонентов. Специфика такого количества в том, что здесь нельзя использовать подходы «мы все проверим глазами», «всем все сделаем». Здесь надо, чтобы все работало четко, иначе человек перестает платить, потому что ему не напоминают: «Вы мне не звонили, вы меня не оповещали». Хотя в ЖКХ и не должны этим заниматься.
- На первый взгляд кажется, что в том, чтобы посчитать воду, газ, тепло и т.д. нет ничего сложного. Но все не так просто, потому что законодательство заставляет подходить к расчетам определенным образом. Следовательно, для всей этой армады нужны биллинговые решения, которые будут все это обсчитывать. На рынке представлено много решений для таких расчетов: есть наше приложение, недавно вышел «1С:Биллинг», есть уфимский «Софт-портал» и есть много не 1С-ных решений.
- Главная ИТ-специфика ЖКХ заключается в том, что на этих предприятиях очень слабый штат ИТ. Запросов от руководства очень много, но реализовывать их практически некому. Если есть администратор – уже повезло. Если он знает Linux – вообще отлично. А чтобы были программисты – это фантастика, потому что их там не держат.
Когда расчеты у наших клиентов в биллинге на 1С только наладились, сразу зашла речь о том, чтобы сделать для них что-нибудь еще и упростить жизнь людей. Главная головная боль у этих предприятий – это очереди. Люди ходят, чтобы свериться и что-то узнать. «Давайте уберем эти очереди, пусть там останутся одни пенсионеры, а вся молодежь пусть использует “Личный кабинет” на сайте и там все это смотрит. Уберем очереди, и, может быть, сократим или перенаправим на более полезную работу персонал».
Почему я так подробно об этом рассказываю? Я хочу, чтобы вы поняли эволюцию нашей мысли, как мы к этому шли.
Какие подходы к созданию «Личного кабинета» рассматривались?
Прежде всего, хотелось, чтобы это было быстро и недорого, поэтому планировали взять какую-нибудь CMS-систему, в которой уже будут все шаблоны. Например, на «Битриксе» много отличных программистов, которые делают все очень быстро и стоят недорого. Сначала мы хотели взять эту CMS-систему и загрузить все туда, чтобы она работала автономно от основного биллинга . Но возникли проблемы.
- Когда мы загружаем все данные на какой-нибудь сайт, у нас сразу возникает вопрос, в какой момент все это обновлять. Потому что если будут какие-то задержки, люди начнут нервничать: «Я же заплатил, почему я не вижу, что деньги прошли?». Это вызывает очень большие проблемы.
- Еще один важный момент – мы провели эксперимент, выгрузили на сайт данные по миллиону абонентов, причем, не все данные, а только фамилии. Потом по каждому абоненту выгрузили историю за пару лет работы. После этого скорость работы сайта стала очень низкой – он стал просто «зависать» при запросах.
Поэтому подход хранить все данные на сайте не показал эффективность на таких объемах.
Был выбран следующий подход – сайт на «1С:Битрикс», база 1С и между ними – прокладка в виде SOAP (веб-сервиса).
- В «1С:Битриксе» (на сайте) данные вообще не хранятся. Следуя последним веяниям – данные людей вообще не должны где-то храниться. Тем более, если хостинг будет стоять где-то за рубежом, то могут прийти и сказать, что вы персональные данные куда-то уводите. Поэтому на «Битриксе» ничего не хранится, его задача – только отрисовывать интерфейс (front-end).
- Скорость работы при такой структуре системы повышается, потому что используются данные только по тем абонентам, которые есть сейчас на сайте. Если на сайт одновременно зайдет десять человек, то данные будут гоняться только по ним. Тем более что на сайте водоканала десять человек одновременно почти никогда не бывает – это вообще мечта наших заказчиков, чтобы люди там были. Но даже если в течение пяти минут зайдет сто человек – уровень нагрузки получается не HighLoad, система справляется. Сейчас у нас установлен 64-битный Apache, и он с такими нагрузками справляется.
- Самое главное преимущество для 1С-команд в том, что такой подход позволяет отделить прикладную и веб-логику. Задача вебера – верстать страницы. Не надо его погружать во все эти коммунальные дебри, формулы, цены и т.д. Ему вообще ничего не надо рассказывать, его задача – просто отрисовать. Мы просто говорим: «Вот тебе веб-сервис, выведи эту информацию на сайт». И вебер очень доволен, что не надо погружаться в предметную область.
Что такое веб-сервис? Это схема, которая говорит веберу: «Вот наши методы, наши типы данных, работай с ними». Чтобы он все сделал, мне достаточно отдать ему одну только эту схему. Ничего не надо описывать – ни спецификацию, ни параметры. Все в схеме. В плане коммуникаций и взаимодействия, если у вас вебер не в штате, а на аутсорсе – это отлично подходит.
Сервисы OData работают быстрее, мы на них уже частично перешли, но там есть нюансы – я о них чуть позже расскажу.
Покажу, как это выглядит изнутри.
Это конфигурация 1С, в которой все реализовано – подсистема «Личный кабинет» встраивается в конфигурацию. Сейчас уже есть возможность реализовывать эту функциональность через расширения, поскольку в них можно встраивать веб-сервисы – поэтому, при желании, все это можно сделать через расширения.
Есть пакет XTDO Abonent – это непосредственно данные водоканала, которые мы будем предоставлять на сайт – показания счетчиков, абоненты и т.д.
Эти данные здесь тоже сгруппированы по типам, которые будут передаваться на сайт – например, в типе «Абонент» находится информация по владельцу, его лицевому счету, количеству проживающих и т.д.
Есть специфичный тип PortalAccessInfo – это информация об аутентификации организации, сюда передается код и пароль организации. Эти данные мы используем во всех методах в качестве первого передаваемого параметра, который нам нужен, чтобы связать многофилиальные структуры. У нас есть проект, в котором объединены 33 базы 1С, разбросанные по всему краю – они удалены друг от друга на расстояние 300-400 километров. Когда человек заходит в «Личный кабинет», нам нужно понять, из какого он района, где его родная база. Веб-сервис запрашивает эти данные, и тогда мы по коду организации понимаем, какой это филиал (какой район). И уже в зависимости от кода организации начинаем стучаться в конкретную базу данных.
С XDTO-пакетом связан веб-сервис.
За веб-сервисом стоит модуль. В нем описано много методов – это те функции, которые будут возвращаться веберу. Для каждого метода описан тот набор параметров, который будет в него передаваться. Это уже пошло простое кодирование на 1С.
В функции ПолучитьДанныеАбонента мы запросом забираем информацию об абоненте из базы данных. Абонент входит в «Личный кабинет», создается пакет «АбонентXTDO», который начинает заполняться значениями из базы: телефоны, количество проживающих и т.д.
Здесь все очень логично – вы заполняете все эти коллекции и возвращаете веберу заполненный пакет «АбонентXDTO».
Перед передачей на сайт есть строчка, где производится логирование текущего действия пользователя на сайте:
РегистрыСведений.ДействияАбонентаВЛичномКабинете.ЗаписатьДействиеАбонента (АбонентWebСайта, Перечисления.ДействиеАбонентаВЛичномКабинете.ПросмотрОбщейИнформации).
Потом на основании этого регистра сведений можно собирать статистику о том, чем люди занимаются на сайте.
Из интересных методов можно выделить получение квитанции в PDF-файле. В «Личном кабинете» есть кнопка «Получить квитанцию». При ее нажатии идет запрос в 1С, где формируется отчет о задолженности и выводится на сайт в виде PDF-файла, чтобы пользователь мог его распечатать и оплатить – или просто ознакомиться.
Смотрите – открылась квитанция, которая пришла из 1С.
Эта квитанция в базе 1С представляет собой внешнюю обработку, потому что у каждого предприятия своя форма квитанции. Эта внешняя обработка формирует печатную форму, которая сохраняется как PDF, и в виде бинарного файла возвращается на сайт.
Человек получает квитанцию и остается довольным. Даже если он ее не распечатывает, ему, по крайней мере, все в квитанции понятно. Иногда люди настолько привыкают смотреть в одни и те же места на квитанции, что им неудобно видеть свою задолженность на экране.
Опять же, логика остается за 1С, а веберу знать ничего не нужно. Он всего лишь передает в браузер бинарный файл на скачивание. Все в 1С, на сайте ничего не происходит. Единственное, что отдано на сайт – это аутентификация, потому что логин/пароль лучше все-таки держать на Битриксе. И реестр пользователей у нас тоже хранится на Битриксе. Сам Битрикс сейчас находится не на внешнем хостинге, а в сети водоканала. Поэтому функции защиты и т.д. мы отдали местным администраторам, чтобы они настраивали их с помощью веб-сервера.
Какие использовались технологии? Сейчас я рассказал про SOAP, но недавно появилась OData, которая работает гораздо быстрее.
Часть функциональности можно переделать под OData. Но когда создавались эти кабинеты (а это было четыре года назад), возможности использовать OData в 1С еще не было.
Единственное ограничение OData – это то, что в нем довольно простые запросы. А если нужно что-то выбрать (или, например, вставить дополнительные вычисляемые поля), то приходится делать много таких запросов. И это должен делать вебер. Получается, что нужно отдать логику веберу, а если что-нибудь сломается и не удастся вовремя исправить – будут недовольны пользователи и т.д. Поэтому некоторые вещи мы пока будем оставлять на веб-сервисах. Мы спрячем от вебера сложную логику, чтобы он просто выводил данные.
Как все это развивалось дальше? У водоканалов используется не одна база, а две – одна база работает для населения, а другая для предприятий. А на сайт хочется вывести информацию из обеих баз. Возникает вопрос «Как это сделать?».
Можно было сделать второй такой же веб-сервис – рассказать веберу, что у нас теперь два веб-сервиса, чтобы он хранил их настройки у себя независимо и работал с ними, как с независимыми друг от друга. Но мы пошли другим путем. Поскольку база для населения и база для юридических лиц – это у нас две абсолютно разных базы по метаданным (два разных царства, как БП и БГУ), мы решили сделать промежуточную шлюз базу. В чем причины такого решения?
Дело в том, что до платформы 8.3.9 основные «тормоза», которые возникали при работе с 1С, были связаны с созданием сеансов. Абонент подключался к базе, вытаскивал данные и отключался – сами запросы отрабатывали моментально, а основное время тратилось на подключение. Потом, когда разработчики в 8.3.9 реализовали переиспользование сеансов, когда для новых подключений подбирается сеанс с такими же параметрами, это значительно повысило производительность сеансов. Более того, теперь каждым сеансом можно управлять из 1С, например, использовать на уровне 1С такие вещи, как cookies. Сейчас, когда к нам приходит запрос, мы каждый раз забираем нужные данные из базы и отдаем их. Но если пользователь повторно запрашивает эти же данные в этом же сеансе, можно было бы сохранить их где-то и вывести уже гораздо быстрее. Пока у нас нет временных переменных для сеанса, нам нужно организовывать для этого какие-то регистры и т.д., но все это можно реализовать, мы проверяли.
- Мы сделали шлюз – промежуточную базу 1С, где реализован один HTTP-сервис, который, в зависимости от запроса, возвращает две разных ссылки WSDL. В итоге у нас описание веб-сервисов теперь находится в одном месте – веберу не нужно делать под них две разные настройки, просто у нас внутри используется два веб-сервиса.
- Возникла проблема в том, как возвращать веберу описание пакета XDTO без его дублирования в шлюз-базе, поскольку, если я хочу вернуть информацию по абоненту, мне надо воссоздать этот пакет XDTO в базе шлюза, а там другая структура, и данные по абоненту не хранятся. Мы решили этот вопрос с помощью сериализации пакетов XDTO в JSON, который вебер понимает.
- Заодно база-шлюз решает еще одну главную задачу – это логирование всех действий пользователя. Кто бы на сайт ни зашел – обычный пользователь или юридическое лицо – я их залогирую в одном месте.
Как это выглядит на практике?
У меня на сайт заходит обычный человек или пользователь от предприятия (от какого-нибудь ООО). Мы пропускаем их запросы через шлюз-базу, которая основана на «1С:Библиотеке стандартных подсистем» (БСП). Повторю правило: если вам нужна база 1С для каких-то сложных целей – всегда берите «БСП», только отрежьте оттуда все ненужное. Там столько всего есть, что вы сэкономите огромное количество времени.
В этой шлюз-базе у нас есть справочник «Подключения к сервисам баз 1С».
Этот справочник позволяет нам сделать запрос к другой базе 1С, чтобы взять данные оттуда.
Вот так выглядят данные для обращения к веб-сервису другой базы. Тут прописывается имя пользователя, его пароль, и, главное, «Ресурс» – путь к WSDL.
Как это работает? Используется два HTTP-сервиса: PortalAbonentData и PortalJurAbonentData – для населения и юридических лиц. В этих HTTP-сервисах методом GET запрашиваются схемы WSDL.
Здесь на слайде показан весь код обращения из базы шлюза к базе населения:
- Мы берем константу, где у нас прописаны параметры подключения к базе для населения.
- Соединяемся с базой по настройкам ресурса – ссылке WSDL.
- Полученную из базы XML-структуру (схему WSDL) отправляем веберу в качестве ответа сервера.
Так у нас вебер узнает о том, какие схемы работают в нашем водоканале. Для него водоканал – это одна база, он не разделяет, сколько у нас внутри баз 1С. Сейчас их уже 3-4, но он об этом даже не подозревает – мы просто выдаем ему разные ссылки этих WSDL.
Как же вызвать сам метод? Был получен запрос, на его основании мы понимаем, что от нас хочет пользователь, но мы же должны обратиться в нужную базу. Для этого в базе-шлюзе мы создали два метода веб-сервиса Vodokanal – для операций с населением и с юридическими лицами. Мы знаем, кто и какую операцию хочет, и знаем параметры, которые к нам приходят в виде строки.
На обработке этих параметров я хотел бы остановиться.
Что происходит при вызове метода?
- Мы соединяемся с нужной базой 1С;
- Параметры, которые нам передал вебер, записаны в JSON – мы выгружаем их в массив и считываем в переменную СтрокаПараметровМетода;
- Эту переменную мы передаем в метод Выполнить() для соединения с конечной базой;
- И параллельно записываем действия пользователя в лог-журнал;
- Далее мы получаем из конечной базы ответ, который упаковываем в JSON и передаем нашему веберу. Единственный момент – если это PDF, то мы здесь сталкиваемся с некоторыми символами, которые убираем, и возвращаем результат в виде Base64.
Это весь код для шлюз-базы. Больше нам здесь ничего не понадобилось. Всю логику отрабатывает уже конечная база.
Водоканал постоянно просят сделать удобным – нам ставили требования от правительства, от президента, чтобы люди могли подавать документы в электронном виде. Был целый консилиум директоров всех водоканалов с их замами – обсуждали, как это можно сделать.
Основная задача состоит в том, что пользователи должны иметь возможность подавать водоканалу электронные документы. Возникает вопрос, кто вообще может подавать такие документы? И оказывается, что подавать в водоканал электронные документы могут абсолютно любые люди – те, кто строит дом; те, кто уже что-то построил; те, кто будет что-то продавать и т.д. Подавать электронные документы может вообще любой человек.
Решили поменять концепцию.
Обычно доступ в «Личный кабинет» предоставляется по номеру лицевого счета и паролю, который выдается в жилконторе лично, чтобы можно было удостовериться, что этот дом принадлежит именно вам.
Но мы решили пойти другим путем и пустить в «Личный кабинет» всех, у кого есть электронный адрес. А дальше уже будем с ними разбираться. Теперь для регистрации нужен только логин и телефон.
Можете попробовать зайти на сайт Ставропольского водоканала и зарегистрироваться. Мы вас пустим, и вам даже что-то разрешат делать, но не все. Неважно, кто вы – рядовой гражданин или предприниматель, заходите, и мы вам уже что-то на нашем сайте предоставим.
Как только вы перейдете по ссылке на сайт, вы уже сможете подавать в водоканал различные документы, к примеру, какие-то заявления. Или сможете задать вопрос – например, спросить, почему цена в Ставрополе такая-то, а в Москве такая-то. Вам ответят, потому что мы придерживаемся к людям такого человеческого отношения, которого требует наш руководитель на самом верху.
При подаче документов есть две основные проблемы.
- Первая – это большое количество видов документов, к которым нужно прикреплять много скан-копий – паспорта, схемы и т.д. Когда мы начали выяснять, сколько таких видов документов, нам сказали, что теоретически их около 200.
- И вторая проблема – все эти виды документов чем-то отличаются. Они могут отличаться одним полем или целыми страницами.
Вот такие различные документы должен принимать сайт водоканала.
Мы задумались, как это сделать. Под каждый вид рисовать страницу – это нехорошо. Если мы начнем рисовать, то вся логика заполнения у нас опять перейдет на вебера, который не хочет во все это вникать. Если ему начать объяснять, что это за документы и чем они отличаются – он вообще с ума сойдет.
Поэтому речь зашла о том, чтобы придумать конструктор документов и дать его в руки работников водоканала – пусть сооружают какой хотят документ, а мы потом на сайт выведем его поля, чтобы люди их заполняли и заполненные данные сразу попадали в базу 1С, где с ними уже начнут работать операторы. Всем эта идея понравилась. Мы не имели понятия, как сделать такой конструктор, но, опять же, приоритетным для нас было, чтобы логика как можно больше была завязана на 1С, потому что в водоканале есть хоть какие-то программисты 1С, а веберов нет.
Мы думали, как это реализовать, и тут вспомнилось, что в БСП есть отличная подсистема «Анкетирование», которая собирает информацию по абсолютно любым вопросам. С ее помощью можно создать любой вопрос и установить варианты ответов на него, причем ответы на вопросы могут быть как простыми (булево, число, строка), так и составными (целыми таблицами).
«Анкетирование», если вы видели его в ЗУП, – отличная подсистема, там все есть. Зачем заново открывать Америку? Мы просто встроили ее в свою конфигурацию и поменяли синоним документа «Анкета» на «Заявка» (электронный документ).
Что собой представляет подсистема «Анкетирование»?
- Это справочники:
- ВариантыОтветов,
- ВопросыАнкет,
- И ШаблоныАнкет.
- Но главный момент, что есть документ «Анкета», табличная часть которого состоит из 5-ти колонок, с помощью которых можно собрать любую информацию любой сложности. Это универсальный механизм.
- Помимо этого, есть еще документ НазначениеОпросов, который устанавливает даты, когда надо пускать анкету в работу, а когда не надо. Это нам подходит, т.к. документы имеют тенденцию меняться. Например, с 1 октября форма подачи заявления меняется. Зачем ждать 1 октября? Форму документа уже разработали, выложили и указали, что она начнет действовать с 1 октября. А старые документы с помощью назначения даты окончания действия выключаются из работы и уходят с сайта.
Давайте я на примере расскажу, как это все работает.
На сайте это называется «Заявки».
Вот список заявок, которые в данный момент можно подать на сайте: «Простое письменное обращение», «Вызов контролера», «Закрытие лицевого счета» и т.д. Это не жесткий список, он получился с помощью OData из базы 1С. Если нужно добавить сюда новый вид заявления, его создадут в базе 1С, и он тут сразу же сам появится. Таким образом, можно регулировать наполнение сайта.
Давайте посмотрим, что такое «Простое письменное обращение». Обратите внимание, что при создании здесь с помощью системы автозаполнения все основные поля сразу подставились. Здесь есть поля, которые имеют тип даты, есть строки и т.д. В поле адреса используется интересный механизм ввода – подключенный бесплатный веб-сервис по работе с КЛАДР.
И главное, к заявке можно подвязать произвольное количество файлов – все это отрабатывается библиотеками Битрикса.
А теперь я расскажу, как это выглядит в 1С.
Если я хочу создать новый шаблон заявки, я захожу в справочник «Шаблоны заявок».
Свой шаблон заявки я назову «Test». Перехожу на закладку «Вопросы».
На закладке «Вопросы», так как мы работаем с системой «Анкетирование», надо создать раздел, например, свой первый раздел я назову «Данные физического лица».
И добавляю в этот раздел несколько простых вопросов (полей для заявки) – «ФИО», «Адрес прописки» и т.п. Можно поставить длвя вопроса флажок «Обязательный». Заметки – это комментарии, которые могут отображаться на сайте.
Заполняю связанный «Элементарный вопрос» – вызываю диалог выбора.
Здесь я выбираю из справочника «Вопросы для заявок» какие-то похожие созданные до этого вопросы (в данном случае, элемент «Адрес прописки»). Готово.
Вот так заявка «Test» наполняется разделами.
Я ее записываю, она появляется в справочнике.
Но она не появится на сайте, пока я не скажу, что она должна пойти в работу. Для этого я захожу в документы «Вид заявок» и создаю новый вид заявки.
В поле «Шаблон заявки» выбираю шаблон «Test», в поле «Действует с» могу заполнить дату, а могу не заполнять – в этом случае ограничение на дату действовать не будет. Нажимаю «Провести и закрыть».
Давайте проверим на сайте, появился ли у нас новый вид заявки. Вот, пожалуйста – новый вид заявки «Test».
Вывелся раздел «Данные заявителя – физического лица», и в нем наши поля. Заполняем их и отправляем. Теперь у меня в 1С появится документ, с которым уже операторы могут продолжить работать.
Вот таким образом накидываются любые разделы. Мы отдали им инструмент в руки, и они сами его развивают. Мы не заморачиваемся, т.к. сделали универсальный механизм.
Я уже говорил, что список видов документов формируется по списку шаблонов заявок в базе данных 1С.
Вот так выглядит настройка полей, из которых мы «накидываем» заявку – это элементы справочника «Вопросы для заявок».
Вот так эти поля выглядят на сайте.
Я хотел бы обратить внимание на то, что полю «Адрес регистрации» мы задали специальный тип «КЛАДР». Он так и называется.
Если в 1С указывается, что тип этого поля – КЛАДР, то он начинает работать с бесплатным сервисом kladr-api.ru. При вводе улицы сервис подыскивает имеющиеся номера домов в этом городе, тем самым правильно вводится адрес. Вещь очень удобная, потому что корректный адрес очень важен для коммунальщиков.
Есть тип данных «Выпадающие списки».
Есть даже целые таблицы, которые можно заполнять – здесь есть кнопка «Добавить строку».
Эти таблицы создаются с помощью табличных вопросов в 1С.
Все заполненные заявки будут сохранены в справочнике «Анкеты» в его табличной части из пяти колонок.
Это – немного кода, который дал мне вебер – можно посмотреть, что он тут делает.
Через OData он обращается к структуре этой анкеты и каким-то образом выводит ее поля. Здесь можно увидеть, как он реализует выпадающие списки – с помощью OData сначала получает описание анкеты, а потом уже ее отрисовывает.
С чем мы столкнулись?
- Во-первых, инструмент для отладки. Рекомендую консоль запросов для OData //infostart.ru/public/667294 – отличный инструмент. Мы, 1С-ники, именно на нем написали все запросы и отдали веберу.
- Некоторые возможности OData работают в платформе, начиная с версии 8.3.8.1652 – это надо иметь в виду, чтобы ничего не отваливалось. В этой версии добавили:
- Отбор к полям по составным типам;
- Сортировку;
- Отличный оператор expand, который позволяет делать то, чего в OData нет – это разыменование. Когда я хочу вытянуть ИНН, КПП, то мне в 1С надо ставить точку, а это – аналог. Expand сразу включает в готовый запрос какие-то поля из других объектов.
- Чего не хватило в логике OData, так это ввода на основании. Мне бы хотелось, чтобы при создании этих заявок в 1С я мог бы их сразу заполнить значениями по умолчанию и вернуть веберу на сайт уже заполненный объект. Такой возможности в OData нет, поэтому нам пришлось немного извратиться через веб-сервисы.
Я по этому поводу даже написал в 1С. Они, как всегда, ответили: «Спасибо, запишем пожелание».
Мы хотели сделать, как в госуслугах, чтобы при создании документа он у нас уже высвечивался заполненным. Он и сейчас у нас высвечивается заполненный, но это пришлось сделать через отдельный веб-сервис. Все данные по заполнению берутся из настроек физлица. Там есть справочник «ФизЛицо», где все это заполнено – все в базе 1С, на сайте ничего нет.
С файлами мы не стали рисковать, т.к. они могут быть большие. Люди своими iPhone нафотографируют и будут нам паспорта по 10 мегабайт присылать. Поэтому:
- Сделали ограничение до пяти мегабайт на каждый файл. И даже количество файлов ограничили – на один блок 20 файлов.
- И грузить их не стали через OData, потому что в случае сбоя загрузки можно потерять весь введенный документ.
Реализовали подход:
- Сначала Битрикс загружает файлы в кэш к себе на сайт.
- Через OData в базу 1С отправляется документ, в табличной части которого содержатся HTTP-ссылки на эти закэшированные файлы.
- В базе 1С каждую минуту крутится регламентное задание, где внешняя обработка начинает эти файлы подтягивать.
- Эта внешняя обработка через подсистему «Файлы» складывает их в тома на диске. Ни в коем случае не в базу 1С, а именно в тома на диске, потому что таких файлов очень много. И ссылки на итоговые файлы в томах записываются в табличную часть «Анкеты».
- В результате, за пару минут эти файлы в любом случае из кэша забираются и после этого удаляются с сайта.
- Но даже если файлы с сайта еще не скачались, мы реализовали, что оператор по кнопке может в принудительном порядке начать их скачивать.
Вот так у нас выглядит раздел «Загружаемые файлы» для одного из видов заявок.
Теперь немного про нативное мобильное приложение – нужно оно или нет. Если кто-то заходил на сайт Ставропольского водоканала, то вы видели, что дизайн адаптивный, на телефоне все хорошо отображается. Поэтому встает вопрос – нужно ли нам нативное мобильное приложение? И почему именно нативное, а не на 1С?
1С позиционирует свое мобильное приложение для работы внутри предприятия, чтобы раздать своим сотрудникам. А здесь могут быть десятки, сотни тысяч абонентов, поэтому речь идет о том, что нужно свое приложение, со своей иконкой.
В чем преимущества нативного мобильного приложения?
- Некоторые вещи неудобно выбирать из браузера, потому что его нужно открыть и перейти на сайт.
- При заходе в «Личный кабинет» нужно логиниться – браузер может запомнить данные, а может и забыть.
- И мы обратили внимание на некоторые особенности работы с нашим сайтом из браузера. Например, на iPhone X файлы с камеры не грузились, а на iPhone 8 все отлично. Поэтому с работой встроенных функций в браузере у нас возникли проблемы.
В итоге наш отдел, который занимается мобильными приложениями, все-таки разработал решение для Android и iOS. Его можно скачать через GooglePlay и через iTunes. Приложение называется «Ставропольский водоканал».
Это приложение не является отдельным самостоятельным приложением, написанным с нуля, потому что разработчики взяли за основу наш сайт и сделали отображение того, что есть на сайте. Как только на сайте появится какая-то функциональность, она появится и в мобильном приложении. Получился такой конструктор – буквально, настраиваешь в Битриксе один конфигурационный файл, и все элементы сразу появляются.
Технология разработки клиентского приложения – Xamarin, в качестве сервера используется наш Битрикс, обмен через JSON.
Пока что приложение не поддерживает push-сообщения, но мы планируем это реализовать.
Вот так выглядит мобильное приложение. У него та же функциональность.
Можно точно так же вывести квитанцию, файл тоже скачивается.
У нас еще реализованы интернет-платежи (эквайринг), т.е. человек может заплатить через «Личный кабинет», никуда ходить не надо – передал показания, заплатил.
- Платеж мгновенный;
- Заключен договор эквайринга со «Сбербанком» и можно производить оплату по любой банковской карте;
- Сам платеж осуществляется не у нас – это происходит на странице «Сбербанка»:https://securepayments.sberbank.ru/payment/merchants/rbs/payment_ru.html;
- Дальше пробивается чек через онлайн-кассу. Сейчас согласно 54-ФЗ, те, кто принимает деньги в личных кабинетах, тоже должны использовать эти кассы. Многие пока не обращают на это внимания, но у нас уже есть опыт. Мы интегрировались с облачными кассами Atol – платеж по «Сбербанку» проходит по банковской карте, сразу идет запрос в Atol, пробивается чек и отправляется на почту в электронном виде. Можно было поставить свой аппарат, но за ним надо ухаживать и т.д. А здесь ухаживать не нужно.
Почему свою конфигурацию мы сделали на базе БСП?
- В БСП есть функциональность по отправке SMS. Мы используем провайдер sms.ru.
- Также мы используем e-mail-уведомления. Как только заявку обработали, пользователю сразу отправляется электронное письмо о том, что заявка обработана – придите, ознакомьтесь. Поэтому БСП, БСП и еще раз БСП.
- Также мы внедрили у себя Telegram-боты. Работают очень быстро. Например, я в Telegram набираю команду, и мне приходит информация.
Я могу спросить:
- Какие вопросы/ответы задавались по моему логину.
- Зная номер вопроса, я могу прочитать его содержимое.
Это администраторские фишки – не для пользователей. Это для того, чтобы можно было получать информацию, не находясь в офисе.
На этом развитие не останавливается, нашим клиентам все время что-то требуется, жизнь меняется:
- Электронная подпись в документе в браузере. Чтобы придать документам юридическую значимость, Правительство Российской Федерации заставляет подписывать документы квалифицированной электронной подписью. Сейчас эта функциональность постепенно повсюду внедряется. Другой вопрос – как этим пользоваться? Для людей эта подпись будет стоить тысячу или полторы тысячи рублей в год. И я, честно говоря, не понимаю, почему наше электронное правительство не возьмет эти затраты на себя. Например, чтобы передать в водоканал какой-то документ, который потом пойдет в министерство, нужна квалифицированная электронная подпись – КриптоПро и вся его обвязка. С другой стороны, когда мы подготовим какой-то документ в ответ, нам тоже надо его подписать. Будем разбираться, как подписать электронной подписью договор на подключение к воде, чтобы отдать его на сайте человеку – вот, ваш договор готов, скачивайте, забирайте. Мы не предполагаем, что нам для этого понадобятся какие-то операторы ЭДО. У нас – не счета-фактуры, не акты, а абсолютно произвольные документы.
- Аутентификация через сайт gosuslugi.ru. Сейчас это модная тема, все там регистрируются. А если зарегистрировались, то пусть и в наш «Личный кабинет» заходят через эту учетную запись.
- Еще параллельно идут проекты по автоматизации колл-центра, IP-телефонии, диспетчерских, аварийных. Заказчики хотят видеть на карте, где сейчас находятся машины их служб с помощью геолокации и т.д. У наших клиентов столько бывает фантазии, что надо останавливать.
Обращу внимание, что вы у себя можете реализовать то же самое. Это – не бухгалтерский налоговый учет, это ваше, то, чем вы можете спокойно заниматься. Главное – выявить потребность и начинать ее закрывать. На одном попробовать – научиться, на втором уже пойдет проще.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.
