اولین محصول شرکت SAP یک سیستم حسابداری مالی (Financial Accounting) بود که در سال 1972 با نام R/1 منتشر شد. روی mainframe اجرا میشد و معماری تک-لایه ای داشت. هدف شون توسعه یک سیستم استاندارد بود برای پردازش بلادرنگ داده ها (Real-time data processing). حرف R در این نامگذاری هم به همین خاطر بود. سال 1979 نسخه دوم رو بنام R/2 منتشر کردن که همچنان روی mainframe بود ولی معماریش دو-لایه بود و امکانات بیشتری داشت مثل فروش (Sale) و مدیریت مواد (Material Management). تا اینکه در سال 1992، یعنی حدوداً بیست سال بعد از اولین نسخه، SAP نسخه R/3 رو منتشر کرد که یک تحول بزرگ به حساب میومد. دیگه خبری از mainframe نبود و روی چند پلتفرم قابل اجرا بود. یک معماری کلاینت-سروری (client-server) داشت و امکانات سیستم در قالب ماژول ها بودند که مشتری میتونست بسته به نیازش هر ماژول رو بخره.
فلش فوروارد: انقلاب بعدی SAP بعد از R/3 حدوداً بیست سال طول میکشه و در سال 2015 نسخه S/4HANA معرفی میشه.
SAP R/3 یک ساختار چند لایه داره که از 3 لایه اصلی تشکیل شده:
لایه ارائه (Presentation Layer): این لایه در بالاترین سطح هستش و کاربر باهاش سر و کار داره. همون UI که کاربران میبینن و توش دیتا وارد میکنن و گزارش میگیرن. عنصر اصلیش SAP-GUI (Graphical User Interface) هست و گویا روی همه سیستم عامل هایی که از جاوا پشتیبانی کنن نصب میشه؛ مثل لینوکسی ها و همچنین ویندوز. خیلی ها بهش میگن «سَپ گویی». انصافاً به زمان خودش هم کاربر پسند (user-friendly) بوده. یه SAP Logon هم داریم که این در واقع هم میشه باهاش تنظیمات سیستم رو انجام داد و هم SAPgui مربوطه رو باهاش اجرا کرد.
لایه کاربردی برنامه (Application Layer): این لایه در وسط هستش و منطق برنامه و فرآیندها توش نوشته شده. درخواست های کاربر رو پردازش میکنه و هر کاری لازم باشه انجام میده. اپلیکیشن سرورها (Application servers) ارتباط بین لایه Presentation و Database رو برقرار میکنن.
لایه پایگاه داده (Database Layer): این لایه در پایین ترین سطح قرار داره و داده های سیستم رو ذخیره و مدیریت میکنه. همه دیتابیس های رابطه ای (RDBMS) مثل Microsoft SQL Server و Oracle و همچنین SAP HANA میتونن توی این لایه استفاده بشن.
مقیاس پذیری (Scalability): معماری چند لایه به سازمان ها این امکان رو میده که هر لایه رو به طور مستقل، بسته به نیازشون مقیاس بندی کنند. یعنی مثلاً میتونن فشار کاری لایه Application رو روی چند سرور تقسیم کنن. اینجوری کاربران زیادی میتونن بدون هیچ مشکلی همزمان از سیستم استفاده کنن.
کارایی (Performance): جدا بودن لایه ها منجر به بالا رفتن کارایی و بهبود عملکرد سیستم میشه. چون لایه ها میتونن مستقل عمل کنند و حجم بار سیستم بین این سه لایه تقسیم میشه.
قابلیت اطمینان (Reliability): ماژولار بودن این معماری باعث میشه که خرابی در یک لایه، لزوماً لایه دیگه ای رو تحت تاثیر قرار نده و سیستم قابل اطمینان تر خواهد بود.
امنیت (Security): اقدامات امنیتی رو میشه توی هر لایه پیاده سازی کرد که این منجر به حفاظت بهتر از داده ها میشه و کنترل دسترسی سیستم رو تقویت میکنه.
سفارشی سازی (Customization): به لطف معماری منعطفی که R/3 داره، سازمان ها میتونن سیستم رو بر اساس نیازهای خودشون تنظیم کنن.
ما توی این نوشته نمیخوایم خیلی وارد جزئیات بشیم، چون هم خیلی گسترده ست و هم میتونه پیچیده باشه. فقط خیلی خلاصه اگه بخوایم نحوه کار این معماری رو توضیح بدیم اینجوری میشه:
وقتی کاربر یه درخواستی (request) رو از طریق SAP GUI ارسال میکنه، Message Server اون درخواست رو دریافت میکنه و با توجه به ملاحظاتی که خودش میدونه (از جمله load balancing) اون رو به یکی از Application Serverها ارسال میکنه. داخل اپلیکیشن سرور، Dispatcher اون درخواست رو میگیره و با توجه به نوعش به یکی از Work Processهای آزاد الصاق میکنه (همینجا اگه work processی آزاد نباشه اونو میذاره توی یه صف که بهش میگن Dispatcher Queue تا نوبتش بشه). Work Process کار اون درخواست رو انجام میده (اینجا احتمالاً لازم میشه که بره سمت دیتابیس و یه کاری بکنه) و بعد نتیجه رو به Dispatcher برمیگردونه. و از اونجا هم نتیجه به SAP GUI برمیگرده و به کاربر نشون داده میشه.
(ادامه دارد...)
لینک ها:
