كيفية إنشاء المستخدمين على العقدة الضلعية. قاعدة المعلومات الموزعة: الأساسيات. مبادئ التشغيل الأساسية لـ RIB

في كثير من الأحيان، من الناحية العملية، توجد مواقف عندما تكون الأقسام أو الفروع المختلفة موجودة جغرافيًا في أماكن مختلفة. وفي الوقت نفسه، يجب أن تصل البيانات المدخلة في البرنامج في الأقسام البعيدة بطريقة أو بأخرى إلى المكتب الرئيسي حتى يتم الاحتفاظ بالسجلات العامة.

حاليًا، يتم حل هذه المشكلة غالبًا من خلال تزويد الموظفين البعيدين جغرافيًا بإمكانية الوصول عن بعد إلى قاعدة بيانات مشتركة. ويمكن القيام بذلك عن طريق نشر قاعدة البيانات على خادم ويب، عبر سطح مكتب بعيد، وما إلى ذلك.

ومع ذلك، فإن المواقف ليست غير شائعة عندما لا يكون هناك إنترنت في مكتب بعيد جغرافيًا، أو عندما لا يكون مستقرًا بدرجة كافية للعمل في قاعدة بيانات معلومات مشتركة. ولهذا الغرض، لدى 1C آلية لإعداد قاعدة بيانات موزعة.

ببساطة، المكتب الرئيسي هو المكان الذي تقع فيه القاعدة الرئيسية. يستخدم القسم البعيد المرؤوس. قد يكون هناك العديد من قواعد العبيد هذه. ونتيجة لذلك، يتم دمج قاعدة البيانات الموزعة هذه في قاعدة بيانات واحدة من خلال المزامنة. يمكن أن يتم ذلك تلقائيًا وفقًا لجدول زمني أو يدويًا.

في هذه المقالة سننظر في إعداد قاعدة بيانات موزعة لـ 1C: Accounting 3.0. وعلى الرغم من ذلك، فإن التعليمات مناسبة لمعظم تكوينات 1C 8.3 الأخرى.

ملحوظةأن جميع تعديلات التكوين الضرورية يجب أن تتم فقط في قاعدة بيانات RIB الرئيسية. أثناء المزامنة، سيتم إرسال هذه التغييرات إلى كافة قواعد البيانات التابعة وتصبح سارية المفعول.

قاعدة المعلومات الرئيسية

عند استخدام قاعدة بيانات موزعة، تقع الإعدادات الرئيسية على قاعدة البيانات الرئيسية. يجب القيام بها في قسم "الإدارة"، كما هو موضح في الصورة أدناه.

في النافذة التي تفتح، حدد مربع الاختيار "مزامنة البيانات" على الفور. في الأسفل، حدد بادئة القاعدة الرئيسية (قاعدة البيانات الحالية). يمكن أن تتكون من حرفين لا أكثر. في حالتنا، ستكون البادئة "BG"، لأننا نعني أن RIB 1C هذا هو "المحاسبة الرئيسية".

يمكنك الآن البدء في إعداد المزامنة نفسها، أي تحديد قاعدة البيانات (أو قواعد البيانات) التي سيتم تبادل البيانات معها. للقيام بذلك، اتبع الارتباط التشعبي "إعدادات مزامنة البيانات". سيكون متاحًا للتنقل فقط إذا تم تحديد خانة الاختيار الموجودة على اليسار.

في النافذة التي تفتح، حدد "كامل..." من القائمة. سيسمح لنا بتحديد أي قاعدة معلومات 1C للمزامنة.

في النافذة الأولى لتوصيل قاعدة بيانات ثانوية، والتي تقع في مكتب بعيد جغرافيًا، حدد المربع الذي سيتم إجراء الاتصال من خلال دليل محلي أو دليل شبكة. في حالتنا هو "D:\DB\InfoBase". وسوف نتحقق أيضًا مسبقًا مما إذا كان بإمكانك الكتابة إليه.

تأكد من تحديد بادئات مختلفة لقواعد بيانات مختلفة. والحقيقة هي أنه عند مزامنة البيانات، يتم تعيين البيانات المحملة بشكل زائد من كل قاعدة بيانات بادئة خاصة بها. وفي حالة تكرارها سيكون العمل غير صحيح، وبالتالي لن يمنحك البرنامج هذه الفرصة.

عندما يطالبك البرنامج بإنشاء صورة بدء التشغيل، حدد هذا الخيار. سيستغرق هذا الإجراء بعض الوقت، وبعد ذلك احفظه على جهاز الكمبيوتر الخاص بك باسم "1Cv8.1CD".

يمكن إجراء المزامنة نفسها إما تلقائيًا وفقًا لجدول زمني يمكنك إعداده بنفسك، أو يدويًا. وفي الحالة الثانية، ما عليك سوى النقر على زر "المزامنة" في الوقت المناسب لك.

عقدة الرقيق RIB

عدد الإعدادات التي تم إجراؤها في قاعدة البيانات التابعة أقل بكثير. في نفس القسم، قم بتعيين علامة "مزامنة البيانات" وبالنقر على الرابط المقابل، سيكون زر "المزامنة" متاحًا.

في مثالنا، تمت إضافة عنصرين إلى قاعدة البيانات الرئيسية: "Beam" و"Board". بعد المزامنة، انتهى بهم الأمر في قاعدة بيانات الرقيق. كما ترون في الصورة أدناه، تم منحهم البادئة "BG". يتم تعيين الموضعين المتبقيين ("المخرطة" و"البليت") بالبادئة "BP"، حيث تم إنشاؤهما مباشرة في قاعدة البيانات الثانوية.

ملحوظةأن ترقيم العناصر في حالتنا مستمر، ولكن فقط ضمن نفس البادئة.

