مشاركة عبر

التحديث المركزي والوسطى مع Azure Logic Apps

  • مقالة

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

بالنسبة للمؤسسات التي لديها استثمارات في الأنظمة المركزية والوسطى، وهذا يعني الاستفادة الأفضل من الأنظمة الأساسية التي ساعدت في إرسال البشر إلى القمر أو ساعدت في بناء الأسواق المالية الحالية وتوسيع قيمتها باستخدام السحابة والذكاء الاصطناعي (الذكاء الاصطناعي). هذا السيناريو هو المكان الذي تلعب فيه Azure Logic Apps وإمكانياتها الأصلية للتكامل مع الأنظمة المركزية والوسطى الدوران، من خلال فتح الباب أمام العالم الذكاء الاصطناعي للاستثمارات القديمة. من بين ميزات أخرى، تتضمن Azure Logic Apps القدرات الأساسية لخادم تكامل المضيف (HIS)، والذي تم استخدامه للتكامل المركزي والوسطى في قلب عملاء Microsoft الأكثر استراتيجية على مدى أكثر من 20 عاما. ونتيجة لذلك، أصبحت Azure Logic Apps نظام أساسي للتكامل كخدمة (iPaaS) للأنظمة المركزية والوسطى.

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

القدرات الأصلية السحابية لتكامل النظام المركزي والوسطى

منذ عام 1990، قدمت Microsoft التكامل مع الأنظمة المركزية والوسطى من خلال Microsoft Communications Server. تطور إضافي ل Microsoft Communications Server الذي أنشأ خادم تكامل المضيف (HIS) في عام 2000. بينما بدأ HIS كبوابة هندسة شبكة النظام (SNA)، توسع HIS ليشمل مخازن بيانات IBM (DB2 و VSAM و Informix) وأنظمة معاملات IBM (CICS وIMAS وIBM i) ومراسلة IBM (MQ Series). استخدم عملاء Microsoft الاستراتيجيون هذه التقنيات لأكثر من 20 عاما.

لتمكين العملاء الذين يديرون التطبيقات والبيانات على Azure من مواصلة استخدام هذه التقنيات، قامت Azure Logic Apps وVisual Studio بدمج هذه الإمكانات تدريجيا. على سبيل المثال، يساعدك مصمم HIS لتطبيقات المنطق التي تعمل على Visual Studio وأداة التصميم 3270 على إنشاء بيانات تعريف البيانات الاصطناعية المطلوبة من قبل الموصلات المضمنة التي تستخدمها للتكامل المركزي والوسطى في Azure Logic Apps. تعمل هذه الموصلات المضمنة باستخدام نفس موارد الحوسبة مثل مهام سير عمل تطبيق المنطق القياسي. لا يسمح لك هذا التصميم فقط بتحقيق سيناريوهات زمن انتقال منخفض، ولكن أيضا يوسع نطاق وصولك لمعالجة المزيد من التعافي من الكوارث واحتياجات العملاء عالية التوفر.

رسم تخطيطي تصوري يوضح قدرات Microsoft السحابية الأصلية لتكامل الكمبيوتر المركزي.

لمزيد من المعلومات حول قدرات Microsoft للتكامل المركزي والوسطى، تابع إلى الأقسام التالية.

Microsoft HIS Designer for Logic Apps

تنشئ هذه الأداة بيانات تعريف النظام المركزية والمتوسطة المدى ل Azure Logic Apps وتعمل مع Microsoft Visual Studio من خلال توفير مصمم رسومي بحيث يمكنك إنشاء كائنات بيانات التعريف وعرضها وتحريرها وتعيينها إلى البيانات الاصطناعية المركزية. تستخدم Azure Logic Apps هذه الخرائط لعكس البرامج والبيانات في الأنظمة المركزية والوسطى. لمزيد من المعلومات، راجع HIS Designer for Logic Apps.

أداة تصميم Microsoft 3270

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

موصلات Azure Logic Apps لأنظمة IBM المركزية والوسطى

تصف الأقسام التالية الموصلات المضمنة المستندة إلى موفر الخدمة التي يمكنك استخدامها للوصول إلى أنظمة IBM المركزية والوسطى والتفاعل معها عند إنشاء مهام سير عمل قياسية في Azure Logic Apps.

إشعار

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

IBM 3270

يسمح موصل Azure Logic Apps هذا ل 3270 لسير العمل القياسي بالوصول إلى تطبيقات IBM المركزية وتشغيلها التي تقودها عادة عن طريق التنقل عبر 3270 شاشة محاكي. يستخدم الموصل دفق TN3270. لمزيد من المعلومات، راجع دمج التطبيقات المستندة إلى الشاشة 3270 على أجهزة الكمبيوتر المركزية من IBM مع Azure باستخدام Azure Logic Apps وموصل IBM 3270.

IBM Customer Information Control System (CICS)

يوفر موصل Azure Logic Apps هذا ل CICS مهام سير العمل القياسية مع القدرة على التفاعل والتكامل مع برامج CICS باستخدام بروتوكولات متعددة، مثل TCP/IP وHTTP. إذا كنت بحاجة إلى الوصول إلى بيئات CICS باستخدام LU6.2، فأنت بحاجة إلى استخدام خادم تكامل المضيف (HIS). لمزيد من المعلومات، راجع دمج برامج CICS على أجهزة IBM الرئيسية مع مهام سير العمل القياسية في Azure Logic Apps باستخدام موصل IBM CICS.

IBM DB2

يتيح موصل Azure Logic Apps هذا ل DB2 الاتصالات بين مهام سير العمل القياسية وقواعد بيانات DB2 إما في أماكن العمل أو في Azure. يوفر الموصل لمتخصصي تكنولوجيا المعلومات في المؤسسة والمطورين وصولا مباشرا إلى المعلومات الحيوية المخزنة في أنظمة إدارة قواعد البيانات DB2. لمزيد من المعلومات، راجع الوصول إلى موارد IBM DB2 وإدارتها باستخدام Azure Logic Apps.

ملفات مضيف IBM

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

IBM i

يتيح موصل Azure Logic Apps هذا ل IBM لسير العمل القياسي التفاعل والتكامل مع برامج COBOL وRPG التي تعمل على أنظمة IBM i باستخدام TCP/IP. إذا كنت بحاجة إلى الوصول إلى بيئات IBM i باستخدام LU6.2، فأنت بحاجة إلى استخدام Host Integration Server (HIS). لمزيد من المعلومات، راجع دمج برامج COBOL وRPG على نطاقات IBM المتوسطة مع مهام سير العمل القياسية في Azure Logic Apps باستخدام موصل IBM i.

IBM Information Management System (IMS)

يستخدم موصل Azure Logic Apps هذا ل IMS مكون IBM IMS Connect، والذي يوفر وصولا عالي الأداء من مهام سير العمل القياسية إلى معاملات IMS باستخدام TCP/IP. يستخدم هذا النموذج قائمة انتظار رسائل IMS لمعالجة البيانات. لمزيد من المعلومات، راجع دمج برامج IMS على أجهزة IBM الرئيسية مع مهام سير العمل القياسية في Azure Logic Apps باستخدام موصل IBM IMS.

IBM MQ

يتيح موصل Azure Logic Apps هذا ل MQ الاتصالات بين مهام سير العمل القياسية وخوادم IBM MQ في أماكن العمل أو في Azure. توفر Microsoft أيضا قدرات تكامل IBM MQ مع خادم تكامل المضيف خادم BizTalk. لمزيد من المعلومات، راجع الاتصال بخادم IBM MQ من سير عمل في Azure Logic Apps.

تحديات تحديث الأنظمة المركزية والوسطى

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

على الرغم من أن القائمة التالية غير شاملة، فإن تحديد استراتيجية التحديث الناجحة يتضمن الحد الأدنى من طرق التعامل مع المهام التالية:

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

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

  • الانفجار الكبير

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

  • موجات مرنة

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

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

الانفجار الكبير أو الشلال

عادة ما يكون لترحيل الانفجار الكبير المراحل التالية:

رسم تخطيطي تصوري يوضح نهج مراحل ترحيل الانفجار الكبير.

  1. تصور: الركلة

  2. التخطيط: تحديد وإعداد تسليمات التخطيط، مثل النطاق والوقت والموارد.

  3. المبنى: يبدأ بعد الموافقة على التسليمات التخطيطية

    تتوقع هذه المرحلة أيضا تحديد جميع أعمال التبعيات، ومن ثم يمكن بدء أنشطة الترحيل. تحدث تكرارات متعددة لإكمال عمل الترحيل.

  4. الاستقرار أو الاختبار: يبدأ عند اختبار البيئة والتبعيات والتطبيقات التي تم ترحيلها مقابل مناطق الاختبار في بيئة الكمبيوتر المركزي.

  5. التوزيع: بعد الموافقة على كل شيء، ينتقل الترحيل مباشرة إلى الإنتاج.

تركز المؤسسات التي تختار هذا النهج عادة على تأمين الوقت ونطاق الترحيل والموارد. يبدو هذا المسار خيارا إيجابيا ولكنه يتضمن المخاطر التالية:

  • قد تستغرق عمليات الترحيل شهورا أو حتى سنوات.

  • عمليات التوزيع إلى الإنتاج أكثر خطورة.

  • لم يعد التحليل الذي تقوم به في بداية رحلة الترحيل أو أثناء التخطيط دقيقا لأن هذه المعلومات قديمة عادة.

  • تركز المؤسسات عادة على الحصول على وثائق شاملة لتقليل مخاطر التسليم للتسليم.

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

موجات مرنة

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

عادة ما يحتوي ترحيل الموجات Agile على الدورات المتكررة التالية:

رسم تخطيطي تصوري يوضح ترحيل الكمبيوتر المركزي مع نهج الموجات Agile.

  • دورة متكررة صفرية (0)

    • حدد الفريق، وتراكم العمل الأولي، والتبعيات الأساسية.
    • تحديد الميزات والحد الأدنى من المنتجات القابلة للتطبيق (MVP) المطلوب تسليمها.
    • ابدأ الاستعداد المركزي مع مجموعة مختارة من عناصر العمل أو قصص المستخدم لبدء العمل.

  • الدورة المتكررة 1، 2، ...، N

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

رسم تخطيطي تصوري يوضح ترحيل الكمبيوتر المركزي مع موجات Agile لكل تدفقات.

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

توصي Microsoft بتحديث أحمال عمل النظام المركزية والمتوسطة النطاق من خلال اتباع نموذج متكرر قائم على الموجات Agile من خلال التركيز على الاستثمارات في النظام الأساسي الجديد، مع الحد من نمو الأنظمة القديمة. ويقلل هذا النهج بدرجة كبيرة من مخاطر التنفيذ من خلال الحفاظ على قيمة الأعمال الحالية، مع إدخال البيئة المحدثة. وبهذه الطريقة، يمكن لفريقك أيضا الاستفادة من المهارات التكنولوجية التي تساعد عملك على أن يكون أكثر قدرة على المنافسة. هذا السيناريو هو المكان الذي يمكن أن تساعدك فيه Azure Logic Apps في رحلة التحديث الخاصة بك.

أنماط التحديث

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

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

نمط الطبقة المضادة للتلف

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

رسم تخطيطي تصوري يوضح نمط طبقة مكافحة الفساد.

لمزيد من المعلومات، راجع طبقة مكافحة الفساد.

نمط Strangler Fig

بعد تنفيذ طبقة مكافحة الفساد، يحدث التحديث تدريجيا. لهذه المرحلة، تحتاج إلى استخدام نمط "Strangler Fig" حيث يمكنك تحديد أحمال العمل أو الميزات المركزية التي يمكنك تحديثها بشكل متزايد. على سبيل المثال، إذا اخترت تحديث تطبيق CICS، يجب عليك ليس فقط تحديث برامج CICS، ولكن على الأرجح تطبيقات 3270 جنبا إلى جنب مع التبعيات والبيانات والمهام الخارجية المقابلة لها.

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

رسم تخطيطي تصوري يوضح نمط Strangler Fig.

لمزيد من المعلومات، راجع نمط Strangler Fig.

أنماط الملحمة والرقص

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

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

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

رسم تخطيطي تصوري يوضح نمط SAGA.

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

الخطوات التالية