في العام الماضي ، اتصل بنا مدير تكنولوجيا المعلومات لإحدى أكبر الحيازات الصناعية الزراعية في روسيا. كان نهج العمل الذي نفذه عملائنا مثيرًا للإعجاب. كان من أوائل من نفذوا فكرة مؤسسة دورة كاملة - من الميدان إلى الرف في متجر البقالة. نظرًا لتوفر المنتجات وجودتها العالية ، أصبحت هذه الملكية علامة تجارية معروفة يعرفونها ويختارونها. في ذلك الوقت ، ضمت الشركة القابضة أكثر من 650 منفذاً وأكثر من 20000 موظف موزعين في جميع أنحاء الاتحاد الروسي.
احتاج العميل إلى ضمان تسليم الشيكات إلى المركز من جميع منافذ البيع بالتجزئة في روسيا ، بما في ذلك أكشاك الطعام في القرى النائية مع الإنترنت العرضي والحد الأدنى من الحوسبة.
نظرًا لهذه الخصوصية ، تحول حل المشكلة إلى مغامرة مثيرة مع الدف ، الشامان ومخالب الأرانب في مواجهة RabbitMQ. كيف قمنا ببناء مجموعة من قوائم الانتظار المتحدة وما واجهناه - تحت الخفض.
حول قضايا العملاء
طالب عقد مع عدد كبير من المنافذ الموزعة ، التي تعمل في ظروف المنافسة الشرسة ، قادتهم على اتخاذ قرارات الإدارة على الفور. لهذا ، يحتاج المديرون إلى معلومات حول الشيكات في وضع الوقت الحقيقي.
في النظام الحالي ، بلغ وقت تسليم الشيك من الصراف إلى النظام المركزي 3 أيام. في الوقت نفسه ، لم يتم تسجيل معلومات حول الشراء المثالي بشكل دوري (فقدان الشيك).
كان مطلوبًا تقديم معلومات حول المبيعات "هنا والآن" لتحسين توصيل المنتجات إلى المنافذ والاستجابة بسرعة للتغيرات في ميزان السلع والطلب. يجب أن تذهب هذه المعلومات في وقت واحد إلى IS المركزي للحيازة على أساس 1C وإلى كمبيوتر التاجر في متجر / منفذ معين.
بالإضافة إلى ذلك ، كان من الضروري التأكد من إعادة تقييم مركزية وتشغيلية للبضائع عبر الشبكة ، بالإضافة إلى توصيل نظام BI الخاص بالممتلكات بتدفق بيانات عبر الإنترنت من جميع المنافذ.
ونتيجة لذلك ، تم تشكيل معايير نجاح المشروع:
- يجب أن تكون الشيكات المثقبة في مكتب النقد في المتجر مرئية في نظام 1C المركزي في مدة لا تزيد عن ثانية واحدة من لحظة "وضعه المالي" في مكتب النقدية في وجود (اتصال) الاتصال ؛
- في حالة فشل الاتصال المؤقت ، تأكد من التسليم الفوري المضمون للشيكات إلى النظام المركزي بعد استعادة قناة الاتصال.
بالنسبة إلى فريق Silver Bullet ، كان هذا شيئًا مغريًا للغاية ، حيث أننا في ذلك الوقت طورنا بالفعل محول 1C لـ RabbitMQ والقدرة على إطلاقه في المعركة على مسافات كبيرة وجذبت الأحمال العقول العبقرية. إن مفهوم "موضع الشيك في المركز في ثانية واحدة" ليس جديدًا جدًا ، ففي عام 2013 قدمنا فكرة استخدام قوائم الانتظار في 1C ، بل واختبرناها على شبكة تجارية واحدة ، ولكن في ذلك الوقت كانت عكازات تجريبية للغاية ، والتي شملت ، بالإضافة إلى الأرنب + 1C لا يزال C # ، WCF وحتى القليل من C ++.
بالطبع ، كلنا تجسسنا عليه في كتب ذكية كتبت حتى قبل ذلك. لذلك ، لن أجرؤ على الحكم على وجه الدقة عندما بدأت فكرة الخطوط في مشاريع التكامل في السيطرة على العالم.
بطريقة أو بأخرى ، أثبت الجزء النظري والمفهوم المعماري فعاليتهما ، ولم يبق سوى القليل - للقيام بكل شيء ، واختبار ، وإصلاح الأخطاء ، وتوثيق ونشر. : trollface:
الغوص مع الرأس
لا أحد يعرف أكثر من صاحب العمل نقاط القوة والضعف ، لذلك تبدأ جميع مشاريع التكامل بمراجعة لعمليات العميل وفهم نقطة البداية (كما هي). عادة ، يشمل مسح الأعمال ما يلي:
- تحليل المعلومات حول كيفية سير العمليات التجارية الآن ؛
- جمع متطلبات النظام عن طريق إجراء مقابلات مع الموظفين الرئيسيين من أجل فهم كيفية ترتيب العمليات التجارية في رأيهم ؛
- إضفاء الطابع الرسمي على العمليات التجارية وتحسينها.
للقضاء على التناقضات ، نستخدم إضفاء الطابع الرسمي على AS IS والعمليات التجارية في شكل مخططات BPMN. من الأسهل فهمها بأنفسنا ، ومن الأسهل على العميل عدم تفويت أي شيء عندما نذهب إلى مخطط العملية معًا.
من الميزات الفنية ، خلال المراجعة وجدت أن:
- تستخدم المنافذ الأجهزة المستندة إلى Windows - مع تثبيت أنظمة تشغيل غير متجانسة (اعتمادًا على سنة الإنشاء) من Windows XP إلى Windows 7 و 8 و 10 ؛
- تقوم أجهزة تسجيل النقد بتشغيل برنامج Frontol الثابت مع Windows Embedded على اللوحة ؛
- تستخدم دائرة إدارة البيع بالتجزئة برامج غير متجانسة ، بما في ذلك الحلول من بائعي 1C والتطورات الخاصة بها ؛
- يتم تنفيذ قنوات الاتصال على أساس مبدأ "ما هو ،" في النطاق من خطوط الكابلات إلى أجهزة مودم صافرة USB ؛
- يتم تقديم منافذ البيع بالتجزئة من قبل شركات الاستعانة بمصادر خارجية محلية وليس من خلال خدمة قابضة مركزية ؛
- يعتمد عمل النظام بشكل كبير على إمكانية الخدمة (الأداء المناسب) لجهاز كمبيوتر مدير السلع في كل منفذ.

مخطط تكامل AS-IS
كما أظهر التدقيق أن العمليات التجارية للشركة لا تحتاج عمليا إلى تعديل ، ولكن يلزم تحسين البنية التحتية لضمان تدفق المعلومات دون انقطاع.
بشكل عام ، واجهتنا مهمة التسليم الموثوق للوثائق بين المكونات الثلاثة للعملية: تسجيل النقد وتاجر الكمبيوتر والمكتب المركزي. في نفس الوقت ، كمبيوتر التاجر هو آلة "تحت الطاولة". يمكن تشغيل / إيقاف تشغيله بناء على طلب التاجر. أو حتى يتم إيقاف تشغيله 23 ساعة من أصل 24. ومع ذلك ، عند مغادرة الغسق ، يجب أن يرى التاجر مجموعة حقيقية من الأسعار والأرصدة وعناصر المخزون وما إلى ذلك.
اختيار الحل ، وجمع أشعل النار ووضع العكازات
أصبح تكامل قائمة الانتظار نمطًا شائعًا منذ فترة طويلة. عندما تحتاج إلى نقل شيء ما إلى مكان ما ، مع وجود العديد من الروابط ، في بيئة غير موثوق بها ، وتدفقات بيانات المسار في نفس الوقت ، فأنت بحاجة إلى أحداث وقوائم انتظار. لذلك ، اخترنا RabbitMQ ، لأنه يندمج بسهولة في أي بيئة (على ما يبدو لنا) ، بما في ذلك النظام الأساسي 1C ، والذي كان لدينا بالفعل محول خاص بنا لبروتوكول AMQP.
RMQ هو نوع من إدارة تدفق البيانات ويسمح بالتكامل في وضع الوقت "شبه الحقيقي" ، مع الحفاظ على اتصال ضعيف للأنظمة ، وتحمل الأحمال ، وما إلى ذلك ... خادم جيد ، في كلمة واحدة ، تمت كتابة الكثير عنه في حبري.
إحدى الميزات الرائعة هي التجميع خارج الصندوق والقدرة على بناء مجموعات الخادم الموزعة التي تعمل معًا.

لطالما أحببت الصور مع بنية التكامل على قوائم الانتظار. تتكون دائمًا من ثلاثة زهر ، في وسطها وسيط رسائل. فليكن مثل هذه الصورة في هذه المقالة ، حتى لا تنتهك الشريعة.
عند إنشاء المخطط ، نشأ السؤال - أين يجب أن يكون خادم قائمة الانتظار؟ ما هي الشروط التي يمكن أن ينتهي بها نظامنا؟ اكتشفنا أن هناك 5 حالات طوارئ لا يجب أن يتوقف فيها العمل.
- يتم تضمين كافة الكتل.
- المركز غير متصل ، هناك إمكانية الوصول إلى التاجر.
- التاجر غير متصل ، هناك وصول إلى المركز.
- معاق وتاجر ومركز.
- نظام 1C معطل.
يجب اختراق الشيكات في كل هذه المواقف ، لا يجب أن تتوقف التجارة. عند استعادة القناة - يجب أن تصل الشيكات إلى المشترك. دعني أذكرك أن نقطة البيع يمكن أن تكون أيضًا كشكًا ريفيًا. لا يوجد خادم منفصل مثبت يمكن تثبيت RMQ عليه. اتضح أن وسيط الرسائل يجب أن يكون مباشرة عند الخروج. الخوادم هي رفاهية غير مسموح بها ، والأرنب خفيف الوزن تمامًا ويمكنه العمل على محطة نقاط بيع صغيرة. فلماذا لا نعم؟
بالطبع ، لم نجعل POS العقدة الوحيدة لمجموعة RMQ ، لكننا وضعنا إحدى عقد الكتلة المتحد مباشرة على منصة التداول ، بتشغيل Windows Embedded. لقول هذا كان أسهل إلى حد ما من القيام به ، لكننا فعلنا ذلك بمرح وتهور. ما سأخبرك به الآن.
كيفية وضع محطة RMQ فرونتول
يجب أن أقول أن Erlang وخادم RMQ وصلوا إلى محطة Windows تقريبًا دون مشاكل. نشأت مشاكل في العميل ، والتي يجب أن تتفاعل مع الخادم من برنامج تسجيل النقدية.
يحتوي برنامج تسجيل النقد الخاص بـ Frontol على وثائق جيدة إلى حد ما ، اكتشفنا من خلالها أنه من الممكن تخصيص السلوك باستخدام جافا سكريبت. يوهو! - قلنا وبدأنا في google عميل JS لـ RabbitMQ. سرعان ما أصبح من الواضح أن المشكله كان ينتظرنا. في الأمام ، ليس جافا سكريبت تمامًا. حسنًا ، أي من الناحية الرسمية ، نعم ، بناء الجملة هو نفسه هناك ، ولكن آلة جافا سكريبت نفسها من Windows Script Host ، وهي نفسها VBScript و cscript.exe والمزيد. باختصار ، إنه قديم جدًا ، خاص بـ Microsoft ، ولن يعمل عليه عميل JS أرنب عاقل واحد.
ومع ذلك ، في النظام البيئي WSH ، يمكنك استخدام كائنات COM ، واتجهنا نحو عميل RMQ لـ .NET .
لم تعد الإصدارات الحديثة من هذا العميل تدعم NET 3.5 ، التي كانت متاحة لنا على جهاز نقطة البيع ، ولكن لحسن الحظ ، كود المصدر الخاص بالعميل مفتوح ، وإلى جانب ذلك ، احتفظت علامات المشروع في github للمشروع والتي لا تزال تدعم NET 3.5. المجد للمصدر المفتوح! بقي لتفرغ التعليمات البرمجية المصدر للإصدار القديم من عميل .NET ، والتحقق من مربع الاختيار Com-Visible هناك ونشره إلى المحطة الطرفية.
تفاعل الخروج فرونتول
برنامج تسجيل النقدية لديه واجهة برمجة التطبيقات التي يمكن استخدامها للتفاعل.
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();
قدرات JS الأصلية الموجودة على نظام Windows ضعيفة للغاية. على سبيل المثال ، لا يوجد 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 - وضع خادم الاتحاد بحيث يتم تسليم الأحداث إلى جميع المستلمين ؛
- بقاء مكتب النقدية المحلي - إذا حدث حدث عند الخروج ، فيجب تسليمه على أي حال ، حتى إذا لم يكن مكتب النقد في الوقت الحالي متاحًا على الشبكة ؛
- موفران للبيانات - في الوضع العادي ، يتم تسليم البيانات من خلال الخادم (كمبيوتر التاجر) ، إذا كان كمبيوتر التاجر غير متاح (نتيجة لحادث أو لأسباب أخرى) ، يقوم أمين الصندوق بتسليم التسليم ، عندما يتم تشغيل جهاز الكمبيوتر الخاص بالتاجر ، سيتلقى الجزء الخاص به من الأحداث بعد المركز ، ولكن مضمونة
- RMQ - خدمة خادم RabbitMQ مع منافذ TCP مفتوحة للتجميع والمراسلة ؛
- لضمان التسليم المضمون للرسائل ، يتم تطبيق تكرار تدفق البيانات. هذا يقلل من تأثير اتصالات الشبكة بين عقد النظام ؛
- في 1C: في المركز ، تقرر تثبيت مجموعة من خوادم RMQ في وضع HA - توفر عالي للخادم المركزي ، بما في ذلك. هناك حجز مزدوج وتكرار الحدث ، لضمان التسليم.

وفقًا للحل المعماري ، تم إنشاء مخطط تدفق البيانات التالي:
- Frontol، 1C - نقاط البداية والنهاية للتبادل - الأشياء التي هي مصادر ومستقبلات الرسائل ؛
- قائمة الانتظار المتحدة - نوع خاص من قائمة الانتظار يسمح لك بإنشاء نظام موزع لإرسال الرسائل ، حيث يمكن نشر قائمة الانتظار في العقدة الموجودة في المخرج (أعلى التيار) ، واستلامها من قائمة الانتظار في المركز (أسفل التيار). لإرسال الرسائل من المنبع إلى المصب ، يتم تثبيت مكون إضافي خاص (الاتحادية PlugIn) على خادم قائمة الانتظار المركزي ؛
- مجرفة - (حرفيا "مجرفة") - آلية لنقل الرسائل من كائن (قائمة الانتظار) إلى آخر. يمكن أن تنتمي الكائنات إلى خادم واحد أو مختلف ؛
- توفر بنية النظام إدارة النشر عن بُعد ، أي القدرة على تثبيت خوادم RabbitMQ على أي جهاز كمبيوتر في الشبكة القابضة من مركز واحد ؛
- يتم إجراء التكوين والاتصال بالاتحاد باستخدام ما يسمى بالبرامج النصية لما بعد التثبيت ، والتي تأتي بشكل قياسي مع تسليم خوادم RMQ ، مع التكوين الضروري لمعلمات الشبكة المقبولة على شبكة العميل.
توفر الدائرة الناتجة خصائص السرعة المطلوبة وتعمل بثبات عند سقوط أي من المكونات. بعد فقدان الاتصال واستعادته ، تنتقل البيانات المتراكمة إلى المركز خلال 5-10 ثوانٍ. من الناحية العملية ، أثبتت تقنية الأنظمة المترابطة بشكل غير فعال فعاليتها. تحدث جميع الأحداث كما لو كانت في مكتب واحد ، دون مراعاة الأنواع المختلفة من التأخيرات المرتبطة بالتوزيع الإقليمي والدرجة المختلفة لتوافر قنوات الاتصال المتأصلة فيه.
استنتاج موجز
أود أن أستمتع بشكل منفصل بوقت مدهش نعيش فيه. في الآونة الأخيرة ، كان استخدام المصدر المفتوح في منتج ما نوعًا من الزهد. "هل يعمل برنامج المصدر المفتوح؟" فكيف تحب هذا الصبار؟ " اليوم ، هذا هو المبدأ المطلق.
لا يمكنني تخيل شركة ليس لديها منتجات مفتوحة المصدر في المنتج. بفضل توافر المعلومات والبرمجيات مفتوحة المصدر ، أصبح تنفيذ أفكار الأعمال أسهل وأسرع. هل تحتاج إلى وضع RMQ على جافا سكريبت و Windows المخصصين؟ لا يوجد شيء أسهل. حل googled غير مناسب قليلا؟ - انظر كيف يتم ذلك وإضافة المفقودين. يتم تقليل الوقت المستغرق في السوق عند استخدام المنتجات المفتوحة بشكل كبير. ويعلم الجميع أن الإصدار السريع للحل يعني ميزة تنافسية.
تتيح Github و Stackoverflow والتوثيق والمعايير المفتوحة إمكانية البدء في غضون أسابيع بما قد يتطلب سابقًا سنوات عديدة من الخبرة في مختلف مجالات المعرفة بالكمبيوتر.
وبالطبع ، من دواعي سرورنا بشكل خاص أن يخرج مجتمع الاسم المستعار 1C من عالمه المغلق كل عام ويدمج في تكنولوجيا المعلومات العالمية. على سبيل المثال ، تعد "1C: Enterprise" اليوم واحدة من اللغات الرسمية التي تدعمها Github ، وقد قام أشخاص من مجتمع 1C "بتدريسها" لهذه اللغة. ربما تستحق هذه القصة مقالة منفصلة ، ربما سأكتبها يومًا ما. في هذه الأثناء - كل التوفيق والتوفيق!
شكرا على وقتك!