مروری بر ویژگی های نرم افزار کاموندا یا کموندا (Camunda)
نرم افزار کاموندا (Camunda) یک چارچوب مبتنی بر جاوا است که از BPMN برای گردش کار و اتوماسیون فرآیند، از CMMN برای مدیریت پرونده و ازDMN برای مدیریت تصمیم گیری کسب و کار پشتیبانی میکند. این مطلب حاوی اطلاعاتی در مورد ویژگی های ارائه شده توسط پلتفرم Camunda BPM است. برای نمایش کلی نرم افزار کاموندا (Camunda)، تصویر زیر مهمترین مؤلفه ها به همراه برخی از نقش های یک کاربر معمولی را نشان میدهد.
نام نرم افزار کاموندا (Camunda) از افعال لاتین “capere” (به معنای درک”) و “munda” (به معنای پاک) گرفته شده است. این بدان معنی است که ما میخواهیم دنیای پیرامون خود را عمیقا درک کنیم و بر اساس آن درک، میخواهیم به روشی که هم مؤثر و هم اخلاقی است عمل نماییم – تا جهان را به مکانی بهتر برای همه تبدیل کنیم.
موتور پردازش و زیرساخت ها
- موتور پردازش فرآیند یک کتابخانه جاوا است که وظیفه اجرای فرآیندهای BPMN0، مواردCMMN1.1 و تصمیماتDMN 1.1 را بر عهده دارد. این موتور یک هسته POJO سبک وزن دارد و برای ماندگاری از یک پایگاه داده رابطه ای استفاده میکند. نقشه برداریORMتوسط چارچوب نقشه برداریMyBatisتهیه میشود.
- چارچوب ادغام اسپرینگ
- ادغام CDI / JavaEE
- ادغام کانتینر زمان اجرا (ادغام با زیرساخت های سرور برنامه)
مدل سازها:
- CamundaModeler: ابزار مدل سازی برای نمودارهایBPMN 2.0وCMMN1و همچنین جداول تصمیم گیریDMN1.1.
- bpmn.io: پروژه منبع باز برای چارچوب مدل سازی و مجموعه ابزارهای برنامه.
اپلیکیشن های وب
- RESTAPI به شما امکان میدهد از طریق یک اپلیکیشن از راه دور یا یک اپلیکیشن جاوا اسکریپت، از موتور پردازش نرم افزار کاموندا (Camunda) استفاده نمایید. (توجه: مستنداتRESTAPIدر اسناد خودش وارد شده است).
- CamundaTasklist یک اپلیکیشن وب برای مدیریت گردش کار انسانی و وظایف کاربران است که به شرکت کنندگان در فرآیند اجازه میدهد تا وظایف گردش کار خود را بررسی نموده و فرم های وظیفه را مسیریابی کنند تا بتوانند روی وظایف کار کرده و داده های ورودی را ارائه دهند.
- CamundaCockpit یک اپلیکیشن وب برای نظارت بر فرآیندها و عملیات که به شما امکان میدهد نمونه های فرآیند را جستجو کنید، وضعیت آنها را بازرسی نموده و خرابی ها را ترمیم نمایید.
- CamundaAdmin یک اپلیکیشن وب که به شما امکان میدهد کاربران، گروه ها و مجوزها را مدیریت نمایید.
- CamundaCycle یک اپلیکیشن وب برای هماهنگ سازی مدل های فرآیندBPMN 2.0بین ابزارهای مختلف مدل سازی و مدل سازها.
- Camunda Optimize: برای ایجاد گزارش های زیبا میتوانید از Camunda Optimize استفاده کرده و برای نظارت بر کسب و کار، تنظیمات لازم را در داشبورد روی آنها انجام دهید. همچنین میتوانید آلارم هایی را تنظیم کنید که در صورت عدم موفقیت اهداف عملکرد، روشن می‌شوند. و سپس از تجزیه و تحلیل پیشرفته برای شناسایی گلوگاه های فرآیند استفاده نمایید.
معماری موتور پردازش نرم افزار کاموندا (Camunda):
- موتور پردازش عمومی: APIموتور عمومی APIسرویس گرا به برنامه های جاوا اجازه میدهد تا با موتور پردازش ارتباط برقرار نمایند. در واقع مسئولیت های مختلف موتور پردازش (یعنی مخزن پردازش، تعامل با پردازش زمان اجرا، مدیریت وظیفه و …) به سرویس های انفرادی تقسیم می‌شوند. APIعمومی دارای یک الگوی دستیابی به فرمان است. به این معنا که وقتی رشته های پیام وارد موتور پردازش می‌شوند از طریق یک رهگیرهدایت میگردند که برای تنظیم محتوای پیام (فرضا تراکنش ها) استفاده میگردد.
- BPMN0CoreEngine: این مورد، هسته اصلی موتور پردازش است که دارای یک موتور اجرای سبک برای سازه های گرافیکیمیباشد. همچنین دارای یک تجزیه گر BPMN2.0 است که فایل هایBPMN2.0 XMLرا بهJavaObjectها و به مجموعهای از پیاده سازی هایBPMN تبدیل مینماید( امکان اجرای سازه های BPMN2.0 مانند Gatewayها یا ServiceTask را مهیا میکند).
- Job Executor: وظیفه پردازش کارهای پس زمینه ناهمزمان مانند تایمرها یا دنباله های ناهمزمان در یک فرآیند را بر عهده دارد.
- ThePersistenceLayer: موتور پردازش دارای یک لایه ماندگاری است که مسئول پایدار نگهداشتن حالت لحظه ای پردازش به صورت یک پایگاه داده مرتبط است.
متداول ترین سناریوهای معماری پلتفرم نرم افزار کاموندا (Camunda)
- موتور پردازش تعبیه شده: در این حالت، موتور پردازش به عنوان کتابخانه اپلیکیشن به یک اپلیکیشن سفارشی اضافه میشود. به این ترتیب موتور پردازش را میتوان به راحتی با چرخه عمر برنامه شروع نموده و متوقف کرد. اجرای چندین موتور پردازش تعبیه شده در بالای یک پایگاه داده مشترک امکان پذیر است.
- موتور پردازش به اشتراک گذاشته شده و مدیریت شده با کانتینر: در این حالت، موتور پردازش نرم افزار کاموندا (Camunda) در داخل محفظه زمان اجرا(Servlet Container، Application Server،) شروع به کار میکند. موتور پردازش به صورت یک سرویس کانتینر ارائه میشود و میتواند توسط همه اپلیکیشن های مستقر در داخل کانتینر به اشتراک گذاشته شود. این مفهوم را میتوان با صف پیام JMS مقایسه کرد که در زمان اجرا ایجاد میشود و توسط همه اپلیکیشن ها قابل استفاده است. نوعی نگاشت یک به یک بین استقرار فرآیند و اپلیکیشن ها وجود دارد: موتور پردازش، تعاریف فرآیند مستقر در یک اپلیکیشن را پیگیری نموده و اجرای آن را به برنامه مورد نظر تفویض مینماید.
- سرور موتور پردازش مستقل (از راه دور): در این حالت موتور پردازش به صورت یک سرویس شبکه ای ارائه میشود. برنامه های مختلف که در شبکه در حال اجرا هستند میتوانند از طریق کانال ارتباطی از راه دور با موتور پردازش ارتباط برقرار نمایند. ساده ترین راه برای دسترسی موتور پردازش از راه دور استفاده از REST API داخلی است.
- مدل خوشه بندی: به منظور فراهم آوردن قابلیت های مقیاس بالا یا سوئیچ کردن به سیستم دیگر برای غلبه بر خرابی، موتور پردازش نرم افزار کاموندا (Camunda) را میتوان در یک خوشه به گره های مختلف توزیع کرد. سپس هر یک از موتورهای پردازش باید به یک پایگاه داده مشترک متصل شوند.
هر یک از خوشه ها وضعیت گردهمایی را در طول تراکنش ها حفظ نمیکنند. هر زمان که موتور پردازش تراکنشی انجام دهد، حالت کامل به پایگاه داده مشترک منتقل میشود. این مدل بسیار ساده و قابل فهم است و محدودیت های کمی را در هنگام استقرار نصب خوشه اعمال میکند.
Job Executor نیز به صورت خوشه ای تنظیم شده و بر روی هر گره اجرا میشود. به این ترتیب، هیچ نقطه ای از خرابی در مورد موتور پردازش وجود ندارد. Job Executor میتواند در هر دو گروه همگن و ناهمگن اداره شود.
- مدل های چند مستاجری: برای ارائه چند نوع سرویس مستقل با یک بار نصب Camunda، موتور پردازش از مدل چند مستاجری نیز پشتیبانی میکند. این مدل ها در نرم افزار کاموندا (Camunda)دو نوع هستند:
- جداسازی داده ها به صورت جدولی با استفاده از پایگاه داده ها یا طرح های پایگاه داده مختلف
- جداسازی داده ها به صورت ردیفی با استفاده از یک نشانگر مستاجر
کاربران باید مدلی را انتخاب کنند که متناسب با نیازهای جداسازی اطلاعات آنها باشد. API های Camunda امکان دسترسی به فرآیندها و داده های مرتبط را برای هر مستاجر فراهم میکنند.
آیا نرم افزار کاموندا (Camunda)ی منبع باز میتواند بازار BPM را مختل نماید
به نظر میرسد نرم افزار کاموندا (Camunda) در حال جلب توجه همه تمایلات اصلی در دنیای امروز BPMS است. نرم افزار کاموندا (Camunda) به جای تغییر پلتفرم خود به صورت پلتفرم کم کد، به طور غیرمنتظره ای در خدمت توسعه دهندگان جاوا است و برای آنکه بتوان به طور موثر از بستر آن استفاده نمود به مهارت های خاص جاوا نیاز است. در ادامه به شرح برخی از ویژگی های پلتفرم نرم افزار کاموندا در مقایسه با رقبای خود میپردازیم.
در مورد یکپارچگی
سهم بازار Camunda ممکن است نسبتاً ناچیز باشد، اما این مانع از آن نیست که وارد نبرد سه گانه علیه رهبران پلتفرم های کم کد یعنی BPMN Appian، Pega و IBM BPM نشود.
تمهید Camunda : این سه بازیکن دائمی، در حال ارائه سیستم عامل های یکپارچه به مشتریان سازمانی خود هستند. البته نیاز به تعهد متقابل از طرف این دسته از مشتریان دارند، زیرا محصولی ارائه میدهند که در پایان دارای مشکلات مقیاس پذیری است.
برخی صاحب نظران حوزهBPM ، با موضع نرم افزار کاموندا (Camunda) موافقند که قرار گرفتن در طبقه بندی BPMS” هوشمند” (iBPMS) گارتنر را هدف قرار داده است. چرا که در کنار یکپارچگی، درصدی از مقیاس پذیری را نیز شامل میشود.
درعوض، مشتریان میتوانند در صورت تمایل، نرم افزار کاموندا را در سطح دپارتمانی مستقر کنند تا از موقعیت هایی حمایت نمایند که در آنها نیازهای ذینفعان ممکن است از دپارتمانی به دپارتمان دیگر متفاوت باشند.
دریک واندیور، معمار شرکت و معمار پلتفرم برای شرکت های خدمات مالی ING، فهمید که انعطاف پذیری و مقیاس پذیری نرم افزار کاموندا متناسب با نیازهای شرکت وی است. ING پگا را که یکی از پلت فرم های یکپارچه است در سطح منطقه مستقر کرده بود – اما میخواست با آن جهانی شود. تنها راه تحقق این شاهکار، نصب چندین نسخه از پگا بود که منجر به پیچیدگی سنگین و حاکمیت ناکافی میشد.
برای مقابله با این چالش، ING نرم افزار کاموندا (Camunda) را به صورت تاکتیکی در کشورهای خاص مستقر نموده و به توسعه دهندگان نرم افزار در آن مکان ها امکان میدهد فرآیندهایی را تهیه نمایند که نیازهای محلی را برآورده سازند؛ بدون آنکه به طور کامل پگا را از بین ببرند.
دنیس کوتوف، معمار راه حل در بانک بزرگ تینکوف روسیه، این ماجرا را نقل میکند که چگونه سازمانش از ING فراتر رفت. تینکوف، پلتفرم BPM یکپارچه خود را (که نامش را نبرد) پردازش مجدد نمود تا بتواند فرآیندهای نرم افزار کاموندا (Camunda) را فراخوانی کند و در نهایت تمام عملکردها را روی پلتفرم جدید تغییر داد.
کم کد بودن تحت هر عنوان
Jakob Freund، مدیرعامل و بنیانگذار نرم افزار کاموندا، مخاطبان خود را با توجه به شروع رقابت در زمینه کم کد بودن خوشحال کرد. وی در ابتدا گفت: “با BPMS کم کد میتوانید بدون برنامه نویسی برنامه ایجاد کنید، بنابراین نیازی به برنامه نویسان ندارید. اما یک جای کار غلط است! اگر BPMS کم کد منطقی باشد، آمازون کل سیستم عامل خود را به صورت کم کد اجرا میکند، اما اینگونه نیست.”
اما در کمال تعجب، هنگامی که دانیل میر و دیگر بنیانگذاران نرم افزار کاموندا (Camunda)، روی صحنه رفتند و نمایشی از Camunda Modeler را به اجرا درآوردند، هیچ شکی نبود که این محصول در واقع کم کد است و اجرای نرم و بی دردسری برای راه اندازی دارد.
در واقع،Modeler نه تنها یک رویکرد بصری کم کد را برای ایجاد گردش کار ارائه میدهد (که همه محصولات BPMS امروز انجام میدهند)، بلکه در واقع نوتیفیکیشن BPMN را مستقیماً در ویرایشگر تصویری گنجانیده است، و به مدلسازان این امکان را میدهد که بتوانند مدل های سازگار با BPMN را فقط با داشتن دانشی گذرا از استاندارد بسازند.
در حالی که Camunda به طور غیرمستقیم دارای کد بالا است، چگونه از توسعه دهندگان انتظار میرود مدل ها را به عملکردی که میخواهند آن را اتوماتیک سازند، متصل نمایند. در حقیقت، رویکرد مطلوب نرم افزار کاموندا (Camunda) برای اجرای چنین عملکردهایی از طریق Spring Boot است. Spring Boot یک زیر مجموعه سبک از چارچوب محبوب Spring Java است که فرآیند ایجاد اپلیکیشن های مستقل و گرید تولیدی[۱] جاوا را ساده میکند.
این قابلیت عملی جاوا به وضوح انگیزه اصلی برای انتخاب Camunda در بین جمعیت پلتفرم های BPM بوده است. با این حال، در مقایسه با BonitaSoftکه یکی دیگر از BPMS های منبع باز موجود در بازار است، نرم افزار کاموندا (Camunda) به طور کلی از لحاظ سهولت در ساخت چنین برنامه های حمایتی، در سایت های رتبه بندی مانند IT Central Station و TrustRadius ، امتیاز کمتری میگیرد.
رسیدن به درجه بالای ابر بومی
نرم افزار کاموندا (Camunda) ممکن است بتواند فضای اندکی در غلبه جهانی Appians، IBMs و Pegas پیدا کند، اما ظهور یک BPMS متناسب با جاوا و منبع باز در بازار، بعید است که باعث ایجاد اختلال اساسی در نحوه تفکر شرکت ها در مورد خودکار سازی فرآیندهای کسب و کار گردد.
خوشبختانه نرم افزار کاموندا، ترفند دیگری در آستین خود دارد: موتور گردش کار Zeebe برای ارکستراسیون میکرو سرویس ها. Zeebe منبع باز است و در قلب سرویس های جدید پیشنهادی Camunda Cloud BPMS-as-a- service قرار دارد.
با Zeebe، نرم افزار کاموندا (Camunda) اساساً با رعایت اصول کامل ابر بومی، جریان گردش کار را دوباره اختراع کرده است. Zeebe به عنوان میکروسرویس اجرا می شود و خودش ارکستراسیون و کورئوگرافی میکروسرویس ها را در گردش کار انجام میدهد که باعث افزایش مقیاس پذیری افقی Kubernetes میگردد.
Zeebe دو قابلیت مهم را برای بازی BPMS به ارمغان میآورد. اول اینکه میتواند تعداد بی حد و حصری از نمونه های فرآیند را به طور همزمان پشتیبانی نماید. این ویژگی برای مثال برای پشتیبانی از فرآیندهای مبتنی بر کاربر با حجم بالا ضروری است. (اگر در گذشته آمازون Zeebe داشت، شاید میتوانست بستر تجارت الکترونیکی خود را روی آن بنا کند).
دوم اینکه، Zeebe برای مقابله با مشکل “ماشین پین بال ” که میکرو سرویس های رویداد محور آن را بروز میدهند، یک رویکرد ابری به توسعه دهندگان نرم افزار ارائه میدهد. این مشکل توصیف میکند که چگونه پیام ها تمایل به گشت و گذار در اطراف میکروسرویس دارند و منجر به وضعیتی غیرقابل پیش بینی می‌شوند که مدیریت اثرات را دشوار مینماید.
در عوض، Zeebe تعادلی هم برای وجود کورئوگرافی میکروسرویس ها و هم باقی ماندن ارکستراسیون ایجاد میکند. وقتی هریک از این رویکردها به طور جداگانه پیاده سازی می‌شوند، مشکلاتی وجود خواهد داشت: کورئوگرافی میکروسرویس های رویداد محور، منجر به مشکل ماشین پین بال میشود. ارکستراسیون نیز به تنهایی منجر به رفتار یکپارچه و در نتیجه غیر مقیاس پذیر خواهد شد.
بنابراین، Zeebe بدون در نظر گرفتن اینکه محتوای چنین برنامه هایی برای اتوماسیون یک فرآیند کسب و کار است یا نوعی گردش کار دیگر، یک لایه هماهنگ ابر بومی برای برنامه های میکروسرویس ارائه میدهد.
آیا Zeebe به نرم افزار کاموندا (Camunda) یک مزیت رقابتی میبخشد؟
کانتینرهای ارکستر Kubernetes ممکن است شامل همه نوع کد برنامه ای باشند. بنابراین هیچ دلیلی وجود ندارد که فروشندگان iBPMS نتوانند سیستم عامل های خود را در چنین کانتینرهایی قرار دهند. به عنوان مثال،Pega راهنمایی های دقیقی در مورد چگونگی استقرار سکوی خود در Kubernetes ارائه میدهد، و فروشندگان دیگر بدون شک از محصولات ارائه شده مبتنی بر Kubernetes در کار خود استفاده میکنند.
اما اشتباه نکنید: یک تفاوت اساسی بین اجرا کردن کد روی Kubernetes و تغییر معماری یک اپلیکیشن به صورت ابری وجود دارد – به خصوص وقتی که این اپلیکیشن خود شامل زیرساخت های سیستم عاملی باشد.
Zeebe فقط سکوی نرم افزار کاموندا (Camunda) نیست که روی Kubernetes کار میکند. Zeebe نوع جدیدی از پلتفرم های BPMS است که نرم افزار کاموندا (Camunda) را از حالت محلی به ابر بومی تبدیل می کند.
Zeebe قول میدهد توسعه دهندگان را قادر سازد که از یک رویکرد مدل محور برای گردش کار در برنامه های ابر بومی استفاده کنند. بنابراین از طیف گسترده ای از سناریوهای اتوماسیون هم در کسب و کار و هم در افق IT استفاده میکنند.
فروشندگان بزرگ و ارائه دهنده سیستم عامل های یکپارچه علاقه دارند که مشتریان را در این مرحله گیج کنند. پس دقت کنید که گیج نشوید.
بازیکنان فعلی iBPMS با این وجود باید امیدوار باشند. Zeebe هنوز نابالغ است. و از آنجا که منبع باز نیز است، شما خوشحالید که از آن استفاده می کنید. این ممکن است بهترین راه اقدام باشد وقتی که مشتریان متوجه شوند چسباندن کدهای قدیمی به کانتینرها باعث نمیشود که آنها به یک اپلیکیشن ابری تبدیل شوند.
منابع:
https://docs.camunda.org/manual/7.7/introduction/
https://docs.camunda.org/manual/7.9/introduction/architecture/
https://techbeacon.com/enterprise-it/can-open-source-camunda-disrupt-bpms-market
[۱] – Production Grade : یک اصطلاح عمومی است که برای اشاره به نرم افزار یا سخت افزاری که برای استفاده منظم و فشرده با کاربران واقعی طراحی شده است.