وبلاگ پرنیان پردازش پارس

مقالات آموزش اتوماسیون اداری و شیرپوینت، فیلم های آموزشی، آخرین اخبار و دیگر مطالب مرتبط با دنیای نرم افزارهای سازمانی

اطلاعات بیشتر »

پیاده سازی لایه سرویس در پورتال سرویس گرا با شیرپوینت

بخشهای اول تا سوم این مقاله را در لینکهای زیر مطالعه فرمایید.

بخش اول: "طراحی پورتال سازمانی سرویس‏گرا با شیرپوینت - مقدمه"

بخش دوم: "پورتال سرویس‏گرا با شیرپوینت - دام کلاسیک"

بخش سوم: "نقش BCS در پورتال سرویس گرا با شیرپوینت"

راه های مختلفی برای پیاده سازی لایه سرویس زیر پورتال سازمانی شیرپوینت وجود دارد که SharePoint Service Applications  و BizTalk Server (درون سازمان) و یا Azure Service Bus (ابر) پرکاربردترین ها در محیط های «غیر از شیرپوینت» هستند. BizTalk Server  اغلب استفاده می شود چون معمولا پیاده سازی معماری SOA از طریق استفاده از ESB انجام می شود، و BizTalk Server را می توان با توجه به الگوی طراحی ESB پیاده سازی کرد. اگر شیرپوینت در ابر (SharePoint Online) پیاده سازی شود، Azure Service Bus (که با توجه به الگوی طراحی ESB پیاده سازی می شود) انتخاب بهتری است. برای راه حل ها�� ترکیبی، که در آن بخشی از سرویس درون سازمان و بخشی دیگر در ابر اجرا می شود، الگوی ترکیبی Federated Service Bus بهترین راه حل خواهد بود.

شیرپوینت فقط از ESB (فدراسیون شده) برای مصرف و افشای سرویس  ها استفاده می کند. هر چند برای سناریوهای ساده ی فقط شیرپوینتی، Service Applications می تواند کفایت کند. بخش باقیمانده این مقاله درباره پیاده سازی ESB به عنوان لایه سرویس است.
External Contents Types در شیرپوینت را می توان در مخزن External Content Type Repository سازماندهی و ذخیره کرد (شکل 2 را ببینید). به عنوان مثال، کاربر دانای شیرپوینت می تواند از ECT "Customer" برای نمایش داده  های «زنده» مشتری در یک وب پارت روی صفحه ای که شامل تمام اسناد قبلا رد و بدل شده برای آن مشتری خاص است استفاده کند. همچنین می توان از چندین وب پارت مختلف در یک صفحه استفاده کرد که از طریق استفاده از فناوری وب پارت  های متصل می توانند داده های کلیدی را به اشتراک بگذارند و اطلاعات را در زمینه درست نمایش دهند. به عنوان مثال، نشان دادن داده های مشتری «زنده»، و نشان دادن تمام RFQها و Quoteهای مربوط به آن مشتری در دیگر بخش های آن صفحه کار آسانی است (کافی است «شناسه مشتری» را بین وب پارت ها به اشتراک بگذارید).

شکل 2

مهم این است که این ECT به طور مستقیم به سرویس های ارائه شده در ESB مربوطه لینک شوند. هنگامی که صفحه اصلی Project Site برای «پروژه X برای مشتری Y» نمایش داده می شود، آن را به داده های زنده Customer، RFQ و Quote مربوط به مشتری Y را از طریق ESB بازیابی می کند که به نوبه خود داده ها را از سیستم ها و سرویس های back-end مربوطه از طریق فراخوانی وب سرویس (تنظیم شده) می گیرد.

