Пост про POST

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

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

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

Ну или такой:

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

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

 

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

35 Comments

  1. Аватар

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

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

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

  2. Аватар

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

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

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

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

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

      1. Аватар

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

        Может так?

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

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

          1. Аватар

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

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

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

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

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

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

      1. Аватар

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

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

  3. Аватар

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

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

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

      1. Аватар

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

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

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

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

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

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

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

  4. Аватар

    А можно ли добавить еще возможность авторизации по 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. Аватар

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

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