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

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

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

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

بخش سوم: "نقش 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) دیگر دور از ذهن نخواهد بود.

 

نقش BCS در پورتال سرویس گرا با شیرپوینت

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

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

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

شیرپوینت دارای ویژگی هایی برای یکپارچه سازی اطلاعات از سایر برنامه های کاربردی است. این قابلیت در آخرین نسخه شیرپوینت "Business Connectivity Services" (BCS) نامیده می شود. هنگام استفاده از این فناوری، می توانید از "External Content Types" (ECT)  مانند سایر انواع محتوا در لیست ها و کتابخانه های خود استفاده کنید. اما به جای بازیابی اطلاعات از مخازن داده بومی، شیرپوینت از BCS برای بازیابی داده ها استفاده می کند. ECT طرح و عملیات هایی را که روی داده ها انجام می شود تعریف می کند.

شکل1

همانطور که در شکل 1 دیده می شود، BCS می تواند بازیابی و ارسال داده ها از و به منابع دیگر را با استفاده از پرسش های (query) مستقیم SQL توسط اجزای دات نت یا با فراخوانی وب سرویسها انجام دهد. از طریق BCS، قابلیت های کامل CRUD را در اختیار دارید. با این حال، چند محدودیت وجود دارد. عدم قابلیت برای ترکیب سرویس ها، و استفاده از تبدیل فرمت داده ها مهمترین موارد در این بخش هستند. ترکیب چند منبع داده در یکی و نمایش آن در وب پارت یا لیست استاندارد شیرپوینت (به راحتی) امکان پذیر نیست.
علاوه بر این، افتادن در دام دیگری بسیار آسان است؛ که دام «یکپارچه سازی اسپاگتی» نامیده می شود که در آن بسیاری از سیستم ها و سرویس با یکدیگر به شکل نظیر به نظیر ارتباط برقرار می کنند و در نتیجه وضعیت غیرقابل کنترلی ایجاد می شود.
هنگامی که نگاهی به نمونه های آنلاین BCS می اندازید، می بینید که در بسیاری از آنها اتصال به جداول SQL Server بسیار آسان است. در واقع خوب است، اما چه می شود اگر شما مالک این پایگاه داده SQL نباشید؟ چه می شود اگر یک به روز رسانی نرم افزار موجب تغییر نام ستون یا جدول شود؟ آیا قصد دارید تمام ECTهایی را که قبلا تعریف کرده اید به روز رسانی کنید؟ حتی اگر بتوانید (در مورد دردسرهایی که تقسیم جدول ایجاد می کند فکر کنید)، ممکن است موجب دوباره کاری فراوان در جاهای مختلف شود. مثال دیگر، اتصالات WCF (سرویس های وب) است: چه می شود اگر اکنون محصولات شما در دو انبار ذخیره شوند در حالی که قبلا در یکی ذخیره می شدند؟ شما نیاز به بازنویسی اتصال BCS و تغییر آن به یک کانکتور سفارشی .Net Assembly دارید.
با پیاده سازی یک لایه سرویس در زیر BCS شیرپوینت، مصرف سرویس های ترکیبی و پیاده سازی نسخه های سرویس، ردیابی واقعی انتها به انتها، و نظارت بر ویژگی ها ممکن می شود. همچنین، پیاده سازی لایه سرویس موجب افزایش انعطاف پذیری و قابلیت ها با توجه به رسیدگی به تراکنش ها و ارائه راه حل های مقیاس پذیر و ایمن می شود.
و شاید مهمتر از همه، BCS در ترکیب با لایه سرویس و ویژگی های امنیتی مبتنی بر ادعاها که همراه شیرپوینت است محیط امنی ایجاد می کند که در آن اطلاعات با توجه به مقررات امنیتی، و نقش ها و مسئولیت های تعریف شده در SharePoint Governance Plan مدیریت خواهد شد.

 

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

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

