Привет.
Нарисовалась одна проблемка которая ставит крест на очень интересном проекте.
Есть EmailService который принимает письма и делает кое какую сложную работу.
Делает он ее с использованием Tooling API. Вернее должен делать, но не делает 
Отдельно логика в EmailService без Tooling API работает прекрасно. И если вручную запускать метод с Tooling API он тоже отлично работает. Но вместе фуй.
Пробдема вот в чем - нужна sessionID. А в контексте EmailService UserInfo.getSessionId() возвращает null.
Кто сталкивался и может посоветовать что-нибудь. Буду признателен. Идеи с предварительным логином через OAuth/UsernamePassword не предлагать (пока это самый самый крайний случай). Может есть альтернативные способы получить sessioId или как-то по другому использовать Tooling API?
Класс, который висит на EmailService какой api имеет(версия) ?
все классы и package.xml 43.0
А что? Есть какие идеи?
Этой проблеме, судя по https://developer.salesforce.com/forums/?id=906F00000008wHAIAY, уже 9 лет.
Видимо этот процесс работает в неком "системном" контексте, хоть в настройках и есть Context User...
А что? Есть какие идеи?
Попробуй 34
Не, не помогло :(
Решил запилить специальную страницу которая будет получить (через пользователя) oauth token.
Смысл примитивнейший - VF страница со ссылкой на
https://login.salesforce.com/services/oauth2/authorize
и redirect_uri на эту же страницу чтобы перехватить токен и сохранить его.
Все работает чтобы получить access_token
НО мля нихрена не работает чтобы получить еще refresh_token. Что млять за фигня с этим SF?
В документации нашел
Если ставишь редирект к примеру
https://login.salesforce.com/services/oauth2/success
то рефреш токен приходит.
Если ставишь редирект на туже самую VF страницу пишет
error=invalid_scope&error_description=the requested scope is not available
Как можно получить refresh_token в SF?
Слушайте, а нет такой темы чтобы сгенерить access_token и refresh_token не особо напрягая пользователя. Он же у нас и так залогинен. Ну типа взять его sessionId и получить access_token и refresh_token. Хотя, да, пока писал понял что звучит бредово с точки зрения безопасности.
Эта страница должна быть публичная и в явнов виде прописана в настройках коннектед апп.
она и так прописана. Иначе ругается на return_url not match
А публичная это обязательно? Как то не сильно хочется заниматься гемороем с поднятием сайта и открытием страниц из пакета. Который собственно никак и не связан с сайтами или чем-то публичным. А в чем интересно собственно проблема с refresh_token? Почему проблема его вернуть при редиректе на VF?
О! Кстати нагугли и вспомнил старую задачу когда рефреш токен приходил (но приходил на внешний сервис).
Я тут играюсь с OAuth 2.0 User-Agent Flow (когда response_type=token), а есть еще OAuth 2.0 Web Server Authentication Flow (response_type=code) и в нем нет ограничений с refresh_token судя по документации.
Буду пробовать.
Wilder, у тебя случайно нет под рукой кода для OAuth 2.0 Web Server Authentication Flow (response_type=code) для Apex?
Замутил через
OAuth 2.0 Web Server Authentication Flow (response_type=code)
Refresh_token приходит.
Такая же проблема появилась, нужно в Email Web Service через Tooling API поменять email у Workflow Alert'a.
Dmitry Shnyrev в твоем решении есть какие-то ручные действия от пользователя? Или все автоматом происходит?
Да, есть ручные - юзверь(админ) должен пройти OAuth web flow чтобы получить Session и Refresh tokens и сохранить их в custom settings. Дальше Email Web Service использует эти токены (Session ID если он актуален или генерит новый с помощью Refresh Token, заменяет старый и использует его).
Печаль, в нашей задаче весь смысл автоматизации был в том, что пользователю ничего не надо делать руками .
Но все-равно спасибо.
Увы, в этом и проблема. Я не нашел способа. Нет в контексте Email Web Service SessionID, а значит к API не достучаться.
Ну только через Connected App
