بسیاری از مراکز و مشتریان سیستم مدیریت فرایندهای نوسا دارای نرم افزارهای تولید شرکتهای غیر از نوسا هستند و بنا به هر دلیل تمایلی به تعویض این سیستمها ندارند. از طرف دیگر این مراکز برای ایجاد یکپارچگی و هماهنگی بیشتر در روالهای سازمانی، نیاز به تعامل و ارتباط میان سیستمهای نرم افزاری خود و سیستم مدیریت فرایندها دارند. در این زمینه به چند مثال توجه کنید:
مثال 1: درخواست خرید یک کالا
فرض کنید یک مرکز از سیستم مدیریت فرایندهای نوسا برای امور تامین و تدارکات خود استفاده می کند اما مدیریت موجودی کالاهای خود را توسط یک سیستم انبار دیگری انجام می دهد. حال این مرکز می خواهد زمانی که موجودی یک کالا از یک مقدار خاص کمتر می شود بتواند یک درخواست به گردش کار تامین و تدارکات ارسال کند و در نتیجه آن یک کار خرید برای آن کالا بصورت خودکار ایجاد شود.
مثال 2: درخواست پشتیبانی برای یک مشتری
فرض کنید سیستم فروش یک شرکت توسط یک سیستم و امور پشتیبانی مشتریان توسط سیستم مدیریت فرایندهای نوسا انجام می شود. طبیعی است که این شرکت مایل است به محض قطعی شدن فروش، یک درخواست به گردش کار پشتیبانی ارسال کند و به این ترتیب، یک کار پشتیبانی برای آن مشتری خاص ایجاد شود.
یکی از راه حلهای معمول در حال حاضر برای تعامل سیستمهای مختلف نرم افزاری ارائه API های تحت وب یا همان وب سرویسها می باشد. در ادامه مطلب با راه حل نوسا که بر پایه همین تکنولوژی است آشنا می شویم:
راه حل نوسا برای تعامل سیستمهای دیگر با سیستم مدیریت فرایندها نوسا
شرکت نوسا برای پاسخ به این نیاز، وب سرویسی را تحت استاندارد SOAP راه اندازی کرده است که از این طریق، سیستمهای نرم افزاری دیگر می توانند درخواستهای خود را به شکل پیام (message) به سیستم مدیریت فرایندهای نوسا ارسال کنند.
حال ممکن است این سوال در ذهن شما ایجاد شود که آیا برای انواع تعامل با سیستم مدیریت فرایندها، ارسال پیام به گردش کارها کفایت می کند؟ برای جواب به این سوال بهتر است ابتدا باکارکردهای پیام در سیستم مدیریت فرایندها آشنا شویم.
کارکرد پیام در سیستم مدیریت فرایندها
پیامها می توانند تمام فعالیتهای معتبر و تعریف شده در سیستم مدیریت فرایندها را در سطح کار، یا گردش کار انجام دهند. فعالیتهایی مثل ایجاد کار جدید، تغییر مقادیر فیلدهای کارها، تعلیق/ رفع تعلیق کارها، توقف موقت، ادامه کار، بیدارکردن کارهای در حالت تاخیر، خاتمه یا لغو کارها، ارسال اعلامیه ها و ... بنابراین برای هر گونه فعالیت یا تغییر در گردش کارها، کافی است یک درخواست به فرم پیام را به گردش کار ارسال کنیم. برای آشنایی بیشتر با مفهوم و عملکرد پیامها می توانید به مستندات زیر مراجعه کنید:
مفهوم و کارکرد پیام در سیستم مدیریت فرایندها
رخداد (Event) : نوع خاصی از پیام
حال برای ارسال درخواستها به وب سرویس SOAP باید یک کلاینت SOAP داشته باشیم، در ادامه مطلب، با ساختار این کلاینت و نحوه ایجاد و ارسال درخواستها از طریق آن آشنا می شویم.
پیاده سازی کلاینت SOAP در محیط javascript
یک درخواست شامل پیام (message) در واقع یک HTTP Request از نوع POST است. برای این کار باید با استفاده از امکانات کلاس XMLHTTPRequest در محیط برنامه نویسی javascript یک کلاینت SOAP برای ارسال درخواستها بنویسیم. توضیح این که توابع و ابزارهای این کلاینت در شرکت نوسا نوشته شده و در یک فایل با نام RepositoryXPSOAPClt.js ارائه می گردد.
تابع ارسال درخواست در کلاینت SOAP
در کلاینت SOAP، ارسال درخواست از طریق تابع SendSoapRequest انجام می شود که الگوی کلی آن به شکل زیر است:
function SendSoapRequest (url, userName, password, method, parameters, async, callback)
همانطور که ملاحظه می کنید این تابع شامل پارامترهای زیر است:
- url: آدرس سرور SOAP در مقصد. مثال: http://nosa-test.nosa.com/RepositoryXPSOAP
- userName : نام کاربر معتبر در گردش کار مقصد
- password: کلمه عبور کاربر معتبر در گردش کار مقصد
- :method تابعی است که باید در وب سرور اجرا شود و در این مورد خاص، منظور تابع ارسال پیام (WorkSendMessage) است که طبق قرارداد در این پارامتر مقدار "WS_WorkSendMessage" قرار می گیرد.
- parameters: یک آرایه (Array)از اطلاعات پیام (message) ارسالی که شامل موارد زیر است:
- ADBName: نام پایگاه گیرنده پیام که الگوی MyDB _ReposXP_ دارد. یعنی پیشوند _ReposXP_ میان نام تمام پایگاهها مشترک است و MyDB عبارت دلخواهی است که برای هر پایگاه به شکل خاص تعیین می شود.
- AWorkKey:کلید کار گیرنده پیام. اگر گیرنده پیام مشخص است باید کلید کار گیرنده پیام را در این پارامتر مقداردهی می کنیم در غیر این صورت اگر گیرنده مشخص نیست باید مقدار صفر را به این پارامتر بدهید. در این حالت پیام به شکل رخداد (event) ارسال خواهد شد.
- :AMessageKeyStr کلید حرفی پیام
- ANote: یادداشت پیام
- ANumberParam: پارامتر عددی پیام. اگر پارامتر عددی تعیین نشده است باید مقدار این پارامتر را برابر صفر قرار دهید.
- AStringParam: پارامتر حرفی پیام
- ACheckPendings : انجام/عدم انجام امور معوقه موتور گردش کار. این پارامتر نیز از نوع منطقی است و مقدار true به معنی این است که CheckPendings انجام شود.
- async: وضعیت آسنکرون (ناهمزمانی). یک داده از نوع منطقی است که مقدار آن باید همواره true به معنی آسنکرون بودن ارتباط باشد.
- callback: تابعی که پاسخ و خطاهای احتمالی را برمی گرداند. این تابع به شکل پیش ساخته نوشته شده است و مطابق با یک الگوی تعیین شده، کد و متن پاسخ و خطاها را برمی گرداند.
تعیین Headerهای درخواست
علاوه بر پارامترهای فوق، دو داده دیگر هست که باید به شکل header به درخواست اضافه شود:
این موارد در تابع SendSoapRequest به شکل Header اضافه شده اند برای آشنایی با محتوای این موارد، به متن اسکریپت این تابع مراجعه کنید.
نحوه پاس کردن داده ها به تابع SendSoapRequest
در ابتدای این مستند گفته شد که قرار است سیستمهای نرم افزاری دیگر از طریق کلاینت SOAP درخواستهای حاوی پیام را به وب سرور SOAP سیستم مدیریت فرایندهای نوسا ارسال کنند. به این ترتیب تنها نرم افزارهایی می توانند با وب سرور SOAP نوسا تعامل داشته باشند که امکان ارتباط با کلاینت SOAP و پاس کردن داده های مورد نیاز به تابع SendSoapRequest را داشته باشند. برای درک بهتر پاس کردن داده ها به یک مثال توجه کنید:
مثال : ارسال پیام برای شروع یک کار پشتیبانی
فرض کنید در یک مرکز، نرم افزار فروش می خواهد درخواست ایجاد یک کار جدید پشتیبانی را به به سیستم مدیریت فرایندها ارسال کند. در این نرم افزار، داده های مربوط به درخواست ارسال پیام (message) در فیلدهایی با نامهای زیر ذخیره می شود:
url: آدرس سرور SOAP
userName: نام کاربری
password: کلمه عبور
dbName : نام پایگاه
wKey: کلید کار
msgKey: کلید حرفی پیام
msgNote: یادداشت پیام
numParam: پارامتر عددی پیام
strParam: پارامتر حرفی پیام
chkPending: وضعیت انجام امور معوقه
همانطور که قبلا گفته شد، سه مورد اول به شکل مقادیر ساده و بقیه موارد که پارامترهای پیام را تشکیل می دهند باید به شکل یک Array پاس شود. بنابراین ابتدا یک متغیر بنام AParams و از نوع Array تعریف می کنیم و سپس اعضای آرایه را به شکل زیر تعیین می کنیم و در نهایت تابع SendSOAPRequest را صدا می زنیم:
function SendMessaage() {
var AParams= [ ];
AParams[ADBName]=dbName;
AParams[AWorkKey]=wKey;
AParams[AmessageKeyStr]=msgKey;
AParams[ANote]=msgNote;
AParams[ANumberParam]=numParam;
AParams[AStringParam]=strParam;
AParams[AcheckPendings]=chkPending;
SendSoapRequest (url, userName, password, “WS_WorkSendMessage”, AParams, true,
function (ARes) {
let status=JSON.parse(ARes);
const state= 'ErrNo:' + status["_ErrNo"] + '\nErrStr: ' + status["_ErrStr" ] ;
return state;
}
}
از میان پارامترهای تابع SenSoapRequest ، شاید تنها پارامتر آخر یا تابع callback برای مخاطب ایجاد ابهام کند. همانطور که قبلا هم توضیح داده شد، این تابع پاسخ و خطاهای احتمالی درخواست را برمی گرداند روش کار این تابع به این شکل است که ابتدا از طریق JSON.parse رشته حرفی پاسخ (ARes) را به یک موجود (Object) تبدیل می کند و سپس دو عضو این موجود یعنی کد خطا (ErrNo) و شرح خطا (ErrStr) را در دو سطر نمایش باز می گرداند.
مقداردهی پارامترها
حال اگر پارامترها مقداردهی شوند آنگاه می توانیم درخواست را ارسال کنیم. مقداردهی پارامترها در هر نرم افزار ممکن است به شیوه های مختلف انجام شود. برای مثال در یک نرم افزار ممکن است این مقادیر توسط کاربر و به شکل دستی وارد شود و در نرم افزار دیگر، ممکن است این پارامترها به شکل خودکار و توسط کد نویسی انجام شود. برای نمونه در مثال بالا، ممکن است پارامترها به شکل مقادیر ثابت در نرم افزار فروش ذخیره شده باشد یا این که در یک مرحله، از کاربر بخواهد مقادیر لازم برای پارامترها را در یک فرم وارد کند. یک نمونه از این روش ارسال دستی استفاده از رابط کاربری HTTP است.
رابط کاربری HTTP Client
برای تست کلاینت SOAP بهترین راه این است که یک رابط کاربری HTTP به شکل محاوره داشته باشیم که بتوانیم داده های درخواست را به شکل دستی تعیین و ارسال کنیم. برای مثال به محاوره زیر توجه کنید:
حال می توانیم داده ها و پارامترهای مورد نظر خود را در این فرم وارد کنیم و با کلیک روی تکمه اجرا، درخواست خود را به وب سرور SOAP ارسال کنیم و سپس پاسخ را در فیلد نتیجه اجرا مشاهده کنیم. ضمنا فایل source این کلاینت نیز با نام RepositorySOAPXPClt.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
و به همین ترتیب پاسخهای دیگری که در روند پردازش پیام در سیستم مدیریت فرایندها اتفاق می افتد که به دلیل تعدد خطاها به همین مثالها اکتفا می کنیم.