битрикс 24 создать приложение

Создание приложения для Bitrix24 с нуля

Для расширения функциональности Bitrix24 удобно использовать приложения. В данной статье описано создание с нуля локального serverless приложения.

Для установки нашего приложения нам понадобится собственно портал bitrix24, в котором мы обладаем правами администратора или правом установки и редактирования приложений.

Если такого портала нет — создать его можно здесь.

Здесь нам нужно будет остановится, так как добавлять пока нечего. Оставим вкладку браузера открытой и приступим к созданию нашего приложения.

Официальная javascript-библиотека

Создадим папку с произвольным названием и в ней единственный пока файл index.html со следующим содержанием (исходный код):

Помещаем файл index.html в zip-архив и указываем этот архив в качестве значения поля Загрузите архив с вашим приложением (zip)* в диалоге создания приложения.
Затем нажимаем кнопку «Сохранить»

Посмотрим, что у нас получилось.

Кликаем по Перейти к приложению и видим… пустое место на месте нашего приложения.

Все необходимое для нас на данном этапе находится сейчас в консоли разработчика.

Мы видим, что наше приложение успешно получило данные необходимые для авторизации.

Официальная javascript-библиотека c promise

Использование callback-функций имеет свои преимущества, но не всем нравится или не всегда подходит к ситуации.
Поэтому попробуем получить тот же результат в promise-стиле. Для этого изменим наш index.html (исходный код)

Опять архивируем, опять обновляем наше приложение, опять смотрим, опять все работает.

Инструменты разработки

В папке нашего проекта инициализируем npm:

Установим необходимые пакеты:

Состояние проекта после всех изменений можно посмотреть здесь.

Создадим в корне нашего проекта файл server.js

Создадим папки src и public
В папку public перенесем index.html и изменим его содержимое на:

В папке src создадим файлы

Если package.json еще не создан, выполним:

Добавим скрипты в package.json :

Далее так как и команда start и команда watch не заканчиваются, их нужно запускать параллельно. Для этого в двух командных строках запускаем

Завершим настройку среды разработки редактированием нашего приложения в Bitrix24.
Перейдем в диалог редактирования нашего приложения и укажем в поле
Укажите ссылку* значение http://127.0.0.1:3000/

Перейдите к просмотру вашего приложения:
Вы должны увидеть приветствие с именем текущего пользователя:

Если использовать официальную библиотеку, то отличаться будут только два файла:

Итоговый код проекта для использования официальной библиотеки здесь.

Ознакомиться со всеми возможными методами и возможностями API можно здесь.

Исходный код можно увидеть здесь.

И последнее замечание. Описанные выше способы и методы не являются набором лучших практик. Это скорее предложение к конструктивному обсуждению.

UPD: желающих высказаться о 1С-Битрикс или Битрикс24 прошу сделать небольшое интеллектуальное усилие и осознать, что статья не о Битрикс24 и совсем не о 1С-Битрикс.
Это если в Питере прохожий объясняет другому, как пройти к Петропавловской крепости и тут третий вмешивается с репликой:
«Да тиран был ваш Петр I. Тиран и деспот. И усы у него дурацкие».

Если есть конструктивные замечания к коду в СТАТЬЕ или к подходам или к используемым паттернам — добро пожаловать.

Источник

Мы уже больше года рассказываем о приложениях для Битрикс24. Наши эксперты изучили и подготовили обзоры более 130 приложений! Если вы еще не видели эти обзоры, крайне рекомендуем ознакомиться, наверняка вы найдете для себя что-то интересное. Все обзоры приложений собраны тут. Сегодня мы решили копнуть глубже и рассказать не просто про готовые приложения, а про процесс разработки приложений для Битрикс24. Наша команда регулярно создает приложения, которые помогают решать различные задачи клиентов, так что нам есть, что рассказать.

С чего начинается приложение?

Из сказанного получается, что в качестве примера можно взять простую задачу и на ней провести анализ самого процесса разработки, составных частей программы, выполняемых подзадач, необходимых для ее эксплуатации в дальнейшем. В качестве такого примера я возьму интеграцию СМС-провайдера с порталом Битрикс24. В голове я при этом буду удерживать конкретное приложение, конкретную интеграцию, подглядывать в его логи и код, но для общего анализа совсем не важно, чего с чем оно действительно интегрирует.

Еще немного о приложении. Существует несколько способов работы с порталом Битрикс24. Здесь речь пойдет о приложении с пользовательским интерфейсом и размещаемом на стороннем сервере. Таким образом, в интеграции будет участвовать как минимум три сервера: портала, нашего приложения и СМС-провайдера.

