Новость короткой строкой: Мы научили автоматические сценарии отправлять POST-запросы.
Я понимаю, что это порадует только очень маленькое количество наших пользователей, которые знают, что такое POST-запросы и для чего они нужны. Для них, скорее всего, будет достаточно картинки:
Ну или такой:
Если вам эта новость ни о чем не говорит, это нормально: большая часть взрослых образованных людей понятия не имеет о POST – да оно им, по большому счету, и не нужно. Единственное исключение – если у вас есть необходимость связать ПланФикс с другой своей корпоративной системой управления, возможно имеет смысл дать ссылку на этот пост своим айтишникам.
Дмитрий Гончаренко Команда ПланФикса
Извините, что сегодня такой малоинформативный пост – следующий будет интересней 🙂
Отличные новости
О! Мы только вчера об этом подумали, а Вы уже реализовали … молодцы! )
Прекрасно.
Теперь CRM можно связать с корпоративной телефонией.
Дмитрий. Не поделитесь с какой телефонией таким образом планируете подружить ПФ?
Дмитрий Гончаренко, а поля Постановщика/Исполнителя для POST можно будет развернуть как для Контрагента задачи? Чтобы, например, отправлять СМС контакту на номер мобильного телефона по какому-то событию…
Обсудим это. Теоретически, это возможно, обычно возникает только одна проблема с такими полями: так как в них может содержаться несколько значений, непонятно, по какому из них отдавать дополнительные данные. А если отдавать по всем (исполнителям, к примеру), то непонятно, как адресоваться к ним.
Смайлик “мартышка закрывает глаза”
Отличные новости. Спасибо!!!
Потрясающе!
Теперь просто дух захватывает от возможностей интеграции.
О таком можно было только фантазировать 🙂
Реальность – она лучше фантазий.
А можно как-нибудь использовать возвращаемые результаты?
К примеру возвращается
{“result”:{“person_id”:2500767342}}
или
{
“error”: “List \”New_listtt\” (id: 7068222) already exists”,
“code”: “invalid_arg”,
“result”: “”,
“existing_list_id”: 7068222
}
На этапе отладки это сильно может помочь…
Да и потом – такие данные могут пригодиться
А как именно их было бы удобно использовать? Как отражать ответ в системе?
Наверное, примерно так же, обрабатывать, как обрабатываются e-mail сообщения.
Такой подход мне кажется не очень удобным тем, что сложно будет собрать в одном месте запрос и ответ на него и управлять этим в одном интерфейсе. А настраивать в разных сложно, легко запутаться что, зачем и почему происходит.
Выполняем Post-запрос с целью создания какого-то элемента в стороннем сервисе. Получаем web-ссылку на созданный элемент, или какой-то id. Заполняем кастомное поле задачи полученным значением.
Может так?
Ну вот мне тоже пришел в голову такой вариант + вариант создавать действие с текстом ответа. Оба варианта позволяют вызвать новые сценарии (на изменение задачи и на добавление нового действия), которые будут обрабатывать ответ и в зависимости от него что-то делать дальше.
думаю, что для начала стоит просто создавать новое действие с текстом ответа.
А где-нить в настройке действия “создавать post-запрос” сделать флажок “дополнительно создать действие с текстом ответа”.
И на текущем этапе этого будет вполне достаточно.
А все эти правила, кастомные поля… наверное тоже нужно, но с ними слишком уж сложно получается.
Если уж это реально надо, то тогда ведь можно ваше API использовать.
Да, уже столкнулся с трудностями отладки, потому что система возвращает ответ, а я не могу увидеть какой
Ответов нет …
И как не отправлять, а принимать POST запросы в Planfix?
Хотелось бы по какому запросу искать задачу (или создавать ее) и добавлять аналитику в нее.
Ответы добавляются действием, а с текстом действия можно работать (если я, конечно. правильно понял о чем речь).
А вообще, ветка дальнейшего развития по запросам такая:
– Делаем механизм универсального разбора внешних данных (данные раскладываются в переменные, которые затем могут использоваться в сценариях). Это происходит прямо сейчас.
– Распространяем действие этого механизма в том числе и на POST-запросы (а еще на правила для почты и интеграции).
– Делаем механизм принятия GET-запросов – то есть, возможность сгенерировать ссылку, по которой может обратиться внешний сервис и прислать какие-то данные. Для таких запросов сразу будет подключен механизм универсального разбора, о котором я пишу выше.
А есть ли планы по механизму _отправки_ GET-запросов? Чтобы сценарий мог тут же получить в ответ и обработать внешние данные.
(да, я понимаю, что серверная реализация такого механизма значительно сложнее, чем реализация POST-запросов, ответ на которые сценарию ждать вообще не надо)
Есть.
Шикарно!
Спасибо!
А можно узнать, когда такое счастье может случиться?
Или – традиционно – “всему своё время, следите за новостями”? 🙂
Да, на стандартный вопрос – стандартный ответ 🙂
Дмитрий, подскажите пожалуйста, когда планируется и планируется ли вообще добавить возможность обработки json ответов от post запросов в самом ПФ?
Да, такие планы есть. В сентябре-октябре для всех станут доступны новые правила разбора писем, после этого мы займемся пасширением этого же механизма на ответы, приходящие на POST-запросы. При хорошем раскладе, к концу года можно будет попробовать это в работе.
Добрые вести)
Благодарю Вас за оперативность.
Здравствуйте, Дмитрий!
>>>В сентябре-октябре для всех станут доступны новые правила разбора писем,
Позволю себе заметить, что уже наступил ноябрь…
>>>после этого мы займемся расширением этого же механизма на ответы, приходящие на POST-запросы.
>>>При хорошем раскладе, к концу года можно будет попробовать это в работе.
Или вы имели ввиду 2020 год?
:)))
Привет, Алексей!
Сложная штука, находим все время новые нюансы в ходе тестирования, поэтому пока не выпустили. Планирую на следующей неделе в блоге анонсировать, посмотрим как получится.
Дмитрий, это очень приятно слышать!
А можно ли добавить еще возможность авторизации по Oauth протоколу перед POST запросом с указанными данными?
К примеру в результате работы нужно добавить контакт в список e-mail рассылки на стороннем сервисе (в нашем случае SendPulse).
А почему не используете нативную интеграцию с SendPulse, есть неудобства? По замыслу, чтобы контакт попал в нужный список на стороне сервиса рассылки, достаточно чтобы он попал в нужный список (фильтр контактов) в ПланФиксе. То есть, сценарий может не слать POST-запросы, а просто изменить поле контакта, ответственное за попадание в нужный фильтр, а дальше автоматика сама отработает.
Подробнее про то, как это работает: https://planfix.ru/docs/%D0%A1%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B_%D1%80%D0%B0%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B8_e-mail
Проблема интеграции с сервисами рассылки в том, что интеграция не отслеживает изменения, которые происходят с контактом, когда он попадает в список рассылки.
К примеру в Mailchimp можно так настроить автоматизацию, что в зависимости от того, что пользователь делает (ну т.е. открывает письма, кликает по ссылке) – могут меняться какие-то свойства пользователя (ну т.е. он может попадать в другие списки рассылки, у него могут появляться какие-то теги или он может включаться в различные сегменты).
Думаю, что в SendPulse есть аналогичные возможности.
А ПФ – не умеет отслеживать эти изменения
(о чём в справке отдельно написано).
И это – ужасно.
Приходится изобретать такие “костыли”, что просто жуть.
А еще бывает так, что в список рассылки контакт попадает через форму рассылки на сайте. И тогда приходится обрабатывать две ситуации:
1. контакт попадает в список рассылки с сервиса рассылки
2. Контакт попадает в список рассылки через ПФ.
И тут эти костыли становятся… вот совсем уж неудобными….
(так… стеснительно…)
Дмитрий, а можно попросить вас сделать двухстороннюю синхронизацию с сервисами рассылки?
Ха, а я ведь уже писал об этом, но чуть другими словами….
И вы обещали посмотреть:
https://blog.planfix.ru/rassylka-pisem-na-email/#comment-3017
Скоро, кстати, случится три года, когда рекомендуется ждать обещанного
🙂
А для чего передавать все это назад в ПФ? Почему не вести триггерную рассылку средствами сервиса рассылки, а ПФ использовать для поставки контактов на “точку входа” рассылки?
Рассылка – это часть “воронки продаж”.
В некоем сферическом случае контакт может стать клиентом после завершения серии писем.
Но чаще всего – не становится… И потому приходится его “дожимать” другими способами….
Правильно ли я понимаю, что в POST нельзя передать данные из Инфоблока, то есть в случае если необходимо работать с данными попавшими в фильтр, то единственная возможность это использовать
{{Действие.Текст.Без форматирования}}
И уже на стороне получателя разбирать его и принимать решения ?
Вообще, вскоре должна появиться возможность оперировать содержимым инфоблоков в переменных, в том числе вставляемых в POST-запросы.
Это великолепная новость!
А в данный момент только так как я описал ?
Ну или заполнять данными инфоблока поле и потом использовать в тексте запроса переменную поля.
А как можно записать в одно поле значения нескольких инфоблоков сразу ?
Нет, только в разные. В одно можно собрать значения нескольких полей.
Подскажите, ответы POST-запросов все еще нельзя обрабатывать?
Напрямую нет, только помещая оивет в комментармй – иогда можно будет вылавливать ключевые слова в тексте оивета сценарием на событие «Добавлен комментарий». Но обязательно сделаем обрсбоиуу ответа в более удобоваримой форме, двигаемся к этому.
Получается что dadata не подключается и за 2 года вы даже не приблизились к решению этой, цитирую: “приоритетной задачи”.
Обращаться к dadata через post запросы нет смысла, потому что они не обрабатываются. Получается надо сооружать костыли.
Как же вы долго реализуете действительно важный для бизнеса функционал.
В телеграмме подписан уже год на вас с целью уловить хоть что-то связанное с заполнением реквизитов dadata, использования их в договорах…но вы то кнопку сделаете новую, то перекрасите старую, улучшите то, что улучшали месяц назад и по кругу.
Я очень рад что вы развиваетесь, но когда мы просим реализовать вас с 2017 года нужный бизнесу функционал, а вы по прежнему прорабатываете и улучшаете то, что не поменяет особой погоды в работе — выглядит как издевательство.
Вот прям нечего написать. Мне просто тупо жаль, что даже вы, не прислушиваетесь к бизнесу.
Конечно, пишу со своей колокольни и бла бла бла….кому-то это не надо…а ваши изменения здорово влияют на чей-то климат.
Понимаю Ваши эмоции, Иван – наверное. со стороны это так и выглядит. На самом деле, люди, которые “красят кнопки” и люди, которые делают новые интеграции – это разные люди, с разной квалификацией и опытом работы. И те разработчики, кто до сих пор не сделали интеграцию с нужной Вам (и не только Вам) dadatой, это время занимались другими задачами, не менее важными.
На приоритет интеграции оказывает влияние в том числе и то, что острота вопроса с получением данных во многом снимается наличием стороннего сервиса, который выполняет эту функцию: https://planfix.kireev-k.ru/automatic-completion-of-details.
Конечно, это не отменяет наших планов и интеграция обязательно появится, как и разбор POST-запросов (он, скорее всего, раньше).
Дмитрий, мне хочется донести до вас на сколько влияют размытость ваших ответов на чьи-либо решения. Со стороны это выглядит именно так. Но мы же оцениваем результат с данными ранее обещаниями. А они не совпадают. Вы же не получаете удовольствия общаться с разработчиками без привязки к определенному времени. Все должно быть точно. Иначе как вы определяете эффективность?
Я четвертый раз регистрируюсь в планфикс с надеждой увидеть реализацию и окончательно перейти. Да, мне это не хватает и менять шило на мыло не имеет смысла.
Каждый раз я спрашиваю: “когда…”. И уже четвертый раз получил ответ “в планах…”.
Понимаете, если бы мне сообщили типа: “Иван, в планах есть, но через 5 лет…”, я бы, скорее всего, перешел бы на вас или нашел других, сделал бы пару костылей и был спокоен.
Проблема как раз таки в том, что я не понимал…надо делать костыли и платить за их разработку, внедрение, поддержку…либо подождать пол года и все будет работать из коробки.
Речь идет о целесообразности и эффективности использования денежных средств. Как и у вас у меня есть бюджет и т.д. и т.п.
Не знаю как у кого, но в моем представлении (если речь идет не о космической программе) в планах — это ближе чем год, может месяцев восемь максимум…но не 3 года. Быть может я отстал от реалий, конечно, но интуитивно придерживался этих цифр.
“Люди, которые «красят кнопки» и люди, которые делают новые интеграции — это разные люди, с разной квалификацией и опытом работы.” Дмитрий, значит вы слукавили о приоритетности задачи, либо у вас много неквалифицированного персонала, либо они опытные, но их не хватает. В чем именно проблема?
Видел надстройку. Двоякое отношение… С одной стороны круто, что это хоть кто-то реализовал. С другой — стыдно что это сделали не вы. Она появилась спустя 3 года, в апреле или чуть раньше.
Теперь вы пишите: “…острота вопроса с получением данных во многом снимается…”
То есть вы не собираетесь реализовывать “…в ближайшее время” (то что было “важно многим” несколько лет и было на первых местах в планах) прямую интеграцию и понижаете приоритет интеграции (на эмпирическом уровне я делаю вывод, что этого не произойдет), так как появилась альтернатива одного из ваших интеграторов?
Выглядит немного странно, но я бы предпочел прямой ответ типа: “да, мы подумали, что интеграторам надо зарабатывать, не чураемся этого, потому это решение мы представим в качестве официального и рекомендуем”. Грубо, честно и, если он с вами делится прибылью , оправдано.
“Конечно, это не отменяет наших планов “.
Дмитрий, планы без проставленных дат — это мысли. Мысли эфемерны и не стоят ничего. Следовательно, вся это переписка, какие-то обещания с вашей стороны ни на чем не основываются и приближены к пустой болтовне и тратой времени.
Спасибо за подробное изложение своих ощущений, Иван. Не буду отвечать пространно на все Ваши посылы, т.к. каждый следующий уровень комментариев отображается еще более узким столбцом и длинный текст становится неудобочитаемым. Попробую тезисно:
– Существуют разные системы планирования. Мы используем agile-подобную методику, которая не подразумевает точных планов со сроками на годы вперед. Именно в этим связана размытость наших (и моих в частности) ответов на любые вопросы по срокам.
– При этом у методики есть важное преимущество – она позволяет нам быть очень гибкими.
– Методика подразумевает разную скорость продвижения по каждому из направлений развития продукта. Основная движущая сила при этом – количество запросов пользователей на ту или иную возможность. То, что Вы наблюдаете с “долгостроем”в плане интеграции с dadata, в первую очередь связано с малым количеством таких запросов. Когда их много, приоритет направления или конкретной задачи возрастает. Когда мало – падает. Поэтому представление о сроках в любой момент времени “плавает”, даже на уровне ощущений “скоро – не скоро”. Что-то конкретное можно сказать только в момент, когда задача уже взята в работу.
– По задаче с интеграцией с dadata можно сказать, что она одна из первых в своем направлении, но в работу не взята. Что делает прогноз сроков по ней оптимистичным (теоретически в любой момент мы можем за нее взяться), но все таким же расплывчатым (если запросов будет все так же мало, “светлое завтра” может еще долго не наступить).
– О нашем подходе к планированию мы хотели рассказать на весенней партнерской конференции. Жаль что ее пришлось отменить, а так бы дал ссылку на видео и это помогло бы лучше этого пережатого описания.
Не знаю, насколько Вам все эти объяснения в принципе интересны – не удивлюсь, если совсем не. Просто пытаюсь рассказать все как есть, чтобы было хоть какое-то понимание о том, как мы работаем и чего стоит ждать (или не ждать) от команды ПланФикса.
Я знаком с методологией agile. И у него есть свои минусы.
Вы поставили меня в положение “…это нужно только вам и еще вон тем двум…”.
Расскажите, как вы считаете спрос на доработки? Как составляете рейтинг? На вашем форуме тема “Интеграция с сервисом dadata.ru” самая просматриваемая.
Предлагаю перенести общение по этому поводу на форум, а то тут мы удаляемся от темы топика, да и место в комментариях заканчивается) Создайте отдельную тему в подходящем разделе и поговорим по поводу того, как принимаются решения о продвижении в очереди разработки той или иной задачи.
Иван, а что вам мешает пользоваться надстройкой здесь и сейчас, пока не выйдет интеграция ПланФикса, если это один из важных для вас моментов?
простите, за 3 года…с половинкой
По моему, Дмитрий очень хорошо прояснил всю ситуацию – данный вопрос неактуален – реализация отложена на неопределенный срок.
Сам долго ждал данной реализации, но таких, Иван, как мы с Вами, уверен очень немного. И здесь, Дмитрий прав – если нет достаточно запросов – то реализация просто откладывается – так как нет оснований считать данную ветвь потенциально прибыльной.
С другой стороны, я соглашусь с Иваном, здесь лучшая стратегия – это правда, какая есть. Если вопрос подвисает – через контрольный срок объявить, что так мол и так – вопрос пока не актуален, потому реализация откладывается на неопределённый срок. Это всегда, повторюсь – всегда решает все вопросы с обратной связью клиентов. Либо принимаешь, как есть либо уходишь в сторону. Но практика показывает, что если клиент вовлечен в проект, так или иначе, нужна будет очень основательная причина для выхода из него. Эта задача к такой причине конечно не относится.
Но, как говорил наш самый известный летчик-испытатель АС Пушкин, все это – “сын ошибок трудных”, который приходит через время ).
Вижу, что попытки коротко объяснить достаточно сложную тему о том, как продвигаются задачи в очереди, у меня не получилось. Выше предложил Ивану создать отдельную тему по этому поводу на форуме, готов продолжить общение по этому поводу там.
Я бы рад, но форум не дает мне создать тему или отвечать на какие-либо комментарии.
Такое может быть, если у Вас нет регистрации в ПланФиксе. В таком случае доступен только раздел “Вопросы от незарегистрированных пользователей” https://forum.planfix.ru/viewforum.php?f=5 – можно воспользоваться им.
да нет, я зарегистрирован. В разделе «Вопросы от незарегистрированных пользователей» я так же не могу ничего написать.
Войти получается? http://joxi.ru/l2ZXM8UEJR1DrJ
да, я под своим аккаунтом
https://prnt.sc/txpq39
Поставьте, пожалуйста, отдельную задачу в Службу поддержки по этому поводу – мы выясним детали и разберемся, почему у Вас так происходит.
отправил.
пока молчание.
возможно проблема в правах пользователя. Это не проблема браузера или кэша.
Запишите и мой голос в список ожидающих обработку POST запросов и вообще обработку комментариев по принципу как реализована обработка email с инфоблоками. Инфоблоки ещё вчера нужны были в автоматических действиях, и при помощи них обрабатывать POST запросы.
Спасибо, Александр. Эта работа идет, она представляет собой цепочку связанных задач, реализация которых в итоге приведет в том числе к появлению возможности обработки результатов POST-запросов.
Обработка POST запросов частично может решить отсутствие интеграции с DaData.
Сотрудник DaData писал о такой возможности:
https://support.dadata.ru/communities/1/topics/2517-modul-dlya-planfiksa?lang=ru