Возможность интегрировать облачную 1С определяется не тем, что она в облаке, а моделью размещения. Их три: сервис по подписке на общей платформе провайдера, аренда виртуального сервера с вашей собственной 1С и своя виртуальная машина, которую вы администрируете сами. В первой почти ничего из привычного инженеру недоступно, во второй доступно почти всё по заявке, в третьей — всё то же самое, что на своём сервере в офисе.
Практическая разница выглядит так: в подписной модели вам не дадут опубликовать собственный HTTP-сервис, то есть у внешней системы не будет адреса, по которому она могла бы постучаться в вашу 1С. Дальше всё строится вокруг обхода этого ограничения, и обход стоит денег — в модельном расчёте ниже на 44 % дороже разово по тем же самым работам.
Разбираем: три модели и что доступно в каждой, что именно запрещено в подписной, четыре обходных пути с их платой, смету одной и той же связки в трёх вариантах размещения и шесть вопросов провайдеру, которые задают до переезда, а не после. Ставка в расчётах — 3 500 ₽/час, как в остальных материалах этого раздела.
Три модели размещения и что доступно в каждой
Слово «облачная 1С» продаётся как один продукт, а на деле обозначает два-три разных. Сравнение по стоимости владения самой системой — лицензии, администрирование, резервные копии, обратный переезд — мы делали в материале про облачную 1С и свой сервер. Здесь смотрим только на один вопрос: какие способы обмена в каждой модели работают.
| Модель размещения | Конфигуратор и расширения | Свои HTTP-сервисы | OData | Файл базы и СУБД | Кто решает, когда обновлять конфигурацию |
|---|---|---|---|---|---|
| Сервис по подписке на общей платформе | Конфигурация типовая, конфигуратор ограничен, расширения — по правилам провайдера | Как правило нельзя | Только если включён провайдером, часто с лимитом запросов | Доступа нет, выгрузка базы по регламенту провайдера | Провайдер, по своему расписанию |
| Аренда виртуального сервера с вашей 1С | Есть, расширения свои | Можно, по заявке провайдеру: порт, сертификат, публикация | Включается вами | Обычно есть, объём прав определяется договором | Вы, в согласованное окно |
| Своя виртуальная машина или свой сервер | Полный доступ | Можно, без согласований | Включается вами | Полный доступ | Вы |
Вторая и третья строки для интегратора почти неразличимы: разница только в том, что публикацию сервиса и открытие порта в аренде делает не он, а инженер провайдера по заявке — это плюс несколько дней ожидания и 4–8 часов переписки. Настоящая граница проходит между первой строкой и остальными. Какие вообще бывают механизмы обмена у 1С и чем они отличаются по цене, разобрано в материале про способы обмена с 1С.
Сравнение в три колонки. Левая «Сервис по подписке»: пять строк с отметками — «Свои HTTP-сервисы: нельзя», «OData: если включит провайдер», «Файл базы и СУБД: нет», «Расширения: по правилам провайдера», «Обновление конфигурации: по расписанию провайдера». Средняя «Аренда сервера с 1С»: те же строки с отметками «по заявке», «да», «обычно да», «свои», «в ваше окно». Правая «Своя виртуальная машина»: все пять «да» и «вы». Между левой и средней колонкой проведена жирная вертикальная граница с подписью «здесь начинаются обходные пути». Чертёжный стиль, подписи по-русски.
Что запрещено в подписной модели и почему это дорого
Ограничения подписной модели логичны: платформа общая, на ней живут сотни компаний, и произвольный код одной из них не должен влиять на остальных. Проблема не в самих запретах, а в том, что о них узнают после переезда, когда смета на интеграцию уже согласована по обычным расценкам.
- Публикация собственных HTTP-сервисов. Это главный запрет. Без него у 1С нет входящего адреса, и внешняя система не может передать в неё заказ в момент его появления. Всё, что в обычном проекте делается одним методом на 14–18 часов, приходится заменять связкой «шлюз снаружи плюс опрос изнутри».
- Доступ к файлу базы и к СУБД. Отсюда невозможны реплика базы и прямая ночная копия, а значит, отпадает целый способ построения аналитики. Что остаётся и сколько это стоит, разобрано в материале про выгрузку данных из 1С для аналитики: в подписной модели живут только OData и регламентная выгрузка.
- Произвольные внешние компоненты и обработки. Всё, что требует установки своего кода на стороне платформы, проходит согласование провайдера, а часть не проходит вовсе. Это бьёт по интеграциям с оборудованием: сканеры, весы, кассы, терминалы сбора данных.
- Своё расписание обновлений. Конфигурация обновляется по календарю провайдера. Обмен, который ломается на релизе, ломается в момент, который выбрали не вы; сколько стоит адаптация и как к ней готовиться, разобрано в материале про обновление, которое сломало обмен.
Обходные пути: инициатива изнутри вместо входящей точки
Общий принцип всех обходов один: если снаружи в 1С постучаться нельзя, значит, 1С должна стучаться наружу сама. Исходящие запросы из регламентного задания в подписных сервисах обычно разрешены — иногда с белым списком адресов, который надо согласовать заранее. Дальше вопрос только в том, кто и где держит очередь.
- 1Опрос изнутри. Регламентное задание в 1С раз в несколько минут делает исходящий запрос к вашему шлюзу: «есть ли новые заказы». Шлюз отвечает пакетом, 1С создаёт документы и той же процедурой возвращает статусы. Это основной рабочий вариант, и на нём держится большинство связок с подписной 1С.
- 2Шлюз с очередью на своём хостинге. Небольшой сервис, который принимает данные от CRM или сайта, складывает их в очередь, отдаёт по запросу 1С и ведёт журнал с повторными попытками. Он же обеспечивает защиту от повторной обработки одного и того же заказа — без неё опрос по расписанию рано или поздно создаст дубли.
- 3Регламентная выгрузка файлами. 1С по расписанию кладёт файл со справочниками, остатками или отчётом в облачное хранилище или на FTP, снаружи его разбирают. Дёшево и надёжно для того, что не требует срочности, и совсем не годится для заказов и резервирования.
- 4Готовые коннекторы и типовые обмены. Обмен с сайтом по CommerceML, 1С-ЭДО, банк-клиент, обмен с маркетплейсами через сервис провайдера — если ваша задача попадает в типовой сценарий, это самый дешёвый путь, и проверять его надо первым. Половина запросов «нам нужна интеграция» закрывается здесь без единой строки кода.
Опрос по расписанию не даёт мгновенной реакции: заказ появляется в 1С не в момент оформления, а на ближайшем цикле. Для заказов с сайта и передачи статусов это обычно приемлемо. Для резервирования дефицитного товара — нет: за десять минут два клиента успевают купить одну последнюю позицию, и вы получаете пересортицу вместо продажи. Если оборачиваемость высокая, подписная модель здесь просто не подходит, и это выясняется до подписания договора, а не после.
Схема из трёх блоков. Слева «CRM или сайт», стрелка вправо «передаёт заказ» в средний блок «Шлюз на вашем хостинге: очередь, журнал, защита от повторов». Справа блок «Облачная 1С по подписке». Между шлюзом и 1С две стрелки: верхняя, направленная в 1С, перечёркнута с подписью «входящей точки нет — публикация HTTP-сервиса запрещена»; нижняя, направленная из 1С к шлюзу, живая, с подписью «регламентное задание опрашивает раз в 5 минут и возвращает статусы». Внизу подпись «задержка 1–15 минут вместо секунд». Чертёжный стиль, подписи по-русски.
Смета: одна и та же связка в трёх моделях
Считаем одинаковую задачу для модельной компании: 1С:УТ 11, связка с CRM, заказы идут в 1С, статусы и оплаты возвращаются обратно, около 400 заказов в месяц. Меняется только модель размещения — состав работ по существу тот же.
Та же связка на своей виртуальной машине занимает 64 часа — 224 000 ₽: контракт данных 10 часов, два HTTP-сервиса 28 часов, публикация и права 10 часов, журнал 8 часов, приёмка 8 часов. Отдельного шлюза с очередью не нужно, потому что у 1С есть собственный адрес. В аренде сервера добавляется 6 часов на заявку провайдеру, сертификат и открытие порта — 70 часов и 245 000 ₽. Как эта смета устроена целиком и почему одинаковая задача стоит по-разному, разобрано в материале про цену интеграции с 1С.
| Модель размещения | Разово | Эксплуатация в месяц | За 36 месяцев |
|---|---|---|---|
| Своя виртуальная машина — 64 часа | 224 000 ₽ | 12 000 ₽ | 656 000 ₽ |
| Аренда сервера с 1С — 70 часов | 245 000 ₽ | 12 000 ₽ | 677 000 ₽ |
| Сервис по подписке — 92 часа | 322 000 ₽ | 18 500 ₽ | 988 000 ₽ |
Разрыв — 332 000 ₽ за три года, и его важно правильно интерпретировать. Облако выигрывает на владении самой 1С: в расчёте на 10 пользователей разрыв в его пользу за 36 месяцев составлял 503 000 ₽. Одна связка с CRM съедает из этого выигрыша 332 000 ₽, оставляя 171 000 ₽. Две связки — и подписная модель оказывается дороже. Поэтому решение о размещении принимают, уже зная список интеграций, а не наоборот.
Три составных вертикальных столбика, ось в рублях до 1 000 000. Первый «Своя виртуальная машина»: нижний сегмент «разово 224 000 ₽», верхний «эксплуатация 12 000 ₽ × 36 = 432 000 ₽», итог «656 000 ₽». Второй «Аренда сервера с 1С»: «245 000 ₽» и «432 000 ₽», итог «677 000 ₽». Третий «Сервис по подписке»: «322 000 ₽» и «18 500 ₽ × 36 = 666 000 ₽», итог «988 000 ₽». Справа вертикальная скобка между первым и третьим столбиком с подписью «332 000 ₽ разницы за 3 года». Внизу подпись «одна и та же связка 1С и CRM, 400 заказов в месяц». Чертёжный стиль, подписи по-русски.
Шесть вопросов провайдеру до переезда
Один звонок в поддержку провайдера снимает почти все сюрпризы. Ответы стоит получить письмом и приложить к техническому заданию — тогда подрядчик по интеграции считает смету по фактам, а не по предположениям.
- 1Можно ли опубликовать собственный HTTP-сервис? Если да — по какой процедуре, за какой срок и за какие деньги. Ответ «в принципе можно, напишите заявку» стоит уточнить до конкретного числа дней.
- 2Включён ли OData-интерфейс, на какие объекты конфигурации он открыт и есть ли ограничение по числу запросов в минуту или в сутки. Лимит определяет, годится ли OData для аналитики или только для точечных обращений.
- 3Разрешены ли исходящие HTTP-запросы из регламентных заданий и нужен ли белый список адресов. Это ключевой вопрос: на исходящих строятся все обходные пути, и запрет на них закрывает тему интеграции целиком.
- 4Можно ли ставить свои расширения и внешние обработки, кто их проверяет и сколько занимает согласование. Отдельно спросите про внешние компоненты, если у вас есть торговое или складское оборудование.
- 5Есть ли доступ к файлу базы или к СУБД, а если нет — в каком формате и за какой срок отдают выгрузку базы по запросу и при уходе. Это одновременно вопрос про аналитику и вопрос про то, чем закончится расставание с провайдером.
- 6Кто и как часто обновляет конфигурацию, за сколько предупреждают и есть ли тестовая копия, на которой можно проверить обмен до релиза. Отсутствие тестовой копии означает, что каждую поломку обмена вы будете обнаруживать на боевой базе и в рабочее время.
Шестой вопрос — самый недооценённый. В своей инфраструктуре обновление конфигурации планируют: выбирают окно, прогоняют чек-лист, держат наготове откат. В подписной модели релиз приезжает по календарю провайдера, и если обмен после него встал, вы узнаете об этом по отсутствию заказов. Как поставить наблюдение, чтобы узнавать за сорок минут, а не за неделю, разобрано в материале про то, почему отваливается обмен с 1С.
Когда модель размещения не имеет значения
Всё написанное выше касается собственных интеграций. Есть три ситуации, в которых модель размещения не влияет ни на что и переплачивать за аренду сервера ради «свободы доступа» не нужно.
- Задача закрывается типовым механизмом. Обмен с сайтом по CommerceML, электронный документооборот, банк-клиент, обмен с маркетплейсами через сервис провайдера — всё это одинаково работает в любой модели, потому что реализовано внутри самой конфигурации. Проверять типовой сценарий надо первым: он бесплатен и уже поддерживается вендором.
- Обмен односторонний и не требует срочности. Ночная выгрузка справочников, отчётов или прайса файлом в хранилище работает везде и стоит одинаково. Разница между моделями начинается там, где нужен двусторонний обмен с реакцией в секундах.
- Через связку идёт меньше 50 документов в месяц. Шлюз с очередью и журналом стоит одинаково при 50 и при 500 документах, поэтому на малом потоке не окупается ни в какой модели: дешевле вводить руками и вернуться к вопросу, когда объём вырастет втрое.
И последнее. Список интеграций — такая же часть решения о размещении, как число пользователей и требования к резервным копиям. Составлять его надо до переезда: обратный путь стоит дороже прямого.
Облако экономит на администрировании и берёт своё на интеграциях. Считать надо обе стороны сразу, а не по очереди.
