По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Бизнес процессы в CRM – системе Битрикс24 позволяют упростить жизнь рядовым сотрудникам, автоматизируя различные сферы деятельности. В статье мы хотим рассказать о цикличном бизнес процессе, который будет запускать до тех пор, пока сделка находится в статусе «Дожатие»
Сценарий
Предположим, мы сконвертировали лида в сделку, выставили предложение и ждем реакции от клиента. В таком случае, с клиентом необходимо периодически связываться, уточняя, как у него обстоят дела, не решился ли он на покупку нашей услуги/товара.
Чтобы ответственный менеджер не забыл про нашего клиента, мы хотим чтобы ему периодически (раз в три дня) приходили напоминания на почту о том, что данная сделка все еще находится на этапе «Дожатие» и с клиентом необходимо связаться. Это плоский, и весьма тривиальный бизнес процесс, но надо заметить, весьма эффективный. Как только менеджер сменит статус сделки на любой другой, или сконвертирует ее, сообщения приходить перестанут.
Битрикс24 бесплатно!
Реализация
Переходим к настройке бизнес процессов. В разделе CRM →
Настройки → Автоматизация → Бизнес-процессы и нажимаем Добавить шаблон:
Во вкладке «Основное» даем название для бизнес – процесса, даем небольшое описание и снимаем галочки с параметров автоматического запуска, как показано ниже:
Нажимаем «Сохранить». Переносим в рабочее поле необходимые элементы. В разделе «Конструкции», переносим элемент «Цикл». Нажатием на значок шестеренки этого элемента производим следующие настройки:
Заголовок - название для элемента
Тип условия - установите «Поле документа»
Поле документа - указываем «Стадия сделки»
Условие - выставляем «Равно»
Значение - этап сделки под название «Дожатие»
Условно говоря, наш цикл, будет выполняться до тех пор, пока статус сделки будет равен «Дожатие». Как только он будет изменен, бизнес процесс будет закончен. Добавляем элементы «Почтовое сообщение» и «Уведомление пользователя» из раздела «Уведомления» последовательно в цикле. В настройках почтового уведомления производим следующие настройки:
Заголовок - название элемента внутри бизнес – процесса. Носит локальный характер
Отправитель сообщения - с какого email адреса будет отправлено письмо.
Получатель сообщения - адрес электронной почты адресата сообщения. В нашем случае, указана переменная {=Document:ASSIGNED_BY_EMAIL}, в которой хранится адрес электронной почты ответственного по данной сделке.
Тема сообщения - тема электронного письма
Текст сообщения - сообщение, которое будет отправлено адресату. Можно (и нужно) использовать переменные.
Тип сообщения - типа может быть либо текстовый, либо html. В последнем случае, вы можете применять оформление письма с помощью html кода. Рекомендуем табличную верстку, как в случае с email рассылкой
Помимо почтового уведомления, мы настроим отправку сообщения внутри Битрикс24. Переходим к опция настройки элемента «Уведомление пользователя»:
Заголовок - так же имеет локальное значение внутри бизнес процесса
Отправитель уведомления - пользователь, от которого поступит сообщение. В нашем случае это руководитель отдела продаж.
Получатель уведомления - переменная, в которой хранится ответственный по сделке.
Текст уведомления для сайта - сообщение, которое получит юзер внутри Битрикс24
Тип уведомления - мы выбираем персонализированное уведомление от руководителя отдела продаж. Чтобы неповадно было :)
Как было сказано в начале статье, уведомления мы хотим посылать один раз в три дня. Находим раздел элементов «Прочее» и добавляем элемент «Пауза в выполнении». Производим его настройку, она тривиальна:
Готово. Мы сделали простенький бизнес – процесс для отработки конкретного статуса. На финальном этапе он выглядит вот так:
Сохраняем. Теперь нам необходимо создать служебный бизнес – процесс, который будет отслеживать изменение статусов. Как и ранее, в разделе «Сделка» нажимаем «Добавить шаблон»:
Все настройки идентичны предыдущим, за исключение параметров автоматического запуска. Здесь мы выставляем галочку «При изменении».
Производим настройку элементов бизнес – процесса. В разделе «Конструкции» добавляем элемент «Условие». По умолчанию, данный блок имеет два ответвления. Выбираем любое, и переходим к его настройке:
Заголовок - локальное значение. Для наглядности мы назвали его согласно статусу – «Дожатие»
Тип условия - выставляем «Поле документа»
Поле документа - проверять будем стадию сделки
Условия - равняется ли заданное поле нашему значению. Выставляем «Равно».
Значение - тут выставляем «Дожатие»
Следом за этим блоком добавляем из раздела «Обработка документа» элемент «Запуск бизнес-процесса» со следующими параметрами:
Заголовок - любое удобное наименование
ID документа - ID документа и указание сущности. Так как мы работаем со сделками, то указываем префикс DEAL_
Сущность - указываем «Сделка»
Тип документа - укажите «Сделка»
Шаблон - выберите бизнес – процесс, который необходимо запустить. В нашем случае это созданный БП «Дожатие»
Для запуска бизнес-процесса изнутри бизнес-процесса используйте префикс CONTACT_, COMPANY_, DEAL_, LEAD_.
Во второй ветке условия настройка тривиальна:
В результате мы имеем следующую картину:
Сохраняем и закрываем. Готово. Теперь, когда наш менеджер переведет сделку в статус «Дожатие», ему раз в три дня будет приходить напоминания о том, что данная сделка нуждается в его внимании. Как только сделка будет сконвертирована или переведена в иной статус, уведомления прекратятся.
Графовые базы данных (Graph databases) – это нереляционные системы (NoSQL), которые определяют корреляции между сложно взаимосвязанными сущностями. Такая структура позволяет обойти ограничения реляционных БД и уделяет больше внимания отношениям между данными.
Графовая база данных позволяет аккуратно определять взаимосвязи и дает ответы на сложные вопросы о том, как точки данных соотносятся друг с другом.
В данной статье объясняется, что такое графовые базы данных, и как они работают. Но для начала можно быстро познакомиться с другими видами NoSQL.
Что такое графовая база данных?
Графовая база данных – это нереляционный тип баз данных, основанный на топографической структуре сети. Идея этой БД восходит к математической теории графов. Графы представляют наборы данных в виде узлов, ребер и свойств.
Узлы, или точки (nodes) – это экземпляры или сущности данных; ими является любой объект, который вы планируете отслеживать. Например, люди, заказчики, подразделения и т.д.
Ребра, или линии (edges) – это важнейшие концепции в графовых БД. Они отображают взаимосвязь между узлами. Эти связи имеют направление и могут быть одно- или двунаправленными.
Свойства (properties) содержат описательную информацию, связанную с узлами. В некоторых случаях свойства бывают и у ребер.
Узлы с пояснительными свойствами создают взаимосвязи, представленные через ребра.
Графовые БД предлагают концептуальное представление данных, тесно связанных с реальным миром. Моделировать сложные связи гораздо проще, поскольку отношениям между точками данных уделяется такое же внимание, как и самим данным.
Сравнение графовых и реляционных баз данных
Графовые БД не создавались для замены реляционных БД. Стандартом отрасли на текущий момент считаются реляционные БД. Но перед этим важно понять, что может предложить та или иная разновидность систем.
Реляционные базы данных обеспечивают структурированный подход к данным, а графовые БД считают более гибкими и ориентированы на быстрое понимание взаимосвязей между данными.
Графовые и реляционные БД имеют свою область применения. Сложные взаимосвязи лучше реализовать через графовые БД, поскольку их возможности превосходят традиционные реляционные СУБД. При создании моделей баз данных в реляционных системах MySQL или PostgreSQL требуется тщательное планирование, а в графовых используется более естественный и гибкий подход к данным.
В таблице ниже приведены ключевые отличия между графовыми и реляционными БД:
Тип
Графовые БД
Реляционные БД
Формат
Узлы и ребра со свойствами
Таблицы со строками и столбцами
Связи
Представлены в виде ребер между узлами
Создаются с помощью внешних ключей между таблицами
Гибкость
Гибкие
Жестко заданные
Сложные запросы
Быстрые и отзывчивые
Необходимы сложные соединения
Варианты использования
Системы с взаимосвязанными зависимостями
Системы с транзакциями и более простыми отношениями
Как работают графовые базы данных?
Графовые базы данных одинаково относятся к данным и взаимосвязям между ними. Связанные узлы физически связываются, и эта связь рассматривается как часть данных.
При таком моделировании данных вы можете запрашивать взаимосвязи также, как и сами данные. Вместо вычисления и запросов на подключение, графовые БД считывают взаимосвязи напрямую из хранилища.
По гибкости, производительности и адаптивности графовые БД близки к другим нереляционным моделям данных. В них, как и в других нереляционных БД, отсутствуют схемы, что делает данную модель гибкой и легко изменяемой.
Примеры использования графовых баз данных
Есть много примеров, когда графовые БД превосходят все прочие методы моделирования данных. Среди таких примеров можно выделить:
Рекомендательные сервисы в режиме реального времени. Динамичные рекомендации по продуктам и электронным товарам улучшают пользовательский опыт и максимизируют прибыль. Из известных компаний можно упомянуть Netflix, eBay и Walmart.
Управление основными данными. Привязка всех данных к одной общей точке обеспечивает постоянство и точность данных. Управление основными данными крайне важно для крупномасштабных компаний мирового уровня.
GDPR и соблюдение нормативных требований. С графами гораздо проще управлять безопасностью и отслеживать перемещение данных. Базы данных снижают вероятность утечки информации и обеспечивают большую согласованность при удалении данных, чем повышается общее доверие к конфиденциальной информации.
Управление цифровыми ресурсами. Объем цифрового контента просто огромен и постоянно растет. Графовые БД предлагают масштабируемую и простую модель данных, позволяющую отслеживать цифровые ресурсы: документы, расчеты, контракты и т.д.
Контекстно-зависимые сервисы. Графы помогают в предоставлении сервисов, приближенных к актуальным характеристиками мира. Будь то предупреждения о стихийных бедствиях, информация о пробках или рекомендации по товарам для конкретного местоположения, – графовые базы данных предлагают логическое решение для реальных обстоятельств.
Выявление мошенничества. Поиск подозрительных закономерностей и раскрытие мошеннических платежных схем выполняется в режиме реального времени. Выявление и изоляция частей графа позволяет быстрее обнаружить мошенническое поведение.
Семантический поиск. Обработка естественного языка бывает неоднозначной. Семантический поиск помогает определить значение ключевых слов и выдает более подходящие варианты, которые, в свою очередь проще отобразить с помощью графовых БД.
Сетевое управление. Сети – это не что иное, как связанные графы. Графовые БД снижают время, необходимое для оповещения сетевого администратора о проблемах в сети.
Маршрутизация. Информация передается по сети за счет поиска оптимальных маршрутов, и это делает графовые БД идеальным вариантом для маршрутизации.
Какие есть известные графовые базы данных?
С ростом больших данных и аналитики в соцсетях популярность графовых БД возрастает. Моделирование графов поддерживает множество многомодельных БД. Кроме того, доступно много нативных графовых БД.
JanusGraph
JanusGraph – это распределенная, масштабируемая система графовых БД с открытым кодом и широким набором возможностей по интеграции и аналитике больших данных. Ниже приведен перечень основных функций JanusGraph:
Поддержка ACID-транзакций с возможностью одновременного обслуживания тысяч пользователей
Несколько вариантов хранения графических данных, включая Cassandra и HBase
Встроенный сложный поиск, а также дополнительная (опциональная) поддержка Elasticsearch
Полная интеграция Apache Spark для расширенной аналитики данных
JanusGraph использует полный по Тьюрингу язык запросов для обхода графов
Neo4j
Neo4j (Network Exploration and Optimization 4 Java, что переводится как «исследование сети и оптимизация для Java») – это графовая база данных, написанная на Java с нативным хранением и обработкой графов. Основные возможности:
Масштабируемость БД за счет разделения данных на части – сегменты
Высокая доступность благодаря непрерывному резервному копированию и последовательным обновлениям
Высокий уровень безопасности: несколько экземпляров баз данных можно разделить, оставив их на одном выделенном сервере
Neo4j использует Cypher – язык запросов для графовых БД, который очень удобен для программирования
DGraph
DGraph (Distributed graph, что переводится как «распределенный граф») – это распределенная система графовых БД с открытым исходным кодом и хорошей масштабируемостью. Вот несколько интересных возможностей DGraph:
Горизонтальная масштабируемость для работы в реальной среде с ACID-транзакциями
DGraph – это свободно распространяемая система с поддержкой множества открытых стандартов
Язык запросов – GraphQL, который был разработан для API
DataStax Enterprise Graph
DataStax Enterprise Graph – это распределенная графовая БД на базе Cassandra. Она оптимизирована под предприятия. Несколько функций:
DataStax обеспечивает постоянную доступность для корпоративных нужд
База данных легко интегрируется с автономной платформой Apache Spark
Полная интеграция аналитики и поиска в реальном времени
Масштабируемость за счет наличия нескольких центров обработки данных
Поддержка Gremlin и CQL для запросов
Плюсы и минусы графовых баз данных
В каждом типе баз данных есть свои плюсы и минусы. Именно поэтому так важно понимать отличия между моделями и доступные возможности для решения конкретных проблем. Графовые БД – это развивающаяся технология с целями, отличными от других типов БД.
Плюсы
Вот несколько плюсов графовых баз данных:
Гибкая и адаптивная структура
Четкое представление взаимосвязей между сущностями
Запросы выводят результаты в реальном времени. Скорость зависит от количества связей
Минусы
Ниже перечислены основные минусы системы:
Отсутствует стандартизированный язык запросов. Язык зависит от используемой платформы
Графы не подходят для систем на основе транзакций
Небольшая база пользователей; при возникновении проблема сложно получить поддержку
Заключение
Графовые базы данных – это отличный подход для анализа сложных отношений между объектами данных. Быстрота запросов и результаты в режиме реального времени хорошо вписываются в требования современных и стремительно растущих исследований данных. Графы – это развивающаяся технология, которую ждет еще много улучшений.
Всем привет! Иногда настаёт момент, когда необходимо удалить FreePBX или Asterisk. Например, для того чтобы использовать сервер, на котором они были установлены для других приложений или для того, чтобы начать всё «с чистого листа» после неудачного обновления/установки/манипуляций с конфигурационными файлами.
Поэтому в данной статье, мы покажем как правильно удалить FreePBX 13 версии и Asterisk версии 13.7.1.
Удаление FreePBX
Внимание! Описанные ниже действия полностью удалят FreePBX с вашего сервера без возможности восстановления. Поэтому рекомендуем сделать резервную копию
Внимание! Данные действия удалят только FreePBX, но оставят Asterisk. Однако, если Вы устанавливали Asterisk из источников и затем ставили на него FreePBX, то после удаления, настройки Asterisk не восстановятся.
Первое, что необходимо сделать – это подключиться к нашему серверу по SSH, далее есть два способа удаления FreePBX:
Найдите или перезагрузите с помощью SVN файл ./install_amp и просто запустите следующую команду: ./install_amp --uninstall
Удалите FreePBX и его компоненты вручную, данные действия применимы только на системах CentOS:
Удаление таблиц MySQL
Подключаемся к MySQL с правами root’а: mysql -u root
Инициируем удаление таблиц asterisk и asteriskcdrdb:
DROP DATABASE asterisk;
DROP DATABASE asteriskcdrdb;
Выходим из MySQL: exit;
Придаем забвению файлы, связанные с FreePBX, прописав следующие команды:
rm /usr/sbin/amportal
rm -rf /var/lib/asterisk/bin/*
rm -rf /var/www/html/*
rm /etc/amportal.conf
rm /etc/asterisk/amportal.conf
rm /etc/freepbx.conf
rm /etc/asterisk/freepbx.conf
rm -f /etc/asterisk/*.conf
На этом всё. Можете быть уверенными, что от FreePBX не осталось и следа… При попытке зайти на web-интерфейс, вас ожидает ошибка 404. Однако, Asterisk всё ещё доступен и работает.
Удаление Asterisk
Внимание! Описанные ниже действия полностью удалят Asterisk с вашего сервера без возможности восстановления. Поэтому рекомендуем сделать резервную копию рабочей системы.
Для того, чтобы удалить Asterisk, первым делом необходимо остановить процесс, связанный с ним и удалить соответствующие модули. Обычно необходимо остановить сам процесс Asterisk и связанные с ним процессы DAHDI (на более ранних версиях – Zaptel). Но не торопитесь останавливать DAHDI, он нам ещё понадобится. Остановим Asterisk:
service asterisk stop
Затем необходимо удалить драйверы, использующиеся DAHDI. Для того, чтобы проверить какие драйверы загружены – используем команду:
lsmod | grep dahdi
Видим, что DAHDI использует много подмодулей, все их необходимо удалить по порядку и завершить процедуру удалением самого DAHDI. Вводим следующие команды:
Останавливаем процесс:
service dahdi stop
Отключаем модули:
modprobe -r wctc4xxp
modprobe -r wctdm24xxp
Повторяем для всех модулей, а в самом конце:
modprobe -r dahdi
Теперь приступаем к удалению Asterisk. Как только команды, которые описаны ниже будут введены – обратного пути нет:
rm -rf /etc/asterisk
rm -f /etc/dahdi.conf
rm -rf /var/log/asterisk
rm -rf /var/lib/asterisk
rm -rf /var/spool/asterisk
rm -rf /usr/lib/asterisk
Готово, теперь Asterisk полностью удалён с Вашего сервера. Надеемся, что данная статья Вам помогла.