المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

معلومات أساسية

عرض 50000 قدم

فينسي تومكات

HTTP(s)

XMPP

بونوسبوت

BOSH - التدفقات ثنائية الإتجاه عبر HTTP المتزامنة

CTI

يابي

عرض 30000 قدم

إسبات

أكسل

صابون

عرض يبلغ 20000 قدم

اشنديج الاباتشى

ملفات حرب

عرض يبلغ 10000 قدم

أجاكس - جمال الفاينسيس

فوائد إستخدام AJAX

عمل أجاكس

إرسال طلب مع AJAX إلى الخادم

بنية سطح المكتب

عمارة الأدوات الذكية

روابط مرجعية

المقدمة

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

المتطلبات الأساسية

المتطلبات

توصي Cisco بمعرفة هذه الأدوات والميزات:

JTAPI - Java Telephony API

واجهة برمجة التطبيقات

UCCX - Unified Contact Center Express

CUCM - مدير الاتصالات الموحدة من Cisco

CTI - دمج الاتصال الهاتفي عبر الكمبيوتر

المكونات المستخدمة

- Cisco Unified Contact Center Express (UCCX)

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

معلومات أساسية

يصف هذا المستند بنية Finesse التي تبدأ من نظرة عامة على المستوى العالي ثم تدفق إشارة العمق مع الأمثلة والمخططات.

عرض 50000 قدم

طريقة عرض 50000

فينسي تومكات

Finesse Tomcat مماثل ل Cisco Tomcat في CUCM حيث أن الوظيفة هي نفسها لتحميل صفحات الويب ولكن لخدمة مختلفة تسمى Finesse. لقد تم تصميم تومكت من أجل Finesse لأنها تطبيق ويب منفصل. يمكنك فقط تسجيل الدخول إلى Finesse باستخدام عقدة CCX الرئيسية وفقا للإصدارات السابقة 11.5. من 11.6 فصاعدا، يمكنك تسجيل الدخول إلى أي عقدة (ولكن لا يوصى بذلك)، فقط أثناء تجاوز الفشل. لذلك، إذا وضعت في الاعتبار مجموعة WAN، حيث يتم توصيل الوكلاء (في الموقع A والموقع B) في Finesse على العقدة الرئيسية، ففي جميع الأوقات، يكون هناك اتصال غير نشط بالعقدة الأخرى من Cisco Finesse إلى المحرك، وهو طلب CTI OpenConf مطلوب لتجاوز الفشل.

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

تم تقديم 3 شهادات وهي:

- شهادة خدمة الإعلامات لتلك العقدة.

- شهادة خدمة الإعلام للعقدة البعيدة.

- شهادة خدمة FindSe للعقدة البعيدة.

ملاحظة: يلزم قبول شهادات العقد البعيدة من أجل تشغيل تجاوز الفشل.

HTTP(s)

إنه بروتوكول طبقة تطبيق لإرسال وثائق الوسائط الظاهرية مثل HTML. وهو مصمم للاتصال بين مستعرضات الويب وخوادم الويب. وهو بروتوكول عديم الحالة مما يعني أن الخادم لا يحتفظ بأي بيانات بين الطلبين. هذا بروتوكول خادم عميل. بالنسبة ل UCCX، يعمل عميل Finesse على مستعرض الوكيل (PC). وهو يقدم طلبا إلى الخادم باستخدام HTTP. فيما يلي بعض أساليب HTTP الشائعة:

GET - للحصول على معلومات من خادم.

POST - لإرسال معلومات إلى خادم.

PUT - لاستبدال أي شيء على خادم.

الحذف - لإزالة معلومات من خادم.

يستخدم Finesse طلبات API الخاصة ب SystemInfo داخل طلب HTTP. على سبيل المثال، إذا كنت ترغب في تغيير حالة عميل، يرسل المستعرض PUT بدلا من POST لأنه إذا تم إرسال POST، فسيحدث إرتباك في الخادم نظرا لوجود حالتين في يده، أي حالة يتم تحديدها؟ إذا بإستخدام PUT، فإنه يستبدل الحالة الحالية.

