تجربه من در مورد نوسازی Mainframe برای بانک بزرگ ایالات متحده (Bhasheer Lepakshi)

پیشینه مدرن سازی Mainframe:

      پس از شروع انقلاب رایانه ای در بانکداری، بیمه و سایر بخش های اصلی، Mainframe یکی از بزرگترین انقلاب ها برای ذخیره و مدیریت داده ها به روشی امن تر بود. حتی در حال حاضر بسیاری از بانک ها و شرکت های بیمه بزرگ هنوز سیستم Mainframe را حفظ می کنند.

      با گذشت زمان، از نظر فناوری تغییرات زیادی رخ داد و جهان دیجیتالی تر شد و کاربران/مشتریان می خواهند به داده ها در کسری از ثانیه دسترسی داشته باشند و زمانی برای رفتن به روش سنتی بانکداری و سایر خدمات وجود نداشته باشد. بنابراین بانک ها و سایر صنایع مجبور به حرکت به سمت دیجیتال هستند.

 در این دنیای دیجیتال سریع، دسترسی به داده‌های سیستم‌های قدیمی مانند Mainframe برای ارائه خدمات سریع به مشتریان دشوار شده است، بنابراین مشتریان به دنبال مدرن‌سازی هستند.

ابتکارات عمده ای که برای مدرن سازی Mainframe باید دنبال شود عبارتند از:

1. مهندسی مجدد: تبدیل مخرب به پلتفرم های دیجیتال مانند خدمات ابری و میکرو
2. میزبانی مجدد: بسترسازی مجدد برنامه های کاربردی واجد شرایط در پلتفرم توزیع شده با حفظ معماری قدیمی و کد
3. In Place Modernization: Leverage System z و System I با ترکیبی مناسب در Legacy
4. جایگزینی: پس از انجام آنالیز برازش کامل، برنامه را با محصول مناسب COTS جایگزین کنید

این وبلاگ در مورد سناریوی مهندسی مجدد توضیح می دهد. در این سناریو باید قوانین کسب و کار را از کد Legacy استخراج کنیم که تیم Forward Engineering به عنوان سند مورد نیاز استفاده خواهد شد:

چگونه کد Mainframe را به قوانین تجاری تبدیل کنیم؟

1. آماده سازی الگو:

     هر زمان که ما هر تبدیل Legacy را شروع می کنیم، اولین چالش این است که منطق کسب و کار موجود را درک کنیم و آن را به قالب مناسبی برسانیم که تیم مهندسی فوروارد بتواند آن را درک کند و راه کدنویسی خود را ارائه دهد.

این الگو برای کنار هم قرار دادن قوانین کسب و کار کلیدی است، اگر الگو بتواند موارد زیر را توصیف کند، مفید خواهد بود:

1. خلاصه شغل (خلاصه JCL) که باید موارد زیر را شرح دهد -
   1. قابلیت کار / شرح
   2. فایل های مورد استفاده در کار (خواندن/نوشتن)
   3. جداول DB2 استفاده شده (برنامه نویسی)
   4. اطلاعات زمان بندی
   5. جریان کار (احتمالاً ساختار درختی)
   6. راه اندازی مجدد دستورالعمل
2. قوانین تجاری - باید قوانین مرتبط با عملکرد خاص از برنامه خاص را توصیف کند
3. طرح‌بندی ضبط – طرح‌بندی ضبط/ساختارهای فایل مورد استفاده در برنامه
4. نقشه برداری میدانی – باید به صورت تصویری یا در قالب جدول نحوه انجام نقشه برداری منبع را در منطق/برنامه تجاری توضیح دهد.

   2. نوشتن قوانین تجارت:

     کد را تجزیه و تحلیل کنید و جریان منطقی برنامه را درک کنید. سعی نکنید هر پاراگراف را به عنوان یک قانون بنویسید، در صورت نیاز ممکن است مجبور شویم پاراگراف ها را ترکیب کنیم تا منطق/قانون تجاری را به روشی منطقی بیاوریم.

هنگام نوشتن قوانین کسب و کار باید موارد زیر در نظر گرفته شود:

• هر تراکنش و شغل را به یک عملکرد تجاری ترسیم کنید   
• پس از ثبت قوانین، آنها را به سطح 4، سطح 3، سطح 2، سطح 1 و سطح 0 ترسیم کنید. سطح 0 بالاترین است و ترکیبی از سطوح 1 تا 4 برای دستیابی به این ویژگی است (به عنوان مثال: ورود مشتری سطح 0 خواهد بود)
• سرفصل ها، سرفصل های فرعی – سرفصل ها و عنوان های فرعی هنگام نوشتن قوانین تجاری برای مثال بسیار مهم هستند: به طور کلی، Processing Paragraph برای پردازش منطق اصلی وجود دارد، تمام عملکردهای این بخش / پاراگراف به عنوان زیرعنوان ارائه می شود، شما می توانید کل را درک کنید. جریان یا منطق با دیدن عنوان و زیر عنوان.
• متغیرهای موقت / متغیرهای ذخیره سازی کار – اطمینان حاصل کنید که مرجع هر متغیر Temp را ذکر کنید، شماره قانون را در جایی که از این متغیر استفاده خواهیم کرد یا ارجاع خواهیم داد، ذکر کنید 
• IF شرایط و ارزیابی بیانیه ها – در سبک برنامه نویسی قدیمی برای شرایط IF END-IF ذکر نمی شود، بنابراین حتماً END-IF را ذکر کنید و در صورت وجود IF های تو در تو از رنگ ها استفاده کنید. هر شرط را به یک قانون خاص بشکنید.
• حلقه های PERFORM – به وضوح در مورد حلقه زمانی که شروع می شود و زمانی که پایان می یابد ذکر کنید
• آرایه ها / جداول - تمام اعلان در مورد Arrays/Table و استفاده مرتبط با آن برای یک تابع خاص را ذکر کنید.
• پایگاه داده – در حین نوشتن منطق مربوط به پایگاه داده، بهتر است که DECLARE CURSOR و سایر دستورات SQL را به عنوان یک قانون بنویسید و هر کجا که نیاز دارید مرجع را ارائه دهید. معنی SQLCODE را در حین اضافه کردن منطق در Business Rule ذکر کنید.
• مدیریت خطا - مطمئن شوید که رسیدگی به خطا به همراه عبارات DISPLAY به درستی مستند شده است.
• روال های رایج - قوانین معمول روال را می توان در یک برگه یا سند مشترک قرار داد تا تیم مهندسی فوروارد بتواند آنها را یک بار بسازد و از آن استفاده کند.

ارائه قوانین تجاری به تیم مهندسی فوروارد:

       چالش اصلی که چقدر می‌توانید منطق را برای تیم مهندسی پیشرو توضیح دهید، اگر لیسانس فنی بگیرید که در مورد سیستم دانش دارد، به اندازه کافی خوش شانس هستید! به طوری که شما می توانید منطق را توضیح دهید و BA متوجه می شود و می تواند موارد استفاده را بیاورد.

راه بهتر از سمت Mainframe ارائه نمودار جریان با جریان بسیار بالا در سطح شغلی است. به طوری که هضم آن برای تیم مهندسی فوروارد در کل جریان و برای بچه های Mainframe آسان است که در مورد جریان توضیح دهند.

مطمئن شوید که تمام منطق را برای تیم مهندسی BA و Forward توضیح دهید. و اگر طراحی سطح پایین در بخش Forward Engineering ایجاد شود، آنگاه به روش کار خودشان. برای تیم مفید خواهد بود.

تبدیل قوانین به جاوا:

      هنگام تبدیل Mainframe COBOL به جاوا، باید تفاوت بین COBOL و Java را درک کنید. اولاً، COBOL زبان رویه‌ای است و مراحل را به ترتیب تعریف می‌کرد. در حالی که جاوا زبان شی گرا است که از مفاهیم OOPs پیروی می کند.

انواع برنامه هایی را که برای COBOL مناسب هستند در نظر بگیرید. اصطلاح COBOL مخفف Common Business Oriented Language است. این زبان برای پشتیبانی از عملکردهای تجاری مانند گزارش دهی، خرد کردن اعداد و پردازش داده ها طراحی شده است. این بدان معنا نیست که COBOL نمی تواند انواع دیگر پردازش را انجام دهد. می تواند. فقط اینکه برخی از انواع برنامه ها ممکن است با استفاده از زبان دیگری بهتر توسعه داده شوند.

    جاوا یک زبان برنامه نویسی شی گرا است که برای محاسبات چند منظوره مناسب است و مزیت آن قابل حمل بودن در چندین پلتفرم سخت افزاری است. توانایی اجرای یک برنامه بر روی کامپیوترهای مختلف (اگر ماشین مجازی جاوا برای پلتفرم موجود باشد) یکی از دلایلی است که جاوا یکی از محبوب ترین زبان ها برای توسعه جدید امروزی است.

ملاحظات زیر باید از سمت جاوا برای تبدیل کد COBOL انجام شود:

1. استانداردهای کدنویسی جاوا را مطابق با محیط مشتری درک کنید
2. تفاوت بین انواع داده COBOL و جاوا
3. توابع معادل بین COBOL و جاوا.
4. در صورت تماس های پایگاه داده قدیمی (JPA یا JDBC) از چه اتصال پایگاه داده در جاوا استفاده می شود؟
5. آیا می توان برای پرس و جوهای DB بهینه سازی Query انجام داد؟
6. آیا اجرای موازی (بین مراحل) امکان پذیر است؟
7. آیا می توانیم منطق Chunking را روی عملیات DML پیاده سازی کنیم؟
8. هر روال/سرویس معمولی نیاز به ایجاد و استفاده مجدد از آنها دارد

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• پلاتوبلاک چین. Web3 Metaverse Intelligence. دانش تقویت شده دسترسی به اینجا.
• منبع: https://www.finextra.com/blogposting/23602/my-experience-on-mainframe-modernization-for-major-us-bank?utm_medium=rssfinextra&utm_source=finextrablogs