من المؤكد أن الكثير منكم، مثلي، كان لديه فكرة للقيام بشيء فريد من نوعه. سأصف في هذه المقالة المشكلات الفنية والحلول التي كان علي مواجهتها عند تطوير PBX. ولعل هذا يساعد أحداً على اتخاذ قرار بشأن فكرته، ويساعد أحداً على السير على الطريق الصحيح، لأنني أيضاً استفدت من تجربة الرواد.
الفكرة والمتطلبات الأساسية
وبدأ كل شيء ببساطة بالحب النجمة (إطار لبناء تطبيقات الاتصالات)، وأتمتة الاتصالات الهاتفية والمنشآت FreePBX (واجهة الويب لـ النجمة). إذا كانت احتياجات الشركة بدون تفاصيل وتقع ضمن الإمكانيات FreePBX - كل شيء عظيم. تم التثبيت بالكامل في غضون XNUMX ساعة، وحصلت الشركة على نظام PBX مهيأ وواجهة سهلة الاستخدام وتدريب قصير بالإضافة إلى الدعم إذا رغبت في ذلك.
لكن المهام الأكثر إثارة للاهتمام كانت غير قياسية ومن ثم لم تكن رائعة جدًا. النجمة يمكن أن تفعل الكثير، ولكن للحفاظ على واجهة الويب في حالة جيدة، كان من الضروري قضاء المزيد من الوقت عدة مرات. لذا فإن تفصيلًا صغيرًا قد يستغرق وقتًا أطول بكثير من تثبيت بقية PBX. والنقطة ليست في أن كتابة واجهة ويب تستغرق وقتًا طويلاً، بل النقطة في الميزات المعمارية FreePBX. الأساليب والأساليب المعمارية FreePBX تم وضعه في وقت php4، وفي تلك اللحظة كان هناك بالفعل php5.6 الذي يمكن من خلاله جعل كل شيء أسهل وأكثر ملاءمة.
القشة الأخيرة كانت خطط الاتصال الرسومية في شكل رسم تخطيطي. عندما حاولت بناء شيء مثل هذا ل FreePBXأدركت أنه سيتعين علي إعادة كتابتها بشكل كبير وسيكون من الأسهل بناء شيء جديد.
وكانت المتطلبات الرئيسية هي:
- إعداد بسيط، يمكن الوصول إليه بسهولة حتى للمسؤول المبتدئ. وبالتالي فإن الشركات لا تطلب صيانة PBX من جانبنا،
- تعديل سهل بحيث يتم حل المهام في الوقت المناسب،
- سهولة التكامل مع PBX. ش FreePBX لم يكن هناك API لتغيير الإعدادات، أي. لا يمكنك، على سبيل المثال، إنشاء مجموعات أو قوائم صوتية من تطبيق تابع لجهة خارجية، فقط واجهة برمجة التطبيقات نفسها النجمة,
- المصدر المفتوح - يعد هذا أمرًا مهمًا للغاية بالنسبة للمبرمجين لإجراء تعديلات على العميل.
كانت فكرة التطوير الأسرع هي جعل جميع الوظائف تتكون من وحدات في شكل كائنات. يجب أن تحتوي جميع الكائنات على فئة أصل مشتركة، مما يعني أن أسماء جميع الوظائف الرئيسية معروفة بالفعل وبالتالي توجد تطبيقات افتراضية بالفعل. ستسمح لك الكائنات بتقليل عدد الوسائط بشكل كبير في شكل صفائف ترابطية مع مفاتيح سلسلة، والتي يمكنك اكتشافها في FreePBX كان ذلك ممكنًا من خلال فحص الوظيفة بأكملها والوظائف المتداخلة. في حالة الكائنات، سيُظهر الإكمال التلقائي العادي جميع الخصائص، وبشكل عام سيُبسط الحياة عدة مرات. بالإضافة إلى ذلك، فإن الميراث وإعادة التعريف يحل بالفعل العديد من مشاكل التعديلات.
الشيء التالي الذي أبطأ وقت إعادة العمل وكان يستحق تجنبه هو الازدواجية. إذا كانت هناك وحدة مسؤولة عن الاتصال بموظف، فيجب على جميع الوحدات الأخرى التي تحتاج إلى إرسال مكالمة إلى موظف استخدامها، وليس إنشاء نسخ خاصة بها. لذلك، إذا كنت بحاجة إلى تغيير شيء ما، فسيتعين عليك التغيير في مكان واحد فقط ويجب إجراء البحث عن "كيف يعمل" في مكان واحد، وعدم البحث عنه طوال المشروع بأكمله.
النسخة الأولى والأخطاء الأولى
كان النموذج الأولي الأول جاهزًا في غضون عام. كان نظام PBX بأكمله، كما هو مخطط له، معياريًا، ولم تتمكن الوحدات من إضافة وظائف جديدة لمعالجة المكالمات فحسب، بل يمكنها أيضًا تغيير واجهة الويب نفسها.
نعم فكرة بناء مخطط الاتصال على شكل مثل هذا المخطط ليست فكرتي ولكنها مريحة للغاية وقد فعلت الشيء نفسه بالنسبة النجمة.
من خلال كتابة وحدة نمطية، يمكن للمبرمجين بالفعل:
- قم بإنشاء وظائفك الخاصة لمعالجة المكالمات، والتي يمكن وضعها على الرسم التخطيطي، وكذلك في قائمة العناصر الموجودة على اليسار،
- أنشئ صفحاتك الخاصة لواجهة الويب وأضف قوالبك إلى الصفحات الموجودة (إذا قام مطور الصفحة بتوفير ذلك)،
- أضف إعداداتك إلى علامة تبويب الإعدادات الرئيسية أو قم بإنشاء علامة تبويب الإعدادات الخاصة بك،
- يمكن للمبرمج أن يرث من وحدة موجودة، أو يغير جزءًا من الوظيفة ويسجلها تحت اسم جديد أو يستبدل الوحدة الأصلية.
على سبيل المثال، هذه هي الطريقة التي يمكنك بها إنشاء القائمة الصوتية الخاصة بك:
......
class CPBX_MYIVR extends CPBX_IVR
{
function __construct()
{
parent::__construct();
$this->_module = "myivr";
}
}
.....
$myIvrModule = new CPBX_MYIVR();
CPBXEngine::getInstance()->registerModule($myIvrModule,__DIR__); //Зарегистрировать новый модуль
CPBXEngine::getInstance()->registerModuleExtension($myIvrModule,'ivr',__DIR__); //Подменить существующий модульجلبت التطبيقات المعقدة الأولى الفخر الأول وخيبات الأمل الأولى. لقد كنت سعيدًا لأن الأمر نجح، وأنني تمكنت بالفعل من إعادة إنتاج الميزات الرئيسية FreePBX. كنت سعيدًا لأن الناس أحبوا فكرة المخطط. لا يزال هناك العديد من الخيارات لتبسيط عملية التطوير، ولكن حتى في ذلك الوقت كانت بعض المهام قد أصبحت أسهل بالفعل.
كانت واجهة برمجة التطبيقات (API) لتغيير تكوين PBX مخيبة للآمال - ولم تكن النتيجة ما أردناه على الإطلاق. أخذت نفس المبدأ كما في FreePBX، بالنقر فوق الزر "تطبيق"، تتم إعادة إنشاء التكوين بالكامل وإعادة تشغيل الوحدات.
تبدو هكذا:
*Dialplan هي قاعدة (خوارزمية) تتم من خلالها معالجة المكالمة.
ولكن مع هذا الخيار، من المستحيل كتابة واجهة برمجة تطبيقات عادية لتغيير إعدادات PBX. أولاً، عملية تطبيق التغييرات على النجمة طويلة جدًا ومستهلكة للموارد.
ثانيا، لا يمكنك استدعاء وظيفتين في نفس الوقت، لأنه كلاهما سيقوم بإنشاء التكوين.
ثالثًا، يقوم بتطبيق جميع الإعدادات، بما في ذلك الإعدادات التي قام بها المسؤول.
في هذا الإصدار كما في اسكوزيا، كان من الممكن إنشاء تكوين الوحدات النمطية التي تم تغييرها فقط وإعادة تشغيل الوحدات الضرورية فقط، ولكن هذه كلها مجرد تدابير نصفية. وكان من الضروري تغيير النهج.
الإصدار الثاني. الأنف انسحبت الذيل عالقة
لم تكن فكرة حل المشكلة هي إعادة إنشاء التكوين وخطة الاتصال لـ النجمةولكن احفظ المعلومات في قاعدة البيانات واقرأها من قاعدة البيانات مباشرة أثناء معالجة المكالمة. النجمة كنت أعرف بالفعل كيفية قراءة التكوينات من قاعدة البيانات، فقط قم بتغيير القيمة في قاعدة البيانات وستتم معالجة المكالمة التالية مع مراعاة التغييرات، وكانت الوظيفة مثالية لقراءة معلمات Diaplan REALTIME_HASH.
في النهاية، لم تكن هناك حاجة حتى لإعادة التشغيل النجمة عند تغيير الإعدادات وبدأ تطبيق كافة الإعدادات على الفور النجمة.
التغييرات الوحيدة التي طرأت على خطة الاتصال هي إضافة أرقام فرعية و تلميحات. لكن هذه كانت تغييرات طفيفة
exten=>101,1,GoSub(‘sub-callusers’,s,1(1)); - точечное изменение, добавляется/изменяется через ami
; sub-callusers – универсальная функция генерится при установке модуля.
[sub-callusers]
exten =>s,1,Noop()
exten =>s,n,Set(LOCAL(TOUSERID)=${ARG1})
exten =>s,n,ClearHash(TOUSERPARAM)
exten =>s,n,Set(HASH(TOUSERPARAM)=${REALTIME_HASH(rl_users,id,${LOCAL(TOUSERID)})})
exten =>s,n,GotoIf($["${HASH(TOUSERPARAM,id)}"=""]?return)
...يمكنك بسهولة إضافة أو تغيير خط في خطة الاتصال باستخدام عامي (واجهة التحكم النجمة) ولا يلزم إعادة تشغيل خطة الطلب بالكامل.
أدى هذا إلى حل مشكلة واجهة برمجة تطبيقات التكوين. يمكنك أيضًا الانتقال مباشرة إلى قاعدة البيانات وإضافة مجموعة جديدة أو تغييرها، على سبيل المثال، وقت الطلب الهاتفي في حقل "وقت الاتصال" للمجموعة وستستمر المكالمة التالية بالفعل في الوقت المحدد (هذه ليست توصية لـ الإجراء، نظرًا لأن بعض عمليات واجهة برمجة التطبيقات تتطلب ذلك عامي المكالمات).
جلبت التطبيقات الصعبة الأولى مرة أخرى الفخر وخيبة الأمل الأولى. كنت سعيدا لأنه نجح. أصبحت قاعدة البيانات رابطا حاسما، وزاد الاعتماد على القرص، وكانت هناك مخاطر أكثر، ولكن كل شيء يعمل بثبات ودون مشاكل. والأهم من ذلك، الآن كل ما يمكن القيام به من خلال واجهة الويب يمكن القيام به من خلال واجهة برمجة التطبيقات (API)، وتم استخدام نفس الأساليب. بالإضافة إلى ذلك، تخلصت واجهة الويب من زر "تطبيق الإعدادات على PBX"، والذي غالبًا ما نسيه المسؤولون.
كانت خيبة الأمل هي أن التطوير أصبح أكثر تعقيدًا. منذ الإصدار الأول، قامت لغة PHP بإنشاء مخطط اتصال باللغة النجمة ويبدو غير قابل للقراءة تمامًا، بالإضافة إلى اللغة نفسها النجمة لكتابة مخطط الطلب فهو بدائي للغاية.
كيف بدا الأمر:
$usersInitSection = $dialplan->createExtSection('usersinit-sub','s');
$usersInitSection
->add('',new Dialplanext_gotoif('$["${G_USERINIT}"="1"]','exit'))
->add('',new Dialplanext_set('G_USERINIT','1'))
->add('',new Dialplanext_gosub('1','s','sub-AddOnAnswerSub','usersconnected-sub'))
->add('',new Dialplanext_gosub('1','s','sub-AddOnPredoDialSub','usersinitondial-sub'))
->add('',new Dialplanext_set('LOCAL(TECH)','${CUT(CHANNEL(name),/,1)}'))
->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="SIP"]','sipdev'))
->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="PJSIP"]','pjsipdev'))في الإصدار الثاني، أصبح Dialplan عالميًا، حيث تضمن جميع خيارات المعالجة الممكنة اعتمادًا على المعلمات وزاد حجمه بشكل كبير. كل هذا أدى إلى إبطاء وقت التطوير بشكل كبير، وفكرة أنه كان من الضروري التدخل مرة أخرى في مخطط الطلب، جعلني أشعر بالحزن.
النسخة الثالثة
لم تكن فكرة حل المشكلة هي التوليد النجمة اطلب خطة من php واستخدمها FastAGI واكتب جميع قواعد المعالجة في PHP نفسها. FastAGI يسمح النجمةلمعالجة المكالمة، قم بالاتصال بالمقبس. تلقي الأوامر من هناك وإرسال النتائج. وبالتالي، فإن منطق Diaplan هو بالفعل خارج الحدود النجمة ويمكن كتابتها بأي لغة، في حالتي PHP.
كان هناك الكثير من التجربة والخطأ. كانت المشكلة الرئيسية هي أنه كان لدي بالفعل الكثير من الفئات/الملفات. استغرق إنشاء الكائنات وتهيئتها وتسجيل بعضها البعض حوالي 1,5 ثانية، وهذا التأخير لكل مكالمة ليس شيئًا يمكن تجاهله.
كان من المفترض أن تتم التهيئة مرة واحدة فقط وبالتالي بدأ البحث عن حل بكتابة خدمة في PHP باستخدام باتريدس. بعد أسبوع من التجارب، تم تأجيل هذا الخيار بسبب تعقيدات كيفية عمل هذا الامتداد. بعد شهر من الاختبار، اضطررت أيضًا إلى التخلي عن البرمجة غير المتزامنة في PHP؛ كنت بحاجة إلى شيء بسيط ومألوف لأي مبتدئ في PHP، والعديد من ملحقات PHP متزامنة.
كان الحل هو خدمتنا متعددة الخيوط في لغة C، والتي تم تجميعها باستخدام PHPLIB. يقوم بتحميل جميع ملفات ATS php، وينتظر تهيئة جميع الوحدات، ويضيف رد اتصال لبعضها البعض، وعندما يصبح كل شيء جاهزًا، يقوم بتخزينه مؤقتًا. عند الاستفسار عن طريق FastAGI يتم إنشاء دفق، ويتم إعادة إنتاج نسخة من ذاكرة التخزين المؤقت لجميع الفئات والبيانات فيه، ويتم تمرير الطلب إلى وظيفة php.
مع هذا الحل، الوقت من إرسال مكالمة إلى خدمتنا إلى الأمر الأول النجمة انخفضت من 1,5 ثانية إلى 0,05 ثانية وهذه المرة تعتمد قليلاً على حجم المشروع.
ونتيجة لذلك، تم تقليل الوقت اللازم لتطوير Diaplan بشكل كبير، ويمكنني أن أقدر ذلك حيث كان علي إعادة كتابة Diaplan بالكامل لجميع الوحدات في PHP. أولاً، يجب كتابة الأساليب بالفعل بلغة php للحصول على كائن من قاعدة البيانات، وكانت هناك حاجة إليها للعرض في واجهة الويب، وثانيًا، وهذا هو الشيء الرئيسي، أصبح من الممكن أخيرًا العمل بشكل ملائم مع السلاسل ذات الأرقام والمصفوفات مع قاعدة بيانات بالإضافة إلى العديد من ملحقات PHP.
لمعالجة مخطط الطلب في فئة الوحدة النمطية، تحتاج إلى تنفيذ الوظيفة dialplanDynamicCall والحجة pbxCallRequest سيحتوي على كائن للتفاعل معه النجمة.
بالإضافة إلى ذلك، أصبح من الممكن تصحيح أخطاء الطلب الهاتفي (يحتوي PHP على xdebug وهو يعمل لخدمتنا)، ويمكنك التحرك خطوة بخطوة من خلال عرض قيم المتغيرات.
بيانات المكالمة
تتطلب أي تحليلات وتقارير بيانات تم جمعها بشكل صحيح، وقد مرت كتلة PBX هذه أيضًا بالكثير من التجارب والأخطاء من الإصدار الأول إلى الإصدار الثالث. في كثير من الأحيان، بيانات المكالمة هي علامة. مكالمة واحدة = تسجيل واحد: من اتصل، من أجاب، كم من الوقت تحدثوا. في خيارات أكثر إثارة للاهتمام، هناك علامة إضافية تشير إلى موظف PBX الذي تم الاتصال به أثناء المكالمة. لكن كل هذا لا يغطي سوى جزء من الاحتياجات.
وكانت المتطلبات الأولية:
- حفظ ليس فقط من اتصل PBX، ولكن أيضًا من أجاب، لأنه هناك اعتراضات ويجب أن يؤخذ ذلك في الاعتبار عند تحليل المكالمات،
- الوقت قبل التواصل مع الموظف. في FreePBX وبعض أنظمة PBX الأخرى، تعتبر المكالمة قد تم الرد عليها بمجرد أن يلتقط PBX الهاتف. ولكن بالنسبة للقائمة الصوتية، فأنت بحاجة بالفعل إلى التقاط الهاتف، بحيث يتم الرد على جميع المكالمات ويصبح وقت انتظار الرد 0-1 ثانية. لذلك، تقرر توفير ليس فقط الوقت قبل الاستجابة، ولكن الوقت قبل الاتصال بالوحدات الرئيسية (الوحدة نفسها تحدد هذه العلامة. حاليًا هي "الموظف"، "الخط الخارجي")،
- بالنسبة لخطة الاتصال الأكثر تعقيدًا، عندما تنتقل المكالمة بين مجموعات مختلفة، كان من الضروري أن تكون قادرًا على فحص كل عنصر على حدة.
تبين أن الخيار الأفضل هو عندما ترسل وحدات PBX معلومات عن نفسها عند المكالمات وتحفظ المعلومات في النهاية على شكل شجرة.
تبدو هكذا:
أولا، معلومات عامة عن المكالمة (مثل أي شخص آخر - لا شيء خاص).
- تلقيت مكالمة على خط خارجي"للعجين"الساعة 05:55:52 من الرقم 89295671458 إلى الرقم 89999999999، وفي النهاية تم الرد من قبل أحد الموظفين"سكرتير2» بالرقم 104. انتظر العميل 60 ثانية وتحدث لمدة 36 ثانية.
- موظف "سكرتير2"يتصل على 112 والموظف يرد"مدير1» بعد 8 ثواني. يتحدثون لمدة 14 ثانية.
- يتم تحويل العميل إلى الموظف "مدير1"حيث يواصلون الحديث لمدة 13 ثانية أخرى
ولكن هذا هو غيض من فيض؛ لكل سجل يمكنك الحصول على سجل مكالمات مفصل من خلال PBX.
يتم تقديم جميع المعلومات كتداخل للمكالمات:
- تلقيت مكالمة على خط خارجي"للعجين» الساعة 05:55:52 من الرقم 89295671458 إلى الرقم 89999999999.
- في تمام الساعة 05:55:53 يقوم الخط الخارجي بإرسال اتصال إلى دائرة الوارد "تجربه بالعربي»
- عند معالجة مكالمة وفقًا للمخطط، يتم استخدام الوحدة "مكالمة مدير"، حيث تكون مدة المكالمة 16 ثانية. هذه وحدة تم تطويرها للعميل.
- وحدة "مكالمة مدير" يتم إرسال اتصال للموظف المسؤول عن الرقم (العميل) "مدير1" وينتظر 5 ثواني للرد. المدير لم يجيب.
- وحدة "مكالمة مدير"يرسل مكالمة إلى المجموعة"مديري كورب" هؤلاء هم مديرون آخرون من نفس الاتجاه (يجلسون في نفس الغرفة) وينتظرون الرد لمدة 11 ثانية.
- مجموعة "مديري كورب"استدعاء الموظفين"مدير1, مدير2, مدير3"في وقت واحد لمدة 11 ثانية. لا اجابة.
- تنتهي مكالمة المدير. وترسل الدائرة مكالمة إلى الوحدة "اختيار الطريق من 1C" أيضا وحدة مكتوبة للعميل. هنا تمت معالجة المكالمة لمدة 0 ثانية.
- تقوم الدائرة بإرسال مكالمة إلى القائمة الصوتية "الأساسية مع الاتصال الإضافي" انتظر العميل هناك لمدة 31 ثانية، ولم يكن هناك أي اتصال إضافي.
- يرسل المخطط مكالمة إلى المجموعة "أمناء"، حيث انتظر العميل 12 ثانية.
- في المجموعة، يتم استدعاء موظفين في نفس الوقت "سكرتير1"و"سكرتير2" وبعد 12 ثانية يجيب الموظف "سكرتير2" يتم تكرار الرد على المكالمة في مكالمات الوالدين. اتضح أنه في المجموعة أجاب "سكرتير2"، عند الاتصال بالدائرة أجاب"سكرتير2"والرد على المكالمة على الخط الخارجي ب"سكرتير2".
إن حفظ المعلومات حول كل عملية وتداخلها هو الذي سيجعل من الممكن إعداد التقارير ببساطة. سيساعدك التقرير الموجود في القائمة الصوتية في معرفة مدى مساعدتك أو إعاقتك. إنشاء تقرير بالمكالمات الفائتة من قبل الموظفين مع مراعاة أن المكالمة تم اعتراضها وبالتالي لا تعتبر فائتة، ومراعاة أنها كانت مكالمة جماعية، وقام شخص آخر بالرد في وقت سابق، مما يعني أن المكالمة لم يتم تفويتها أيضًا.
سيسمح لك تخزين المعلومات هذا بأخذ كل مجموعة على حدة وتحديد مدى فعالية عملها، وإنشاء رسم بياني للمجموعات التي تم الرد عليها والمجموعات التي لم يتم الرد عليها حسب الساعة. يمكنك أيضًا التحقق من مدى دقة الاتصال بالمدير المسؤول من خلال تحليل التحويلات بعد الاتصال بالمدير.
يمكنك أيضًا إجراء دراسات غير نمطية تمامًا، على سبيل المثال، عدد المرات التي تطلب فيها الأرقام غير الموجودة في قاعدة البيانات الامتداد الصحيح أو النسبة المئوية للمكالمات الصادرة التي يتم إعادة توجيهها إلى الهاتف المحمول.
النتيجة؟
لا يلزم وجود متخصص لصيانة PBX، ويمكن للمسؤول العادي القيام بذلك - تم اختباره عمليًا.
بالنسبة للتعديلات، ليست هناك حاجة إلى متخصصين ذوي مؤهلات جدية، ومعرفة PHP كافية، لأن لقد تمت بالفعل كتابة الوحدات النمطية لبروتوكول SIP وقائمة الانتظار واستدعاء الموظف وما إلى ذلك. هناك فئة المجمع ل النجمة. لتطوير وحدة نمطية، يمكن للمبرمج (ويجب عليه ذلك بطريقة جيدة) استدعاء الوحدات الجاهزة. والمعرفة النجمة ليست ضرورية على الإطلاق إذا طلب العميل إضافة صفحة تحتوي على بعض التقارير الجديدة. لكن الممارسة تظهر أنه على الرغم من قدرة مبرمجي الطرف الثالث على التأقلم، إلا أنهم يشعرون بعدم الأمان دون التوثيق والتغطية العادية للتعليقات، لذلك لا يزال هناك مجال للتحسين.
يمكن للوحدات:
- إنشاء إمكانات جديدة لمعالجة المكالمات،
- إضافة كتل جديدة إلى واجهة الويب،
- ترث من أي من الوحدات الموجودة، أو تعيد تعريف الوظائف وتستبدلها، أو ببساطة تكون نسخة معدلة قليلاً،
- أضف إعداداتك إلى قالب الإعدادات الخاص بالوحدات الأخرى وغير ذلك الكثير.
إعدادات PBX عبر API. كما هو موضح أعلاه، يتم تخزين جميع الإعدادات في قاعدة البيانات وقراءتها في وقت المكالمة، حتى تتمكن من تغيير جميع إعدادات PBX من خلال واجهة برمجة التطبيقات. عند استدعاء واجهة برمجة التطبيقات (API)، لا تتم إعادة إنشاء التكوين ولا تتم إعادة تشغيل الوحدات، وبالتالي، لا يهم عدد الإعدادات والموظفين لديك. يتم تنفيذ طلبات API بسرعة ولا تحظر بعضها البعض.
يقوم نظام PBX بتخزين جميع العمليات الرئيسية مع المكالمات ذات الفترات (الانتظار/المحادثة)، والتداخل وبمصطلحات PBX (موظف، مجموعة، خط خارجي، وليس قناة، رقم). يتيح لك ذلك إنشاء تقارير متنوعة لعملاء محددين، ويتمثل معظم العمل في إنشاء واجهة سهلة الاستخدام.
سيخبرنا الوقت بما سيحدث بعد ذلك. لا يزال هناك العديد من الفروق الدقيقة التي تحتاج إلى إعادة بنائها، ولا تزال هناك العديد من الخطط، ولكن لقد مر عام منذ إنشاء الإصدار الثالث ويمكننا أن نقول بالفعل أن الفكرة تعمل. العيب الرئيسي للإصدار 3 هو موارد الأجهزة، ولكن هذا عادة ما يتعين عليك دفع ثمنه مقابل سهولة التطوير.
المصدر: www.habr.com