XMPP

بروتوكول الحضور والمراسلة القابلة للتوسيع

إنها مجموعة من البروتوكولات المستخدمة للمراسلة الفورية والحضور. يتم تحديد جميع كيانات XMPP باستخدام معرفات Jabber أو JIDs الخاصة بها. يعرف أحد ملحقات بروتوكول XMPP هذا الذي يتم إستخدامه للأدوات الذكية باسم PUBSUB.

بونوسبوت

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

الغرض من هذه المواصفات هو السماح لخادم XMPP (خدمة الإعلام) بنشر المعلومات إلى عقد XMPP (موضوعات) ثم إرسال أحداث XMPP إلى الكيانات المشتركة في تلك العقدة.

في حالة Finesse، يرسل خادم دمج الاتصال الهاتفي بجهاز الكمبيوتر (CTI) رسائل CTI إلى خدمة Finesse على الويب لإطلاع Finesse على تحديثات التكوين مثل إنشاء عميل أو قائمة انتظار خدمة جهات الاتصال (CSQ) أو معلومات حول مكالمة، ولكن لا يقتصر على ذلك. يتم بعد ذلك تحويل هذه المعلومات إلى رسالة XMPP تقوم خدمة Finesse على الويب بنشرها إلى خدمة Finesse Notification Service.ثم تقوم خدمة Finesse Notification بإرسال XMPP عبر رسائل BOSH إلى الوكلاء الذين تم اشتراكهم في عقد XMPP معينة.

BOSH - التدفقات ثنائية الإتجاه عبر HTTP المتزامنة

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

ملاحظة: XMPP يحدد الحالة في حين أن HTTP عديم الحالة (لا يقوم بتخزين المعلومات حول الطلب الأخير)

إذا كان تطبيق ويب بحاجة إلى العمل مع XMPP، تنشأ مشاكل متعددة.

المشكلة 1: لا تدعم المستعرضات XMPP عبر بروتوكول التحكم في الإرسال (TCP) بشكل طبيعي.

الحل 1: تتصل خوادم الويب ومستعرضات الويب عبر رسائل بروتوكول نقل النص التشعبي (HTTP)، لذا يقوم Finesse وتطبيقات الويب الأخرى بتغليف رسائل XMPP داخل رسائل HTTP.

المشكلة 2: HTTP هو بروتوكول عديم الحالة.

الحل 2: يمكنك إستخدام ملفات تعريف الارتباط/نشر البيانات لهذا الغرض.

المشكلة 3: تتمثل المشكلة الثالثة في السلوك أحادي الإتجاه ل HTTP مما يعني أن العميل فقط يرسل الطلبات، ويمكن للخادم الاستجابة فقط. عدم قدرة الخادم على دفع البيانات يجعل من غير الطبيعي تنفيذ XMPP عبر HTTP.

الحل 3: للتغلب على هذه المشكلة، تحتاج إلى جسر بين HTTP و XMPP.

والحلول المقترحة هي:

1. الاقتراع (البروتوكول القديم): طلبات HTTP المتكررة التي تطلب بيانات جديدة معرفة: فحص HTTP

2. يعرف الاقتراع الطويل أيضا باسم BOSH: بروتوكول النقل الذي يحاكي دلالات اتصال TCP ثنائي الإتجاه طويل المدى بين كيانين باستخدام أزواج طلب/إستجابة HTTP متعددة التزامن بكفاءة دون الحاجة إلى إستخدام الاقتراع المتكرر. يتمثل سبب إستخدام بروتوكول BOSH في تغطية حقيقة أن الخادم لا يحتاج إلى الاستجابة بمجرد وجود طلب. يتم تأخير الاستجابة حتى وقت محدد حتى يحتوي الخادم على بيانات للعميل، ثم يتم إرسالها كاستجابة. وبمجرد حصول العميل على الاستجابة، يقدم العميل طلبا جديدا وما إلى ذلك.