تتيح لك تقنية قواعد المعلومات الموزعة (RIB) إنشاء نظام موزع جغرافيًا بناءً على تكوينات 1C Enterprise. يتيح لك ذلك الحصول على مساحة معلومات مشتركة حتى مع تلك الأقسام التي ليس لديها قناة اتصال موثوقة، تجمع بين الاستقلالية العالية للعقد مع القدرة على تبادل المعلومات بسرعة. سنلقي نظرة في مقالاتنا على الميزات والتنفيذ العملي لهذه الآلية على منصة 8.2

بداية، دعونا نسأل أنفسنا: لماذا التبادل التلقائي؟ تتيح التقنيات الحديثة، جنبًا إلى جنب مع الإنترنت السريع وغير المكلف، تنظيم العمل عن بعد دون أي صعوبات. إن اختيار الأساليب واسع كما كان دائمًا: RDP، وعملاء الويب والشبكات، وربط الشبكات باستخدام VPN - هناك الكثير مما يجب التفكير فيه. ومع ذلك، فإن كل هذه الأساليب لها عيب واحد كبير - الاعتماد القوي على جودة قناة الاتصال.

وحتى مع التشغيل المثالي للمزود المحلي، فمن المستحيل ضمان توفر قناة الاتصال بنسبة 100%. المشاكل مع مزود العمود الفقري، ونقص إمدادات الطاقة، والأضرار المادية لخط الاتصال والعديد من العوامل الأخرى تجعل هذه المهمة غير قابلة للتغلب عليها. وفي الوقت نفسه، يؤدي عدم إمكانية الوصول إلى قاعدة المعلومات في مستودع بعيد أو متجر بيع بالتجزئة إلى خسائر كبيرة جدًا. وأخيرًا، دعونا لا ننسى أن هناك أماكن (على سبيل المثال، المناطق الصناعية في ضواحي المدن) حيث يكون توفير قناة اتصال عالية الجودة أمرًا مكلفًا و/أو مثيرًا للمشاكل.

تتيح لك آلية RIB التخلص من أوجه القصور هذه؛ فكل قسم لديه نسخته الخاصة من قاعدة المعلومات التي يمكنك من خلالها العمل بشكل مستقل حتى في حالة الغياب التام للتواصل مع العالم الخارجي. والكمية الصغيرة من المعلومات المرسلة تسمح لك باستخدام أي قناة اتصال للتبادل، بما في ذلك الإنترنت عبر الهاتف المحمول.

RIB على النظام الأساسي 8.2 ليس شيئًا جديدًا بشكل أساسي، ويمثل تطويرًا إضافيًا لمنصة RIB 7.7، الآن فقط أصبحت هذه التكنولوجيا أكثر سهولة وأبسط. على عكس مكون RIB، الذي يجب شراؤه بشكل منفصل، يعد RIB جزءًا لا يتجزأ من العديد من التكوينات القياسية ويعمل بالكامل في وضع المستخدم، مما يسمح لك بالاستغناء عن Configurator حتى في مرحلة الإعداد.

في هذه المرحلة، سيكون الوقت قد حان للانتقال إلى الجزء العملي، ولكن سيتعين علينا إجراء استطراد آخر. والحقيقة هي أن الانتقال إلى النظام الأساسي 8.2، والذي يبدو أنه حدث بالفعل، أدى في الواقع إلى ظهور نوعين من التكوينات: استنادًا إلى تطبيق مُدار، "أصلي" لمنصة 8.2، ومُقتبس من 8.1، مستمرًا لاستخدام التقنيات والآليات التي عفا عليها الزمن. نظرًا لأن جزءًا كبيرًا من التكوينات (محاسبة المؤسسات وكشوف المرتبات وإدارة الموارد البشرية) معدلة أو انتقالية، فلا يمكن استبعادها، لذلك سيتم تخصيص الجزء الأول من مقالتنا لهذه التكوينات (أساسًا النظام الأساسي 8.1)، بينما في الجزء الثاني سوف نقوم بفحص إعداد التبادل التلقائي للتكوينات بناءً على تطبيق مُدار (النظام الأساسي 8.2).

لنفكر في مهمة عملية: إعداد التبادل التلقائي عبر FTP لتكوين Enterprise Accounting 2.0. على الرغم من أن RIB يسمح لك بالتبادل باستخدام البريد الإلكتروني أو مشاركة الملفات، فإننا نوصي باستخدام FTP باعتباره أبسط وسيلة اتصال وأكثرها موثوقية. يمكنك قراءة كيفية إعداد خادم FTP الخاص بك، أو يمكنك استخدام خدمة FTP لأي مزود استضافة.

أولا وقبل كل شيء، نحن بحاجة إلى تكوين عقد التبادل. للقيام بذلك، قم بتشغيل التكوين باستخدام حقوق المسؤول وحدد المعاملات - خطط التبادل.

في القائمة التي تظهر، حدد ممتلىءخطة أو حسب التنظيم، إذا تم الاحتفاظ بسجلات لعدة شركات في قاعدة بيانات واحدة ويجب إجراء التبادل لواحدة منها فقط. في النافذة التي تفتح، توجد بالفعل عقدة واحدة - العقدة المركزية، ونحتاج إلى تعديلها من خلال الإشارة إلى الرمز والاسم.

ثم سنقوم بإنشاء عقدة أخرى للفرع، وملئها بنفس الطريقة (للإضافة، انقر فوق الدائرة الخضراء مع علامة زائد). والخطوة التالية هي إنشاء صورة أولية لهذه العقدة، وهي عبارة عن قاعدة معلومات جاهزة في وضع الملف. للقيام بذلك، انقر بزر الماوس الأيمن على العقدة المطلوبة واختر من القائمة المنسدلة إنشاء صورة البداية.