هنگام استفاده از شیرپوینت به عنوان پورتال سازمانی، مهم است بدانید که افتادن در دام کلاسیکی که ابزارهای مایکروسافت به خاطر آن «معروفند» بسیار آسان است: یعنی، آشنایی سریع با محصول و ساخت اولین برنامه های بسیار آسان"hello, world" . با این حال، به سرعت با انواع قابلیت هایی مواجه می شوید که دارند در محیط های تولید استفاده می شوند، و شرکت به سرعت با راه حل پورتال یا اینترانت مواجه می شود که به راحتی قابل کنترل، مقیاس پذیر و پایدار نیستند و یا حتی بدتر محیطی که قابل پشتیبانی نیست.
شیرپوینت محصول ساده ای نیست. می تواند کارهای بسیاری را انجام دهد، و معماری اش بسیار پیچیده است. بنابراین قبل از طراحی و ایجاد راه حل های شیرپوینت، بسیار مهم است که این معماری را بسیار خوب بشناسید، و زیر و بم های پلتفرم را با توجه به توسعه پذیری بشناسید. به راحتی می توانید پلتفرم را مقصر بدانید و نه راه حل هایِ با طراحی ضعیف خودتان، و قبل از اینکه متوجه شوید، شیرپوینت در شرکت شما بدنام می شود، که اصلا منصفانه نیست.
به منظور جلوگیری از بروز چنین وضعیتی، برای ایجاد راه حل ها با استفاده از شیرپوینت به عنوان پلتفرم باید چند قانون ساده را رعایت کنید:
1.    قبل از شروع به ساخت «راه حل های اختصاصی»، مطمئن شوید که در حال حاضر (کم و بیش) در بازار موجود نیست؛ در مورد نیازهای خود با یک مشاور شیرپوینت صحبت کنید.
2.    اطمینان حاصل کنید که راه حل ها را با توجه به معماری شیرپوینت ایجاد می کنید؛ در مورد طراحی راه حل خود با یک معمار شیرپوینت صحبت کنید و بگذارید او طراحی شما را در برابر Project Start Architecture بررسی کند.
3.    طراحی راه حل خود را در برابر SharePoint Governance Plan بررسی کنید؛ تا مطمئن شوید که طراحی شما مطابق دستورالعمل ها و قواعد ایجاد شده برای اینترانت یا پورتال شرکت شماست.
این قواعد به طور کلی به طراحی و توسعه راه حل شیرپوینت اعمال می شوند. به طور خاص درباره یکپارچه سازی محتوای خارجی، دو قاعده دیگر وجود دارد:
1.    اطمینان حاصل کنید که اصول طراحی سرویس را هنگام ارائه اطلاعات و فرآیندها به عنوان سرویس ها در SOA خود رعایت می کنید.
2.    یک لایه سرویس را پیاده سازی کنید تا یکپارچه سازی محتوای خارجی را موثر و قابل مدیریت و قابل پشتیبانی کنید.
سایر بخش های این مقاله که به تدریج در بلاگ پرنیان منتشر می شوند، به بررسی یکپارچه سازی داده های خارجی در شیرپوینت با جزئیات بیشتر می پردازند.

 

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

چکیده: این مقاله به درک این موضوع کمک می کند که چگونه طراحی پورتال سازمانی سرویس گرا با شیرپوینت به عنوان front-end و لایه زیرین میان افزار یکپارچه سازی مبتنی بر Microsoft SOA به م�� امکان می دهد تا از سرویس های ترکیبی استفاده کنیم و فضاهای کاری مرکزی کارآمدتر، مقیاس پذیرتر و قابل پشتیبانی تر ایجاد کنیم که در محیط های BYOD مدرن استفاده شوند.

مقدمه

مایکروسافت شیرپوینت پلتفرم همکاری بسیار رایجی است که بیش از 70 درصد از شرکت ها در سراسر جهان از آن استفاده می کنند. شیرپوینت امکان اشتراک گذاری کارآمدترِ اسناد، بهبود یافت پذیری و ارائه کارکردها برای همکاری با اعضای تیم در پروژه ها و اسناد را فراهم می کند و همچنین می تواند به عنوان پورتال سازمانی پیاده سازی شود. در واقع، با ارائه ویژگی های مدیریت اسناد، قابلیت های اینترانت و یکپارچگی با سیستم های دیگر، می توانید فضای کاری مرکزی مناسب را برای کارکنان، مشتریان و شرکا پیاده سازی کنید و با قابلیت های سلف سرویس، به آنها ارائه کنید.

البته شهرت شیرپوینت به خاطر ذخیره سازی بومی و اشتراک گذاری انواع اسناد و فایل ها، و همچنین فراهم کردن امکان همکاری افراد روی این اسناد است. با این حال، در بسیاری از راه حل های شیرپوینت، بخش بزرگی از اطلاعات از سیستم های خارجی می آید. به همین دلیل، یکپارچگی پروژه های پیاده سازی شیرپوینت اغلب می تواند نقش بزرگ تری ایفاء کند.

یکپارچگی با سایر سیستم ها و سرویس ها باید با توجه به اصول SOA سازماندهی شود تا ابزاری برای گنجاندن داده ها و فرآیندهای خارجی در پورتال فراهم کند، و محیطی ایجاد کند که در آن همه چیز در چارچوب مناسب و با امنیت مناسب گردهم می آید. با پیاده سازی لایه سرویس مبتنی بر SOA در زیر شیرپوینت، ساخت چنین راه حل هایی بسیار ساده تر خواهد شد و نتیجه نهایی خیلی بیشتر مقیاس پذیر و قابل پشتیبانی خواهد بود.

 

مهاجرت از سیستم های سنتی به شیرپوینت - جمع بندی

بیشترین بهره را از سرمایه گذاری در شیرپوینت ببرید
شیرپوینت چارچوبی منعطف و مقیاس پذیر است و مبنای زیرساختی است که می‌تواند گسترش یابد و به روشی مقرون به صرفه نیازهای هر شرکتی را برآورده سازد. مهاجرت پلتفرم مدیریت محتوای فعلی به مدیریت محتوایی که توسط شیرپوینت قدرتمند و مستحکم شده است، به سازمان شما امکان خواهد داد تا سرمایه گذاری در فناوری را مستحکم کرده و سرمایه گذاری‌های بی نقص شما را در فناوری‌های ثابت شدۀ مایکروسافت بیشینه کند.

پلتفرم شیرپوینت همۀ بار سنگین مرتبط با انبارش محتوا، امنیت محتوا، اجازه و تصدیق سندیت را به دوش می‌کشد. واسط کاربر نیز زیربنای قدرتمندی برای قرار دادن محتوا در دسترس کاربران نهایی بدون حتی یک خط کد فراهم می‌کند. اما انعطاف پذیری آنجاست تا موجب خمش، کشش، شکل گیری و در غیر این صورت، بهبود راهبردی که کمی بیش از مجموع بخش‌های خارج از محدوده (out of box) است گردد.

شیرپوینت به خاطر عملی بودن، نوآوری و انطباقش به سرعت به «پلتفرم برگزیده» تبدیل می‌شود. با این حال، محبوبیت ادامه دار «برافزاهای» (add ons) جانبی به سازمان‌ها امکان داده‌اند تا از یک سیستم مدیریت محتوا، مقرون به صرفه تر و زنده تر بهره ببرند. ملاحظات زیادی وجود دارند که باید برآورده شوند و تجربۀ جانبی قطعاً برای مهاجرت‌ها توصیه می‌شود. روند کارها نشان می‌دهد که هزینه ها به  جای مجوزهای شیرپوینت برای برافزاها و خدمات جانبی صرف می‌شوند. تولیدکنندگان جانبی می‌توانند شکاف‌ها (همچون جریان کاری، جستجو و گزارش‌دهی) را پر کنند و خدمات حرفه ای ماهرانه ارائه دهند. با این حال، پیش از تقاضای کمک تولید کنندۀ جانبی در مهاجرت‌ها یا ارزش بر افزا، اطمینان حاصل کنید که تحقیقات خود را انجام داده اید.

