去年，俄罗斯最大的农产工业公司之一的IT主管与我们联系。 客户实施的业务方法令人印象深刻。 他是最早实施全周期企业构想的人之一-从杂货店的田间到货架。 由于产品的可用性和高质量，该控股公司已成为他们了解和选择的公认品牌。 当时，这家公司拥有650多个网点，并在整个俄罗斯联邦分布着20,000多名员工。
客户需要确保从俄罗斯的所有零售商店，包括偏远村庄的食品摊，以偶尔的Internet和最少的计算机化，以最快的速度将支票送到中心。
考虑到特定的细节，该问题的解决方案变成了令人兴奋的冒险，手鼓，萨满和兔子腿面对RabbitMQ。 我们如何构建一个联合的队列集群以及遇到的问题-切入。
关于客户问题
在竞争激烈的情况下，拥有大量分布的网点的公司要求其领导者迅速做出管理决策。 为此，管理人员需要实时模式下的支票信息。
在当前系统中，支票从收银员到中央系统的交付时间达到3天。 同时，没有定期记录有关完美购买的信息（支票丢失）。
要求“现在和现在”提供有关销售的信息，以优化产品到网点的交付，并快速响应商品和需求平衡的变化。 此信息应同时发送到基于1C的公司的中央信息系统，并同时发送到特定商店/商店中的销售商的计算机。
此外，有必要确保通过网络对商品进行集中和可操作的重估，以及将来自所有销售点的在线数据流连接到控股公司的BI系统。
结果，形成了项目成功的标准：
- 从商店的收银台打孔的支票应该在中央1C系统中可见，从存在通信（通讯）的收银台“财务化”之日起不超过1秒；
- 如果出现临时通信故障，请确保在恢复通信通道后立即保证将支票交付给中央系统。
对于Silver Bullet团队来说，这是一件非常诱人的事情，因为那时我们已经为RabbitMQ开发了我们的1C适配器，并且能够在远距离和高负载下将其投入战斗的能力引起了众人的关注。 “在1秒内将支票放在中心位置”这个概念并不是什么新鲜事物，早在2013年，我们就提出了在1C 中使用队列的想法 ，甚至在一个交易网络上对其进行了测试，但是当时这是非常实验性的拐杖，除了Rabbit之外，还包括+ 1C仍然是C＃，WCF甚至是C ++。
当然，我们都在更早编写的智能书中对此进行了监视。 因此，我不会冒险确切地判断集成项目中的生产线何时开始风靡全球。
无论如何，理论部分和体系结构概念已经证明了它们的有效性，仅差一点就可以完成所有工作，测试，修复错误，记录和部署。 ：trollface：
潜水头
没有人比企业主更了解其优势和劣势，因此所有集成项目都始于对客户流程的审核和对起点的理解（按原样）。 通常，业务调查包括：
- 分析有关业务流程如何进行的信息；
- 通过采访关键员工来收集系统需求，以了解他们认为应该如何安排业务流程；
- 正式化和优化业务流程。
为了消除差异，我们以BPMN方案的形式使用AS IS和TO BE业务流程的形式化。 我们自己更容易理解它，并且当我们与他一起浏览流程图时，客户也很容易不遗漏任何东西。
从技术功能来看，审核期间发现：
- 网点使用基于Windows的计算机-已安装从Windows XP到Windows 7、8、10的异构操作系统（取决于创建年份）；
- 收银机运行Frontol固件，并带有Windows Embedded；
- 零售管理电路使用异构软件，包括来自1C供应商的解决方案及其自身的开发；
- 通信通道是根据“即是”原理实现的，范围从电缆线到USB口哨调制解调器；
- 零售店由本地外包公司提供服务，而不是由集中控股服务提供服务；
- 系统的功能基本上取决于每个出口处商品管理器计算机的可维护性（适当的功能）。
AS-IS整合方案
审计还表明，实际上无需调整公司的业务流程，但需要完善基础架构以确保信息流不中断。
总的来说，我们面临着在流程的三个组成部分之间可靠地交付文件的任务：收银机，计算机销售商和中央办公室。 同时，售货员的计算机是“桌子下面”的机器。 可以根据售货员的要求将其打开/关闭。 甚至在24小时中的23小时被关闭。 但是，离开黄昏时，销售商必须看到一组实际的价格，余额，库存项目等。
选择解决方案，收集耙子并放置拐杖
队列集成早已成为一种常见的模式。 当您需要在不可靠的环境中通过许多链接在某个地方传输某些东西并同时路由数据流时，您需要事件和队列。 因此，我们选择RabbitMQ是因为它可以轻松集成到任何（在我们看来）环境，包括1C平台，对此我们已经拥有自己的AMQP协议适配器。
RMQ是一种数据流管理器，它允许在“几乎实时”的时间模式下进行集成，同时保持系统之间的弱连接，承受负载等，等等。一句话，好的服务器已经在Habré上写了很多。
出色的功能之一是开箱即用的群集以及构建可协同工作的分布式服务器群集的功能。
我总是喜欢队列中集成架构的图片。 它们始终由三个骰子组成，其中心是一个消息代理。 让这样的图片出现在本文中，以免违反规范。
在构造方案时，出现了一个问题-队列服务器应位于何处？ 我们的系统最终会处于什么条件？ 我们发现有5种紧急情况下不应停止工作。
- 包括所有块。
- 中心已断开连接，可以使用推销员。
- 残疾商人，可以进入中心。
- 残疾人士和推销员及中心。
- 禁用的1C系统。
在所有这些情况下的检查都必须突破，贸易不应该停止。 恢复频道时-支票必须到达订户。 让我提醒您，销售点也可以是农村摊位。 没有安装可以安装RMQ的单独服务器。 原来，消息代理应该直接在结帐处。 服务器是不允许的奢侈品，Rabbit相当轻巧，可以在小型POS终端上工作。 那为什么不呢？
当然，我们并不是使POS成为RMQ群集的唯一节点，而是将联邦群集的节点之一直接放在运行Windows Embedded的交易终端上。 要说这比做起来容易一些，但我们乐于不顾一切地做到了。 我现在要告诉你。
如何放置RMQ终端Frontol
我必须说，Erlang和RMQ服务器本身到达Windows终端几乎没有问题。 客户端出现问题，客户端应通过收银机软件与服务器交互。
Frontol收银机软件具有相当好的文档，从中我们发现可以使用Java脚本自定义行为。 “玉湖！” -我们说过并开始为RabbitMQ谷歌JS客户端。 很快就知道，无赖在等着我们。 在最前面，不是Java语言。 好吧 正式地，是的，语法在那里是相同的，但是JavaScript机器本身来自Windows Script Host，同一机器是VBScript，cscript.exe等。 简而言之，它非常老，是特定于Microsoft的，并且没有一个健全的Rabbit JS客户端可以在其上工作。
但是，在WSH生态系统中，您可以使用COM对象，而我们将转向.NET的RMQ客户端。
该客户端的现代版本不再支持POS终端上可用的.NET 3.5，但是幸运的是，该客户端的源代码是开放的，此外，该项目的github保留了仍支持.NET 3.5的标签。 开源荣耀！ 剩下的工作是缩小.NET客户端的旧版本的源代码，选中其中的Com-Visible复选框，然后将其部署到终端。
Frontol结帐互动
收银机软件具有可用于交互的API。
function init() { frontol.addEventListener("openDocument", "beforeOpenDocument", true); frontol.addEventListener("closeDocument", "beforeCloseDocument", true); frontol.addEventListener("closeDocument", "afterCloseDocument", false); frontol.addEventListener("closeSession", "beforeCloseSession", true); frontol.addEventListener("closeSession", "afterCloseSession", false); addPolyfills();
Windows上的本机JS的功能非常差。 例如，没有Array.indexOf或JSON.stringify。 但是世界上并非没有好人。 我们想起了流行的基于浏览器的拐杖，名为“ polyphillas”，并愉快地将它们内置到收银台中。 撇开这些笑话，JS的所有魔术技巧都经过了精心细致的评论，以便以后的下一代管理员可以清楚，快速地了解正在发生的事情，发生的地方以及它的工作方式。
很快就很清楚，JS-API并不涵盖部分情况，但是，由于Frontol包含Firebird DBMS，并且有ODBC提供程序，因此我们可以使用Javascript使用Javascript直接联系收银员的数据库在那获取我们需要的数据。
function afterCloseSession() { var connection = getDatabaseConnection(); var qSelect = new ActiveXObject("ADODB.Command"); qSelect.ActiveConnection = connection; qSelect.CommandText = "SELECT ChequeNumber " + "FROM Document " + "WHERE " + " State = 1 " + " AND(ChequeType IN(0, 1, 2)) "
最后，直接从我们的JS与队列服务器一起工作看起来像这样：
function createRMQConnection() { factory = new ActiveXObject("RabbitMQ.Client.ConnectionFactory"); factory.UserName = rmqUser; factory.Password = rmqPass; factory.VirtualHost = "/"; factory.HostName = "localhost"; try { rmqConnection = factory.CreateConnection(0); } catch (e) { throw new Error(" . !\n" + e.message); } rmqChannel = rmqConnection.CreateModel(); rmqMessageProperties = rmqChannel.CreateBasicProperties(); rmqMessageProperties.ContentType = "text/plain"; rmqMessageProperties.ContentEncoding = "string"; rmqMessageProperties.DeliveryMode = 2; }
解决方案的整体情况
在体系结构中已经确立了以下原则：
- RabbitMQ服务器联合-RMQ-联合服务器模式，以便将事件传递给所有接收者；
- 本地收银台生存-如果结帐时发生了某个事件，则无论如何都必须交付该事件，即使此时无法通过网络访问收银台；
- 2个数据提供者-在正常模式下，数据是通过服务器（跟单员的计算机）传递的，如果跟单员的计算机不可用（由于事故或其他原因），则收银员会进行传递，当推拿员的计算机打开时，他将晚于中心接收事件的一部分，但是保证
- RMQ-服务RabbitMQ服务器，具有用于群集和消息传递的开放TCP端口；
- 为了确保有保证的消息传递，将应用数据流冗余。 这样可以最大程度地减少系统节点之间网络连接的影响。
- 在1C：Center中，决定以HA模式安装一组RMQ服务器-中央服务器的高可用性，包括。 有双重保留和事件复制，以确保传递。
根据体系结构解决方案，创建了以下数据流程图：
- Frontol，1C-交换的起点和终点-消息的源和接收者的对象；
- 联合队列-一种特殊的队列，可让您创建用于发送消息的分布式系统，在该系统中，可以在出口（上游）的节点中发布队列，并从中心（下游）的队列中接收消息。 为了从上游向下游传输消息，在中央队列服务器上安装了一个特殊的插件（Federation PlugIn）。
- 铲子-（直译为“铲子”）-一种将消息从一个对象（队列）传输到另一个对象的机制。 对象可以属于一台服务器，也可以属于其他服务器。
- 系统体系结构提供了远程部署管理，即能够从单个中心在保持网络中的任何计算机上安装RabbitMQ服务器；
- 配置和与联盟的连接是使用所谓的“安装后”脚本进行的，该脚本是RMQ服务器交付时的标准配置，并且对客户网络上接受的网络参数进行了必要的配置。
所得电路可提供有序的速度特性，并且在任何组件掉落时都能稳定工作。 连接丢失并恢复后，累积的数据将在5-10秒内到达中心。 在实践中，松耦合系统技术已证明其有效性。 所有事件都好像在一个办公室中一样发生，而没有考虑与领土分配相关的各种类型的延迟以及内部固有的各种可用通信渠道。
简要结论
我想分别享受我们所生活的美好时光。 最近，在产品中使用开源是一种禁欲主义。 “您的开源软件可以工作吗？” 那么，您如何看待这个仙人掌？” 今天，这是绝对的准则。
我无法想象一家产品中没有开源产品的公司。 由于信息的可用性，开源软件的实现，业务构想的实现变得越来越容易和快捷。 是否需要在古老的自定义Javascript和Windows上放置RMQ？ 没有什么比这更容易了。 用谷歌搜索的解决方案有点不合适吗？ -查看完成情况并添加缺失内容。 使用开放产品的上市时间大大减少。 每个人都知道，快速发布解决方案意味着竞争优势。
Github，Stackoverflow，开放文档和标准允许在几周内启动以前需要在计算机知识各个领域拥有多年专业知识的软件。
当然，让1C昵称社区每年走出封闭的世界，并融入全球IT领域，这一点尤其令人高兴。 例如，今天的“ 1C：企业”是Github支持的官方语言之一，而来自1C社区的人们则将其“教”了这种语言。 这个故事可能值得单独写一篇文章，也许我有一天会写。 同时，祝您好运！
感谢您的宝贵时间！