الآن دعنا ننتقل الخدمة - قاعدة المعلومات الموزعة (DIB) - تكوين عقد RIB.

في النافذة التي تفتح، انقر فوق الزر يضيفوقم بتكوين تبادل جديد عن طريق تحديد المضيف البعيد ونوع التبادل (عبر FTP) ومعلمات اتصال الخادم.

إشارة مرجعية التبادل التلقائييسمح لك بإعداد جدول تبادل، والتبادل حسب الأحداث (بداية ونهاية العمل، وما إلى ذلك)، يتم إجراء هذه الإعدادات للمستخدم الذي سيتم إجراء التبادل نيابة عنه، لذا تأكد من أن لديه حقوق تبادل البيانات.

لا تنس تحديد بادئة العقدة لترقيم المستندات (وإلا ستتلقى مستندات مختلفة بنفس الأرقام) في الأدوات - إعدادات البرنامج، حيث يمكنك أيضًا تكوين بعض معلمات التبادل الأخرى. في نفس علامة التبويب، يجب عليك تحديد مستخدم لتنفيذ مهام التبادل؛ إذا لم تقم بذلك، فلن يعمل الجدول الزمني. تذكر أن التبادل لن يتم إلا إذا قام المستخدم بتسجيل الدخول إلى البرنامج.

يكتمل هذا تكوين العقدة المركزية، والآن تحتاج إلى إجراء إعدادات مماثلة للعقدة الطرفية، وربط الصورة الأولية كنظام أمان معلومات موجود. وبعد ذلك يمكنك البدء في تبادل البيانات. للتحكم يجب عليك استخدام مراقب الاتصالات، فهو لا يسمح لك بمراقبة نجاح التحميل/التنزيل فحسب، بل يُظهر أيضًا أي تصادمات نشأت أو تأخرت في الحركات (إذا لم يكن لدى المستخدم الذي أجرى التبادل الحقوق الكافية لتنفيذ أي إجراءات في قاعدة البيانات). يتيح لك وجود هذه الأداة حل أنواع مختلفة من المشكلات التي تنشأ أثناء التبادل التلقائي بسرعة وفعالية.

عند هذه النقطة، يمكن اعتبار إعداد التبادل مكتملًا ويمكنك البدء في العمل في الوضع الموزع. من المفيد التركيز بشكل خاص على تحديث التكوين أو إجراء تغييرات عليه. هذه الإجراءات متاحة فقط على العقدة المركزية، وسيتم نشر جميع التغييرات التي تم إجراؤها تلقائيًا إلى العقد الطرفية أثناء التبادل التالي. لإجراء تغييرات تلقائيًا، يجب أن تكون قاعدة البيانات الطرفية في الوضع الحصري، وإلا فستحتاج إلى التشغيل مكونوتنفيذ تحديث تكوين قاعدة البياناتيدويا.

25 أكتوبر 2016

لا يوجد فرق كبير بين إعداد ودعم RIB لعقدتين ولـ 10، ولكن عندما يتجاوز عدد النقاط البعيدة مائة، يجب حل مشكلات مختلفة تمامًا

البيانات الأولية:

التكوين: البيع بالتجزئة 2.2
المنصة 1C: 8.3.7.1970



مدة المشروع: سنة واحدة.




بنيان:

أولاً، قررنا استخدام مخطط RIB. تقرر التركيز على مخطط "النجم" لأطول فترة ممكنة؛ عند الوصول إلى القيود التكنولوجية - ندفة الثلج.





محددات:
- 2 جيجا رام
- 1 معالج فيزيائي


من بين كل ما سبق، الشيء الرئيسي المزعج هو الحد الأقصى لحجم قاعدة البيانات.

ولكن هذا يعني فقط أنك بحاجة إلى تنظيم الإجراء بعناية لتنظيفه من البيانات القديمة في الموقع.

يتم تخصيص خادم فعلي منفصل لخادم 1C وMS SQL. وسوف تتحمل العبء الرئيسي للتبادلات والعمليات طويلة الأجل.
لا يتم استبدال أجهزة الكمبيوتر العميلة النهائية، لأنها ستعمل مع العميل الرقيق وسيكون الحمل عليها في حده الأدنى.
.


الإعدادات الأساسية

منذ وقت UT 10.3، حيث كان لدي أول مشروع لي لتنفيذ RIB بسرعة 60 عقدة، بالطبع، "مرت الكثير من المياه تحت الجسر".

1C لم يقف ساكنا. يأخذ البيع بالتجزئة 2.2 الآن في الاعتبار الحاجة إلى تحميل البيانات الانتقائية.
سيتم تحميل المعلومات ذات الصلة فقط إلى قاعدة بيانات المتجر:
- جميع الكتب المرجعية (ماعدا المتخصصة منها)
- وثائق لهذا المتجر

سؤال آخر هو أن إضافة عقدة إلى قاعدة البيانات بطريقة أو بأخرى يعني إضافة إدخال آخر إلى جدول التسجيل لكل عنصر مشترك عند كتابته.





1) من الضروري التقسيم إلى سيناريوهات مزامنة منفصلة للتحميل والتنزيل
والحقيقة هي أن التفريغ يستغرق وقتا طويلا وينطوي على حظر، في حين أن التحميل خالي من المتاعب تماما. في الوقت نفسه، غالبًا ما يحدث أننا نحتاج إلى تلقي البيانات بسرعة من منافذ البيع بالتجزئة، مع منحها عدة مرات فقط في اليوم.