نتیجه گیری
داشتن تخصص درست و کافی می‌تواند بین مهاجرتی ضعیف و موفقیت آمیز تفاوت زیادی ایجاد کند. مطمئناً ، حتی با برنامه ریزی و تحلیل کامل و مناسب، چالش‌هایی در هر مهاجرت وجود دارد. نکته کلیدی داشتن تخصصی است که بتواند از عهدۀ چنین چالش‌هایی برآید و اجرای مهاجرت را هموار نگه دارد. مثل هر مهاجرتی، شما باید برنامه ریزی و تحلیل سیستم سنتی و نحوۀ هماهنگی آن با شیرپوینت را به طور کامل و مناسب انجام دهید. معماری مناسب شیرپوینت تضمین خواهد کرد راهبرد شما دسترسی سریع به اطلاعات حیاتی برای کسب‌وکار امروز و آیندۀ کاربران را فراهم می‌کند.

با کارکردی که شیرپوینت دارد کاربران سازمان می‌توانند مزایای نرخ بازگشت سرمایۀ ECM را اهرم‌بندی کنند، از جمله: تطابق بهبود یافته، بهره‌وری کاربر، فرآیندهای کارامدتر کسب‌وکار و امنیت بهتر اطلاعات کسب‌وکار.

 

همه مطالب مربوط به این موضوع را در لینکهای ذیل مطالعه کنید:

 

 

 

جستجوی محتوای حساس در اسناد شیرپوینت

امروزه سازمان‌های مسئول، از انواع روش ها و سیاست‌ها استفاده می‌کنند تا داده‌هایشان را امن و مطمئن نگه دارند. این مساله وقتی که با داده های حساسی (ازجمله شماره کارت اعتباری، شماره امنیت اجتماعی، یا اطلاعات مربوط به مشتری) تا اطلاعات اختصاصی (از جمله اختراع ثبت شده و یا اسناد محرمانه) سر و کار داشته باشیم، اهمیت بیشتری پیدا می‌کنند. حفاظت از این اطلاعات حساس مهم است چراکه سازمان‌ها را قادر می‌سازد تا با صنعت، دولت، و قواعد دیگر همکاری مناسب داشته باشند.
آفیس 365 اکنون این قابلیت‌های ضروری را برای پست الکترونیک با DLP در سرویس‌های اکسچنج، اوتلوک، و OWA فراهم کرده است. خوشبختانه مایکروسافت در حال برداشتن قدم‌های اولیه برای DLP در شیرپوینت و OneDrive است. تا امکان جستجوی امن در اطلاعات حساس را فراهم نماید.

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

در ادامه توضیح می دهیم این قابلیت چگونه به شما کمک می کند:

جستجوی محتوای حساس در شیرپوینت آنلاین و OneDrive
DLP برای شیرپوینت آنلاین و OneDrive، اکنون در نسخه Enterprise جستجو تعبیه شده است. این قابلیت به شما این اجازه را می‌دهد تا محتوای حساس را در مرکز eDiscovery موجود جستجو کنید، و محتوا را در جایش نگه می‌دارد و جستجوی سریع را ممکن می‌کند.

بیشتر...

 

مهاجرت از سیستم های سنتی به شیرپوینت - قبل، حین و پس از مهاجرت

تا کنون در پنج مطلب سریالی با موضوع "مهاجرت از سیستم های سنتی به شیرپوینت" به بررسی روش موفقیت آمیز مهاجرت از یک سیستم سنتی به شیرپوینت پرداختیم. این پست ششم از این مجموعه است که پیشنهاد می کنم قبل از مطالعه آن نگاهی به مطالب قبلی بیاندازید.

 

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

1- قبل از مهاجرت
برای اکثر مهاجرت‌ها، راهبرد سنتی تا مدتی اجرا شده است که به میلیون‌ها سندی که باید انتقال داده شوند منتهی می‌شود. این بدان معناست که شیرپوینت در قاب زمانی بسیاری سریعی با انبوهی از محتوا در شرف انفجار است. مهم است که به ذخیرۀ اسنادی که منتقل خواهند شد نگاهی داشته باشید تا نحوۀ تأثیرگذاری آن بر پلتفرم شیرپوینت مقصد خود را بررسی کنید.

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

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

از معماری انبارۀ مکفی اطمینان حاصل کنید.
از حجم و نرخ بار اسناد برای تعیین انبارۀ ضروری شیرپوینت استفاده کنید، هم از انبارۀ پردازش‌نشدۀ شیرپوینت و هم از کارایی انباره. فهم این نکته از اهمیت برخوردار است که مهاجرت به شیرپوینت یک محاسبۀ مهاجرت سادۀ 1 به 1 نیست. عوامل متعددی وجود دارند که نحوۀ برنامه‌ریزی برای داده های بالاسری را تعیین می‌کنند.

تضمین این مورد مهم است که وب سرورهای شیرپوینت، سرورهای SQL و زیرسیستم‌های انباره می‌توانند از عهدۀ درخواست‌های کاربر نوعی تجاری برآیند بدون اینکه تحت تأثیر بار اضافی قابل توجه اضافه شده توسط سرورهای مهاجرت قرار بگیرند.

وب سرورهای شیرپوینت
برای کاربران فعلی شیرپوینت، اثر راهبرد مهاجرت با حجم بالا بر وب سرورهای فعلی را ارزیابی کنید. در صورت امکان، سرورهای «هدف» اختصاصی را که نرم افزار مهاجرت می‌تواند بدون اثرگذاری بر کاربران نهایی استفاده کند برپا کنید.

  SQL Servers شیرپوینت (لاگ فایل‌ها)
حین مهاجرت، داده ها با سرعت بسیار زیاد در پایگاه داده‌های محتوا جای خواهند گرفت. بی‌تردید، اثر شمارۀ یک مهاجرت بر فارم شیرپوینت لاگ فایل‌های پایگاه داده های محتواست. اکثر به کاراندازی‌های شیرپوینت برای نرخ بار بالای مهاجرت طراحی نمی‌شوند. بدون برنامه‌ریزی درست، لاگ فایل‌ها طی مهاجرت پر خواهند شد. این می‌تواند موجب عملکرد نامنظم مهاجرت یا بروز خطا گردد و بر کاربران نهایی نیز تأثیرگذار خواهد بود.

منابع SQL Server
شیرپوینت از SQL Server برای انبارش و مدیریت داده‌های سند استفاده می‌کند. طی مهاجرت، پایگاه داده‌های محتوا به شدت مختل می‌شود. همچنین، راهبرد مهاجرت کامل باید پیگیری همۀ عملیات اجرا شده بین سیستم‌های منبع و مقصد را مستند کند. این امر می‌تواند به اثر عملکردی سنگین روی سرور پایگاه داده های مهاجرت منتهی گردد. برای مهاجرت‌های بزرگ‌تر، ممکن است این مورد برای اختصاص یک SQL Server به هماهنگی پایگاه داده های مهاجرتی که نرم افزار مهاجرت استفاده می‌کند ضروری باشد. همیشه این امکان وجود دارد که مهاجرت کند شود اما در اکثر موارد، وقت طلاست و هرچه مهاجرت طولانی‌تر اجرا گردد هزینۀ آن بالاتر خواهد بود.

بیشتر...

 

مهاجرت از سیستم های سنتی به شیرپوینت - راهبردهای مهاجرت

معماری شیرپوینت مهم‌ترین نکته ای است که برای برنامه ریزی و تحلیل باید در نظر بگیرید. لازم است نحوۀ تطبیق سازمان ِ سیستم سنتی فعلی را با توپولوژی شیرپوینت بررسی کنید. برخی مشاوران شما را به مهاجرت همه چیز یا هیچ چیز – و انجام آن‌ها همین حالا – تشویق خواهند کرد. در برابر این راهبرد مقاومت کنید. گزینه های دیگری وجود دارند که برای سازمان شما عملی‌تر خواهند بود.