Итак, поставлю задачу.

СМС-провайдер предоставляет API для отправки СМС-ок, отслеживания текущего статуса конкретного СМС-сообщения, получения сведений об аккаунте и текущем балансе пользователя. С другой стороны, портал Битрикс24 имеет API для регистрации СМС-провайдера, смены статуса отправленного сообщения, а также дает зарегистрированному провайдеру команду на отправку конкретного СМС. Наша задача связать одно с другим так, чтобы, например, при смене статуса у сделки в CRM кому-то отправлялось СМС-уведомление, а при изменении его статуса у СМС-провайдера менялся соответственно статус сообщения на портале.

Выделим подзадачи из этой общей. В итоге получим такие точки входа в приложение:

Теперь настройки. В данном приложении они совершенно необходимы, поскольку для взаимодействия с СМС-провайдером нам потребуются авторизационные данные. Это может быть т.н. API Key или логин и пароль или, как предпочитают делать в последнее время, логин и API Key вместо пароля. Эти данные мы можем получить лишь от самого пользователя, установившего приложение. Отмечу сразу, что для нашей задачи не требуется спрашивать ключи от каждого пользователя портала, одной авторизации будет достаточно. Итак, необходимо вывести на странице форму с полями ввода, в которых указать текущие значения, если они уже есть. Будет также неплохо дать возможность здесь же сразу проверить их валидность, предоставив возможность отправки тестового СМС-сообщения.

Обработчик. При описании настроек я забыл упомянуть еще об одном, спрятанном в backend действии в случае, когда авторизационные данные первый раз получены и проверены на валидность. Это регистрация на портале СМС-провайдера. При его регистрации мы указываем среди прочего URL обработчика команды на отправку сообщения. И в данной точке входа (handler) мы получаем набор параметров, среди которых есть само сообщение, а также номер телефона, на который оно должно быть отправлено. Задача обработчика постучать с этими данными (используя авторизацию, сохраненную в настройках) к СМС-провайдеру, вызывая некий его метод send и получая ответ об успешной или неудачной постановке в очередь на отправку. Когда она успешна, то нам вернется уникальный идентификатор сообщения у провайдера.

Ну, вот теперь все точки входа в наше приложение вкратце описаны, выяснены действия, какие необходимо выполнить, и данные, которые необходимо где-то у себя хранить. Было бы неплохо их еще раз перечислить отдельно от описания точек входа. Итак:

Хранилище данных требует пояснений. Например, почему всюду дублируется домен и id портала. Ну. домен, потому что так удобнее просматривать и фильтровать записи при осуществлении технической поддержки, а MEMBER_ID. можно, конечно, привязку сделать по первичному ключу с данными из п.1 (Сведения о портале). Но и выборки придется делать всегда с джойном двух таблиц. Короче, я выбираю именно вариант с id портала в каждой таблице. Когда мы работаем с порталом, то у нас в наличии всегда именно member_id, он приходит с портала, и его же мы посылаем самим себе при обращении с фронта в бэк.

И еще одно важное замечание по поводу версий. Во всех местах программы, где вы указываете путь к приложению, а это URL обработчика событий, это URL для атрибута action формы настроек, это URL отправки тестового СМС из фронта в бэк, всюду URL должен формироваться динамически, исходя из текущего расположения приложения. Иначе при выпуске новой версии вам придется лазить по всему коду и заменять. Даже, если вынесете эти URL-ы в конфигурационный файл, всегда можно что-то пропустить. Динамическое формирование URL-ов самое правильное.

Теперь REFRESH_DATE_END в таблице пользователей. Токен, с которым мы стучимся на портал, живет лишь один час, а затем требует обновления через refresh_token, но у того самого (пока еще) есть собственный lifetime размером в 30 дней. Чтобы не потерять возможность делать запросы от лица каждого пользователя, мы обязаны отслеживать момент окончания валидности и делать обновление. По данному полю мы определяем такую необходимость. Вот поэтому я и вынес авторизацию пользователей в отдельное хранилище, поскольку по нему придется периодически пробегать, обновляя токены. Ну и с точки зрения построения баз данных это правильнее. И еще замечание по токенам. Если приложение размещается не на вашем сервере, а может, даже и в этом случае, токены следует хранить в зашифрованном виде.

Итак, после перечисления всех данных мы обнаруживаем, что список наших действий необходимо дополнить пунктом 16.

16. Обновление refresh_token-ов, у которых срок жизни приближается к 30 дням, раз в сутки.

Ну вот, теперь и действия все прописаны и данные описаны. Можно переходить к следующему шагу и рассмотреть каждую точку входа подробнее. Примечание, я не стану говорить об архитектуре приложения, поскольку тут многое зависит и от языка программирования, и от сложившейся практики у конкретных разработчиков. Речь только о построении приложения без специфических языковых особенностей.

Источник

На прошлой неделе мы начали рассказывать о том, как разрабатываются приложения для Битрикс24. В первом выпуске мы определили, с чего начинать разработку, а также описали основные задачи, выполняемые приложением, и данные, которые будут использоваться для этого. Если вы не читали первую часть, рекомендуем начать именно с нее, чтобы у вас была полная картина разработки.

Начинаем разработку

Схема 1. Установка приложения

Сохраняем в лог запрос с портала

Пробуем получить ранее сохраненные о портале данные

Есть ли запись о портале?

фиксируем факт установки в логах

формируем поля для новой записи

фиксируем в логах значения полей

добавляем новую запись

фиксируем в логах результат добавления

формируем запрос для подписки на событие OnAppUninstall

отсылаем запрос на портал

фиксируем в логах запрос и результат выполнения

фиксируем факт обновления в логах

формируем поля для обновления записи

фиксируем в логах значения полей

обновляем старую запись

фиксируем в логах результат обновления

формируем запрос на текущий список наших подписок на события

отсылаем запрос на портал

фиксируем в логах запрос и результат выполнения

инициализируем массив под батч-запрос

собираем в массив запросы на удаление старой подписки

если массив не пустой, отправляем запрос на портал

фиксируем в логах запрос и результат выполнения

формируем запрос для новой подписки на событие OnAppUninstall

отсылаем запрос на портал

фиксируем в логах запрос и результат выполнения

Выводим страницу пользователю

подключаем js-библиотеку портала

Я расписал всю логику без какой-либо оптимизации. Некоторые авторы так и рекомендуют делать: вначале писать все подряд, добиваться рабочего кода, а уж только затем приступать к оптимизации. Кажется, Фаулер говорил, что нельзя одновременно писать код и по ходу дела оптимизировать, нужно разделять на два этапа. Теперь же, глядя на то, что у нас получилось, можно заметить, что у нас один, по крайней мере, код выполняется в обеих ветках условия, а именно подписка на событие. Что ж, можно его вынести за рамки условия и удалить из обеих веток. Однако, в действительности алгоритм будет куда сложнее, поскольку в этом автор проживает в сказочном мире, где все всегда заканчивается хорошо. К сожалению, он в этом не одинок. Для начала создадим переменную errors и проинициализируем массивом.

Вопрос об обработке ошибок настолько важен, насколько часто упускается из вида. Можем ли мы сказать порталу, что установка завершена, если нам не удастся подписаться на события или сохранить запись о портале? Вероятно, ничего уж такого критичного в плане основной задачи приложения не произойдет, мы лишь не сможем потом определить факт обновления и не сможем почистить таблицы от данных портала, на котором приложение было удалено. И все-таки факт того, что написано кривовато, привяжется навсегда к приложению в наших головах, повысит уровень адреналина, снизит стрессоустойчивость. Короче, самим же хуже будет. А потому давайте решать, что завершать установку при наличии подобных ошибок нельзя ни в коем случае.

Схема 2. Вторая версия кода (конкретные действия спрятаны в вызовы функций):

Сохраняем в лог запрос с портала

Пробуем получить ранее сохраненные о портале данные

Есть ли запись о портале?

фиксируем факт установки приложения в логах

фиксируем факт обновления в логах

Выводим страницу пользователю

есть ли сообщение об ошибке?

подключаем js-библиотеку портала

Думаю, что все понятно, кроме вызовов createUserMessage() и rollBackIntstall().

Теперь по второму методу. С ним попроще: если мы зафиксировали у себя данные о портале (добавили или обновили), а ошибка произошла на этапе событий, то очевидно нам следует вернуть назад все, как было. Отсюда возникает задача запоминать выполненные действия и исходные данные. Либо, если все действия были связаны с базой данных, использовать транзакции.

Схема 3. Третья версия:

Сохраняем в лог запрос с портала

Пробуем получить ранее сохраненные о портале данные

Есть ли запись о портале?

фиксируем факт установки/обновления в логах

Выводим страницу пользователю

есть ли сообщение об ошибке?

подключаем js-библиотеку портала

Логика установки приложения теперь не вызывает вопросов. Но вызывает вопрос логирование. В коде указано, что мы логируем сам запрос с портала. Вот он:

здесь (не удивляйтесь только):

А я их, вроде как, рекомендовал шифровать при сохранении в базу. Если так рассудить, то нам и логировать-то его не нужно, поскольку все, что в нем содержится нам итак будет известно, разве что язык. В логи всегда попадет либо факт установки, либо ошибки при установке. Но в действительности запрос может приходить и не с портала вовсе, а из хакерского приложения. В таком случае зачем его вообще логировать? И по этом размышлении становится понятно, что непонятно, как приложение вообще защищено от левых запросов. В результате наш список действий дополняется еще одним пунктом:

17. Проверка валидности запроса извне.

В данном случае (при установке приложения) мы так и так делаем запрос на портал для получения дополнительной информации, вызывая app.info с переданным нам access_token (AUTH_ID). Какие возникают варианты ответа:

Причиной первого может быть формирование неверного УРЛ к rest-у портала, например, когда кто-то стукнулся на страницу установки напрямую и никакого домена в запросе нет или он неверный. Второй вариант. Все запросы в портал приложение должно, по-хорошему, не только выполнять через защищенное соединение (по SSL), но и с проверкой сертификата сервера, не допуская самоподписанные. При пустом теле ответа можно проверить код ошибки (http status code ответа), и, если до сервера достучаться не удалось именно из-за неверного сертификата, то об этом необходимо сообщить пользователю. Битрикс24 существует как облачный, так и коробочный, и здесь мы имеем дело, стало быть, с коробкой, размещенной на собственном сервере владельца.

На этом с установкой, пожалуй, все. Но на примере подписки хотелось бы чуть коснуться rest-запросов портала. REST Битрикс24 довольно неплохой. Да, порою требуемые для передачи параметры удивляют. Например, где-то регистр ключей имеет значение, а где-то не имеет. А есть еще и запросы, в которых все данные имеют соответствующие ключи, но, тем не менее, переданы должны быть в нужной очередности. Однако, в батч-запросах можно, формируя последовательность команд, из одной обращаться к данным, полученным из предыдущей. Это круто. Рассмотрим удаление подписки на события, оставшейся от прежней версии приложения. Для этого нам нужно получить наши старые обработчики, делаем запрос (команда, параметры):

получаем в результате что-то вроде:

Портал возвращает все прежние подписки нашего приложения. При переходе с версии на версию у нас меняется УРЛ, теперь он должен вместо v1 должен содержать v2.

if array res.result

foreach res.result as item

if not empty batch

if not empty res.result_errors

Как я уже сказал, я не вникаю в архитектуру приложения, и имена вызываемых функций здесь служат лишь для указания, какое действие выполняется в данный момент и какие данные оно использует. В этом коде мы точно уверены, что наши подписки никогда не превысят ограничения батч-запросов в 50 команд, но там, где это неочевидно, следует вставлять проверку. При этом нужно учитывать, что размер команд вместе с их параметрами (представьте обновление 5000 компаний или счетов за один раз) может составлять в байтах довольно большое число, так что не стоит собирать все команды в один массив, потом резать его по 50 штук, и затем отправлять эти нарезки на выполнение. Fatal error, cannot allocate memory могут быть запросто получены. Алгоритм обработки в данном случае должен быть иным. Пример в псевдокоде:

while row = getSomething()

if count batch equal 50

Ну, теперь и с установкой, и с запросами точно все.

Доставка полезной информации от экспертов по Битрикс24!

Подпишитесь, и раз в неделю у вас на почте будет подборка полезных советов и обзоров про Битрикс24

Источник

Создание приложений на базе Битрикс24

Поделиться в социальных сетях:

Ряд компаний, работая в Битрикс24, не находят в существующем функционале нужного способа решения своей задачи. Для расширения стандартного набора функционала Битрикс24 используются приложения. Компания Пинол уже много лет занимается разработкой приложений для Битрикс24. В этой статье мы решили рассказать о наших приложениях и о том, как они разрабатываются.

В портал Битрикс24 встроена богатейшая функциональность по управлению взаимоотношениями с клиентами и организации внутренних бизнес-процессов компании. Портал обладает большой гибкостью для самостоятельных настроек: добавления новых полей, редактирования стадий в воронках продаж и задач, установки прав доступа и т.д.

Но часто даже этой функциональности бывает недостаточно, чтобы решить определенные точечные проблемы автоматизации. Если организация не хочет уходить с облака и связываться с самостоятельным циклом разработки в рамках коробочной версии портала, то тогда верным вариантом является поиск приложения на Маркетплейс Битрикс24, которое может закрыть пробел в функциональности.

Технически приложение представляет из себя PHP и JavaScript код, обращающийся по REST API к данным Битрикс24 и используемый базовый интерфейс платформы. Код, как правило, размещается на сервере поставщика приложения, что позволяет поставщику решения быстро решить техническую проблему при прямом обращении к нему.

