Слабая связанность и стабильность 1С решений

или управляемый хаос ИТ компонентов бизнеса
Меня пугает тяга текущих архитекторов 1С агрегировать всю функциональность необходимую для работы предприятия в одну систему. Причем я не против существования ERP, а даже за, но тяга "засунуть" все в одну систему на самом деле очень дорого обходится предприятию. Есть такой даже термин "совокупная стоимость владения", но сегодня не об этом.

Сегодня мы попробуем поговорить о другом "антипатерне" архитекторов - а именно об способе интеграции "точка-точка"
Суть патерна в следующем

  • поступает запрос бизнеса "необходимо интегрировать данные из A в B"
  • архитектор 1С, с высоты своего архитекторского взгляда, принимает решение интегрировать A в B напрямую
  • "занавес"
Протоколы интеграции могут быть любыми

  • файлы
  • COM коннектор
  • SOAP
  • HTTP
Самое главная особенность - это то что интеграция идет напрямую, без использования промежуточных решений.
Очень удачная схема отражающая принципы что получается при таком подходе к интеграции (взята с сайта https://zato.io/docs/intro/esb-soa.html)
И теперь становится понятным почему архитекторы так любят монолитные системы - кому охота получить такую схему в своей зоне ответственности.

Обычно в этом случае все вспоминают господина Фаулера с его Enterprise Integration Patterns
Но и в этом случае есть проблема: комплект продуктов для интеграции который в "простанародии" еще называют ESB или "шиной данных":

  • во первых - обычно стоит "много денежков"
  • во вторых - требует совершенно другого мышления при разработке

К вопросу о другом мышлении - например, резервирование товаров с сайта в Управлении торговлей, в ESB мире происходит в формате намерений, а не прямой постановке на резерв товара.
Намерение на резерв - это такой принцип резервирования внешней системой, при котором выполняется следующая последовательность действий

  • система A вызывает метод системы B - TryReserveGoodForOrderWith
  • передавая параметры - Order, GooId, Quantity, Callback
  • система B ставит намерение системы A в очередь на попытку резервирования
  • результат попытки отправляется по адресу указанному в параметре Callback

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

Для удобства давайте назовём её система R

G-Ones
ArchTeam
картинка взята с официальной документации RabbitMQ - читать тут
предположим у Вас сайт на PHP
тогда код вызова с помощью php-aqmp будет выглядеть так

<?php

require_once __DIR__ . '/vendor/autoload.php';
use PhpAmqpLib\Connection\AMQPStreamConnection;
use PhpAmqpLib\Message\AMQPMessage;

class OrderReserveRpcClient {
private $connection;
private $channel;
private $callback_queue;
private $response;
private $corr_id;

public function __construct() {
$this->connection = new AMQPStreamConnection('localhost', 5672, 'guest', 'guest');
$this->channel = $this->connection->channel();
list($this->callback_queue, ,) = $this->channel->queue_declare(
"", false, false, true, false);
$this->channel->basic_consume(
$this->callback_queue, '', false, false, false, false,
array($this, 'on_response'));
}
public function on_response($rep) {
if($rep->get('correlation_id') == $this->corr_id) {
$this->response = $rep->body;
}
}

public function call($Order, $GooId, $Quantity) {
$this->response = null;
$this->corr_id = uniqid();
         
$n = tojson($Order, $GooId, $Quantity)        
         
$msg = new AMQPMessage(
(string) $n,
array('correlation_id' => $this->corr_id,
'reply_to' => $this->callback_queue)
);
$this->channel->basic_publish($msg, '', 'rpc.warehouse.try.reserve,goods.for.order');
while(!$this->response) {
$this->channel->wait();
}
return intval($this->response);
};

$orderreserve_rpc = new OrderReserveRpcClient();
$response = $orderreserve_rpc->call(Order, GooId, Quantity);
echo " [.] Got ", $response, "\n";

?>
Важным моментом является нечто, которое находится в примере на адресе 'localhost' порту 5672 и имеющие пользователя и пароль 'guest', 'guest'. Как вы уже догадались, это и есть система R, и в моём случае это RabbitMQ
Остаётся только сделать так, чтобы на стороне 1С смог бы обеспечить ответ на данную попытку резервирования. Если вы внимательно изучили код выше, то уже поняли, что фактически мы должны обеспечить подписчика на очередь

rpc.warehouse.try.reserve,goods.for.order

В случае 1С мы используем наш продукт YellowRabbitMQ или наши же наработки в рамках курса по интеграции Старый курс по интеграции содержит ссылки на C# код сервиса для 1С и RabbitMQ
Таким образом я и достигаю "трёх вещей"

* сайт ничего не знает об 1С
* 1С ничего не знает о сайте
* сайт и 1С могут спокойно уходить "на обслуживание" и единственное что им надо знать, это имя очереди

rpc.warehouse.try.reserve,goods.for.order

причем, если завтра появится новый сайт - ему также нужно будет знать только имя очереди, и про команду 1С они в принципе знать ничего не будут.
АНОНИМ:
И вся статья ?
Silverbulleter:
Это не статья, а запись в блоге, чтобы понемногу описывать бизнес-сценарии использования AMQP в 1С, больше вопросов лучше задавать на форуме
Не забывай что есть возможноcть обсудить статью на форуме
Форум xDrivenDevelopment