بخش به بخش
هر بار یک بخش را انجام دهید و از ساده‌ترین بخش شروع کنید.

Day Forward شیرپوینت با مهاجرت مرحله ای
شیرپوینت به طور Day forward استفاده خواهد شد و بعدا دربارۀ نحوۀ مهاجرت اسناد سیستم سنتی تصمیم گیری خواهد شد.

همراهی با سیستم سنتی
این مورد مرسوم نیست اما می‌تواند انجام شود چراکه شاید سازمان‌ها تصمیم به استفاده از شیرپوینت همراه با سیستم سنتی در یک رویکرد مرحله ای بگیرند.

چالش‌های مهاجرت
چالش‌های زیر نه فقط در شیرپوینت که در هر مهاجرتی واقعاً وجود دارند. این چالش‌ها حتی می‌توانند در به روز رسانی پلتفرم نرم افزار سنتی فعلی نیز وجود داشته باشند.

مجموعۀ ویژگی‌های اصلی یک سیستم جدید با سیستم سنتی شما به طور یک به یک همتراز نیست.
چگونه این شکاف‌ها را پر خواهید کرد؟

نیاز به جایگزینی سفارشی‌سازی‌های فعلی همچون یکپارچه‌سازی با نرم افزارهای دیگر ، جریان‌های کاری، فرم‌ها.
این موارد در پلتفرمی جدید چگونه مدیریت خواهند شد؟

ملزومات جانبی برای ویژگی‌هایی که شاید در پلتفرم اصلی سیستم جدید موجود نیستند را تعیین کنید.
مثلاً: پیمایش، جستجو و نماسازی، مدیریت سوابق، پشتیبان گرفتن/ بهبود، کاربردهای دپارتمانی (حساب‌های قابل پرداخت، منابع انسانی) و راهبردهای عمودی (حقوقی، بهداشت و درمان).


 

مهاجرت از سیستم های سنتی به شیرپوینت - برنامه ریزی

​لازم نیست مهاجرت‌های شیرپوینت طولانی و پیچیده باشند. برای مثال، در یک پروژه مهاجرت‌ از یک سیستم سنتی با سه میلیون تصویر از جمله سخت افزار اختصاصی OSAR در سه هفته تکمیل شده است. کلید مهاجرت موفقیت آمیز به شیرپوینت : برنامه ریزی و تحلیل. از آنجایی که حتی دو مهاجرت به هم شباهت ندارند، مسیری که انتخاب می‌کنید اهمیتی ندارد بلکه پرداختن به پرسش‌های برنامه ریزی کلیدی زیر حیاتی است.
پرسش‌های برنامه ریزی کلیدی

  • حجم اسنادی که قرار است مهاجرت داده شوند چه میزان است؟
  • چه سیاست‌های حفاظتی را در محل اجرا می‌کنید؟
  • چه نوع اسنادی در سیستم فعلی شما ذخیره می‌شوند؟
  • این اسناد در کجا ذخیره می‌شوند؟
  • اسناد در حال حاضر چگونه به سیستم شما اضافه می‌شوند؟ تعیین این روش می‌تواند به شناسایی انواع فایل و دیگر ملزومات مورد نیاز برای  سیستم جدید کمک کند. برای مثال، شاید علاوه بر اسکن به پشتیبانی از فاکس یا ابزار چند کاره نیاز داشته باشید.
  • آیا سیستم فعلی از فولدرسازی استفاده می‌کند؟
  • چگونه اسناد را جستجو می‌کنید؟
  • امنیت را چگونه کنترل می‌کنید؟
  • آیا نسخه های متعدد از یک سند وجود دارد؟ آیا هنگام مهاجرت برای انتقال همۀ نسخه ها برنامه‌ریزی می‌کنید؟
  • آیا از حاشیه نویسی استفاده می‌کنید؟ حاشیه نویسی‌ها چگونه به اسناد اعمال می‌شوند؟ آیا به طور جداگانه جاسازی یا ذخیره می‌شوند؟
  • آیا از سندهای مرکب استفاده می‌کنید؟ برای مثال، ممکن است یک سند ورد (Word) داشته باشید که داخل آن، لینکی به یک سند اکسل (Excel) وجود داشته باشد.
  • آیا از جای‌گذاشت (overlay) استفاده می‌کنید؟
  • آیا از فرآیندهای جریان کاری (Workflow) مرتبط با اسناد برخوردارید؟

 

