В моем варианте все предельно просто и показывает что и как работает в API по деталям. Именно это я и хотел описать, фундаментальную механику, сам принцип.
Готовые библиотеки от Б24 сложнее и я пока в них не разбирался ещё. Но спасибо что обратили на это внимание.
Хуки это простое решение, OAuth для более серьезного на мой взгляд. Если с сайта падают заявки по 2-3 в день для 1 портала мне кажется хука более чем хватит.
Официальная документация Битрикса тоже говорит что если портал один и скрипт простой, то лучше хук.
Тут вопрос кому удобнее OAuth развернуть, а кому по простому через хук если там объем данных минимален.
То что OAuth надежнее хука безусловно так, но мне кажется для простых интеграций хука хватит более чем.
По поводу параллельности и одновременности запросов это да, я про это думал, тут может быть сбой. expires_at в БД мне кажется это сможет решить, потому что если токен не истек, то он два раза одновременно использует его и по идее проблем быть не должно. Но если токен истек, то тут да, один запрос может потеряться в момент обновления. Шанс малый но есть. Redis с TTL должен исключить полностью.
Вам спасибо за диалог и обмен опытом, всегда полезно узнать опыт других.
Спасибо за ответ, интересно разобрать реальный кейс.
Я опираюсь на BPMN стандарт моделирования бизнес-процессов. Для меня этап воронки это этап продвижения сделки до успеха, каждый этап это состояние сделки в бизнес-процессе, прогресс сделки.
"Не отвечает" - это не прогресс сделки, это результат действия и выводить его в стадию не корректно + в аналитике будет бардак.
Т.е. этап сделки для меня это задача перевести из одного состояния в другое, например у вас было бы что то похожее: новый -> взят в работу -> согласился приехать -> приехал
Этапы "Взят в работу" и "Согласился приехать" всегда проходятся хоть и моментально, потому что что бы узнать приедет ли вообще - надо взять в работу, а что бы приехал - надо что бы согласился - иначе нельзя.
А вот "Не отвечает" это внутри стадии "Взят в работу" событие что нет связи и это по факту не продвижение сделки (прогресса) по этапам далее, это просто отсрочка изменения статуса.
Воронка продаж это прогресс, каждый этап прогресс, в этом её смысл.
Я бы переводил на статус "взят в работу", а внутри сделки уже задачами/делами фиксировал событие "перезвонить" или в полях сделки (потом по фильтрам вывести именно такие сделки) или в тегах ставил отметку - это правильнее.
Например в Битрикс24 у задачи можно делать тег и потом по этому тегу фильтровать задачи "не отвечает". Я пришел к выводу что через уровень задач и тегов надо фиксировать когда связи нет.
Не знаю как в esm-crm задачи и дела реализуются, там доступ только для диллерских центров.
Я понимаю что curl-ом гонять постоянно запрос токена это прокатит только на малых объемах, если там пойдет большой поток то все забуксует. У меня пока что клиенты бывают с малыми потоками данных по API, поэтому для них такого кода более чем хватит, если там в сутки 3-5-7 запросов ничего не нагрузится.
Если там конечно 300 запросов в сутки будет (был один потенциальный клиент с hh в Амо с таким объемом) то тут проблемы могут начаться, но я до такой разработки пока не дошел и буду решать по мере поступления.
Я слышал про значение expires_at передающееся с токеном, т.е. хранить в БД время жизни токена, делать проверку по IF и запрашивать у БД данные жив или нет, а по не API проверять каждый раз - точно будет быстрее у своей БД запросить, чем по API гонять каждый раз.
Redis с TTL в оперативку - мне кажется это имеет место быть если там 1000+ запросов в сутки может быть и параллельные процессы, т.е. потоковая работа идет.
Время отклика пока не замерял, в рамках тех задач что были это не особо критично.
Если клиент будет себе ставить приложение с маркета Амо, то врят ли он будет заморачиватсья с токенами, им надо нажать кнопки и что бы все работало. Хотя может и будут копировать токен, надо будет смотреть, потому что если у готового приложения OAuth 2.0 будет отлетать из за того что токен не обновить, то проще и правда сделать инструкцию откуда скопировать долгосрочный и куда вставить. Спасибо за идеи.
Точно, есть такое. Это скорее всего подойдет для индивидуальной интеграции, но для приложений маркета, как слышал (пока ещё не писал), там только с заменой скорее всего т.к. клиенты разные. Спасибо за информацию.
Не плохо, посмотрел мельком - выглядит мощно, штатное подключение, вроде как вытаскивает все те же таблицы что и BI Конструктор с БД Б24, интерфейс выглядит обширным, вроде как кеш проверять можно. Надо будет как нибудь пробовать юзать, что там сформировать можно и смотреть что там по багам если есть. Спасибо что подсказали.
Смотря с чем вы сравниваете. Я не работал в Power BI, может там и лучше. Могу сравнить только с шаблонными отчетами Битрикс24, конструктором отчетов и API, но API слишком ёмкая работа.
В моем варианте все предельно просто и показывает что и как работает в API по деталям. Именно это я и хотел описать, фундаментальную механику, сам принцип.
Готовые библиотеки от Б24 сложнее и я пока в них не разбирался ещё. Но спасибо что обратили на это внимание.
Вопрос в подходе и в масштабе.
Хуки это простое решение, OAuth для более серьезного на мой взгляд.
Если с сайта падают заявки по 2-3 в день для 1 портала мне кажется хука более чем хватит.
Официальная документация Битрикса тоже говорит что если портал один и скрипт простой, то лучше хук.
Тут вопрос кому удобнее OAuth развернуть, а кому по простому через хук если там объем данных минимален.
То что OAuth надежнее хука безусловно так, но мне кажется для простых интеграций хука хватит более чем.
По поводу параллельности и одновременности запросов это да, я про это думал, тут может быть сбой. expires_at в БД мне кажется это сможет решить, потому что если токен не истек, то он два раза одновременно использует его и по идее проблем быть не должно. Но если токен истек, то тут да, один запрос может потеряться в момент обновления. Шанс малый но есть. Redis с TTL должен исключить полностью.
Вам спасибо за диалог и обмен опытом, всегда полезно узнать опыт других.
Спасибо за ответ, интересно разобрать реальный кейс.
Я опираюсь на BPMN стандарт моделирования бизнес-процессов.
Для меня этап воронки это этап продвижения сделки до успеха, каждый этап это состояние сделки в бизнес-процессе, прогресс сделки.
"Не отвечает" - это не прогресс сделки, это результат действия и выводить его в стадию не корректно + в аналитике будет бардак.
Т.е. этап сделки для меня это задача перевести из одного состояния в другое, например у вас было бы что то похожее: новый -> взят в работу -> согласился приехать -> приехал
Этапы "Взят в работу" и "Согласился приехать" всегда проходятся хоть и моментально, потому что что бы узнать приедет ли вообще - надо взять в работу, а что бы приехал - надо что бы согласился - иначе нельзя.
А вот "Не отвечает" это внутри стадии "Взят в работу" событие что нет связи и это по факту не продвижение сделки (прогресса) по этапам далее, это просто отсрочка изменения статуса.
Воронка продаж это прогресс, каждый этап прогресс, в этом её смысл.
Я бы переводил на статус "взят в работу", а внутри сделки уже задачами/делами фиксировал событие "перезвонить" или в полях сделки (потом по фильтрам вывести именно такие сделки) или в тегах ставил отметку - это правильнее.
Например в Битрикс24 у задачи можно делать тег и потом по этому тегу фильтровать задачи "не отвечает". Я пришел к выводу что через уровень задач и тегов надо фиксировать когда связи нет.
Не знаю как в esm-crm задачи и дела реализуются, там доступ только для диллерских центров.
Я понимаю что curl-ом гонять постоянно запрос токена это прокатит только на малых объемах, если там пойдет большой поток то все забуксует. У меня пока что клиенты бывают с малыми потоками данных по API, поэтому для них такого кода более чем хватит, если там в сутки 3-5-7 запросов ничего не нагрузится.
Если там конечно 300 запросов в сутки будет (был один потенциальный клиент с hh в Амо с таким объемом) то тут проблемы могут начаться, но я до такой разработки пока не дошел и буду решать по мере поступления.
Я слышал про значение expires_at передающееся с токеном, т.е. хранить в БД время жизни токена, делать проверку по IF и запрашивать у БД данные жив или нет, а по не API проверять каждый раз - точно будет быстрее у своей БД запросить, чем по API гонять каждый раз.
Redis с TTL в оперативку - мне кажется это имеет место быть если там 1000+ запросов в сутки может быть и параллельные процессы, т.е. потоковая работа идет.
Время отклика пока не замерял, в рамках тех задач что были это не особо критично.
Если клиент будет себе ставить приложение с маркета Амо, то врят ли он будет заморачиватсья с токенами, им надо нажать кнопки и что бы все работало. Хотя может и будут копировать токен, надо будет смотреть, потому что если у готового приложения OAuth 2.0 будет отлетать из за того что токен не обновить, то проще и правда сделать инструкцию откуда скопировать долгосрочный и куда вставить. Спасибо за идеи.
Точно, есть такое. Это скорее всего подойдет для индивидуальной интеграции, но для приложений маркета, как слышал (пока ещё не писал), там только с заменой скорее всего т.к. клиенты разные. Спасибо за информацию.
Не плохо, посмотрел мельком - выглядит мощно, штатное подключение, вроде как вытаскивает все те же таблицы что и BI Конструктор с БД Б24, интерфейс выглядит обширным, вроде как кеш проверять можно. Надо будет как нибудь пробовать юзать, что там сформировать можно и смотреть что там по багам если есть. Спасибо что подсказали.
Смотря с чем вы сравниваете. Я не работал в Power BI, может там и лучше. Могу сравнить только с шаблонными отчетами Битрикс24, конструктором отчетов и API, но API слишком ёмкая работа.