Как сделать мобильное приложение битрикс

Обновлено: 23.01.2025

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

Как это сделать? Очевидно — доставлять и передавать всю нужную информацию тем же способом, которым мы привыкли это делать в эпоху смартфонов и планшетов. Не имеет значения, прилёг ты на минуту на диван, отошёл покурить, в туалет, едешь в метро или в автобусе — смартфон всегда с тобой. Да мы его из рук почти не выпускаем. В общем, если нужно достучаться до человека, то сделай так, чтобы он получил пуш-уведомление :)

Зачем приложение

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

В сравнении с веб-интерфейсом

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

И да, в комментариях к прошлым публикациям мы натыкались на негативные отзывы об iOS и Android приложениях Битрикс24, но не смогли их повторить у себя. Варианта тут два: либо мы начали активно пользоваться мобильными решениями Битрикс24 позднее, и к этому времени очевидные баги пофиксили, либо это тёмная магия.

Помимо исключительно рабочей деятельности, приложение помогает лучше организовывать коллектив благодаря календарю. То есть, можно сразу из единого интерфейса составить ясное представление о том, кто и в какие часы сегодня доступен. Для пользователей iPhone есть ещё одна приятность: календарь Битрикс24 полностью интегрируется с родным календарём iOS.

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

Кому нужно мобильное приложение

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

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

Ну и, конечно же, продажники — они общаются с клиентами, а клиенты бывают разные. Кто-то отвечает исключительно в рабочие часы и оперативно, а кому-то свойственно отвечать седьмой ночью с момента получения очередного письма. С приложением контролировать активность капризных клиентов и своевременно на неё реагировать куда проще.

На что похожа работа с Битрикс24 через мобильное приложение

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

Не по теме: о ценах

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

--> Всем привет, сегодня речь пойдет про собственные приложения для CRM Битрикс24.
Опыт в интеграции с этой CRM у меня не большой, но кое о чем рассказать могу.
И так, передо мной стояли 2 задачи:
1) Сделать выгрузку всех новых лидов из CRM в сервис email рассылки
2) Сделать страницу на которой отображалось количество поставленных задач в этом месяце с разбивкой по рабочим группам.

Сегодня расскажу про первую задачу, а про вторую как-нибудь в другой раз.

Важный момент, если Вы хотите использовать 2 или 3 тип то Вам нужен SSL, вот как звучит фраза с официального сайта:
На стадии разработки и тестирования приложения нет необходимости иметь сервер,подписанный SSL сертификатом. Вполне достаточно самоподписанного сертификата, если добавить его в исключения браузера.
Я себе делал бесплатно на startssl

Автоматизированный HR-сервис, доступ к которому имеют все работники, вне зависимости от того, имеют ли они закрепленное рабочее место или нет.

Агентство-исполнитель кейса

Заказать похожий проект:

1. Вводная задача от заказчика, проблематика, цели

Предыстория

На предприятиях компании трудятся в общей сложности более 20 тысяч человек. При этом более 70% сотрудников не имеют автоматизированного рабочего места и доступа в корпоративную сеть. Специалисты находятся на удалённых объектах. В этом случае единственный способ решить кадровые, социальные и другие вопросы — лично обратиться в специальное подразделение компании. Это увеличивает:

бумажный документооборот;
вопросы от заявителей о статусе обработки запроса;
специалистов кадровой службы;
неэффективное взаимодействие по кадровым вопросам.

Чтобы сократить трудозатраты и сделать процесс удобнее для сотрудников, заказчику требовалось автоматизировать HR-сервисы и дать доступ всем работникам вне зависимости от того: имеют ли они закрепленное рабочее место или нет.

Цели внедрения

Обеспечить сотрудникам доступ к единой цифровой платформе с помощью мобильных устройств
Повысить скорость и качество предоставления HR-сервисов благодаря приложению с соблюдением регламентов компании и законодательства РФ
Сократить расходы на документооборот, а также трудозатраты на оформление и получение услуг для сотрудников

Задачи

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Решения

Все внутренние HR-процессы в компании делятся на три больших блока:

Вознаграждение персонала
Кадровое администрирование
Административно-хозяйственное обеспечение

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