داستان زمانی جالب تر می شود که ترکیب سرویس مورد نیاز باشد. به عنوان مثال، هنگام ارائه رابط سفارش برای مشتریان خود در بخش اکسترانت پورتال تان. "Order" ECT سرویس Order را در ESB مصرف می کند که می تواند به صورت الگوی Scatter Gather مانند شکل 3 پیاده سازی شود. گذرگاه سرویس Order را به صورت وب سرویسی نشان می دهد که توسط شیرپوینت از طریق ECT مصرف می شود. سرویس Order به صورت سرویس ترکیبی که چند سرویس دیگر را بر اساس نیاز فراخوانی می کند پیاده سازی می شود. به عنوان مثال، می تواند سرویس ارائه شده توسط سیستم CRM را فراخوانی کند تا ببیند که مشتری یک مشتری شناخته شده است و یک مراجعه به آن فراهم کند. گام بعدی می تواند بررسی اعتبار ارائه شده توسط سرویس ابر باشد. مرحله نهایی می تواند ارائه سفارش مشتری به سیستم ERP باشد. نتایج تمام فراخوانی سرویس ها تجمیع می شود و به ECT شیرپوینت برگردانده می شود که از آن برای نمایش نتایج ورودی سفارش در پورتال استفاده خواهد کرد.
فرآیندهای کسب و کار را می توان در ESB مدل سازی کرد، که می تواند کارکردهای سیستم های مختلف backend را ترکیب کند، و قادر به نمایش آنها به صورت سرویس ترکیبی برای مصرف توسط شیرپوینت است. فرآیند کسب و کاری که در ESB اجرا می شود مسئول هماهنگ سازی تعامل با تمام سرویس های مربوطه، و رسیدگی به این فرآیند به عنوان تنها تراکنشی است که در صورت نیاز می تواند رول بک شود.

شکل 3

ESB از سرویس های خود برای انجام درخواست های زیر استفاده می کند:
•    وب سرویس خط سیر: خط سیر (یا تغییر مسیریابی) برای انجام درخواست را تعیین می کند
•    سرویس مسیریابی: مسیریابی درخواست به نقاط پایانی متفاوت
•    سرویس سازگاری پروتکل: فراخوانی سرویس هایی را که مبتنی بر وب سرویس های استاندارد نیستند امکان پذیر می کند
•    سرویس تبدیل: تبدیل بین درخواست ها و مدل داده های متعارف و مدل داده های متعارف و سرویس دهندگان
•    تنظیم فرآیند: برای تنظیم مفصل تر (فراتر از اقدامات خط سیر) فرآیندها، از جمله استفاده از موتور قواعد کسب و کار برای تصمیم گیری

با پیاده سازی ESB کامل BizTalk Server و Azure Service Bus زیر شیرپوینت، مزایای اضافی زیر فراهم خواهند شد:
•    شفافیت نسخه و مکان سرویس
•    تبدیل پروتکل انتقال
•    مدیریت خطا و تعمیر
•    تبدیل فرمت داده ها
•    تعاملات پیام
•    ردیابی و ردگیری انتها به انتها
•    نظارت بر فعالیت (کسب و کار)

مورد آخر بسیار جالب توجه است. از آنجا که تمام سرویس های (ترکیبی) که توسط ESB رسیدگی می شوند از قبل تحت نظارتند، به راحتی می توانید اطلاعاتِ تحت نظارت را به سطحی گسترش دهید که Business Activity Monitoring امکان پذیر شود. با ردیابی مایلستون ها در فرآیندهای کسب و کارتان و یا حتی ردیابی محتوای کسب و کار خاصِی که از تراکنش هایی که توسط ESB پردازش شده اند بازیابی می شود، می توانید راه حل Business Intelligence خود را تغذیه کنید (به عنوان مثال، از طریق قابلیت های SQL Server و SharePoint BI) و از اطلاعات برای تنظیم فرآیندهای کسب و کار خود استفاده کنید. پیاده سازی صحیح مدیریت فرآیند کسب و کار (BPM) دیگر دور از ذهن نخواهد بود.

ارسال نظر

آخرین نظرات

Comment RSS