فرم ساز و گزارش ساز، در شیرپوینت، راه حل یا درد سر؟

شیرپوینت سرویس InfoPath Form Services را جهت تولید و انتشار فرم های سازمانی در قالب سرویسهای پایه WSS ارایه کرده است. مایکروسافت این سرویس را با لیسانس جداگانه ارایه داده که البته مجموعه سرویسهای هوش تجاری  BIو مدیریت فرآیندهای سازمانی یا BPM  نیز از این قاعده مستثنی نمی باشند.

اساس کارکرد این فرم ها ، ارایه یک ساختار مبتنی بر XML (با فرمتxsn) توسط سرویس InfoPath بگونه ای است که جهت تکمیل و خیره اطلاعات فرم نیازی به ملزومات خاصی به جز مرورگر وب نباشد. البته دراین بین ویژگی های خاصی از این فرم ها نیز وجود دارند که سازگار با امکانات مرورگرها نمی باشند. بعنوان چند نمونه از این ویژگی های می توان به کنترلهای Master/Detail ،کنترل های پیشرفته ، نقش های کاربر، کنترل املایی  و کدهای نوشته شده با زبانهای اسکریپت نویسی همچون VBScript و Jscript در قالب طراحی فرم ها اشاره کرد. فرمهای InfoPath امکان مستندسازی را به خوبی ارایه کرده و همچنین برای ایجاد پروتوتایپ  با حداقل کدنویسی مناسب است. با این وجود استقرار این فرم ها پیچیده تر از فرم های وب ASP.Net  می باشد. چنانچه فرم ها نیاز به پشتیبانی از روالهای منطقی و پردازشی خاصی داشته باشند، بهتر است فرم های وب طراحی شده در ASP.Net جایگزین این راهکار شوند.
درصورت استفاده از مرورگر، روال های تصدیق هویت سفارشی همچون FBA ، که از پوشش  AD بهره برداری نمی – کنند کاملا پیچیده است. در واقع مشکل در مدل اجرایی سرویس InfoPath می باشد. سه تایر   اجرایی شامل مرورگر(تایر 1) اطلاعات را به تایر 2 یعنی سرویس Info Path ارسال کرده و نهایتا داده ها به تایر شماره 3 یعنی سرویس دهنده SQL انتقال داده می شود . در این اطلاعات تصدیق هویت تبادل شده بین رده های 1 و2 از نگاه سرویس دهنده بانک اطلاعاتی غیرشفاف و غیر قابل دسترسی است.
علاوه بر این :

• استفاده از تکنیک های Ajax و منابع Flash  در فرم ها و  کنترل دقیق بر ارسال اطلاعات به سرور در جریان Post Back ها
• خطایابی فرم ها
• امکانات کنترل ظاهر نمایشی فرم و وضعیت کنترل (فعال / غیرفعال کردن)
• اعتبارسنجی اطلاعات دریافتی از سایر منابع داده با توجه به محدودیت های InfoPath
• پشتیبانی از سایر زبانها با استفاده از قابلیت های محلی سازی منابع

همراه با مشکلاتی برای توسعه دهندگان خواهد بود. ضمن اینکه مدل رویدادها فرم های InfoPath برمبنای ساختار XML بوده و ارتباط با رابط کاربردی ندارد. البته باید درنظر داشت ساختار اطلاعاتی مبتنی بر XML  این فرم ها مزایای نیز بهمراه دارد همچون امکان تبادل مستندات در چند لایه پردازشی مختلف بر بستر سرویسهای همچون Microsoft BizTalk Service.
سرعت و کارایی مشکل دیگری بر سر راه سرویس InfoPath می باشد. به هر حال در صورتیکه محدودیت های مطرح شده، پارامترهایی کلیدی قلمداد شوند و پیاده سازی روال های سفارشی در مقیاس بالا مورد نظر توسعه دهندگان باشد، پیشنهاد می شود که این امر با استفاده از فرمهای وب ASP.Net در ویژوال استودیو صورت گیرد.

