Дмитрий Гончаренко

Пост про POST

Новость короткой строкой: Мы научили автоматические сценарии отправлять POST-запросы.

Я понимаю, что это порадует только очень маленькое количество наших пользователей, которые знают, что такое POST-запросы и для чего они нужны. Для них, скорее всего, будет достаточно картинки:

Сценарий, отправляющий POST-запрос из ПланФикса в Telegram

Ну или такой:

Сценарий отправки POST-запроса из ПланФикса в SlackЕсли вам эта новость ни о чем не говорит, это нормально: большая часть взрослых образованных людей понятия не имеет о POST – да оно им, по большому счету, и не нужно. Единственное исключение – если у вас есть необходимость связать ПланФикс с другой своей корпоративной системой управления, возможно имеет смысл дать ссылку на этот пост своим айтишникам.

Дмитрий Гончаренко Команда ПланФикса

 

Извините, что сегодня такой малоинформативный пост – следующий будет интересней 🙂

64 комментария

  4. Дмитрий Гончаренко, а поля Постановщика/Исполнителя для POST можно будет развернуть как для Контрагента задачи? Чтобы, например, отправлять СМС контакту на номер мобильного телефона по какому-то событию…

    1. Обсудим это. Теоретически, это возможно, обычно возникает только одна проблема с такими полями: так как в них может содержаться несколько значений, непонятно, по какому из них отдавать дополнительные данные. А если отдавать по всем (исполнителям, к примеру), то непонятно, как адресоваться к ним.

  7. Потрясающе!
    Теперь просто дух захватывает от возможностей интеграции.
    О таком можно было только фантазировать 🙂
    Реальность – она лучше фантазий.

    А можно как-нибудь использовать возвращаемые результаты?
    К примеру возвращается
    {“result”:{“person_id”:2500767342}}
    или
    {
    “error”: “List \”New_listtt\” (id: 7068222) already exists”,
    “code”: “invalid_arg”,
    “result”: “”,
    “existing_list_id”: 7068222
    }

    На этапе отладки это сильно может помочь…
    Да и потом – такие данные могут пригодиться

        1. Такой подход мне кажется не очень удобным тем, что сложно будет собрать в одном месте запрос и ответ на него и управлять этим в одном интерфейсе. А настраивать в разных сложно, легко запутаться что, зачем и почему происходит.

      2. Выполняем Post-запрос с целью создания какого-то элемента в стороннем сервисе. Получаем web-ссылку на созданный элемент, или какой-то id. Заполняем кастомное поле задачи полученным значением.

        Может так?

        1. Ну вот мне тоже пришел в голову такой вариант + вариант создавать действие с текстом ответа. Оба варианта позволяют вызвать новые сценарии (на изменение задачи и на добавление нового действия), которые будут обрабатывать ответ и в зависимости от него что-то делать дальше.

          1. думаю, что для начала стоит просто создавать новое действие с текстом ответа.
            А где-нить в настройке действия “создавать post-запрос” сделать флажок “дополнительно создать действие с текстом ответа”.

            И на текущем этапе этого будет вполне достаточно.

            А все эти правила, кастомные поля… наверное тоже нужно, но с ними слишком уж сложно получается.
            Если уж это реально надо, то тогда ведь можно ваше API использовать.

    1. Ответы добавляются действием, а с текстом действия можно работать (если я, конечно. правильно понял о чем речь).

      А вообще, ветка дальнейшего развития по запросам такая:
      – Делаем механизм универсального разбора внешних данных (данные раскладываются в переменные, которые затем могут использоваться в сценариях). Это происходит прямо сейчас.
      – Распространяем действие этого механизма в том числе и на POST-запросы (а еще на правила для почты и интеграции).
      – Делаем механизм принятия GET-запросов – то есть, возможность сгенерировать ссылку, по которой может обратиться внешний сервис и прислать какие-то данные. Для таких запросов сразу будет подключен механизм универсального разбора, о котором я пишу выше.

      1. А есть ли планы по механизму _отправки_ GET-запросов? Чтобы сценарий мог тут же получить в ответ и обработать внешние данные.

        (да, я понимаю, что серверная реализация такого механизма значительно сложнее, чем реализация POST-запросов, ответ на которые сценарию ждать вообще не надо)

  9. Дмитрий, подскажите пожалуйста, когда планируется и планируется ли вообще добавить возможность обработки json ответов от post запросов в самом ПФ?

    1. Да, такие планы есть. В сентябре-октябре для всех станут доступны новые правила разбора писем, после этого мы займемся пасширением этого же механизма на ответы, приходящие на POST-запросы. При хорошем раскладе, к концу года можно будет попробовать это в работе.

      2. Здравствуйте, Дмитрий!

        >>>В сентябре-октябре для всех станут доступны новые правила разбора писем,

        Позволю себе заметить, что уже наступил ноябрь…

        >>>после этого мы займемся расширением этого же механизма на ответы, приходящие на POST-запросы.
        >>>При хорошем раскладе, к концу года можно будет попробовать это в работе.

        Или вы имели ввиду 2020 год?
        :)))

        1. Привет, Алексей!
          Сложная штука, находим все время новые нюансы в ходе тестирования, поэтому пока не выпустили. Планирую на следующей неделе в блоге анонсировать, посмотрим как получится.

  10. А можно ли добавить еще возможность авторизации по Oauth протоколу перед POST запросом с указанными данными?

    К примеру в результате работы нужно добавить контакт в список e-mail рассылки на стороннем сервисе (в нашем случае SendPulse).

    1. А почему не используете нативную интеграцию с 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

      1. Проблема интеграции с сервисами рассылки в том, что интеграция не отслеживает изменения, которые происходят с контактом, когда он попадает в список рассылки.

        К примеру в Mailchimp можно так настроить автоматизацию, что в зависимости от того, что пользователь делает (ну т.е. открывает письма, кликает по ссылке) – могут меняться какие-то свойства пользователя (ну т.е. он может попадать в другие списки рассылки, у него могут появляться какие-то теги или он может включаться в различные сегменты).
        Думаю, что в SendPulse есть аналогичные возможности.

        А ПФ – не умеет отслеживать эти изменения
        (о чём в справке отдельно написано).
        И это – ужасно.
        Приходится изобретать такие “костыли”, что просто жуть.

        А еще бывает так, что в список рассылки контакт попадает через форму рассылки на сайте. И тогда приходится обрабатывать две ситуации:
        1. контакт попадает в список рассылки с сервиса рассылки
        2. Контакт попадает в список рассылки через ПФ.
        И тут эти костыли становятся… вот совсем уж неудобными….

        (так… стеснительно…)
        Дмитрий, а можно попросить вас сделать двухстороннюю синхронизацию с сервисами рассылки?

          1. А для чего передавать все это назад в ПФ? Почему не вести триггерную рассылку средствами сервиса рассылки, а ПФ использовать для поставки контактов на “точку входа” рассылки?

            1. Рассылка – это часть “воронки продаж”.
              В некоем сферическом случае контакт может стать клиентом после завершения серии писем.
              Но чаще всего – не становится… И потому приходится его “дожимать” другими способами….

  11. Правильно ли я понимаю, что в POST нельзя передать данные из Инфоблока, то есть в случае если необходимо работать с данными попавшими в фильтр, то единственная возможность это использовать
    {{Действие.Текст.Без форматирования}}
    И уже на стороне получателя разбирать его и принимать решения ?

    1. Вообще, вскоре должна появиться возможность оперировать содержимым инфоблоков в переменных, в том числе вставляемых в POST-запросы.

    1. Напрямую нет, только помещая оивет в комментармй – иогда можно будет вылавливать ключевые слова в тексте оивета сценарием на событие «Добавлен комментарий». Но обязательно сделаем обрсбоиуу ответа в более удобоваримой форме, двигаемся к этому.

      1. Получается что dadata не подключается и за 2 года вы даже не приблизились к решению этой, цитирую: “приоритетной задачи”.
        Обращаться к dadata через post запросы нет смысла, потому что они не обрабатываются. Получается надо сооружать костыли.

        Как же вы долго реализуете действительно важный для бизнеса функционал.

        В телеграмме подписан уже год на вас с целью уловить хоть что-то связанное с заполнением реквизитов dadata, использования их в договорах…но вы то кнопку сделаете новую, то перекрасите старую, улучшите то, что улучшали месяц назад и по кругу.

        Я очень рад что вы развиваетесь, но когда мы просим реализовать вас с 2017 года нужный бизнесу функционал, а вы по прежнему прорабатываете и улучшаете то, что не поменяет особой погоды в работе — выглядит как издевательство.

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

        Конечно, пишу со своей колокольни и бла бла бла….кому-то это не надо…а ваши изменения здорово влияют на чей-то климат.

        1. Понимаю Ваши эмоции, Иван – наверное. со стороны это так и выглядит. На самом деле, люди, которые “красят кнопки” и люди, которые делают новые интеграции – это разные люди, с разной квалификацией и опытом работы. И те разработчики, кто до сих пор не сделали интеграцию с нужной Вам (и не только Вам) dadatой, это время занимались другими задачами, не менее важными.

          На приоритет интеграции оказывает влияние в том числе и то, что острота вопроса с получением данных во многом снимается наличием стороннего сервиса, который выполняет эту функцию: https://planfix.kireev-k.ru/automatic-completion-of-details.

          Конечно, это не отменяет наших планов и интеграция обязательно появится, как и разбор POST-запросов (он, скорее всего, раньше).

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

            Я четвертый раз регистрируюсь в планфикс с надеждой увидеть реализацию и окончательно перейти. Да, мне это не хватает и менять шило на мыло не имеет смысла.

            Каждый раз я спрашиваю: “когда…”. И уже четвертый раз получил ответ “в планах…”.

            Понимаете, если бы мне сообщили типа: “Иван, в планах есть, но через 5 лет…”, я бы, скорее всего, перешел бы на вас или нашел других, сделал бы пару костылей и был спокоен.
            Проблема как раз таки в том, что я не понимал…надо делать костыли и платить за их разработку, внедрение, поддержку…либо подождать пол года и все будет работать из коробки.
            Речь идет о целесообразности и эффективности использования денежных средств. Как и у вас у меня есть бюджет и т.д. и т.п.

            Не знаю как у кого, но в моем представлении (если речь идет не о космической программе) в планах — это ближе чем год, может месяцев восемь максимум…но не 3 года. Быть может я отстал от реалий, конечно, но интуитивно придерживался этих цифр.

            “Люди, которые «красят кнопки» и люди, которые делают новые интеграции — это разные люди, с разной квалификацией и опытом работы.” Дмитрий, значит вы слукавили о приоритетности задачи, либо у вас много неквалифицированного персонала, либо они опытные, но их не хватает. В чем именно проблема?

            Видел надстройку. Двоякое отношение… С одной стороны круто, что это хоть кто-то реализовал. С другой — стыдно что это сделали не вы. Она появилась спустя 3 года, в апреле или чуть раньше.
            Теперь вы пишите: “…острота вопроса с получением данных во многом снимается…”
            То есть вы не собираетесь реализовывать “…в ближайшее время” (то что было “важно многим” несколько лет и было на первых местах в планах) прямую интеграцию и понижаете приоритет интеграции (на эмпирическом уровне я делаю вывод, что этого не произойдет), так как появилась альтернатива одного из ваших интеграторов?
            Выглядит немного странно, но я бы предпочел прямой ответ типа: “да, мы подумали, что интеграторам надо зарабатывать, не чураемся этого, потому это решение мы представим в качестве официального и рекомендуем”. Грубо, честно и, если он с вами делится прибылью , оправдано.

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

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

              – Существуют разные системы планирования. Мы используем agile-подобную методику, которая не подразумевает точных планов со сроками на годы вперед. Именно в этим связана размытость наших (и моих в частности) ответов на любые вопросы по срокам.

              – При этом у методики есть важное преимущество – она позволяет нам быть очень гибкими.

              – Методика подразумевает разную скорость продвижения по каждому из направлений развития продукта. Основная движущая сила при этом – количество запросов пользователей на ту или иную возможность. То, что Вы наблюдаете с “долгостроем”в плане интеграции с dadata, в первую очередь связано с малым количеством таких запросов. Когда их много, приоритет направления или конкретной задачи возрастает. Когда мало – падает. Поэтому представление о сроках в любой момент времени “плавает”, даже на уровне ощущений “скоро – не скоро”. Что-то конкретное можно сказать только в момент, когда задача уже взята в работу.

              – По задаче с интеграцией с dadata можно сказать, что она одна из первых в своем направлении, но в работу не взята. Что делает прогноз сроков по ней оптимистичным (теоретически в любой момент мы можем за нее взяться), но все таким же расплывчатым (если запросов будет все так же мало, “светлое завтра” может еще долго не наступить).

              – О нашем подходе к планированию мы хотели рассказать на весенней партнерской конференции. Жаль что ее пришлось отменить, а так бы дал ссылку на видео и это помогло бы лучше этого пережатого описания.

              Не знаю, насколько Вам все эти объяснения в принципе интересны – не удивлюсь, если совсем не. Просто пытаюсь рассказать все как есть, чтобы было хоть какое-то понимание о том, как мы работаем и чего стоит ждать (или не ждать) от команды ПланФикса.

              1. Я знаком с методологией agile. И у него есть свои минусы.
                Вы поставили меня в положение “…это нужно только вам и еще вон тем двум…”.
                Расскажите, как вы считаете спрос на доработки? Как составляете рейтинг? На вашем форуме тема “Интеграция с сервисом dadata.ru” самая просматриваемая.

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

  14. По моему, Дмитрий очень хорошо прояснил всю ситуацию – данный вопрос неактуален – реализация отложена на неопределенный срок.

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

    С другой стороны, я соглашусь с Иваном, здесь лучшая стратегия – это правда, какая есть. Если вопрос подвисает – через контрольный срок объявить, что так мол и так – вопрос пока не актуален, потому реализация откладывается на неопределённый срок. Это всегда, повторюсь – всегда решает все вопросы с обратной связью клиентов. Либо принимаешь, как есть либо уходишь в сторону. Но практика показывает, что если клиент вовлечен в проект, так или иначе, нужна будет очень основательная причина для выхода из него. Эта задача к такой причине конечно не относится.

    Но, как говорил наш самый известный летчик-испытатель АС Пушкин, все это – “сын ошибок трудных”, который приходит через время ).

    1. Вижу, что попытки коротко объяснить достаточно сложную тему о том, как продвигаются задачи в очереди, у меня не получилось. Выше предложил Ивану создать отдельную тему по этому поводу на форуме, готов продолжить общение по этому поводу там.

    1. Поставьте, пожалуйста, отдельную задачу в Службу поддержки по этому поводу – мы выясним детали и разберемся, почему у Вас так происходит.

  16. Запишите и мой голос в список ожидающих обработку POST запросов и вообще обработку комментариев по принципу как реализована обработка email с инфоблоками. Инфоблоки ещё вчера нужны были в автоматических действиях, и при помощи них обрабатывать POST запросы.

    1. Спасибо, Александр. Эта работа идет, она представляет собой цепочку связанных задач, реализация которых в итоге приведет в том числе к появлению возможности обработки результатов POST-запросов.

Добавить комментарий