Эти и другие функциональные решения мы внедрили с помощью расширений типовой платформы. Они доступны для сотрудников через корпоративное приложение круглосуточно. Такое решение позволило сократить сроки запуска проекта.

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

Интеграции

3. Результаты сотрудничества

Благодаря приложению более чем у 70% сотрудников появилась возможность полноценно работать c HR-сервисами с помощью мобильных устройств на платформах Android и iOS. Пока приложение доступно в нескольких городах присутствия компании, но в будущем к системе будут присоединяться и другие подразделения.

4. Заключение

Благодаря приложению более чем у 70% сотрудников появилась возможность полноценно работать c HR-сервисами.

Агентство-исполнитель кейса

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

Руководитель отдела веб-разработки - Вадим Солуянов согласился поделиться своим бесценным опытом разработки приложений для интеграции сторонних сервисов с Битрикс24. Так как материал получился очень объемным, мы разделим его на 4 части, поэтому рекомендуем подписаться на нас в социальных сетях, чтобы ничего не пропустить. Описание работы над приложением будет вестись от лица Вадима. Итак, поехали!

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

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

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

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

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

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

install - установка приложения,
settings - настройка его параметров,
handler - обработка команд на отправку СМС,
task - периодическая проверка статуса СМС,
statistic - сбор статистики по работе и ошибкам приложения.

Во-первых, установка. В принципе, Битрикс24 не требует подобной точки входа, приложение будет установлено и без нее, но было бы неплохо регистрировать где-то у себя сам факт установки. В дальнейшем появится и еще одна тому причина, но пока довольно и одной. При установке необходимо где-то зафиксировать, что на таком-то портале было установлено наше приложение в такой-то день и т.п. Сразу следует отметить одну особенность Битрикс24: на данную точку входа портал постучит не только при установке приложения, но и при обновлении с версии на версию. Поэтому, регистрируя факт установки, нам потребуется отличить первую установку от обновлений. Сделать это элементарно по наличию у нас записи об установке: если она есть, значит произошло обновление, если нет - установка. Отмечу также, что установка - это страница с пользовательским интерфейсом. Она может содержать какую-то информацию, а может лишь вызывать метод js-библиотеки, предоставляемой Битрикс24, который фиксирует факт установки. Допустим, что у нас будет лишь этот вызов: BX24.installFinish(). После чего портал перенаправит пользователя на основную страницу приложения, т.е в настройки.

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

install,
settings,
handler,
event_handler - обработка событий портала,
task,
statistic.

Появилась еще одна - обработчик событий. Факт удаления нашего приложения мы можем узнать лишь подписавшись в портале на событие OnAppUninstall. Когда оно произойдет, портал стукнется на тот URL, что мы указали при подписке. Помимо того, что мы зафиксируем факт удаления, мы еще и почистим все хранилища (за исключением логов и статистики) от записей, привязанных к данному порталу, поскольку от них больше никакого проку.

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

Логирование.
DOMAIN - домен портала (все-таки при техподдержке с ним работать удобнее)
MEMBER_ID - идентификатор портала (домен может быть переименован, но id - нет)
EVENT_TYPE - тип события (напр., факт установки - INSTALL)
EVENT_DATA - любые интересующие данные в виде текста
DATE_CREATE - дата и время события в понятном человеку написании
DATE_POINT - дата, время и миллисекунды для сортировки и получения точной последовательности событий (просто DATE_CREATE для этого не хватит, поскольку за одну секунду может произойти несколько событий)

Хранение авторизации СМС-провайдера
Для простоты добавим поля к п.1 в те самые другие поля
API_LOGIN - логин у СМС-провайдера
API_KEY - АПИ ключ

Авторизация пользователя портала
DOMAIN
MEMBER_ID
BX_USER_ID - униальный в рамках портала id пользователя
ACCESS_TOKEN - собственно, тот токен, с которым будем стучаться на портал
REFRESH_TOKEN - токен для обновления access_token
REFRESH_DATE_END - последняя дата-время валидности refresh_token
VERSION - версия приложения

Статистика
DOMAIN
MEMBER_ID
EVENT_TYPE - тип события
DAY_VALUE - количество событий за день
DATE_CREATE - дата, на которую собрана статистика

Хранилище данных требует пояснений. Например, почему всюду дублируется домен и 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 дням, раз в сутки.

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

Читайте также: