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

معرفی کامل نرم افزار کموندا (Camunda)

مروری بر ویژگی های نرم افزار کاموندا یا کموندا (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 امکان دسترسی به فرآیندها و داده های مرتبط را برای هر مستاجر فراهم می‎کنند.

آیا نرم افزار کاموندا منبع باز می‎تواند بازار 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 است که فرآیند ایجاد اپلیکیشن های مستقل و گرید تولیدی[1] جاوا را ساده می‎کند.
این قابلیت عملی جاوا به وضوح انگیزه اصلی برای انتخاب 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 هنوز نابالغ است. و از آنجا که منبع باز نیز است، شما خوشحالید که از آن استفاده می کنید. این ممکن است بهترین راه اقدام باشد وقتی که مشتریان متوجه شوند چسباندن کدهای قدیمی ‎به کانتینرها باعث نمی‎شود که آنها به یک اپلیکیشن ابری تبدیل شوند.

نرم افزار bpms کموندا

منابع:

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

https://camunda.com/products/

[1] – Production Grade : یک اصطلاح عمومی است که برای اشاره به نرم افزار یا سخت افزاری که برای استفاده منظم و فشرده با کاربران واقعی طراحی شده است.

دیدگاه‌ خود را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.

پیمایش به بالا