سنلقي نظرة هذا الأسبوع على أساسيات خدمة Cognos Mashup. سنقوم بتقسيمها إلى الأجزاء المكونة لها لمعرفة كيف تجلب القيمة إلى مزيج عروض IBM Cognos.
من أجل الاستفادة من خدمة Cognos Mashup ، يحتاج المرء إلى تلبية الحد الأدنى من المتطلبات التالية:
1. IBM Cognos BI Server 8.4.1
2. عميل قادر على التفاعل مع SOAP أو الخدمات المستندة إلى URL عبر HTTP
يمكن الوصول إلى اتصال Cognos وخدمة Cognos Mashup عبر بوابة Cognos
ملاحظة المؤلفين: استخدم صوت الممثل R. Lee Ermey (Gunny from كامل معدن دثار)
بالنسبة إلى المقالات القليلة التالية ، سأكون معلمك. يمكنك مناداتي "رقيب الحفر". سوف أقوم بتقسيم المجندين إلى حبيبات الرمل المنخفضة التي أتت منها وأعيد بناءك إلى قطع محفورة بالليزر من السيليكون. ستغادر هنا مع الأدوات التي تحتاجها للبقاء على قيد الحياة في ساحة المعركة المعروفة باسم Cognos Mashup Service. ستكون قادرًا على ترميز طريقك عبر تضاريس التصور المخصصة الخطرة. ستكون قادرًا على التمييز بين الصديق والعدو عندما يتعلق الأمر بمفاهيم التصميم. ربما كنت تعتقد أنه سيتم ترميزك بوعد خدمات REST السهلة. لكن هذه ليست راحة والدتك. هل يمكنني الحصول على "نعم عامل الحفر!"؟ الآن أسقط وأعطني عشرين!
حسنًا ، دعني آخذ استراحة من الشخصية لأعطيك إياها مباشرة. سنلقي نظرة هذا الأسبوع على أساسيات خدمة Cognos Mashup. سنقوم بتقسيمها إلى الأجزاء المكونة لها لمعرفة كيف تجلب القيمة إلى مزيج عروض IBM Cognos.
من أجل الاستفادة من خدمة Cognos Mashup ، يحتاج المرء إلى تلبية الحد الأدنى من المتطلبات التالية:
1. IBM Cognos BI Server 8.4.1
2. عميل قادر على التفاعل مع SOAP أو الخدمات المستندة إلى URL عبر HTTP
يمكن الوصول إلى اتصال Cognos وخدمة Cognos Mashup عبر بوابة Cognos
تتكون خدمة Cognos Mashup من جزأين متميزين يعملان جنبًا إلى جنب للسماح للمستهلكين بتقسيم بيانات التقرير خارج عارض التقارير إلى تصورات مخصصة. جزء من الخدمة هو واجهة النقل والآخر هو الحمولة. في الرسم البياني أدناه ، يمكننا اعتبار الطلب بمثابة النقل والاستجابة كحمولة.
واجهة النقل هي الوسيلة التي يمكننا من خلالها استدعاء التقارير. هناك خياران للمستهلكين لاستخدامهما. أحدهما يعتمد على SOAP والآخر يستخدم عناوين URL بنمط REST. تعمل كلتا الواجهتين عبر HTTP وهي متشابهة في الهيكل. أي ، لكل عملية منطقية في واجهة نمط SOAP هناك عملية مطابقة في نمط REST. تراعي مواصفات الطريقة الدقيقة الخصائص المميزة لأسلوب الاحتجاج المختار. لكن المحصلة النهائية هي ... أن القدرة على تسجيل الدخول ، واستدعاء التقرير ، والحصول على المخرجات ، وتسجيل الخروج متاحة لكلا المعسكرين.
لذلك قد تسأل نفسك "ذاتك ، لماذا أختار واحدة على الأخرى؟" غالبًا ما تظهر الإجابة على هذا عند النظر إلى تقنية أو اتفاقيات المشروع. خذ مثال المستهلك الذي تم تطويره بالكامل من جانب العميل. يستخدم HTML و JavaScript للتفاعل مع خدمة Cognos Mashup. في الفراغ ، ستجعل الواجهة القائمة على REST URL عملية تكامل أسهل. في المقابل ، قد يحتوي مشروع آخر على أصول Cognos SDK موجودة في Java servlet. لقد اعتادوا على بذرة SOAP التي تعرضها SDK. من الطبيعي أن يميل هذا الموقف إلى كونه مستهلكًا قائمًا على SOAP لخدمات المزج. من الناحية العملية ، لم يكن هذا حقًا خيارًا صعبًا للتقييم. عند النظر إلى الخيارين ، يبدو أن المرء دائمًا ما يكون مناسبًا بشكل أفضل عند التفكير في الحل الشامل. محاولات استخدام الآخر تشعر بالإكراه.
تسمح العمليات المنطقية التي توفرها واجهة النقل للمستهلك بأداء المهام التي تتمحور حول تشغيل تقارير وتحليلات Cognos. تسمح مجموعة الخيارات للمستهلك بالسير خلال دورة الحياة الكاملة لتشغيل التقرير. هذا يشمل:
• المصادقة
• تعيين المعلمة
• تنفيذ التقرير (متزامن وغير متزامن)
• حفر السلوك
• استرداد الإخراج
تقدم خدمة Mashup بعض الأشياء الجيدة التي لا تتوفر عبر SDK. ومع ذلك ، سنحفظ هذه المناقشة لمقال قادم يقارن خدمة Mashup مقابل SDK.
الآن لدينا وسيلة لاستدعاء التقارير من خلال مجموعة خدمات تعتمد على HTTP. ماذا يخرج الطرف الآخر؟ يقودنا ذلك إلى المكون الثاني لخدمة Mashup. أدخل… "الحمولة".
أحد الخيارات التي يمكننا تحديدها عند استدعاء تقرير من خلال خدمة Mashup هو تنسيق الإخراج. هناك عدد من الخيارات المتاحة بما في ذلك HTML Layout Data XML (LDX) و JSON. هناك عدد قليل من الآخرين ولكن هذا يغطي النطاق في أبroad يشعر. HTML هي إلى حد كبير ما تتوقعه. إنها تشبه إلى حد بعيد ما يمكن للمرء الحصول عليه من تقرير يتم عرضه من خلال عارض التقارير داخل Cognos Connection. التنسيقات الواعدة هي LDX و JSON. في الواقع ، إذا كان هناك خطأ واضح في خدمة Cognos Mashup ، فهو تقديم هذين التنسيقين.
ينتج عن كلا هذين التنسيقين إخراج التقرير بتنسيق عرض تقديمي محايد. يسمح هذا للمستهلك بإخراج التقرير لتقديم المعلومات في أي تصور يمكنه فهم JSON أو XML. خذ لحظة لقراءة ذلك مرة أخرى.
يتم الآن تحرير بيانات التقرير من القيود الموضوعة عليها بواسطة Cognos Viewer. يمكن أن تتجول البيانات الآن في أماكن كانت غير عملية في السابق. على سبيل المثال ، يمكن لتطبيقات الإنترنت الغنية استخدام أطر عمل مثل Google Visualization API أو Ext-JS لإضفاء الإثارة على عرض البيانات. يصبح تكامل الهاتف المحمول أكثر قابلية للتحقيق حيث يمكن تكييف الإخراج مع هذه الأجهزة. يمكن مزج بيانات Cognos مع بيانات من مصادر خارجية. في الواقع ، شوهدت البيانات من Cognos BI مؤخرًا ، في البرية ، تتمايل مع البيانات من نظام إدارة محتوى شائع في نفس شبكة Ext-JS لا أقل! فضيحة! ماذا يعني هذا؟ في هذه الحالة ، سمح لكلا مجموعتي البيانات بأن تدار من خلال أدواتهما الأصلية دون عملية معقدة مفتعلة لتوحيدهما على المتصفح.
يوجد أدناه نموذج بسيط منخفض الدقة يوضح مصادر البيانات غير المتجانسة التي تشترك في نفس الصفحة.
تأتي هذه المرونة مع بعض المفاضلات. نظرًا لأننا نؤجل تقديم البيانات إلى جزء آخر من التطبيق ، فإننا نقوم بشكل أساسي بنقل بعض التطوير الذي يتم إجراؤه تقليديًا بواسطة مؤلف التقرير إلى شخص خبير في تقنية التصور. ستختلف الجهود المبذولة لنسج بيانات التقرير في التصور مقارنةً بتأليف تقرير مثالي للبكسل في استوديوهات كوجنوس التقليدية. يحتاج مخططو المشروع إلى فهم تأثير ذلك على الجداول الزمنية للتطوير. سيجد المرء أن التقديرات أكثر دقة عندما يتم تبني هذا التقسيم الجديد للعمل.
لتلخيص هذه القطعة ، تعد Cognos Mashup Service إضافة مثيرة لترسانة الأدوات المتاحة لهذا المزيج. يسمح لبيانات BI بتجاوز مجرد ختم ملف ، التي تحتوي على عارض التقرير ، في صفحة HTML. ومع ذلك ، فقد علمنا الوقت أنه لا يوجد شيء بالمجان. تأتي مرونة عرض البيانات على حساب جلب مجموعات مهارات جديدة إلى مجموعة الحلول. دع هذه المعلومات تنقع لفترة من الوقت. في الإدخالات اللاحقة في هذه السلسلة ، سوف ندخل في مزيد من التفاصيل فيما يتعلق باستخدام Mashup بالإضافة إلى كيفية تكديسها مع الحلول المرشحة الأخرى.