2) تحديد مخازن المشكلة وإزالتها من سيناريو المزامنة العام. قد يكون هناك عمليات تفريغ كبيرة عليها - وهذا سيؤدي إلى إبطاء عملية التبادل بأكملها، بما في ذلك العقد الأخرى. بمجرد حل المشاكل يتم إضافتها مرة أخرى.

3) إنشاء العديد من البرامج النصية لإرسال واستقبال البيانات. ولكن الشيء الرئيسي هنا هو تحقيق التوازن الصحيح لكميتها.
(منذ الإصدار 8.1).
وبالتالي، فإن التوازي في تفريغ RIB محدود. في الممارسة العملية، اتضح تشغيل 2-3 نصوص بالتوازي.


ما كان لا بد من تحسينه

المشكلة الأكثر أهمية في المنطق القياسي لـ 1C RIB هي التحديثات





مشكلة أخرى للتبادل هي سجلات المعلومات. يؤدي تحميل كل سجل من سجل المعلومات إلى XML إلى إنشاء عقدة XML منفصلة مع عناصر الخدمة، وما إلى ذلك. بالإضافة إلى ذلك، فإن وظيفة "SelectChanges()" لسجل المعلومات الذي يوجد به 100 سجل ستتلقى جدولًا ناتجًا مكونًا من 100 صف، في في نفس الوقت، إذا كان هذا الدليل A الذي يحتوي على 100 صف سيحتوي على إدخال واحد فقط محدد في القسم الجدولي الخاص به. وهذا هو وقت الحجب الحصري. لذلك، إذا كان هناك الكثير من السجلات في جهاز الكمبيوتر، والتي يتم تسجيلها بانتظام لتبادلها في متاجر أخرى، فمن الأصح بالطبع تقديم ذلك في شكل دليل بجزء جدولي، والذي، في الحالات القصوى، عند التسجيل ، يمكن أن تشكل صفوفًا من نفس السجل. على أي حال، .

تفاصيل مهمة أخرى - لماذا؟ يوجد بالفعل ما يقرب من 3 ملايين بطاقة خصم يتم استخدام نظام خارجي عبر الإنترنت للعمل معها. إذا واصلت نقل بطاقات الخصم إلى جميع المتاجر، فسيؤدي ذلك إلى زيادة التبادلات بشكل كبير، وقد يؤدي أيضًا إلى تجاوز حجم القاعدة 10 جيجابايت.

يتم تنفيذ بعض الآليات عبر الإنترنت من خلال الاتصال بقاعدة البيانات المركزية: الأرصدة في المتاجر الأخرى، إعادة إيصال من متجر آخر، التحقق من صلاحية شهادة الهدية.


تكرار


إن إنشاء عقدة RIB أولية بطريقة منتظمة سيجعل النسخ المتماثل مستحيلاً من حيث المبدأ.
ولذلك، يتم إنشاء عقدة جديدة على النحو التالي
:


2) تتبادل قاعدة البيانات هذه جميع البيانات العامة في RIB ولكنها لا تتلقى (وثائق) متخصصة


5) قاعدة المتجر جاهزة.

يتم نشر حزمة البرامج الجاهزة على الخادم، لذلك لا يستغرق الأمر الكثير من الوقت. ثم يتم تحميل قاعدة البيانات التي تم إنشاؤها حديثًا إلى الخادم وتكون جاهزة لإرسالها إلى المتجر.


فوائد العميل الرقيق

ميزتان مهمتان لـ Retail 2.2 (Thin Client) التي "تدفئ الروح":








الدعم والتحديثات




1) التحديث يدويًا من المتاجر (ليس صحيحًا جدًا، قد لا يتم تلقي التغييرات، وستكون هناك مكالمات ومشاكل) - كان هذا هو الحال من قبل

3) اكتب برنامج نصي *.cmd أو 1C للتحديث أو احصل على برنامج جاهز. كما تظهر الممارسة، فإن مثل هذا الحل يكون دائمًا فاترًا (غير مستقر)، وسيكون من الممكن بناء القليل من الوظائف فيه.

ماذا كانت مهامنا:


2) عند التحديث، يكون التفاعل التفاعلي مع المستخدم ممكنًا (الرسائل، التأكيد، شريط التقدم).








وظائف رئيسيه:




4) التحقق من حالة الوكلاء
5) تحديث التقارير
6) النسخ الاحتياطي

















على سبيل المثال، هذا ما تبدو عليه رسالة الخطأ بعد التحديث:








وبالتالي، كان للمشروع فرصة جيدة لإنجازه بنجاح. تكون الرحلة عادية في منتصف الرحلة على الأقل.

إذا وصلنا إلى أي حلول أخرى قد تبدو مثيرة للاهتمام، فسوف أكتب بشكل منفصل

ملاحظة. والأهم من ذلك: أن التخطيط السليم لمزيد من الدعم هو أحد العوامل الأساسية لمزيد من النجاح لمثل هذه المشاريع. :)

25 أكتوبر 2016

لا يوجد فرق كبير بين إعداد ودعم RIB لعقدتين ولـ 10، ولكن عندما يتجاوز عدد النقاط البعيدة مائة، يجب حل مشكلات مختلفة تمامًا.

وبالتالي فإن البيانات الأولية:

التكوين: البيع بالتجزئة 2.2
المنصة 1C: 8.3.7.1970
العدد التقديري للعقد في نهاية المشروع: 200
موارد المعدات في المركز: دون قيود كبيرة
المعدات عند هذه النقطة: قضية تمت مناقشتها.
مدة المشروع: سنة واحدة.

بنيان:

أولاً، قررنا استخدام مخطط RIB. تقرر التركيز على مخطط "النجم" من قبل
في منافذ البيع بالتجزئة، يتم استخدام إصدار عمل خادم العميل، مع خادم مخصص يعمل بنظام التشغيل Windows.
سيتم استخدام الخادم 1C في الإصدار "Server 1C MINI" https://1c.ru/news/info.jsp?id=17577
خادم نظم إدارة قواعد البيانات - MS SQL Express 2008 R2.

SQL Express 2008 R2 هو الإصدار الأحدث الحالي من سطر SQL Server هذا.
محددات:

2 جيجا رام
- 1 معالج فيزيائي
- الحد الأقصى لحجم قاعدة البيانات 10 جيجابايت

من بين كل ما سبق، الشيء الأكثر إزعاجًا، بالطبع، هو القيود المفروضة على الحد الأقصى لحجم قاعدة البيانات. ولكن في الواقع، هذا يعني أنه سيكون من الضروري تنظيم إجراء تنظيفه من البيانات القديمة في الموقع بعناية.

يتم تخصيص خادم منفصل لخادم 1C وMS SQL. وسوف تتحمل العبء الرئيسي للتبادلات والمعاملات.
لا يتم استبدال أجهزة الكمبيوتر العميلة النهائية، لأنها ستعمل مع جهاز عميل رفيع وسيكون الحمل الموجود في الجزء السفلي في حده الأدنى.
الخادم الموجود في المتجر هو مجرد جهاز كمبيوتر قوي. لكن الشرط الأساسي هو وجود قرص SSD - الذي توجد عليه قواعد بيانات MS SQL.
سيوفر الخادم أيضًا القدرة على تنفيذ العمليات الروتينية ليلاً والوصول إلى قاعدة بيانات المتجر دون انقطاع عن العمل.

الإعدادات الأساسية

منذ وقت UT 10.3، الذي كان لدي خلاله مشروعي الأول لتنفيذ RIB بسرعة 60 عقدة، بالطبع، "تدفقت الكثير من المياه تحت الجسر". 1C لم يقف ساكنا. يأخذ البيع بالتجزئة 2.2 الآن في الاعتبار الحاجة إلى تحميل البيانات الانتقائية.
سيتم تحميل المعلومات ذات الصلة بالمتجر فقط إلى قاعدة بيانات المتجر:
- جميع الدلائل (ما عدا بعضها)
- وثائق لهذا المتجر
يتم تسجيل البيانات وفقًا لقواعد التسجيل، وكل ما يمكن تخزينه مؤقتًا. لا توجد تباطؤ كبير أثناء التسجيل.
سؤال آخر هو أن إضافة عقدة إلى قاعدة البيانات بطريقة أو بأخرى يعني إضافة سجل آخر لكل عنصر مشترك لجميع قواعد البيانات.

لا يوجد شيء محدد في إعداد التحميل نفسه. هناك بعض الفروق الدقيقة عند إعداد سيناريوهات المزامنة:

1) من الضروري فصل التحميل والتحميل في سيناريوهات مزامنة منفصلة
والحقيقة هي أن التفريغ يستغرق وقتا طويلا وينطوي على حظر، في حين أن التحميل خالي من المتاعب تماما. في الوقت نفسه، غالبًا ما يحدث أننا نحتاج إلى تلقي البيانات بسرعة من منافذ البيع بالتجزئة، مع منحها عدة مرات فقط في اليوم.

2) تحديد المخازن التي بها مشكلات وإزالتها من سيناريو المزامنة العام. قد يكون هناك تفريغ كبير عليها - سيؤدي ذلك إلى إبطاء التبادل بأكمله، بما في ذلك العقد الأخرى

3) إنشاء بعض البرامج النصية للإرسال والاستقبال لإرسال واستقبال البيانات. لكن الشيء الرئيسي هنا هو التوازن.
بعض الأشياء في 1C لا تتغير. لا يمكن تنفيذ نفس أسلوب "SelectChanges" إلا بالتسلسل(منذ الإصدار 8.1).
وبالتالي، فإن التوازي في تفريغ RIB محدود. من الناحية العملية، ينتهي بك الأمر إلى تحميل 2-3 نصوص برمجية في المرة الواحدة.
أما بالنسبة لسيناريو الاستلام، فمن الممكن هنا تحقيق قدر أكبر من التوازي، إذا لزم الأمر، بالطبع.

ما كان لا بد من تحسينه

بالطبع إنه أمر محزن ومحزن، لكن كان علي أن أتدخل بشكل كامل في BSP. المشكلة الأكثر أهمية في منطق 1C القياسي هي التحديثات. بعد التحديث تظهر نافذة مشابهة لهذه:

كل هذا يحدث في وضع الاحتكار. من بين أمور أخرى، سيظل النظام يحاول إجراء تبادل بعد التحديث في الوضع الحصري. وليس من الصعب تخمين أين يؤدي كل هذا.
خلال هذه الفترة الزمنية بأكملها، لا يمكن للمتجر العمل، وهناك عملاء عند الخروج، والشركة تخسر المال.

مشكلة أخرى للتبادل هي سجلات المعلومات. يؤدي تحميل كل إدخال سجل معلومات إلى XML إلى إنشاء عقدة XML منفصلة مع عناصر الخدمة وكل ما يليها. بالإضافة إلى ذلك، وظيفة "تحديد التغييرات" لسجل المعلومات الذي يوجد به 100 سجل، سيحتوي الجدول الناتج على 100 صف، في نفس الوقت، إذا كان هذا دليلًا يحتوي على 100 صف، فسيتم تحديد سجل واحد فقط في قسم الجدول. لذلك، إذا كان هناك الكثير من السجلات في جهاز الكمبيوتر، والتي يتم تسجيلها بانتظام لتبادلها في متاجر أخرى، فمن الأصح بالطبع تقديم ذلك في شكل دليل بجزء جدولي، والذي، في الحالات القصوى، عند التسجيل ، يمكنه إنشاء سجلات لنفس السجل. على أي حال، سجلات المعلومات في البورصات شريرة.