گردش کار سازمانی
مایکروسافت، از ویرایش 3 فریم ورک دات نت اقدام به ارایه  WWF بعنوان زیربنای گردش کار فرآیندی و پردازشی کرد. این زیرساخت کمک می کند تا توسعه دهنده قادر باشد فرآیندهای بزرگ را به فعالیت های کوچکتری تبدیل کرده و نهایتا این فعالیت ها از طریق موتور گردش کار با یکدیگر در ارتباط خواهند بود. درضمن WWF مدعی است که امکان موازی سازی فعالیت ها و فرآیند را بصورت توزیع شده حتی در چند سکوی مختلف سخت افزاری در اختیار توسعه دهندگان قرار می دهد. در واقع می توان هدف این زیرساخت را توسعه برنامه های بزرگی توصیف کرد که قابلیت ریز شدن در قطعات کوچکتر را داشته باشند.
درعین حال که WWF امکانات کافی را در زمینه توسعه برنامه های کاربردی و کنترل فرآیندهای مبتنی بر پردازش در اختیار توسعه دهندگان قرار می دهد، اما برای توسعه گردش اسناد سازمانی   بیش از حد پرهزینه و پیچیده است. در واقع با بررسی و تحلیل روالهای اداری اغلب سازمانها، می توان متوجه شد که فرمهای الکترونیکی ، محتوا و سایر اشکال اسناد و اطلاعات بر اساس ساختار چارت سازمانی اساس گردش کار را تشکیل می دهند. در بخش سیستم های مدیریت درخواست ها  ، فرم های الکترونیکی در قالب اسناد اطلاعاتی در طی یک روال متناهی از گردش سند، بین پست های سازمانی مختلف جهت بررسی، تائید، اقدام و سایر فعالیت های بازنگری و تائید  به گردش درآمده و کلیه این فرآیند را بایستی مدل سازی گردش کار انسان محور  تعریف کرد. اما با وجود سادگی مدل ارتباطی نمی توان از کاربران سازمانی توقع داشت که جهت پیاده سازی این چنین روالهایی از ابزارهایی همچون Visual Studio و XAML استفاده نمایند. هرچند در شیرپوینت 2010 امکان مدل سازی گرافیکی فرآیند از طریق ابزار طراح گردش کار فراهم شده و طبق ادعای مایکروسافت می توان گردش کارهایی بدون کدنویسی در اختیار داشت.
مایکروسافت WWF را جهت مدل سازی فرآیندها، الگوریتم های اجرایی پیچیده و توزیع شده و موازی سازی  پردازش های منطقی بزرگ ارایه کرده است. در واقع WWF ابزاری برای توسعه دهندگان است، تا قادر باشند تفکیک درستی از پردازشهای لایه منطق کسب و کار و لایه های تعاملی کاربر ایجاد نمایند. پیش از برنامه ریزی جهت استفاده از WWF در پیاده سازی یک فرآیند ابتدا بایستی درک صحیحی از نیازمندهای اجرایی و روالهای منطقی کار تصور کرد. در واقع هر فعالیتی همراه با تکرار و یا شرط، می تواند بر مبنای منطق گردش کار مورد پیاده سازی قرار گیرد اما در برنامه های کاربردی همچون سیستم مدیریت پشتیبانی   فقدان روالهای پیچیده پردازشی قابل توزیع و یا رویکرد مدیریت کسب و کار، توسعه دهندگان را به سمت راهکارهای ساده تر به جای WWF سوق می دهند. واقعیت این است که WWF  برای کاربران نهایی و حتی تحلیلگران فرآیندهای کسب و کار   توسعه و تطبیق داده نشده است. لذا فاقد ابزارهای مدیریتی، گزارش گیری یا مانیتورینگ می باشد. حتی متخصصات فناوری اطلاعات سازمان نیز نمی توانند با دید پیاده سازی روالهای سازمانی مبتنی بر فرم های جمع آوری اطلاعات ، WWF را ابزار مناسبی قلمداد کنند.
چنانچه هدف مدل سازی و پیاده سازی پردازشهای تجاری سازمان و یا مدیریت فرآیندهایی که دایما با توجه به نیاز مشتریان از جهت ساختار و ترتیب فعالیت ها تغییر می کنند، WWF می تواند کارآمد باشد. ضمن اینکه با توجه به پشتیبانی تراکنشها از مدل ACID، می توان قابلیت پیگیری وضعیت پردازشها را بصورت قطعی در اختیار داشت. همه این موارد توسعه دهندگان را به سمت این ابزار سوق می دهد، اما عملا تراکنش های صورت گرفته در پورتال سازمانی از ماهیت متفاوتی برخوردارند. رویکرد این فرآیندها فردگرا و اطلاع گراست و نه پردازش گرا، هرچند به سختی می توان در چرخه اطلاعاتی سازمان روالهای پردازشی را نادیده گرفت، اما طبعا هسته پردازش های سازمان را می توان در بعد دیگری از ماجرا دید.
ذکر این نکته اهمیت دارد که مکانیزم خودکار تولید کد در ابزارهای طراح گردش کار نیز در اغلب موارد کدهای قابل بازبینی، نگهداری و تغییر ارایه نمی دهند و توسعه دهندگان بایستی جهت کنترل روالهای منطقی پیچیده، این روال ها را جداگانه پیاده سازی نموده و با پیکربندی گردش کار کنترل اجرا را به این روال ها محول نموده و حتی الامکان از کدهای تولید شده استفاده ننمایند.
در پاسخ به این سوال که آیا WWF یا هر راهکار مشابه دیگری برای توسعه فرآیند جاری سازمان مناسب است یا نه ، این سوال مطرح می شود که آیا سازمان در صدد تولید نرم افزار است یا تهیه و خرید آن از یک ارایه دهنده؟ در واقع با توجه به اینکه معماری WWF جهت توسعه دهندگان بهینه سازی شده و حتی در سازمانهای بزرگ نیز جهت پیاده سازی منطق های کسب و کار معمولا از نرم افزارهای سفارشی سازی شده و خارج از بستر پورتال بهره برداری می شود، آیا مقرون به صرفه و اصولی است که جهت توسعه تراکنش های غیرکلیدی ولی مهم، یک معماری کاملا پیچیده و پرهزینه مورد استفاده قرار گیرد. بعنوان نمونه سازمانی همچون بانک اغلب فرآیندهای کسب و کار خود را بر بستر نرم افزارهای اختصاصی توسعه داده است که البته می تواند با بهره گیری از معماری WWF صورت گرفته باشد. اما آیا معقول است برای پیاده سازی گردش کار یک فرم درخواست، کارشناسان فناوری اطلاعات سازمان درگیر مفاهیم پیچیده WWF، شیرپوینت و کد نویسی با زبانهای C# و XAML شوند؟

نویسنده: مهندس آرش رامز