يقوم عميل Finesse لسطح المكتب (تطبيق ويب) بإنشاء اتصال BOSH قديم عبر منفذ TCP 7443 كل 30 ثانية. بعد 30 ثانية، إذا لم تكن هناك تحديثات من خدمة Finesse Notification، ترسل خدمة Notification رد HTTP يحتوي على 200 OK ونص إستجابة (تقريبا) فارغ. إذا كان لدى "خدمة الإعلامات" تحديث حول وجود حدث وكيل أو حدث حوار (مكالمة)، على سبيل المثال، يتم إرسال البيانات فورا إلى عميل ويب Finesse.

للتلخيص:

يحتوي عميل ويب Finesse على اتصال HTTP قديم (http-bind) تم إعداده إلى خادم Finesse عبر منفذ TCP 7443. وهذا ما يعرف باستطلاع بوش الطويل. خدمة إعلامات Finesse هي خدمة حضور تقوم بنشر التحديثات المتعلقة بحالة العميل والاتصال وما إلى ذلك. إذا كانت خدمة الإعلامات تحتوي على تحديث، فإنها ترد على طلب ربط http مع تحديث الحالة كرسالة XMPP في نص الاستجابة HTTP. في حالة عدم وجود تحديثات حالة بعد 30 ثانية من تلقي طلب ربط http، تقوم "خدمة الإعلام" بالرد دون أي تحديثات حالة للسماح لعميل ويب Finesse بإرسال طلب ربط http آخر. تستخدم هذه الطريقة لكي تعرف خدمة الإعلامات أن عميل ويب Finesse ما يزال قادرا على الاتصال بخدمة الإعلامات وأن الوكيل لم يغلق المستعرض أو يضع الكمبيوتر في وضع السكون وما إلى ذلك.

CTI

يمكنك إستخدام دمج الاتصال الهاتفي بجهاز الكمبيوتر (CTI) للاستفادة من وظائف معالجة الكمبيوتر أثناء إجراء المكالمات الهاتفية وتلقيها وإدارتها. تتيح لك تطبيقات CTI تنفيذ مهام مثل إسترداد معلومات المستخدم من قاعدة بيانات باستخدام معرف المتصل، أو العمل مع المعلومات التي يتم تجميعها بواسطة نظام الاستجابة الصوتية التفاعلية (IVR) لتوجيه مكالمة قادمة من المستخدم بالإضافة إلى معلوماتهم، إلى ممثل الخدمة المناسب. مدير CTI على CUCM يستجيب لطلبات JTAPI من UCCX. منفذ TCP لخادم CTI هو 12018. بهذه الطريقة يلتقي خادم Finesse ومحركها (خادم CTI) مع بعضهما البعض.

فيما يلي بعض المعلومات التي تم تبادلها عبر CTI :

- تكوين النظام الحالي والتحديثات المستقبلية.

- الوكلاء و دولهم.

- المكالمات ودولها.

- إحصائيات العملاء والمكالمات وقوائم الانتظار في الوقت الفعلي.

يابي

يعمل بروتوكول JTAPI الموحد من Cisco كمعيار واجهة برمجة تم تطويره بواسطة Sun Microsystems للاستخدام مع تطبيقات الاتصال الهاتفي عبر الكمبيوتر القائمة على تطبيق جافا. يقوم Cisco JTAPI بتنفيذ مواصفات Sun JTAPI 1.2 مع ملحقات Cisco الإضافية. ويوجد أي اتصال بين UCCX و CUCM في JTAPI. هكذا يتحدث CUCM والمحرك (النظام الفرعي الهاتفي) مع بعضهم البعض. يستخدم JTAPI للتحكم في هواتف CUCM ومراقبتها وتوجيه المكالمات باستخدام منافذ CTI ونقاط المسار، وبدء التسجيلات وإيقافها على CUCM ولأي وظيفة لتوجيه المكالمات

عرض 30000 قدم

يوضح الرسم التخطيطي التالي كيفية اتصال محرك UCCX و Finesse و CUCM ومتصفح الويب فيما بينهم.

طريقة عرض 30000

