Коробка.
Т.к. в Б24 нет события смены ответственного, то как лучше "ловить" это событие?
Мысль 1. Ловить событие смены сделки. Проверять сменился ли отв., используя дополнительное пользовательское поле "прежний_ответственный".
Мысль 2. Ловить (пока не знаю как) event в истории сущности.
Мысль 3. Проверять таблицы где хранятся event (b_crm_event_relations, b_crm_event).
А чем не понравилась идея с списком / смарт-процессом, в который при каждом изменении будет записываться новый ответственный и время измененния?
Мне навскидку приходит несколько моментов: 1. Несколько обработчиков работающих в паре (не думаю что лучший вариант) 2. Асинхронный парсер истории (каждые 5 минут парсить записи с прошедшего запуска и записывать смены ответственных).
Вопрос не о том где хранить. А о том как ловить событие.
вопрос, для чего?
> 1. несколько обработчиков Почему несколько? Кажется, что достаточно одного - изменение сделки. > 2. асинхронный парсер истории Почему асинхронный? Что лучше парсить: таблицы БД или результат возвращаемый api-методом?
Почему несколько? Кажется, что достаточно одного - изменение сделки. Перед изменением чтобы получить состояние ДО После изменения чтобы проверить что изменение действительно было и оно менялось.
> 2. асинхронный парсер истории Почему асинхронный? Что лучше парсить: таблицы БД или результат возвращаемый api-методом? Асихнорнный значит работающий независимо от выполняемых методов обновлений. Запись в историю добавляется через CCrmEvent и там прямой запрос в БД без событий, а значит на него не подпишешься. Можно конечно использовать работу обработчиков в паре, но на каждое изменение сделки доставать предыдущего ответственного несколько расточительно.
Получается, что метод асинхронно парсить БД выглядит получше других?
Да, если устраивает задержка между реальным изменением и появлением записи в истории
Тут такой момент. У меня уже есть БП, который на каждое изменение сделки расточительно достает предыдущего ответственного из пользовательского поля, чтобы поймать смену ответственного. Цель - сразу менять ответственного в связанном лиде. И раз такой БП есть, то наверное разумно использовать его. По моему скромному мнению.
Это уже зависит от бизнес-требований. Если цель этого всего - заменить БП на код - то тогда не вижу смысла менять шило на мыло, пусть и бархатистое.
Не. БП на код не цель. Хотя может и зря. Интуитивно есть ощущение, что код лучше БП. Но аргументов почему - не имею. Если просвятите, то с благодарностью приму эту информацию. Учту в будущем.
Интуитивно есть ощущение, что код лучше БП Код лучше БП, но не на много.
Обсуждают сегодня