Geekly articles weekly

برنامج DataPower التعليمي

شارك في تأليف المواد من قبل wedmeed


في عام 2017 ، عندما بدأ مشروعنا في فيتنام ، واجهنا الوحش الجديد IBM DataPower بالنسبة لنا. يعد IBM DataPower عبارة عن منتج عبّارة بين العملاء والخلفيات مصممة للتصفية أو التوجيه أو التخصيب أو التحويلات الأخرى للرسائل المارة (يشار إليها فيما بعد باسم الطلبات). كان من الضروري أن نتعلم بسرعة ، ولم يكن هناك وقت للتراكم ، لذلك طُلب منا أن نتعرف عليه ، وبعد ذلك كانت هناك عدة ساعات من مؤتمر Skype مع زميلنا من موسكو ، الذي نقل إلينا معرفته وتجربته مع هذا المنتج.


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


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




الجزء 1. تثبيت DataPower مع Docker Toolbox


تثبيت وتشغيل التطبيق Docker Toolbox. بعد بدء التشغيل مباشرة ، سترى عنوان IP الخاص بالجهاز ، والذي من خلاله ستتوفر DataPower لاحقًا:




لبدء الصورة ، تحتاج إلى تغيير بعض إعدادات الجهاز الظاهري (ذات الصلة بالإصدار IDG.2018.4.1.0) وإعادة تشغيله:


  1. أوقف جهاز الإرساء باستخدام الأمر:

    docker-machine stop
  2. النظام -> اللوحة الرئيسية -> الذاكرة الرئيسية: 4096 ميغابايت على الأقل ؛
  3. النظام -> المعالج: الحد الأدنى 2 ؛
  4. عرض -> الشاشة -> ذاكرة الفيديو: 128 ميغابايت على الأقل ؛
  5. نطلق آلة الإرساء باستخدام الأمر:

     docker-machine start

    ملاحظة إذا طُلب منك إعادة تشغيل env-machine env ، قم بتشغيل:

     docker-machine env
  6. بعد ذلك ، تحتاج إلى فك صورة IBM DataPower:

     docker pull ibmcom/datapower
  7. ثم قم بتشغيل حاوية الإرساء باستخدام الأمر التالي:

     docker run -it \ -v $PWD/config:/drouter/config \ -v $PWD/local:/drouter/local \ -e DATAPOWER_ACCEPT_LICENSE=true \ -e DATAPOWER_INTERACTIVE=true \ -p 9090:9090 \ -p 3630:3630 \ -p 9022:22 \ -p 7170:7170 \ --name idg \ ibmcom/datapower
  8. بعد الانتهاء من الأمر ، اضغط على Enter وأدخل admin / admin كاسم مستخدم وكلمة مرور
  9. لبدء واجهة إدارة الويب ، استخدم الأوامر:

     co

    و

     web-mgmt 0 9090
  10. بعد كل هذه الخطوات ، قم بتنفيذها في المتصفح https://192.168.99.100:9090/

الجزء 2. المجالات


2.1. نظرية


تتيح لك المجالات في DataPower فصل أدوات الإدارة والتطوير ، فضلاً عن توفير الأمان.


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


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


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


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


قليلا عن المشروع المنجز. استخدمنا 3 مجالات:


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

نشأت الحاجة إلى نقل جميع الإعدادات إلى مجال منفصل فيما يتعلق بالبحث عن مسار نشر أبسط. كما هو الحال في العديد من المشاريع ، تم فصل بيئات dev ، test و prod ، وسمح لنا النقل إلى مجال إعدادات منفصلة بتثبيت جميع المجالات الرئيسية من بيئة dev في بيئات أخرى من خلال التصدير / الاستيراد ، دون المخاطرة بفقد إعدادات البيئة.


2.2. الممارسة


  • في حقل البحث ، أدخل "المجال" ، حدد "مجال التطبيق" وانقر فوق "إضافة"
  • هنا تحتاج إلى تحديد اسم المجال والتعليق (إذا رغبت في ذلك) وتفعيل التدقيق والتسجيل. املأ الحقول وقم بتطبيق التغييرات
  • إضافة بالمثل مجال آخر "الجذع"
  • انتقل إلى مراجعة التغييرات
  • وحفظ تكوين المجال
  • يمكنك التحقق من حالة الكائنات التي تم إنشاؤها من خلال الانتقال إلى المجال الافتراضي في شجرة التنقل في الحالة -> الرئيسية -> حالة الكائن
  • اختر عرض حسب: الأنواع
  • ابحث عن "مجال التطبيق" في القائمة وتحقق من حالة الكائنات: يجب حفظ كل منها وتشغيله وفي حالته الأعلى. إذا كان الأمر كذلك ، تابع إلى الفصل التالي.



الجزء 3. مديري قائمة الانتظار


مدير قائمة الانتظار ليس مكونًا إلزاميًا في IBM DataPower ، ولكن من خلال مثال MQ يمكنك إظهار القدرة الكاملة لهذا المنتج. سوف نستخدم MQ من IBM. أثناء الاختبار الموضح في الفصل 6 ، سنحتاج إلى إرسال رسالة إلى مدير قائمة الانتظار المحلي. في هذه المقالة ، سأفعل ذلك باستخدام الأداة المساعدة rfhutil ، لكن يمكنك استخدام أي طريقة متاحة لك. للاختبار ، ستحتاج إلى إنشاء اتصال من DP إلى مدير قائمة الانتظار المحلي باستخدام MQ Queue Manager.



3.1. نظرية


يوفر مدير قائمة الانتظار تبادل البيانات بين البوابة ومديري قائمة الانتظار عن بعد.


يمكنك أيضًا تكوين MQ Queue Manager Group ، مما سيزيد من التسامح مع النظام. قد يكون ذلك مفيدًا ، على سبيل المثال ، إذا كنت ترغب في توصيل العميل بأي من مديري قوائم انتظار العمل وفي بعض الحالات ، يمكنك العثور عليه في الوثائق الرسمية.


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



3.2. الممارسة


3.2.1. التحضير


  1. تثبيت WebSphere MQ؛
  2. إنشاء مدير قائمة انتظار محلي LOCAL_DP_QM ، يمكن الوصول إليه على المنفذ 3630 ؛
  3. تكوين قناة DP.SVRCONN ؛

    عند إنشاء قناة ، قد تكون الأوامر التالية مفيدة لك:


     strmqm LOCAL_DP_QM /*  mq*/ runmqsc LOCAL_DP_QM /*   mq*/ DEFINE CHANNEL (DP.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('evlasenko') /* */ SET CHLAUTH('DP.SVRCONN') TYPE(USERMAP) CLNTUSER('evlasenko') USERSRC(channel) ADDRESS('*') ACTION(ADD) /*      */ SET CHLAUTH(DP.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody') /*   */ ALTER LISTENER (SYSTEM.DEFAULT.LISTENER.TCP) TRPTYPE(TCP) PORT(3630) control(QMGR) /*    3630*/ ALTER AUTHINFO (SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) /* */ REFRESH SECURITY TYPE(CONNAUTH) /*  */ endmqm LOCAL_DP_QM /*  mq*/ strmqm LOCAL_DP_QM /*  mq*/ END

  4. إنشاء قوائم الانتظار DP.IIB.REQIN و DP.IIB.RESIN
  5. قم بتشغيل rfhutil تحت اسم المستخدم الذي تم إنشاء القناة له. في سطر اسم إدارة قائمة الانتظار (للاتصال) ، اكتب:

     DP.SVRCONN/TCT/127.0.0.1(3630)

  6. حاول تحميل قائمة أسماء قوائم الانتظار ؛ يجب ألا يكون هناك أي أخطاء في إطار الرسالة. تم التحقق من الاتصال بالقناة.

3.2.2. قم بتكوين IBM MQ Queue Manager


  1. انتقل إلى مجال الجذع.
  2. في البحث ، اكتب MQ ، حدد IBM MQ Queue Manager ، وانقر فوق إضافة.
  3. تحتاج إلى تحديد الاسم (TEST_QM) ، واسم المضيف لمدير قائمة الانتظار ، واسم مدير قائمة الانتظار واسم القناة ، وكذلك المهلة. تكوين وحفظ التغييرات.


تحقق من حالة كائن مدير قائمة الانتظار بنفس طريقة التحقق من حالة المجالات. للقيام بذلك ، حدد حالة الكائن وتصفية حسب: أنواع تصفية من مجال الجذع. في قسم "IBM MQ Queue Manager" ، ابحث عن العنصر المناسب وتحقق من حالته.


الجزء 4. بوابات البروتوكولات


4.1. نظرية


عبارة بروتوكول متعدد البروتوكولات (MPG) عبارة عن بوابة متعددة البروتوكولات تتيح لك تلقي الطلبات من العملاء الذين يستخدمون بروتوكولات مختلفة ، ثم نقلها إلى خوادم مختلفة باستخدام بروتوكولات مختلفة. قد لا يتطابق البروتوكول الذي يستخدمه العميل مع البروتوكول الذي يستخدمه خادم الوصول عن بُعد.


في إعدادات MPG الرئيسية ، يمكنك تحديد المكونات التالية:

  • إدارة XML - يتحكم في تجميع وتخزين أوراق الأنماط (xsl ، xslt) وتخزينها مؤقتًا في المستندات.
  • السياسة - تتكون من قواعد ، يحدد كل منها مجموعة من الإجراءات المطبقة على الرسالة التي تمر عبر البوابة.
  • إعدادات الجانب الأمامي والخلفي (إعداد عنوان url ، أنواع الرسائل الواردة والصادرة ، المهلات والمزيد).

بضع كلمات عن المشروع:


يستخدم المشروع 4 بوابات متعددة البروتوكولات (التوجيه ، 2 التحويلية لأنظمة نهاية مختلفة وواحدة إضافية مصممة لاستقبال الملفات من مجال الإعدادات). يوضح الرسم البياني أدناه مخطط التفاعل العام:



قد يختلف مقدار MPG اعتمادًا على بنية الحل ككل. في حالتنا ، يواجه DataPower ناقل تكامل (IIB) وخدمات ميكروية لها اختلافات كبيرة في الواجهات (json / http مقابل xml / mq) ، لذلك قررنا إنشاء MPGs تحويلية لكل واجهة خلفية محددة وتسمية ذلك وفقًا لذلك. بالنسبة لجميع العملاء ، نحن نعمل على json / http ، لذلك يعد توجيه MPG واحدًا. تتكون MPGs الرئيسية من 3 قواعد لمعالجة الرسائل - الطلب والاستجابة والأخطاء. تتكون كل قاعدة من الإجراءات الضرورية ، مثل التحويل والتسجيل والتوجيه وغيرها.


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


4.2. الممارسة


4.2.1. التحضير


يمكنك العثور على جميع الملفات اللازمة للعمل على الرابط https://github.com/EvgenyaVlasenko/IBM_DataPower.git

4.2.1.1. جذع المجال


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


4.2.1.2. إعدادات المجال


  1. انتقل إلى مجال الإعدادات.
  2. في لوحة التحكم ، حدد إدارة الملفات.
  3. في الدليل المحلي ، قم بإنشاء بنية الدليل التالية ووضع الملفات المناسبة فيها (تحتوي الملفات أيضًا على وصف موجز لها).


4.2.2. إنشاء GetFileMPG


أولاً ، قم بإنشاء مساعد MPG بسيط سيعيد الملفات من مجال الإعدادات.


  1. انتقل إلى مجال الإعدادات.
  2. في لوحة التحكم ، حدد Multi-Protocol Gateway وانقر فوق إنشاء.
  3. حدد الاسم (GetFileMPG) والوصف (اختياري) ونوع الواجهة الخلفية (الديناميكي). في الواقع ، نظرًا لعدم وجود اتصال إلى الواجهة الخلفية ، وسيتم إرجاع الملف فقط من النظام المحلي ، في هذا المثال ، يمكنك تحديد أي نوع من أنواع الواجهة الخلفية.

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


  5. انقر على + وحدد معالج HTTP لإنشاء بروتوكول أمامي جديد.


  6. يجب عليك هنا تحديد اسم وعنوان IP ومنفذ وقائمة بالطرق المسموح بها. إيلاء الاهتمام لعنوان IP. إذا حددت 0.0.0.0 ، فيمكن للجميع الوصول إلى هذه العبارة. إذا 127.0.0.1 - فقط بوابات أخرى داخل نفس DataPower. نظرًا لوجود معلمات أمان بين الإعدادات ، فإننا نستخدم الخيار الثاني. املأ الحقول وانقر فوق "تطبيق" ، سيتم إضافة البروتوكول تلقائيًا إلى البوابة.


  7. انقر على + لإضافة سياسة جديدة.


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


  10. انقر نقرًا مزدوجًا على إجراء المطابقة لتكوينه ، وحدد قاعدة موجودة وتطبيق التغييرات. سيكون من الصحيح أيديولوجيًا وضع قيود على القدرة على تلقي طلبات الحصول على الطلبات فقط ، ولكن في إطار مهمة التدريب ، يمكنك تحديد الطلب الحالي.
  11. أضف إجراءً آخر - GatewayScript بسحبه إلى القاعدة وتكوينه. كتحويل ، سوف نستخدم الملف المعد ، والذي في النظام المحلي: /// سوف يعثر على الملف بالاسم من URI للطلب الوارد ووضعه في نص الرسالة. سيتم نقل نتيجة العملية مباشرة إلى المخزن المؤقت الإخراج من القاعدة. حفظ التغييرات.


  12. يجب أن تبدو نتيجة السياسة النهائية كما يلي:


  13. اكتمال إنشاء MPG وحفظ التغييرات.
  14. يمكنك التحقق من نجاح إنشائها باستخدام Object Object ، على غرار التحقق من حالة المجالات ومدير قائمة الانتظار. للقيام بذلك ، حدد "حالة الكائن" و "عرض حسب: تصفية الخدمات" من مجال الإعدادات. في قسم "بوابة البروتوكولات المتعددة" ، ابحث عن الكائن المقابل وتحقق من حالته.
  15. لا يمكنك الاتصال بهذا MPG من الخارج ، نظرًا لأنك قمت بحمايته بواسطة ip. قم بتغيير ip مؤقتًا من 127.0.0.1 إلى 0.0.0.0 ومنفذ 7171 إلى 7170 وقم بتشغيل الاستعلام التالي:

     curl -vv -k "http://192.168.99.100:7170/trunk/route/routeRules.xml"

  16. يجب أن تحصل على الجواب التالي:


  17. مرة أخرى ، قم بتغيير ip والمنفذ إلى 127.0.0.1:7171 الأصلي.

4.2.3. إنشاء RoutingMPG


الآن قم بإنشاء RoutingMPG. بناءً على طلب الإدخال وقواعد التوجيه ، سيحدد أين ومع أي معلمات يجب إرسال الطلب.


  1. انتقل إلى مجال الجذع.
  2. قم بإنشاء بوابة متعددة البروتوكولات الجديدة وفقًا للبنود 2-10 من القسم 4.2.2 باستخدام القيم التالية:
    • 3 - الاسم: RoutingMPG ، نوع الواجهة الخلفية: ديناميكي (من أجل القدرة على توجيه الطلبات إلى MPGs مختلفة إذا لزم الأمر).
    • 4 - Rq: Non-xml، Rs: Non-xml.
    • 6 - الاسم: RoutingHTTP_FSH، ip: 0.0.0.0، port: 7170، + Get method.
    • 8 - الاسم: RoutingPolicy.
    • 9 - الاسم: RoutingPolicy_rule_req ، الاتجاه: العميل إلى الخادم.

  3. أضف إجراءً واحدًا لتوجيه الطلب ، وللقيام بذلك ، اسحب إجراء "التوجيه" إلى القاعدة ، وانقر نقرًا مزدوجًا فوقه لتهيئته ، وملء الحقول وتطبيق التغييرات. يتلقى ملف route.xsl ملف إعدادات التوجيه من مجال الإعدادات من خلال GetFileMPG الذي تم إنشاؤه مسبقًا. بعد ذلك ، استنادًا إلى URI ، يتم بالفعل تحديد الإعدادات الضرورية لهذه العملية من الملف. يتم استخدام بعضها للتوجيه ، ويتم إضافة بعضها إلى الرؤوس للاستخدام في MPGs الأخرى. تحدد معلمات الإدخال والإخراج طريقة العمل فقط مع نص الرسالة ولا تؤثر بأي حال على الرؤوس والمتغيرات. لذلك: إدخال من لاغية - لأن المعلومات من نص الرسالة لا تستخدم للتوجيه. الإخراج فارغ - نظرًا لأن نتيجة التحول هي مجرد تغيير في معلومات الخدمة.


  4. وبالمثل ، قم بإنشاء قاعدتين أخريين واحفظ كل التغييرات:
    • الاتجاه: Server-Client ، الاسم: RoutingPolicy_rule_resp؛
      التحويل: إدخال الإدخال ، الإخراج NULL ، ملف التحويل المحلي: ///RoutingMPG/transform/resp.xslt. يتلقى ملف resp.xslt حالة http لاستجابة MPG للتحويل ويعينها صراحةً إلى استجابة RoutingMPG. إذا لم يتم ذلك ، فسيتم تعيين الرمز الافتراضي على 200 ، حتى لو حدث خطأ في تحويل MPG.
    • الاتجاه: خطأ ، الاسم: RoutingPolicy_rule_error ؛
      التحويل: إدخال الإدخال ، إخراج PIPE (وفقًا للوثائق ، باستخدام PIPE بين جهازي عقد متجاورتين كما يمكن لـ INPUT و OUTPUT القضاء على معالجة إضافية وتقليل مقدار الذاكرة المستخدمة) ، يكون ملف التحويل محليًا: ///RoutingMPG/transform/errors.xsl. يتلقى ملف errors.xsl رمز الخطأ والنص من الاستجابة من MPG للتحول ويقوم بإنشاء رسالة خطأ JSON بالتنسيق المتوقع من قبل العميل.

  5. يجب أن تبدو نتيجة السياسة النهائية كما يلي:


  6. اكتمال إنشاء MPG وحفظ التغييرات.
  7. باستخدام ، على سبيل المثال ، الأداة المساعدة curl ، قم بتشغيل الاستعلام التالي:

     curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage"

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



4.2.4. إنشاء IIBMPG


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


  1. انتقل إلى مجال الجذع.
  2. قم بإنشاء بوابة متعددة البروتوكولات الجديدة وفقًا للبنود 2-10 من القسم 4.2.2 باستخدام القيم التالية:
    • 3 - الاسم: IIBMPG ، نوع الواجهة الخلفية: ديناميكي
    • 4 - Rq: JSON، Rs: XML
    • 6 - الاسم: IIBHTTP_FSH ، ip: 127.0.0.1 (طلبات فقط من نفس DataPower) ، المنفذ: 7172 ، + الحصول على الطريقة
    • 8 - الاسم: IIBPolicy
    • 9 - الاسم: IIBPolicy_rule_req ، الاتجاه: العميل إلى الخادم

  3. أضف وصفا استنادًا إلى X-DP-Transform-Name في رؤوس الطلبات ، يتلقى ملف IIBRuleRoute.xsl من الملف المحلي: ///IIB/route/IIBRouteRules.xml ملف أسماء ملفات تحويل الطلب والاستجابة والخطأ لهذه الخدمة وتعيين قيمها إلى متغيرات السياق المقابلة var: // context / IIB / reqTransform ، var: // context / IIB / ansTransform ، var: // context / IIB / errTransform. يتم أيضًا وضع قيم أخرى من الرؤوس (url ، uri ، تنتهي صلاحيتها ، المهلة) في متغيرات السياق.


  4. أضف إجراءً آخر بسحب "خيارات متقدمة" إلى قاعدتك وتحديد "تحويل استعلامات Query إلى XML" من القائمة ، تكوين. تحتاج إلى إضافة خريطة تحويل إدخال جديدة ، مع إعطائها اسم (cmnJSONParseCNVM) والنوع المطلوب (JSON).




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


  6. إضافة إجراء توجيه وتعيين المعلمات التالية. يتلقى ملف IIBURLRoute.xsl قيم متغيرات السياق ، يتم تعيين بعضها كمتغيرات طلب خدمة ، ومن الباقي يقوم بتكوين URI للطلب إلى النظام الوجهة ، والذي يخزن أيضًا في متغير الخدمة.


  7. وبالمثل ، قم بإنشاء قاعدتين أخريين واحفظ كل التغييرات:
    • الاتجاه: Server-Client ، الاسم: IIBPolicy_rule_resp؛
      التحويل: إدخال الإدخال ، الإخراج PIPE ، ملف التحويل var: // context / IIB / ansTransform (متغير السياق لاستبدال تحويل الاستجابة "على الطاير").
    • الاتجاه: خطأ ، الاسم: IIBPolicy_rule_error ؛
      التحويل: إدخال NULL و PIPE الإخراج وملف التحويل var: // context / IIB / errTransform (متغير السياق لاستبدال تحويل الخطأ على الطاير).

  8. يجب أن تبدو نتيجة السياسة النهائية كما يلي:

  9. اكتمال إنشاء MPG وحفظ التغييرات.

الجزء 5. الاختبار


5.1. التحضير


  1. قم بتنزيل ، على سبيل المثال ، الأداة المساعدة rfhutil لقراءة الرسائل وكتابتها إلى قائمة الانتظار ؛
  2. توجد ملفات الاختبار في مجلد الاختبارات في نفس الدليل مثل ملفات المشروع.

5.2. فحص الصحة


  1. أرسل الطلب باستخدام أداة curl (للطلب أدناه ، يجب أن يكون الدليل الحالي هو نفسه example.json).

     curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage" -H "Content-Type: application/json" --data-binary @example.json

  2. افتح مثيلات 2 من الأداة المساعدة rfhutil وطرح الرسالة من قائمة الانتظار DP.IIB.REQIN مع المثيل الأول؛
  3. انتقل إلى علامة التبويب MQMD وانسخ MessageID ؛
  4. في المثيل الثاني ، افتح ملف rs.xml ، في علامة تبويب MQMD ، أدخل معرف الرسالة في CorrelID ووضع الرسالة في قائمة انتظار DP.IIB.RESIN ؛
  5. يجب أن تحصل على إجابة مماثلة:


  6. كرر الخطوات 1-3 ؛
  7. rs_error.xml correllId;




6.


6.1. نظرية


Log Targets , .


Log Targets . , 4 1000Kb, . 2-4 . , . , DataPower, , , , , , - MPG, .


6.2.


  1. trunk;
  2. Log Target ;
  3. :
    • (IIB_LOG);
    • (File);
    • (Text);
    • timestamp(zulu);
    • (logtemp:///IIB.log — IIBMPG);
    • (1000).


  4. . MPG IIBMPG.


  5. , , ( , ).


  6. ;
  7. ;
  8. .
  9. Log Targets MPG.
  10. :
    • , , .


    • .




7. -


  1. – , . – , , - .
  2. . View Logs. , « », « » .
  3. . . MPG Show Probe -> Enable Probe. . , .


  4. , .

– .

Source: https://habr.com/ru/post/ar442686/

More articles:


All Articles