فلنعتبر أن المكالمة قد تم إجراؤها مع الوكيل. الآن، RmCm الذي يراقب امتداد الوكيل من خلال JTAPI، يخبر خادم CTI عن تغيير الحالة الذي يتحدث عنه الوكيل. يتم إرسال هذه المعلومات من خادم CTI (داخل محرك CCX) إلى خادم Finesse(Tomcat) باستخدام CTI. يرسل خادم Finesse هذه المعلومات إلى خدمة إعلام CCX باستخدام XMPP حول تغيير الحالة. تقوم خدمة الإعلامات (OpenFire) بفتح نفق BOSH إلى مستعرض الوكيل وتحديث المعلومات حول تغيير الحالة وبهذه الطريقة ترى الوكيل ينتقل إلى الحالة المحجوزة. يتم طلب أي نوع من موارد الويب إلى الخادم المحدد باستخدام HTTPS مثل ملفات WAR والأدوات الذكية وما إلى ذلك (إذا لم تكن موجودة في ذاكرة التخزين المؤقت بالفعل).

إسبات

يشرح الرسم التخطيطي التالي خدمة الإسبات.

سبات

يشار إلى الإسبات باسم خدمة الاستمرارية والاستعلام لكائن/علائقي عالية الأداء. ببساطة، فإنه يرسم خرائط لفئات جافا لجداول قاعدة البيانات. على سبيل المثال، لديك كائن JAVA يسمى فريق ولديك جدول قاعدة بيانات في قاعدة بيانات Finesse تسمى فريق. يتحكم Java Class بالمعلومات الموجودة داخل الجدول والإسبات هو ما يجعل ذلك يحدث. بدلا من إستخدام استعلامات SQL، فإنه يستخدم فئات Java لتحديث المعلومات.

أكسل

XML الإداري.

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

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

تستخدم واجهة برمجة تطبيقات AXL المصادقة الأساسية ل HTTPS. يتمتع أي مستخدم CUCM (تطبيق أو مستخدم نهائي) بالوصول للقراءة/الكتابة عبر AXL إذا كان أعضاء في مجموعة التحكم في الوصول ل CCM Super Users القياسية أو أي مجموعة تم تعيين دور الوصول المعياري AXL API لها. وهذا يعني أن جميع حسابات المستخدمين المتميزين لديهم بالفعل حق الوصول إلى واجهة برمجة تطبيقات AXL ضمنيا. لإنشاء حساب مخصص لاستخدام واجهة برمجة تطبيقات AXL، يجب أولا إنشاء مجموعة تحكم في الوصول وتخصيص دور الوصول AXL API القياسي له، ثم إقران مستخدم التطبيق بالمجموعة التي تم إنشاؤها حديثا. لتوفير وصول واجهة برمجة تطبيقات AXL للقراءة فقط، يمكنك إنشاء مجموعة تحكم وصول منفصلة وتخصيص دور وصول AXL للقراءة فقط API لها.

صابون

بروتوكول الوصول البسيط إلى الكائنات (SOAP) هو طريقة لتمرير المعلومات بين التطبيقات بتنسيق XML. يتم إرسال رسائل SOAP من تطبيق الإرسال إلى تطبيق الاستلام، عادة عبر جلسة عمل HTTP. تتكون رسالة SOAP الفعلية من عنصر المظروف، والذي يحتوي على عنصر نص وعنصر رأس إختياري.

- المظروف - هذا العنصر الإلزامي هو جذر رسالة SOAP، مما يعرف XML الذي تم إرساله على أنه حزمة SOAP. يحتوي المظروف على مقطع متن وقسم رأس إختياري.

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

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

عرض يبلغ 20000 قدم

يشرح المخطط التالي بطريقة أكثر تفصيلا حول البروتوكولات المعنية ببنية Finesse.

طريقة عرض 20000

هذه هي البروتوكولات المسؤولة عن الاتصال بين مكونات UCCX المختلفة.

- محادثة بين محرك UCCX وخادم Finesse عبر بروتوكول CTI.