تفاصيل مهمة أخرى - يتم استبعاد بطاقات الخصم تمامًا من البورصة، ويتم استبعاد موظفي متجر معين فقط من البورصة.لماذا؟ يوجد بالفعل ما يقرب من 3 ملايين بطاقة خصم يتم استخدام نظام خارجي عبر الإنترنت للعمل معها. إذا واصلت نقل بطاقات الخصم إلى جميع المتاجر، فسيؤدي ذلك إلى زيادة التبادلات بشكل كبير، وبالإضافة إلى ذلك، قد يؤدي إلى تجاوز حجم القاعدة 3 جيجابايت.

يتم تنفيذ بعض الآليات عبر الإنترنت من خلال الاتصال بقاعدة البيانات المركزية: الأرصدة في المتاجر الأخرى، إعادة إيصال من متجر آخر، التحقق من صلاحية شهادة الهدية.

تكرار

وبطبيعة الحال، يتم تنفيذ النسخ المتماثل بوتيرة متسارعة.
إن إنشاء عقدة RIB الأولية بطريقة قياسية سيجعل النسخ المتماثل مستحيلاً بالطبع.
ولذلك يتم إنشاء عقدة جديدة على النحو التالي:

1) توجد قاعدة بيانات منفصلة بمتجر مزيف
2) تقوم قاعدة البيانات هذه بتبادل جميع البيانات العامة في RIB ولكنها لا تتلقى البيانات المتخصصة
3) عندما نريد إنشاء قاعدة بيانات جديدة، نقوم ببساطة بنسخ هذه القاعدة
4) ثم نقوم بضبط الإعدادات - المتجر، البادئة، إلخ.
5) قاعدة المتجر جاهزة.

يتم نشر حزمة البرامج الجاهزة على الخادم، لذلك لا يستغرق الأمر الكثير من الوقت. ثم يتم تحميل قاعدة بيانات المتاجر التي تم إنشاؤها حديثًا إلى الخادم وتكون جاهزة لإرسالها إلى المتجر.

فوائد العميل الرقيق

ميزتان مهمتان "تدفئان الروح".

1) ليست هناك حاجة لتغيير ساحة الكمبيوتر بالكامل في منافذ البيع بالتجزئة. 90% من العمليات يتم إجراؤها على الخادم، ويتم إحضار الخادم إلى هناك مع “جهاز كمبيوتر قوي نسبيًا”

2) المعدات لديها القدرة على رفض العمل، وهذا يحدث غالبًا مع المعدات المثبتة حديثًا أو البالية بالفعل.
في هذه الحالة، أصبحت الإجراءات الآن بسيطة للغاية - يتحول المتجر إلى العمل في قاعدة البيانات المركزية.
لا تستغرق هذه العملية أكثر من 5 إلى 10 دقائق، لذلك لا ينقطع التداول حتى لو كانت هناك مشاكل كبيرة في المعدات.

الدعم والتحديثات

أخيرًا وصلنا إلى النقطة الأكثر إثارة للاهتمام - كيفية صيانة وتحديث كل هذا؟
بالنسبة لنا، كانت التحديثات أيضًا معضلة لفترة طويلة:

1) التحديث يدويًا من المتاجر (ليس صحيحًا جدًا، قد لا يتم استلام التغييرات، ستكون هناك مكالمات ومشاكل)
2) التحديث باستخدام الدعم الفني (لا يوجد الكثير من الموارد)
3) اكتب *.cmd للتحديث أو خذ واحدًا جاهزًا. كما تظهر الممارسة، فإن مثل هذا الحل يكون دائما فاترا (غير مستقر)، وهناك القليل من الوظائف فيه.

ماذا كانت مهامنا:

1) يجب أن يتم التحديث في عدة أوضاع وأن تتم إدارته مركزيًا
2) عند التحديث، يكون التفاعل التفاعلي مع المستخدم ممكنًا.
3) يجب استلام تقارير عن حالة التحديث والأخطاء
4) يجب أن يكون هناك نسخة احتياطية
5) يجب أن يكون نظام التحديث قادراً على تحديث نفسه دون مشاكل.
6) أن يكون النظام قابلاً للتوسيع دون أي مشاكل.

وبطبيعة الحال، ذهبت المشاكل إلى ما هو أبعد من قائمة تلك التي يمكن حلها بطرق بسيطة. لأننا لا نستطيع الاستغناء عن الأتمتة مع العديد من نقاط النهاية، ولم نعثر على أي شيء جاهز تقريبًا بوظائف مماثلة
كان علي أن أبدأ في تطوير البرمجيات، والتي اكتسبت في النهاية اسم MU (MagicUpdater).

وظائف رئيسيه:

1) تحديث قاعدة البيانات الديناميكية (أمر أو مجدول)
2) تحديث قاعدة البيانات الثابتة (أمر أو مجدول)
3) العوامل التلقائية على أجهزة الكمبيوتر النهائية عند تعديلها
4) التحقق من حالة الوكلاء
5) تحديث التقارير
6) النسخ الاحتياطي
7) الإجراءات الإدارية مع خادم 1C وMS SQL
8) إغلاق جميع تطبيقات عميل 1C على أجهزة كمبيوتر الشبكة
9) تحديث ثابت مع القبول عند الخروج الرئيسي
10) عرض أوصاف التعديلات بعد التحديث
11) إعداد ترتيب الإجراءات
12) تنفيذ كل هذه الإجراءات وفقا لجدول زمني

مخططات التفاعل التقريبية:


حيث MU Agent هي خدمة يتم تثبيتها وتكوينها في المتجر. في الواقع، تتلقى أمرًا من المركز بتنفيذ مهام معينة.
خادم MU - الخادم الذي يقبل جميع الطلبات المقدمة إلى النظام.
يتم استخدام شاشة MU - ما يراه موظفو الدعم الفني العاديون - لعرض السجلات وتعيين المهام للتحديث أو غيرها.

لقد اتضح الأمر بشكل جيد، في رأيي. الآن تتم التحديثات تلقائيًا تقريبًا.
وهذا، على سبيل المثال، ما تبدو عليه رسالة الخطأ بعد التحديث؛ كل شيء لا يزال ينتظر في المركز.

وهذه هي الطريقة التي نرسل بها الأوامر إلى أجهزة الكمبيوتر العميلة

التطبيقات بالتأكيد ليست 1C، ولكن مع مجموعة لائقة إلى حد ما من إمكانيات الواجهة. على سبيل المثال، هذا ما يبدو عليه التحديد حسب التاريخ:

الآن هم على استعداد لمزيد من النسخ المتماثل. يعد التخطيط السليم لمزيد من الدعم أحد العوامل الرئيسية لمزيد من النجاح لمثل هذه المشاريع.

إرشادات لإنشاء وتكوين قواعد البيانات الموزعة باستخدام مكون URDB (URIB).

يتم استخدام مكون URDB (إدارة قواعد البيانات الموزعة) لتبادل المعلومات بين قاعدتي بيانات 1C متطابقتين. إذا كانت التكوينات مختلفة، فيمكنك أيضا استخدامها، فهي مكتوبة في مكان آخر. لكي يعمل المكون، يجب أن يكون لديك ملف DistrDB.dll في مجلد BIN الخاص ببرنامج 1C: Enterprise.

دعونا نلقي نظرة على خطوات إنشاء قواعد البيانات الموزعة. على سبيل المثال، لدينا قاعدة عمل في الدليل D:\base1. مطلوب جعلها مركزية وإنشاء قاعدة محيطية.

1. قم بإنشاء الدليل D:\base2 لقاعدة البيانات الطرفية.

2. في المجلدين D:\base1 وD:\base2، قم بإنشاء المجلدين CP وPC (استخدم الحروف اللاتينية).

3. قم بتشغيل مكون قاعدة البيانات المركزية (D:\base1) وحدد القائمة - الإدارة - أمن المعلومات الموزعة - الإدارة.

4. انقر على زر "أمن المعلومات المركزي"، في النافذة التي تظهر، أدخل رمز واسم قاعدة البيانات. من الأفضل استخدام أرقام أو أحرف لاتينية للرمز. أدخل، على سبيل المثال، 001 و"القاعدة المركزية"، وأكد ذلك بالضغط على زر "موافق".

5. انقر فوق الزر "أمن المعلومات الطرفية الجديد" لإنشاء قاعدة بيانات طرفية. نقوم بإدخال المعلمات الخاصة به: 002 و "القاعدة الطرفية 1".

6. استخدم المؤشر لتحديد قاعدة "القاعدة الطرفية 1" واضغط على زر "الإعداد". تبادل تلقائي". في الإعدادات، قم بتغيير الوضع اليدوي إلى الوضع التلقائي. كن حذرا، وهذا مهم.

7. باستخدام المؤشر، حدد قاعدة البيانات "قاعدة البيانات الطرفية 1" واضغط على زر "تحميل البيانات"، ثم الزر "موافق". ونتيجة للتحميل، سيظهر الملف D:\base1\CP\020.zip.

8. قم بتشغيل 1C في وضع التكوين، وأضف قاعدة بيانات جديدة "قاعدة البيانات الطرفية 1" في نافذة تشغيل 1C، وحدد الدليل الذي تم إنشاؤه مسبقًا D:\base2 له.

9. حدد القائمة - الإدارة - أمن المعلومات الموزعة - الإدارة. على السؤال المطروح "لم يتم العثور على قاعدة المعلومات. هل تريد تحميل البيانات؟" انقر فوق الزر "نعم" وحدد اسم الملف "D:\base1\CP\020.zip"، وانقر فوق الزر "موافق". بعد اكتمال التنزيل، يمكن اعتبار عملية إنشاء قاعدة بيانات طرفية كاملة.

في وكذلك طرق إنشاء قاعدة بيانات طرفية عن طريق استعادة نسخة من قاعدة البيانات المركزية من نسخة احتياطية أو إرفاق ملفات نسخة من قاعدة البيانات المركزية لتنسيق SQL وتنفيذ البرنامج النصي. سيكون هذا مفيدًا للكميات الكبيرة من البيانات، عندما تستغرق عمليات التحميل والتنزيل ساعات أو عندما تكون غير واقعية على الإطلاق.

تعليمات للتبادل بين قواعد البيانات الموزعة باستخدام مكون URDB (URIB).

دعونا نلقي نظرة على مثال مبسط؛ سنقوم بإجراء التبادل يدويًا عن طريق تشغيل أداة التهيئة. يمكنك استخدام الوضع الدفعي للمكون لتوصيل حزم التبادل، ويمكنك استخدام البريد وبروتوكول نقل الملفات ونسخ الملفات تلقائيًا.

لإجراء التبادل، يجب عليك تحديد القائمة - الإدارة - أمن المعلومات الموزعة - التبادل التلقائي. إذا كان التبادل تلقائيا (انظر النقطة 6 من التعليمات السابقة)، فسيعمل كل شيء.

1. لذلك، نقوم بتغيير أو إنشاء بعض الكائنات التي يتم ترحيلها إلى قاعدة البيانات الطرفية. يتم تعيين قواعد ترحيل الكائنات في علامة التبويب "الترحيل" في خصائص الكائن (راجع شجرة الكائنات في أداة التهيئة).

