رویدادهای مبتنی بر پیام در مقایسه با وظیفه های مبتنی بر پیام

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

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

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

 

جریان پیام در وظیفه ها و رویدادها

به طور ذاتی، رویدادهای پیامی یا در حال فرستادن و یا گرفتن هستند و می توانند موارد زیر را شامل شوند:

  • فرایندی را آغاز کنند (رویداد آغاز پیام)، در واقع نمونه ای جدید را زمانی که پیام دریافت می شود ایجاد می کنند.
  • فرایندی را به پایان رسانند (رویداد پایان پیام)، در واقع نمونه فرآیند جاری را زمانی که پیام فرستاده می شود به اتمام می رسانند.
  • یک جریان فرایند را زمانی که یک پیغام فرا می رسد، دنبال می کنند(رویداد میانی که مسئول گرفتن پیام هستند) .
  • پیامی را  جایی میان آغاز و اتمام یک فرآیند ارسال می کنند(رویداد میانی که مسئول فرستادن پیام هستند)

در نهایت رویداد میانی که مسئول گرفتن پیام است، می تواند در هر مکانی از مرز فعالیت ها، قرار گیرد تا  استثنائات را کنترل کرده و یا جبران خسارت نماید.

 BPMN 1.x، جریان های پیامی را مجاز به ارتباط مستقیم در درون یک وظیفه انتزاعی می دانست و به طور دقیق رفتار رویدادهای پیامی را تقلید نمی کرد. به علاوه  BPMN 1.x،  تنها اجازه می داد  یک پیام به یک فعالیت فرستاده یا دریافت شود و این علاوه بر کار اصلی که این فعالیت انجام می داد، بود. با معرفی وظایف ارسالی و دریافتی در BPMN 2.0، ما می توانیم بگوییم که یک وظیفه در یک فرآیند، به طور دائمی، پیامی را ارسال یا دریافت می کند. پس از این که پیام ارسال یا دریافت می شود، آن وظیفه تمام شده تلقی شده و هیچ کار دیگری اجرا شدنی نیست.

                    

صرف نظر از جزئیات، میان "رویدادهای پیامی" و "وظایف ارسال یا دریافت" تفاوتی وجود ندارد. هر دوی آن ها مزایا و معایبی دارند که در ادامه به آن ها نگاهی می اندازیم.

 

مزایا و معایب استفاده از وظایف ارسال و در یافت: 

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

فعالیت های استاندارد، مدل ساز را قادر می کنند تا نشانگرهای متفاوتی را اضافه کند که می توانند نمایانگر گونه های موازی چند گانه، ترتیبی یا حلقه ای از یک فعالیت باشند. چنین نشانه هایی همچنین می توانند در مورد وظایف ارسال یا دریافت به کار برده شوند و توصیفات اضافه در مورد رفتار پیشرفته یک وظیفه را ارائه دهند.

                                  

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

مزیت دیگر استفاده از وظایف ارسال ودریافت بر رویدادهای پیامی، قابلیت اتصال یک رویداد مرزی به یک وظیفه می باشد. در این صورت ما می توانیم استثنائات متعددی را که ممکن است در هنگام ارسال یا دریافت یک پیغام اتفاق بیفتند، کنترل کنیم.

         

 

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

همانند رویداد آغاز یک پیغام، فعالیت ارسال می تواند مثالی از فرآیند نیز باشد. بدین منظور نمادی که کمی متفاوت است مورد استفاده قرار می گیرد، برای مثال یک پاکت نامه در میان یک دایره.

                               

 

با استفاده از وظیفه دریافت که نمونه ای از یک فرآیند است، ما می توانیم مدلی با ساختاری مستحکم را بدون نیاز به تعریف اضافی یک رویداد آغازی تعریف کنیم. 

 

مزایای استفاده از رویدادهای پیامی میانی

در زمان تعریف جریان یک فرآیند، وضعیت های متعددی وجود دارند که در آن ها فعالیت های ارسال و دریافت را نمی توان مورد استفاده قرار داد. در این صورت، بهتر است از رویدادهای پیامی میانی استفاده کرد. 

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

دوم این که، اگر بخواهیم وضعیتی را به نمایش بگذاریم که دریافت یک پیام لزوماً پایان یک فعالیت نیست، رویدادهای پیامی غیر مداخله ای گیرنده که به صورت مرزی و میانی هستند، مورد استفاده قرار می گیرند.

          

 

مثال بالا نشان دهنده یک فعالیت انسانی است که شامل نگارش یک گزارش می باشد و می تواند با دریافت یک به روز رسانی مهم، متوقف شود. در این صورت، بروز رسانی فایل ها اجرا می شود و نگارش گزارش از نو مدل سازی می شود.

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

 

اشتباهات رایج

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

            

 

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

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

         


در این صورت، فعالیت اول در "Pool 1" یک کار مشخصی را انجام می دهد (برای مثال "مهیا کردن یک پاسخ") و فعالیت دوم این پاسخ را به "Pool 2" می فرستد، جایی که در آن یک وظیفه دریافتی قرار داده شده است که به آن "دریافت پیام" گفته می شود. پس از دریافت پیام به شکل وظیفه دریافتی، وظیفه "تحلیل محتوا"، کار مربوطه را انجام می دهد.

یک اشتباه رایج دیگر نیز در هنگام مدل سازی، ارتباط میان Lane های متعدد در یک Pool است. رویدادهای میانی ارسال و دریافت پیام به صورت تنگاتنگ با جریان های پیامی جفت شده اند. مورد دوم تنها برای ارائه ارتباط میان دو Pool  استفاده می شود و برای استفاده میان Lane های همان Pool مناسب نمی باشند. کاربرد نادرست این چنینی در زمان استفاده از وظایف ارسال و دریافت، بسیار رایج است. 

           

 

در مثال بالا، رویداد پیامی میانی که از نوع ارسالی است و با برچسب "اعلان به Lane2" مشخص شده است، در حقیقت یک جریان پیامی را ارسال می کند و تا زمانی که "پیام از Lane1 دریافت شود" ادامه می یابد و در آنجا به انتظار جریان های پیامی دریافتی که هیچ گاه نمی رسند، می ماند. چنین عملی در مورد وظیفه ارسالی "اعلان به Lane2" و وظیفه دریافت "پاسخ دریافتی از Lane1" نیز رخ می دهد.

با توجه به ویژگی های BPMN 2.0، ارتباط میان Pool ها را می توان به سادگی و تنها با استفاده از جریان های ترتیبی، همان گونه که در شکل شماره 9 نشان داده شده است، ارائه نمود.

 

نتیجه گیری:

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

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

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

کاربران BPMN، به میزان زیادی به رویدادهای میانی ارسال و دریافت عادت دارند. استفاده ازفعالیت های ارسال و دریافت ممکن است در صورت استفاده محض به منظور ارسال و دریافت جریان های پیامی، مبهم به نظر برسد.


نویسنده: Gregor Polancic

منبع: Message Events Vs. Message Tasks

ترجمه: هاجر سازنده


 

درباره رایورز

شرکت مهندسی نرم‌افزار رایورز در اوایل سال 1368 توسط جمعی‌از فعالین حرفه نرم‌افزار تأسیس گردید...

بیشتر بدانید

ارتباط با ما

  • تهران، خيابان ولی عصر، نرسيده به توانير، خيابان احتشام، شماره 5
  • 89326000

  • BPMS@rayvarz.com

خبرنامه پایگاه دانش BPM