- محرك UCCX ومحرك CUCM يتحدثان عبر بروتوكول JTAPI.

- أحاديث Finesse Tomcat و CUCM عبر AXL.

- خدمة إعلام Finesse وحديث مستعرض الوكيل على XMPP/BOSH.

- Finesse Tomcat وقاعدة البيانات تتحدث عن الإسبات.

- محادثة Finesse Tomcat و Finesse Notification عبر XMPP.

اشنديج الاباتشى

شنديغ

Apache Shindig هي حاوية OpenSocial وتساعدك على البدء في إستضافة تطبيقات OpenSocial بسرعة من خلال توفير التعليمات البرمجية لتقديم الأدوات الذكية وطلبات الوكيل والتعامل مع طلبات REST و RPC. OpenSocial هي مجموعة من واجهات برمجة التطبيقات لبناء التطبيقات الاجتماعية التي تعمل على الويب. يتم إستخدام حاوية (Web/Servlet) من قبل خادم ويب لإنشاء صفحات ويب بشكل ديناميكي.

ملفات حرب

الحرب تعني أرشيفا للويب. يحتوي على ملفات مشروع ويب. يمكن أن يحتوي على خادم، XML، JSP، صورة، HTML، CSS، JS، وهكذا. تحتوي سجلات Catalyina على معلومات حول نشر WARs.

عرض يبلغ 10000 قدم

يشرح المخطط التالي بالتفصيل كيفية عمل تدفق المصادقة داخل مكونات UCCX و Finesse.

عرض 10000

يجب عرض ملفات الحرب وإنشاؤها حسب كيفية تسجيل الدخول. المتصفح يطلب من شركة Shindig أن عليها تقديم الأداة، ثم يتبادل الحديث مع CUIC لتجسيد الأداة. يتم إستخدام نطاق CCX للمصادقة مع CUCM باستخدام AXL. كما تتم مصادقة خدمة الإعلامات مع CUCM باستخدام AXL.

تعد Finesse Rest API War بمثابة المستودع الرئيسي الذي يتصل في الواقع بخدمة الإعلامات ومحرك CCX و DB. Shindig يتحدث فقط مع Finesse Rest API (WebServices) لأن Cfadmin وحروب سطح المكتب فقط لعرض الصفحة. أي شيء يأتي إلى حرب Finesse Rest API، يمكنك أن ترى ذلك في سجلات Finesse WebServices التي هي أهم السجلات للحصول على دقة زائدة. يمكنك التحدث عبر HTTP بين خدمة الويب Shindig و Finesse (Rest API War). خدمة Finesse عبر الويب (Rest API War) ومحرك Engine يتحدثان مع بعضهما البعض عبر CTI.

أجاكس - جمال الفاينسيس

AJAX يمثل JavaScript و XML غير المتزامن. وهي ليست لغة برمجة، بل وسيلة للوصول إلى خوادم الويب من صفحة ويب. AJAX هي آلية لإجراء تحديثات جزئية للصفحة. فهي تمكنك من تحديث أقسام صفحة ببيانات تأتي من خادم دون الحاجة إلى تحديث الصفحة بأكملها.

على سبيل المثال، إذا كنت تتحدث عن Facebook Messenger، فعندما تظهر رسالة جديدة، فلن تكون بحاجة إلى تحديث الصفحة بالكامل للحصول على الرسالة، بدلا من تحديث قسم الرسائل في الصفحة نفسها والحصول على الرسائل الجديدة في الوقت الفعلي دون الحاجة إلى تحديث الصفحة بالكامل.

يحتوي كل متصفح على كائن مدمج يدعى XMLHTTPREQUEST (ويسمى أيضا XHR). كل طلب إلى AJAX في الخادم يمر بطلب XML هذا. يحتوي هذا على تفاصيل ما تحتاج إلى تحديثه.

فوائد إستخدام AJAX

يشرح المخطط التالي الفرق بين الطلبات غير المتزامنة والمزامنة.

أجاكس

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

عمل أجاكس

