Какими могут быть способы использования метода log.blogpost.add? Вы можете создавать пост в ЖЛ "на лету", преобразуя данные, вводимые пользователем, но сейчас мы рассмотрим другую возможность - публикацию данных на портале путем запроса "снаружи". На внешнем сервере вы можете сформировать данные для сообщения из любого источника (в нижеследующем примере мы получим их по http) и передать их в виде REST-запроса на портал. Эта схема позволит отправлять данные по расписанию, то есть, по сути, реализовать иными средствами функционал модуля "Импорт данных из внешних источников".
[spoiler]
Итак, мы имеем портал на bitrix24 и внешний сервер (не обязательно с установленной системой в Битрикс).
Скрипт публикации на внешнем сервере должен "знать" следующие данные (вместе с небольшим API мы выделили их в скрипт config.php (он приложен к данному сообщению и сохранили значения в виде констант):
CLIENT_ID - ID приложения, можно получить в партнерском кабинете автора приложения CLIENT_SECRET - секретный ключ приложения, можно получить в партнерском кабинете автора приложения APP_SERVER - доменное имя сервера приложения (например, 'http://site.com') APP_FOLDER - папка, в которой расположен скрипт на сервере приложения (например, '/app_folder/') REDIRECT_URI - APP_SERVER.APP_FOLDER SCOPE - разрешения приложения (например, 'log,user,department,sonet_group') PROTOCOL - протокол для обращения к порталу ('https://') |
Как было сказано выше, формируем небольшую библиотеку методов:
<?php function redirect($url) // перенаправление запроса { ... } function query($method, $url, $data = null, $jsonDecode = false) // построение запроса с REST-методом к порталу { ... } function call($domain, $method, $params) // выполнение запроса с REST-методом к порталу { ... } function build_message() // получение данных по http из источника и преобразование их в массив для передачи в REST-метод публикации в Живой ленте { ... } |
В данном примере мы получаем данные из двух источников:
1.
2.
Порядок реализации:
1. Регистрируем приложение, получаем ID приложения (CLIENT_ID) и секретный ключ приложения (CLIENT_SECRET)
2. Устанавливаем приложение на портал.
3. Регистрируем портал на сервере приложения:
- В браузере отправляем форму регистрации портала (указывая доменное имя портала - $_POST["portal"]
- В скрипте на сервере приложения перенаправляем запрос в браузере на сервер авторизации bitrix24.
$domain = $_POST["portal"]; $params = array( "response_type" => "code", "client_id" => CLIENT_ID, "redirect_uri" => REDIRECT_URI, ); $path = "/oauth/authorize/"; redirect(PROTOCOL.$domain.$path."?".http_build_query($params)); |
Теперь пользователь либо вручную авторизуется в текущей сессии браузера, либо авторизация "подхватывается" из сессии браузера. После получения авторизационных данных скрипт на сервере приложения устанавливает соединение с bitrix24 и получает, в том числе, токен для получения нового кратковременного авторизационного ключа:
// получаем ответ с bitix24 с параметрами авторизации if(isset($_REQUEST["code"])) { $code = $_REQUEST["code"]; $domain = $_REQUEST["domain"]; $member_id = $_REQUEST["member_id"]; $params = array( "grant_type" => "authorization_code", "client_id" => CLIENT_ID, "client_secret" => CLIENT_SECRET, "redirect_uri" => REDIRECT_URI, "scope" => SCOPE, "code" => $code, ); $path = "/oauth/token/"; $query_data = query("GET", PROTOCOL.$domain.$path, $params, true); // обращение к порталу if(isset($query_data["access_token"])) { // сохраняем на сервере приложения пару $domain / $query_data["refresh_token"] (домен / токен) die(); } } |
Этот токен необходимо сохранить на сервере приложения (вместе с доменом портала) для использования в дальнейшем.
4. Теперь, когда данные о портале зарегистрированы на сервере приложения, рассмотрим саму публикацию данных на портале.
Перед отправкой запроса с REST-методом получаем валидный авторизационный ключ (предполагаем, что предыдущий уже истек, т.к. срок его действия - всего один час. Впрочем, если еще не истек - ничего страшного, если мы получим новый):
$params = array( "grant_type" => "refresh_token", "client_id" => CLIENT_ID, "client_secret" => CLIENT_SECRET, "redirect_uri" => REDIRECT_URI, "scope" => SCOPE, "refresh_token" => $refresh_token, ); $path = "/oauth/token/"; // $domain и $refresh_token - сохраненный данные о портале $query_data = query("GET", PROTOCOL.$domain.$path, $params, true); // получаем новый авторизационный ключ if(isset($query_data["access_token"])) { $access_token = $query_data["access_token"]; // далее используем $access_token для запроса с REST-методом } |
5. Запрос с использованием REST-метода log.blogpost.add должен отправляться на зарегистрированный на сервере приложения портал bitrix24 ($domain) вместе с полученным ключом авторизации $access_token (напомним, срок его действия - один час).
$arPost = build_message(); // формируем данные для сообщения Живой ленты $data = call($domain, "log.blogpost.add", array( "auth" => $access_token, "POST_TITLE" => $arPost["TITLE"], "POST_MESSAGE" => $arPost["MESSAGE"], "FILES" => $arPost["FILES"] )); |
В данном примере мы публикуем сообщение на всех сотрудников, но если можно уточнить область видимости, передавая в массиве параметров сообщения ключ "SPERM" с нужным значением. По умолчанию это
array("UA") |
array( "U" => array("U1", "U2", "UA"), "SG" => array("SG1"), "DR" => array("DR4") ) |
в ключе U - пользователи c ID=1 и 2, а также все сотрудники
в ключе SG - рабочая группа c ID=1
в ключе DR - подразделение (и все подотделы) с ID=4
В результате мы имеем в живой ленте портала опубликованное сообщение:
config.php
(2.35 КБ)
Даже если я кажу UA - его получат все, кроме меня. Т.к. формально я автор. А я тоже хочу знать курс ММВБ и посмотреть GIF
Почему? Все, включая вас.
Если же хотите указывать в числе получателей себя персонально, помимо UA, используйте
где <N> - ID пользователя
Проблема в том, что сообщение отправляет "робот" и я-бы, как получатель, хотел получить уведомление. А так я получаюсь автором без уведомления.
То есть, речь идет не о правах на просмотр сообщения, а именно об уведомлении?
Могу в данном случае порекомендовать отправлять сообщения от специально созданного для этой цели пользователя. Именно из-под него нужно получить токен для авторизационного ключа.
Можно поподробное о прикреплении вложения. Или где возможно прочитать.
Ему не достаточно array("UA") ругается на то что нет получателей у сообщения. Если добавить юзера или группу то все проходит как надо.
Не получается найти информацию по взаимодействию php скриптов с REST API 1С-Битрикс24. В увиденных примерах - сперва должна открыться некая форма (в браузере), где пользователь вводит логин-пароль свой. Потом авторизуется, потом происходит его редирект обратно на сервер приложения. Это мне не подходит.
У меня есть купленный портал Битрикс24 (коробка), установлена на отдельном сервере, и есть ещё некая своя самописная внутренняя система компании, которая периодически должна отправлять необходимые данные в портал Битрикс. Никак не могу понять, как можно сделать, чтобы PHP-скрипты, запускаемые с помощью Cron на сервере самописной системы (то есть нет браузера, форма не отобразится, пароль никто не введёт) могли подключаться к порталу Битрикс24 и работать с API
А массив FILES как заполнять? У меня не получается корректного отображения файла.
А то пробовал разные методы. И не получается.