2. قم بتشغيل مكون قاعدة البيانات المركزية، وحدد القائمة - الإدارة - أمن المعلومات الموزعة - التبادل التلقائي، وانقر فوق الزر "تشغيل".

3. انقل الملف الناتج D:\base1\CP\020.zip إلى المجلد D:\base2\CP\

4. نقوم بتغيير بعض الكائنات في قاعدة البيانات الطرفية. ويفضل ألا تكون تلك التي تم تغييرها من قبل في قاعدة البيانات المركزية، لأن تتمتع قاعدة البيانات المركزية بالأولوية لتغييرات الكائنات أثناء التبادل.

5. قم بتشغيل مكون قاعدة البيانات الطرفية، وحدد القائمة - الإدارة - أمن المعلومات الموزعة - التبادل التلقائي، وانقر فوق الزر "تشغيل".

6. نتيجة للتبادل التلقائي، يجب أن نحصل على تغييرات قادمة من قاعدة البيانات المركزية. يجب أن يكون لدينا أيضًا ملف لنقله إلى قاعدة البيانات المركزية D:\base2\PC\021.zip

7. انسخ الملف D:\base2\PC\021.zip إلى المجلد D:\base1\PC

8. كرر النقطة 2. ونتيجة لذلك، ستظهر التغييرات الواردة من قاعدة البيانات الطرفية في قاعدة البيانات المركزية.

لذا، فإن المبدأ العام للتبادل: التنفيذ البديل للتبادل التلقائي مع النقل المتزامن للملفات (حزم التبادل) من مجلد الكمبيوتر الشخصي لقاعدة بيانات واحدة إلى مجلد الكمبيوتر الشخصي لقاعدة بيانات أخرى ومن مجلد CP لقاعدة بيانات واحدة إلى مجلد CP الخاص بقاعدة بيانات أخرى. قاعدة بيانات أخرى.

يتم إجراء تغييرات التكوين فقط في قاعدة البيانات المركزية. عند تغيير التكوين، من الضروري إجراء التبادل في قواعد البيانات الطرفية في الوضع الحصري. لمعالجة الحزم من قواعد البيانات الطرفية في قاعدة البيانات المركزية بنجاح، يجب تحميل التكوين في قواعد البيانات الطرفية. إذا شعرت بالارتباك، فلا بأس، سيتم تنزيل الحزمة التي رفضتها قاعدة البيانات المركزية مرة أخرى.

RIB هي قاعدة معلومات موزعة، وهي عبارة عن هيكل يشبه الشجرة، وفروعها عبارة عن قواعد بيانات 1C Enterprise منتشرة بشكل فردي. تسمى قواعد البيانات هذه بعقد قاعدة المعلومات الموزعة (المشار إليها فيما يلي ببساطة بالعقد). يتم تبادل المعلومات بين هذه العقد لمزامنة جميع العقد (التكوينات وقواعد البيانات).

والآلية الرئيسية هي آلية التبادل مع بعض القدرات المميزة والعالمية. والفرق الرئيسي هو أن آلية تبادل RIB أكثر تخصصًا وضيقة، في حين توفر التبادلات العالمية للمستخدم مجموعة واسعة من الفرص.

مبادئ التشغيل الأساسية لـ RIB

من الممكن تغيير بنية التكوين فقط في العقدة الجذرية الرئيسية لقاعدة المعلومات الموزعة. ثم يتم نشر هذه التغييرات بشكل هرمي إلى العقد الثانوية. وبالتالي، يوفر هذا مساحة بنية تكوين واحدة عبر جميع عقد RIB.

يمكن تغيير البيانات في أي من العقد، والتي بدورها يتم توزيعها على جميع العقد الأخرى. علاوة على ذلك، ليس من الضروري بالضرورة نقل هذه البيانات إلى المشاركين الآخرين في النظام وقد لا يتم الحفاظ على هويتهم الكاملة. يمكن للمطور تخصيص تركيبة البيانات التي تشارك في التبادل مع المشاركين الآخرين في RIB حسب الرغبة. علاوة على ذلك، يمكن إجراء الإعدادات ليس فقط على مستوى بيانات تعريف التكوين، ولكن أيضًا على مستوى العناصر الفردية، والتي يمكن تطبيق التحديدات الخاصة عليها.

كما ذكر أعلاه، يتم تحقيق آلية RIB من خلال استخدام خطط التبادل. ولكن لكي يتم استخدام خطة معينة في هذا الهيكل الهرمي، يجب تفعيل خاصية "قاعدة المعلومات الموزعة" الخاصة بها.

يتم نقل جميع البيانات إلى RIB عبر الرسائل. إن محتوى هذه الرسائل منظم بشكل واضح ولا يمكن أن يكون تعسفياً، كما هو الحال في آلية التبادل العالمي. يتم وضع البيانات في رسالة باستخدام مبدأ تسلسل XML. بالإضافة إلى تغييرات البيانات هذه، تحتوي الرسالة أيضًا على معلومات حول تغييرات التكوين، بالإضافة إلى قدر معين من معلومات الخدمة. يتم تسجيل التغييرات ووضعها في رسالة التبادل بشكل تلقائي بالكامل. لا يمكن للمستخدم ولا المطور التأثير على هذا.

يتم تعيين استقبال وإنشاء رسائل التبادل في RIB بأمر واحد

خطط التبادل. كتابة التغييرات (كتابة الرسائل، 0)

تتم قراءة المحتوى باستخدام الأمر

خاتمة

يمكننا أن نقول بأمان أن آلية RIB تتكون بشكل أساسي من آلية تبادل عالمية مع بعض الميزات المميزة التي لا توجد إلا في هيكل RIB.