AJAX هو مزيج من XMLHTTPREQUEST (XHR) والذي يتم إستخدامه لإرسال التحديثات وتلقيها من خادم الويب بالإضافة إلى JavaScript و HTML والتي يتم إستخدامها لعرض البيانات أو إستخدامها.

إرسال طلب مع AJAX إلى الخادم

هذه عملية مكونة من ثلاث خطوات يتم ذكرها فيما يلي:

1. إنشاء متغير وتخزين كائن XHR فيه.

طلب Var = XMLHttpRequest() جديد؛

2. الوصول إلى متغير الطلب الذي يحتوي على الحمولة داخل كائن XHR.

طلب;.open(GET, URL)

3. إرسال الطلب

Request.Send() ؛

بنية سطح المكتب

يشرح المخطط التالي تدفق إشارات AJAX عند عرض أداة ذكية على صفحة الويب.

بنية سطح المكتب

يقيم IfRame في الحاوية لاستضافة نفق BOSH. يتم توفير لوحة وصل OpenAJAX لنشر الرسائل عبر الأدوات الذكية (باستخدام طريقة PUBSUB) ويتم وكيل طلبات REST من خلال Shindig إلى خوادم أخرى أيضا. يمكن للأدوات الذكية نشر رسائلها الخاصة على محور AJAX.

عمارة الأدوات الذكية

يشرح المخطط التالي بنية أداة ذكية دقيقة التفاصيل.

عمارة الأدوات الذكية

على عكس الأدوات الذكية النموذجية، تتلقى أيضا أدوات XMPP تغذية فورية من OpenFire أيضا.  وفي حالة UCCX، حيث يشترك CUIC و Finesse في الإقامة مع UCCX، هناك مثيل OpenFire مشترك. يتم تمثيل معظم محتويات الأداة الذكية وجميع واجهات برمجة التطبيقات (API) المتبقية من خلال Shindig في خادم Finesse. وهذا ينطبق على الأدوات الذكية Finesse وواجهة برمجة تطبيقات REST بالإضافة إلى مثيلات الأدوات الذكية CUIC و REST API. تستخدم أدوات CUIC الذكية D-Grid لتقديم تقاريرها. هناك عملية تمهيد يجب أن تحدث وهذا يتم بالاقتران مع CUIC مباشرة.  لهذا السبب فإن أدوات CUIC الذكية تتحدث في البداية إلى خادم CUIC أثناء عملية التحميل. ولهذا السبب، يجب قبول شهادة CUIC في مستعرض المستخدم (بالإضافة إلى نفق Socket.io). تكون محتويات الأدوات الذكية وواجهات برمجة تطبيقات REST وكيلة للعميل بين Finesse و CUIC. يتم إجراء إستدعاءات REST API لكل من خدمة تقارير مركز الاستخبارات وخدمة ويب CCX. تحصل خدمة CCX Live Data Socket.io على الرسائل من Live Data عبر JMS من ActiveMQ. تقوم خدمة CCX Live Data Socket.io بنشر Real-Time Reporting JSON عبر اتصال Socket.IO من العميل. وكما هو الحال بالنسبة لواجهة Finesse Desktop التي تحتوي على إطار iFrame لنفق BOSH الذي يحتفظ باتصال BOSH مع خدمة Cisco Finesse Notification Service، فإن الأداة الذكية الرئيسية Live Data Device تحتوي على واجهة Socket.IO Tunnel iFrame التي تحافظ على اتصال Socket.IO (WebSocket) مع خدمة CCX Live Data Socket.IO.

يقوم مركز OpenAjax بتوزيع جميع الأحداث على المستمعين المشتركين.  قد تكون هذه الأدوات الذكية بالإضافة إلى أجزاء من حاوية Finesse نفسها. يحتوي سطح المكتب Finesse على إطار iFrame لنفق BOSH الذي يحافظ على اتصال BOSH بخدمة إعلام CCX الموحدة من Cisco.  يقوم هذا بنشر الأحداث على OpenAjax Hub.

روابط مرجعية

- دليل مطور خدمات ويب FindSE