مهاجرت از سیستم های سنتی به شیرپوینت - چرا؟

​گذشته از این حقیقت که شیرپوینت در دهۀ گذشته ثابت کرده است که برای انواع گستردۀ نیازهای سازمانی از انعطاف لازم برخوردار است ، هنوز دلایل متعدد مهم دیگری وجود دارند که شرکت‌های بزرگ باید شیرپوینت را برای پلتفرم ECM خود در نظر بگیرند. شیرپوینت پلتفرمی استاندارد را با هزینه ای منطقی برای اکثر کسب‌وکارها فراهم می‌کند. شیرپوینت یک پلتفرم مدیریت محتوای شرکتی با هزینۀ کل پایین‌تر مالکیت از سایر سیستم‌های سنتی است. بسیاری از شرکت‌ها در فناوری های مایکروسافت سرمایه گذاری کرده‌اند و این موجب می‌شود که شیرپوینت حتی پلتفرمی مطلوب‌تر بشود. به علاوه، نرخ برگشت سرمایۀ اکثر سازمان‌ها هنگام حرکت از یک سیستم سنتی به شیرپوینت کاملا قانع‌کننده است.
اگر در حال حاضر از یک سیستم سنتی مدیریت محتوای سازمانی استفاده می‌کنید، دلایل بسیاری برای بررسی مهاجرت وجود دارد.
 
هزینه‌های سالانۀ حفظ و نگهداری سیستم‌های سنتی – بسیاری از کارخواهان مهاجرت سیستم سنتی خود را صرفاً بر اساس هزینه های حفظ و نگهداری میراث توجیه می‌کنند. آن‌ها می‌توانند مخارج را به اندازه ای کاهش دهند که تنها بر اساس همین عامل، هزینۀ مهاجرت را توجیه کنند.
 
هزینه های پشتیبانی داخلی – اگر در حال حاضر از شیرپوینت در سازمان خود استفاده می‌کنید، مجبور نیستید اشخاص برخوردار از این مهارت را استخدام کنید یا به افراد آموزش دهید.
 
پشتیبانی از پلتفرم‌های چندگانه و سخت افزار گران‌قیمت – سازمان‌ها غالباً با سیستم‌های سنتی متعددی سروکار دارند که طی سال‌ها به آن‌ها دست یافته‌اند. ممکن است این سیستم‌ها سخت‌افزاری سنتی‌تر و اختصاصی مرتبط با خودشان داشته باشند.
 
کد قابل شخصی‌سازی (custom Code) مرتبط با سیستم سنتی – پشتیبانی از کد قابل شخصی‌سازی می‌تواند هزینه‌بر باشد.
 
اهرم‌بندی فناوری فعلی – باز هم، اکثر سازمان‌ها از شیرپوینت برخوردارند و از برخی از ظرفیت‌های آن استفاده می‌کنند.
 
پیش‌بینی‌پذیری و پشتیبانی – برخلاف بسیاری از سیستم‌های سنتی که به دلیل از دور خارج شدن پلتفرم، مشتریان را وادار به به‌روزرسانی می‌کنند، شیرپوینت قابل پیش‌بینی و برخوردار از پشتیبانی کامل است.

 

آخرین نظرات

Comment RSS