Группы приложений для Маркетплейс Битрикс24

Приложения можно условно разделить на две основные группы. Приложения первой группы добавляют новые функции самого портала, приложения второй группы обеспечивают дополнительные возможности интеграции. Компания Пинол разрабатывает приложения обоих видов.

К первой группе можно отнести наше приложение «Запись на прием к врачу», появление которого было вызвано необходимостью дать нашим клиентам – медицинским организациям – удобный и практичный функционал для бронирования времени врачей, ведущих прием пациентов.

Приложение создавалось в то время, когда в стандартном функционале CRM портала Битрикс24 отсутствовала возможность бронирования ресурсов и было в полном смысле этого слова незаменимым.

В начале этого года к данному приложению была добавлена мощная опция динамического расписания, позволяющая задавать разные интервалы приема врачей в зависимости от видов предоставляемых услуг.

Также данное приложение послужило «родителем» для других программ, в которых задействован учет ограниченных по времени ресурсов. Речь идет о решении управлении парком автотранспортных средств и записи клиентов в парикмахерские (барбершопы, салоны красоты).

Приложение постоянно развивается. Сейчас прорабатываются вопросы ведения ценообразования сделок исходя из сделанных записей на прием.

Алексей Окара,
Учредитель Пинол

К приложению второй группы можно отнести интеграцию с системой почтовых и SMS-рассылок UniSender. На момент разработки уже существовало подобное решение по почтовым рассылкам от конкурирующей компании, но оно страдало рядом недостатков, в частности, невозможностью растягивания картинок в шаблоне сообщения. В итоге, было выпущено более продвинутое решение, обладающее рядом изюминок, которых нет даже в выпущенном позднее типовом модуле CRM-маркетинг: возможности ведения рассылок по базе сделок, сотрудников, инициации отправки сообщений из бизнес-процесса.

Компания Пинол плотно работает с фирмой UniSender в том числе и по вопросам эксплуатации решения. В частности, дарит денежные бонусы клиентам, зачисляемые на аккаунт UniSender при регистрации приложения.

Мы вложили более миллиона рублей и сотни часов в разработку, чтобы создать удобное приложение с широким функционалом для интеграции сервиса UniSender с Битрикс24.

Аналогичным образом были выстроены партнерские отношения с системами онлайн-чатов LiveTex и заказа обратного звонка Callbackhunter, с которыми были сделаны интеграции.

Компания Пинол предлагает версии своих решений не только для Битрикс24, но и для других популярных CRM-систем: AmoCRM, bpm’online. Также мы подготовили удобное приложение Пинкит, обеспечивающее обмен данными Битрикс24 с различными приложениями.

Важно, что получить все эти решения с полным объемом функционала можно совершенно бесплатно просто приобретя платную подписку на облачное CRM-решение (или лицензию на коробочную версию) у компании Пинол.

В процессе эксплуатации решений у клиентов часто возникают пожелания по их доработкам. Например, к нам обратилась компания из Израиля с просьбой убрать галочку Согласия на обработку персональных данных в онлайн форме «Записи на прием к врачу», ибо эта галочка не требуется по локальному законодательству.

В таком случае, руководитель нашей компании принимает решение либо о включении этой опции в следующий релиз, что случается крайне редко, ибо требуется сбора существенного кворума лиц, заинтересованных в функционале, либо о заказной платной доработке под отдельно взятого клиента.

Порядок действий при разработке нового приложения

Если же речь идет о создании с нуля совершенно нового решения, например, интеграции Битрикс24 с ERP-системой отличной от 1С, то здесь имеет место следующий порядок действий:

Составление технического задания на решение – крайне ответственный момент, ибо в нем необходимо детально проработать логику, архитектуру, пользовательские интерфейсы будущего решения. Структура данного многостраничного документа следующая:

Выводы

Выпущенное решение может быть индивидуально предоставлено клиенту, а может быть выложено в публичный доступ на Маркетплейс. Мы поощряем именно последний вариант, ибо он позволяет разделить риски и бюджет создания решения с его другими потенциальными пользователями.

Если остались вопросы по созданию приложений в Битрикс24, задайте их в комментариях к данной статье. Если у Вас есть предложения по доработкам приложений или разработке нового, отправьте нам заявку на почту order@pinall.ru. Наш менеджер свяжется с вами в ближайшее рабочее время для согласования всех вопросов.

Заполните форму и мы проведем вам онлайн-встречу, где вы получите примеры реализации с кейсами внедрений:

Источник