سیستم مدیریت فرایندهای نوسا در راستای توسعه امکان ارتباط و تعامل با سیستمهای نرم افزاری دیگر، از تکنولوژی API استفاده می کند. در همین رابطه و برای ارائه خدمات به سیستمهای دیگر، وب سرویس REST برای دریافت پیام (message)پیاده سازی شده است. بنابراین هر سیستمی که کلاینت REST را پشتیبانی می کند می تواند از طریق این کلاینت، پیامهای مورد نظر خود را به وب سرویس REST سیستم مقصد ارسال کند و با گردش کارهای آن سیستم به تعامل بپردازد.
انواع کاربران وب سرویس REST
در نگاه اول شاید این تصور در ذهن ایجاد شود که این قابلیت صرفا برای امکان تعامل نرم افزارهای دیگر با سیستم مدیریت فرایندها طراحی شده است اما واقعیت این است که وب سرویس REST علاوه بر امکان ارائه خدمات به نرم افزارهای دیگر (غیر از سیستم مدیریت فرایندها)، امکان ارتباط دو طرفه میان چند سیستم مدیریت فرایند را نیز فراهم می کند. در ادامه ابتدا به ارتباط متقابل چند سیستم مدیریت فرایندها از طریق وب سرویس می پردازیم و سپس نحوه تعامل نرم افزارهای دیگر با این وب سرویس را بررسی می کنیم.
ارتباط متقابل میان چند سیستم مدیریت فرایندها
همانطور که می دانید API REST سیستم مدیریت فرایندهای نوسا شامل کلاینت و سرور REST است ولذا مشتریان میزبان این سیستم می توانند از طریق این تکنولوژی به تعامل با یکدیگر بپردازند. به این ترتیب مفهومی بنام شبکه مدیریت فرایندها قابل تصور می شود. از این طریق، کسب و کارهای بزرگ (Enterprise) می توانند بخشها و شعبه های متعدد خود را به شکل یک شبکه یکپارچه طراحی کنند و تعاملهای مورد نیاز کسب و کار خود را در این شبکه ها انجام دهند. برای مثال فرض کنید یک شرکت تولیدی دارای چند گردش کار فروش در شعب متعدد خود می باشد. حال این شرکت در زمان تغییر قیمتها ، می خواهد بروزرسانی قیمت در تمام شعبه ها را به شکل یکسان انجام دهد.
در این مثال فرض شده است که شعبه ها در مواقع لازم قیمت را از بخش فروش مرکزی استعلام می کنند و سپس قیمت جدید از طرف فروش مرکزی به این شعبه ها اعلام می شود. اما شکل دیگری هم می توان تصور کرد به این صورت که سیستم فروش مرکزی در زمان تغییر قیمت، بطور خودکار پیام تغییر قیمت را به سیستمهای شعبه ها ارسال و قیمتها را بروزرسانی کند.
مزایای REST API در سیستم مدیریت فرایندها
تا قبل از پیاده سازی REST API در سیستم مدیریت فرایندها، تنها راه تعامل با سرورهای دیگر از طریق کلاینت (وب یا ویندوز) سیستم مدیریت فرایندها بود. فارغ از پیچیدگیهای کار با کلاینت و مدیریت کاربران و دسترسی ها به گردش کارها، نکته بسیار مهم در این روش این بود که در هر لحظه کاربر می توانست به یک سرور متصل شده و به پایگاههای این سرور دسترسی داشته باشد. به بیان دیگر، امکان تعامل با سرورهای دیگر از درون کلاینت (چه به شکل دستی از طریق محاوره و چه از درون برنامه) وجود نداشت. حال با استفاده از REST API مشتریان سیستم مدیریت فرایندها می توانند بدون نیاز به اتصال از طریق کلاینت (ویندوز یا وب) درخواستهای خود را به شکل پیام به سرورهای دیگر متعلق به خود یا مشتریان دیگر ارسال کنند. به این ترتیب برای مشتریان سیستم مدیریت فرایند، دو مزیت عمده زیر را در استفاده از روش REST API می توان بیان کرد:
- عدم نیاز به اتصال از طریق کلاینت* و بالا رفتن کارایی سیستم
- امکان اتصال و تعامل همزمان با سرورهای دیگر از طریق برنامه گردش کار
تا اینجا با ویژگیها و کارکردهای REST API برای مشتریان سیستم مدیریت فرایند آشنا شدیم. در ادامه مطلب، به کارکردها و الزامات این روش برای مشتریان نرم افزارهای دیگر می پردازیم.
*: دقت کنید که در اینجا منظور اتصال های کسب و کارها به یکدیگر (B2B) است. یعنی این اگر یک یک کسب و کار خاص از یک کسب و کار دیگر خدمات دریافت می کند آنگاه از طریق REST API دیگر نیازی به اتصال از طریق کلاینت برای دریافت خدمات ندارد. بنابراین در اینجا منظور مشتری یا کاربر نهایی نیست ولذا تعامل مشتریان با سیستمهای مدیریت فرایند (C2B) اساسا از طریق کلاینت انجام می شود.
کاربران نرم افزارهای دیگر
بسیاری از مراکز و مشتریان سیستم مدیریت فرایندهای نوسا دارای نرم افزارهای تولید شرکتهای غیر از نوسا هستند و بنا به هر دلیل تمایلی به تعویض این سیستمها ندارند. از طرف دیگر این مراکز برای ایجاد یکپارچگی و هماهنگی بیشتر در روالهای سازمانی، نیاز به تعامل و ارتباط میان سیستمهای نرم افزاری خود و سیستم مدیریت فرایندها دارند. در این زمینه به چند مثال توجه کنید:
مثال 1: درخواست خرید یک کالا
فرض کنید یک مرکز از سیستم مدیریت فرایندهای نوسا برای امور تامین و تدارکات خود استفاده می کند اما مدیریت موجودی کالاهای خود را توسط یک سیستم انبار دیگری انجام می دهد. حال این مرکز می خواهد زمانی که موجودی یک کالا از یک مقدار خاص کمتر می شود بتواند یک درخواست به گردش کار تامین و تدارکات ارسال کند و در نتیجه آن یک کار خرید برای آن کالا بصورت خودکار ایجاد شود.
مثال 2: درخواست پشتیبانی برای یک مشتری
فرض کنید سیستم فروش یک شرکت توسط یک سیستم و امور پشتیبانی مشتریان توسط سیستم مدیریت فرایندهای نوسا انجام می شود. طبیعی است که این شرکت مایل است به محض قطعی شدن فروش، یک درخواست به گردش کار پشتیبانی ارسال کند و به این ترتیب، یک کار پشتیبانی برای آن مشتری خاص ایجاد شود.
نحوه اتصال نرم افزارهای دیگر به وب سرویس REST
نرم افزارهای دیگر برای ارسال درخواست به وب سرویس REST باید امکان استفاده از یک کلاینت REST را داشته باشند، در ادامه مطلب، با ساختار این کلاینت و نحوه ایجاد و ارسال درخواستها از طریق آن آشنا می شویم.
پیاده سازی کلاینت REST در محیط javascript
یک درخواست حاوی پیام (message) در واقع یک HTTP Request از نوع POST است. برای این کار باید با استفاده از امکانات کلاس XMLHTTPRequest در محیط برنامه نویسی javascript یک کلاینت REST برای ارسال درخواستها بنویسیم. توضیح این که توابع و ابزارهای این کلاینت در شرکت نوسا نوشته شده و در یک فایل با نام RepositoryXPRESTClt.js ارائه می گردد.
تابع ارسال درخواست در کلاینت REST
در کلاینت REST، ارسال درخواست از طریق تابع SendRestRequest انجام می شود که الگوی کلی آن به شکل زیر است:
function SendRestRequest (baseUrl, userName, password, dbName, workKey, messageKeyStr, note, checkPendings, numberParam, stringParam, async, callback)
همانطور که ملاحظه می کنید این تابع شامل پارامترهای زیر است:
- baseUrl: آدرس سرور REST در مقصد. مثال:
- userName : نام کاربر معتبر در گردش کار مقصد
- password: کلمه عبور کاربر معتبر در گردش کار مقصد
- parameters: یک آرایه (Array)از اطلاعات پیام (message) ارسالی که شامل موارد زیر است:
- dbName: نام پایگاه گیرنده پیام که الگوی MyDB _ReposXP_ دارد. یعنی پیشوند _ReposXP_ میان نام تمام پایگاهها مشترک است و MyDB عبارت دلخواهی است که برای هر پایگاه به شکل خاص تعیین می شود.
- workKey:کلید کار گیرنده پیام. اگر گیرنده پیام مشخص است باید کلید کار گیرنده پیام را در این پارامتر مقداردهی می کنیم در غیر این صورت اگر گیرنده مشخص نیست باید مقدار صفر را به این پارامتر بدهید. در این حالت پیام به شکل رخداد (event) ارسال خواهد شد.
- :messageKeyStr کلید حرفی پیام
- note: یادداشت پیام
- checkPendings : انجام/عدم انجام امور معوقه موتور گردش کار. این پارامتر نیز از نوع منطقی است و مقدار true به معنی این است که CheckPendings انجام شود.
- numberParam: پارامتر عددی پیام. اگر پارامتر عددی تعیین نشده است باید مقدار این پارامتر را برابر صفر قرار دهید.
- stringParam: پارامتر حرفی پیام
- async: وضعیت آسنکرون (ناهمزمانی). یک داده از نوع منطقی است که مقدار آن باید همواره true به معنی آسنکرون بودن ارتباط باشد.
- callback: تابعی که پاسخ و خطاهای احتمالی را برمی گرداند. این تابع به شکل پیش ساخته نوشته شده است و مطابق با یک الگوی تعیین شده، کد و متن پاسخ و خطاها را برمی گرداند.
تعیین Header درخواست
در استاندارد REST ، نوع محتوا (Content-Type)ی درخواست نیز باید به شکل header به درخواست اضافه شود. این کار در تابع SendRestRequest انجام شده است. برای آشنایی با این مورد، به متن اسکریپت این تابع مراجعه کنید.
نحوه پاس کردن داده ها به تابع SendRestRequest
در ابتدای این مستند گفته شد که قرار است نرم افزارهای دیگر از طریق کلاینت REST درخواستهای حاوی پیام را به وب سرور REST سیستم مدیریت فرایندهای نوسا ارسال کنند. به این ترتیب تنها نرم افزارهایی می توانند با وب سرور REST نوسا تعامل داشته باشند که امکان ارتباط با کلاینت REST و پاس کردن داده های مورد نیاز به تابع SendRestRequest را داشته باشند. برای درک بهتر پاس کردن داده ها به یک مثال توجه کنید:
مثال : ارسال پیام برای شروع یک کار پشتیبانی
فرض کنید در یک مرکز، نرم افزار فروش می خواهد درخواست ایجاد یک کار جدید پشتیبانی را به به سیستم مدیریت فرایندها ارسال کند. در این نرم افزار، داده های مربوط به درخواست ارسال پیام (message) در فیلدهایی با نامهای زیر ذخیره می شود:
url: آدرس سرور REST
userName: نام کاربری
password: کلمه عبور
dbName : نام پایگاه
wKey: کلید کار
msgKey: کلید حرفی پیام
msgNote: یادداشت پیام
chkPending: وضعیت انجام امور معوقه
numParam: پارامتر عددی پیام
strParam: پارامتر حرفی پیام
بنابراین تابع ارسال پیام چیزی شبیه به تابع زیر خواهد بود:
function SendMessaage() {
SendRestRequest (url, userName, password, dbName, wKey, msgKey, msgNote, true, numParam, strParam, async, callback)
function (ARes) {
let status=’Err_No: ‘+ ARes._ErrNo;
if (ARes._ErrStr)
status += ‘\nErrStar: ‘ + ARes._ErrStr;
return status;
}
}
از میان پارامترهای تابع SenSoapRequest ، شاید تنها پارامتر آخر یا تابع callback برای مخاطب ایجاد ابهام کند. همانطور که قبلا هم توضیح داده شد، این تابع پاسخ و خطاهای احتمالی درخواست را طبق یک الگوی معین نمایش می دهد. هر پاسخ (ARes)به شکل یک موجود ودارای دو مشخصه بنامهای کد خطا (ErrNo) و شرح خطا (ErrStr) است که کدخطا در سطر اول و شرح خطا در سطر بعد نمایش داده می شود.
مقداردهی پارامترها
حال اگر پارامترها مقداردهی شوند آنگاه می توانیم درخواست را ارسال کنیم. مقداردهی پارامترها در هر نرم افزار ممکن است به شیوه های مختلف انجام شود. برای مثال در یک نرم افزار ممکن است این مقادیر توسط کاربر و به شکل دستی وارد شود و در نرم افزار دیگر، ممکن است این پارامترها به شکل خودکار و توسط کد نویسی انجام شود. برای نمونه در مثال بالا، ممکن است پارامترها به شکل مقادیر ثابت در نرم افزار فروش ذخیره شده باشد یا این که در یک مرحله، از کاربر بخواهد مقادیر لازم برای پارامترها را در یک فرم وارد کند. یک نمونه از این روش ارسال دستی استفاده از رابط کاربری HTTP است.
توضیح مهم: تمرکز این مطلب روی پیاده سازی کلاینت REST برای نرم افزارهای دیگر (غیر از سیستم مدیریت فرایندهای نوسا) است. در مورد کلاینت REST موجود در سیستم مدیریت فرایندها، تفاوتهای جزئی وجود دارد که برای توضیحات بیشتر می توانید به ضمیمه مستند زیر مراجعه کنید:
تعامل سیستم مدیریت فرایندها با RESTFul API : کلاینت REST
رابط کاربری HTTP Client
برای تست کلاینت REST بهترین راه این است که یک رابط کاربری HTTP به شکل محاوره داشته باشیم که بتوانیم داده های درخواست را به شکل دستی تعیین و ارسال کنیم. برای مثال به محاوره زیر توجه کنید:
حال می توانیم داده ها و پارامترهای مورد نظر خود را در این فرم وارد کنیم و با کلیک روی تکمه اجرا، درخواست خود را به وب سرور REST ارسال کنیم و سپس پاسخ را در فیلد نتیجه اجرا مشاهده کنیم. ضمنا فایل source این کلاینت نیز با نام RepositoryXPRESTClt.html در دسترس می باشد. از آنجایی که در این کلاینت، یک نمونه عملی از نحوه تولید و ارسال یک درخواست پیاده سازی شده است لذا این فایل source می تواند در زمینه درک ساختار درخواست و نحوه نوشتن اسکریپت برای درخواست، الهام بخش باشد.
پاسخها و خطاهای احتمالی
پس از ارسال درخواست به وب سرور، با دو دسته از پاسخها روبرو می شویم:
- پاسخهای تا زمان رسیدن درخواست به وب سرور (HTTP Responses)
این پاسخها میزان موفقیت درخواست HTTP Request را تا زمان تحویل به مقصد (وب سرور) نشان می دهد و مستقل از اتفاقی است که بر اثر این درخواست در مقصد رخ می دهد. کدهای وضعیت استاندارد HTTP برای وضعیت پاسخ در پنج دسته زیر طبقه بندی می شود:
- Informational responses (
100 – 199)
- Successful responses (
200 – 299)
- Redirection messages (
300 – 399)
- Client error responses (
400 – 499)
- Server error responses (
500 – 599)
این دسته از پاسخها به صورت یک متن xml نمایش داده می شود که شامل دو مشخصه کد وضعیت (ErrNo) و شرح وضعیت (ErrStr) می باشد. برای مثال اگر آدرس url وب سرور اشتباه باشد با خطای زیر روبرو خواهیم شد:
<_RSLT ErrNo="404" ErrStr="Not Found"/>
نکته مهم: دقت کنید که در صورت موفقیت آمیز بودن ارسال درخواست، هیچ پاسخی نمایش داده نخواهد شد.
- پاسخهای وب سرور مدیریت فرایند
پس از این که درخواست به سیستم مدیریت فرایند می رسد آنگاه در این سیستم پردازش می شود و بسته به ساختار و محتوای درخواست و نتیجه پردازش در گردش کارها، یک پاسخ شامل کد وضعیت و شرح وضعیت به کلاینت برمی گردد. به عبارت دیگر این پاسخ میزان موفقیت آمیز بودن درخواست در سیستم مدیریت فرایندها را بیان می کند.
ساختار پاسخهای وب سرور مدیریت فرایند
پاسخهای وب سرور به درخواستها بصورت گزارش خطا می باشد واز دو قسمت تشکیل می شود: کد خطا (ErrNo) و شرح خطا (ErrStr) . برای نمونه به مثالهای زیر توجه کنید:
- اگر درخواست کاملا موفقیت آمیز باشد کد خطا صفر خواهد بود
- اگر نام پایگاه اشتباه باشد کد خطا 1003 و شرح آن به شکل زیر خواهد بود:
ErrNo:1003
ErrStr: اتصال به پايگاه با خطا مواجه شد. احتمالا نام پايگاه نادرست است. پيغام خطا: Property value is invalid. Make sure the value is typed correctly
- اگر کلید کار گیرنده پیام اشتباه باشد. کد خطا 1 خواهد بود:
ErrNo: 1
ErrStr: "تراکنش گردش کار" يافت نشد. احتمالا توسط كاربر ديگري حذف شده است
و به همین ترتیب پاسخهای دیگری که در روند پردازش پیام در سیستم مدیریت فرایندها اتفاق می افتد که به دلیل تعدد خطاها به همین مثالها اکتفا می کنیم.