BPMN 2.0 Teknolojileri

BPMN 2.0 Nedir?

BPMN 2.0, iş süreçlerini görselleştirmek, anlamak ve yönetmek için kullanılan standart bir notasyondur. İş süreçlerini bir dizi sembol ve kural setiyle temsil etme yeteneği sayesinde, farklı departmanlar arasında iletişimi kolaylaştırır ve iş süreçlerinin bütünleşik bir şekilde anlaşılmasını sağlar.

Günümüz iş dünyasında, karmaşık iş süreçlerini anlamak, tasarlamak ve optimize etmek kurumsal başarı için vazgeçilmez bir hale gelmiştir. İşte bu noktada, Business Process Model and Notation (BPMN) 2.0, iş süreçlerini daha anlaşılır ve yönetilebilir bir hale getirme amacı güden bir standarttır.

BPMN Task Türleri:

1. User Task (Kullanıcı Görevi):
   • User Task’lar, kullanıcıların manuel olarak gerçekleştirdiği görevlerdir.
   • Örneğin, müşteri siparişi onaylamak, form doldurmak gibi görevler kullanıcı görevi olarak modellenebilir.
   • Genellikle insan etkileşimini gerektiren işlemler için kullanılır.
2. Service Task (Hizmet Görevi):
   • Service Task’lar, otomatik olarak gerçekleştirilen görevlerdir.
   • Genellikle hizmet çağrısı yapılmasını veya sistemdeki işlemleri gerçekleştirmeyi ifade eder.
   • Örneğin, API çağrısı yapmak, veri tabanı işlemi gerçekleştirmek gibi işlemler hizmet görevi olarak tanımlanabilir.
3. Script Task (Betik Görevi):
   • Script Task’lar, genellikle belirli bir betiği veya kod parçasını yürütmek için kullanılır.
   • Örneğin, bir karar yapısı üzerinde hesaplamalar yapmak veya belirli bir koşula göre işlem yapmak için kullanılabilir.
4. Business Rule Task (İş Kuralı Görevi):
   • Business Rule Task, belirli iş kurallarının uygulanmasını ifade eder.
   • İş süreçleri içinde belirli koşullara dayalı kararlar almak için kullanılabilir.
   • Örneğin, bir siparişin indirim miktarını hesaplamak gibi işlemler bir Business Rule Task olarak tanımlanabilir.

Bu task türleri, iş süreçlerini modelleme ve anlama sürecinde farklı görevlerin nasıl gerçekleştirileceğini göstermektedir. BPMN’nin sağladığı bu görev türleri, iş süreçlerini daha modüler hale getirir ve sürecin karmaşıklığını azaltır.

Bu tasklara ek olarak BPMN 2.0 içinde tanımlı olan diğer task türleri ve onların gösterimi Şekil 1’deki gibidir.

User Task ve Service Task İçin BPMN Örneği:

Şekil 2’deki BPMN modelinde ilk olarak “izin iste” taskı çalıştırılıyor. “izin iste” taskı bir Service Task olup bizim projemizde tanımladığımız bir uca istek atar ve uçtan dönen yanıtın başarılı olup olmamasına göre akışı ilerletir ya da hata verir. Service Task Şekil 2’de ayarlar simgesiyle gösterilir. Service Task’larının içeriğini (input, output, variables, gideceği uç) de kullanılan teknoloji ile ayarlamak mümkündür. Bu örnekte yer alan Service Task’a ait XML formatında yer alan kod bloğu aşağıdaki gibidir.

1
2
<bpmn:serviceTask id="izinIste" name="izin iste">
</bpmn:serviceTask>

Eğer Service Task’ımız başarılı dönerse şemadaki bir sonraki adım olan “izinOnayla” taskına geçeriz. Bu task bir User Task’tır. User Task’larda ise kullanıcının aksiyon alıp onay vermesi gerekmektedir. Yoksa akış burada takılı kalır ve diğer taska geçemez. Burada onay için basit bir arayüz tasarlanabilir. User Task’ın ayarları da yine kullanılan teknolojiye göre değişiklik gösterebilir. Örnek akışta yer alan User Task’a ilişkin XML kod bloğuna aşağıda yer verilmiştir.

1
2
<bpmn:userTask id="userTaskIzinOnayla" name="izinOnayla">
</bpmn:userTask>

BPMN 2.0 Nasıl Çalışır?

BPMN 2.0, iş süreçlerini modelleme sürecinde kullanılan semboller ve bağlantılar aracılığıyla temsil eder. Temel unsurlar arasında görevler, karar noktaları, akışları belirten oklar, etkinlikler ve olaylar bulunmaktadır. Bu unsurlar, iş süreçlerini adım adım ve anlaşılır bir şekilde ifade etmek için kullanılır.

İş süreçlerinin modellenmesi sırasında, başlangıç noktalarından bitiş noktalarına kadar olan adımlar ve bu adımlar arasındaki ilişkiler net bir şekilde belirlenebilir. BPMN 2.0’nin sunduğu bu standart, iş süreçlerini yazılı ve görsel bir dil aracılığıyla ifade etme yeteneğiyle, ekipler arasında uyum sağlar ve süreçlerin anlaşılabilirliğini artırır.

Bu noktada, yazılım mühendisleri ve iş analistleri, BPMN 2.0’nin avantajlarından yararlanarak iş süreçlerini daha verimli bir şekilde tasarlamak ve yönetmek için çeşitli araçlara yönelebilir. Bu yazıda, Camunda 8, Camunda 7, Activiti, Flowable ve Kogito gibi beş farklı aracı inceleyerek, BPMN 2.0 ile modelleme sürecini daha derinlemesine keşfedeceğiz.

Camunda 8 Nedir?

Camunda 8, BPMN süreçleri ve DMN kararları için güçlü yürütme metodlarıyla birleştirilmiş ve hizmet olarak ölçeklenebilir, isteğe bağlı süreç otomasyonu sunan, ilişkili modelleme, yürütme ve analitik olarak raporlama sağlayan bir iş akış yönetim aracıdır.

Camunda 8 Mimari ve Bileşenleri

• Desktop Modeler: İş süreçlerini BPMN standartlarına uygun bir şekilde grafiksel veya görsel olarak modellemek, tasarlamak veya düzenlemek için kullanılan bir araçtır.
• Zeebe: Camunda bileşenleri arasında gerekli ilişkiyi sağlayarak akışları kontrol etmemiz ve yönetebilmemizi sağlayan Java ile geliştirilmiş bir API’dir.
• Tasklist: İş akışı içerisinde tanımlanmış User Task’ların yönetilmesi, ilerletilmesi, listelenmesi gibi işlevleri yapmamızı sağlayan bir bileşendir.
• Operate: Akışları yönetmek, izlemek, hata ayıklamak ve takip edip süreçleri ilerletmemiz için kullandığımız bir bileşendir.
• Optimize: Sisteminizdeki kısıtlamaları tanımlayarak veya BPMN içerisindeki tasklar üzerinde analiz yapabilmemizi sağlayan bir bileşendir.
• Connector: Harici bir sistemle entegrasyonu gerçekleştiren yeniden kullanılabilir bir yapı oluşturmayı sağlar. Çoğu akış, işi düzenlemek ve tamamlamak için Camunda dışındaki sistemlerle etkileşimi gerektirir.

Camunda 8 Kurulum

Camunda 8 platformu bulut tabanlı (SaaS) sistem üzerinden bağlantı sağlayarak kullanıldığı gibi kendi ortamınızda kurabileceğiniz şekilde de tasarlanmıştır. Biz yazımızda kendimizin yönetebileceği şekilde kurulum gerçekleştireceğiz. Camunda 8 platformunun önerisi olarak kubernetes veya docker image’ları kullanılarak kurulumu gerçekleştirilmelidir.

Kurulum Türleri

1. SaaS
2. Helm/Kubernetes
3. Docker
4. Manual

Docker İle Kurulum

Camunda 8’in kullanılması için minimum gerekli olan bileşenler: Zeebe, Operate, Tasklist Connectors ve süreçleri yönetmek için veri tabanı olarak kendisi Elastic Search kullandığı için Elastic Search’e ihtiyaç vardır. Güncel docker image’larına link üzerinden ulaşabilirsiniz.

Camunda Platform GitHub reposunda bulunan temel Camunda docker dosyasına uygun konfigürasyonlar yapıldıktan sonra docker compose -f docker-compose-core.yaml up -d komutuyla ilgili docker image’ları repodan çekilerek container olarak ayağa kaldırılır.

Camunda Modeler Nedir?

İş süreçlerini BPMN standartlarına uygun bir şeklide grafiksel veya görsel olarak modellemek, tasarlamak veya düzenlemek için kullanılan bir araçtır. Camunda Modeler, tasarlanan iş süreçlerini XML formatında dışa aktarmaya ve dışardan tasarlanan bir iş sürecini içe aktarmaya olanak sağlar. Bu da iş süreçlerinin yönetilmesinde esneklik sağlar.

Linkten Camunda Modeler’a ait kurulum dosyasını indirip çalıştırdıktan sonra Camunda 8 için iş akış çizimlerini gerçekleştirebilirsiniz.

Örnek Uygulama

İlk olarak Camunda kendi bileşenleri ile istediğimiz akış üzerinden işlemleri yönetmemiz için yeterli donanıma sahiptir. Biz ihtiyacımıza göre servisleri veya başka API’leri akışlarımız içerisinde kullanabiliriz.

Bunun için Camunda Modeler üzerinde BPMN 2.0 standartlarına uygun şekilde örnek bir akış çizelim.

Bu çizdiğimiz akışı Camunda üzerinde deploy etmemiz gerekmektedir. Deploy ederken Camunda Modeler bizden SaaS (Camunda’nın sunduğu bulut tabanlı ortam) olan bağlantı bilgilerini veya ‘Self Managed’ yani lokal ortama kurulu olan Zeebe API’nin bağlantı bilgisini bizden isteyecektir. İlgili alanlar tanımlandıktan sonra akış deploy edilir.

Lokalde ayağa kaldırmış olduğumuz Zeebe bağlantısı ilgili akış deploy edildikten sonra Operate API’nin sunmuş olduğu arayüz üzerinden akış görüntülenebilir. Operate API’nin sunduğu panelden yani localhost:8081 arayüzü üzerinden ilgili akışın tanımlandığı görülür.

Deploy edilen akışın detayı açılarak aktif, tamamlanmış, iptal edilmiş gibi daha önceden başlatılmış akışın hangi aşamada olduğu takip edilebilir.

Şekil 8’de akışın detayı görülmektedir. Şu an başlatılmış bir akış olmadığından Şekil 8’de ‘Process Instances’ panelinde akış bulunmamaktadır. Sol menüde ise akışların, versiyonların ve akışların durumu hakkında filtre yapabildiğimiz bir panel bulunmaktadır. Şimdi Tasklist API’nin sunduğu arayüz yani localhost:8082 üzerinden deploy edilen akışı başlatarak adım adım durumunu inceleyelim.

Camunda Modeler üzerinden akışı istediğimiz JSON veri yapısıyla akış içinde görebileceğimiz veriyle birlikte başlatabiliriz. Biz örneğimizde herhangi bir veri setlemeden akışımızı başlatıyoruz.

Akış başlatıldıktan sonra ilk taskımız yani izin oluşturma için belirlemiş olduğumuz User Task üzerinde aktif olarak kullanıcı aksiyonu beklemektedir. Şekil 11’deki arayüzde akış üzerinde başlatılmış olan akış ağaç yapısı şeklinde görüntülenmektedir. Camunda tarafından User Task aktif duruma geçtiğinde Tasklist API’nin arayüzünde aktif olarak bir task görüntülenir.

Tasklist arayüzünde akış içinde belirtilen User Task üzerinde tanımlı olan Camunda Form’un kullanıcı tarafındaki görünümü bu şekildedir. Kullanıcı bu taskı ilk önce ‘Assign to me’ diyerek üzerine alır. Daha sonra formdaki ilgili alanları doldurarak taskı ‘Complete Task’ ile tamamlar.

Bu task tamamlandıktan sonra akışımızın ilk taskı tamamlanır ve Camunda tamamlanan taskı ilerleterek bir sonraki taska geçer.

Görüldüğü üzere izin isteme taskı kullanıcı tarafından yapılarak yapmış olduğu task tamamlanmış olup girilen değerler akış içerisine setlenmiş durumdadır. Şu an akışımızı 2. taskı yani yöneticinin bu taska bir karar girmesini sağlayan User Task’a gelmiş durumdadır ve Camunda otomatik olarak bir User Task başlatır. Başlatılan User Task yönetici tarafından Tasklist API’nin arayüzü üzerinden tamamlanmalıdır. Aksi durumda bu task tamamlanana kadar akış bu adımda aktif bir şekilde bekler.

Burada oluşturulmuş izne yönetici tarafından üç farklı karar girilebilir. İzin kabul edilebilir, reddedilebilir veya ekstra bilgi istenebilir. Akışımızda ekstra bilgi istenmesi durumunda akış başa dönecek şekilde tasarlanmıştır. Reddedildiği durumda kullanıcıya bildirim gönderilmesi sağlanmıştır. Kabul edildiğinde ise bu izin talebi servis aracılığıyla loglanıp daha sonra kullanıcıya bildirim gönderilmesi sağlanacak şekilde tasarlanmıştır. Biz örneğimizde iznin kabul edilmesi senaryosu üzerinden ilerleyeceğiz.

User Task tamamlandıktan sonra akışımız Şekil 16’daki gibi görülmektedir.

Şimdi ise ‘Log Request’ adında tanımlamış olduğumuz Service Task tipindeki taskımıza gelmiş bulunmaktayız. Bu task bir servise içerdiği variable’lar ile istek atarak cevap dönmesi durumunda tamamlanır. Biz bağlantı kuracağımız servisi bir Spring projesi ile basit bir API üzerinden sağlayacağız.

İlk olarak Spring üzerinden projemizi oluşturup sonrasında ilgili dependency ve konfigürasyonları tanımlamamız gerekmektedir. Spring Initializr üzerinden oluşturalım.

Daha sonra seçilen Camunda ile ilgili dependency’i eklememiz gerekmektedir.

1
2
3
4
5
<dependency>
<groupId>io.camunda.spring</groupId>
<artifactId>spring-boot-starter-camunda</artifactId>
<version>8.3.1</version>
</dependency>

Dependency eklendikten sonra Spring projemizin Zeebe ile iletişime geçmesi için application.properties dosyasında ilgili bilgilerin verilmesi gerekmektedir.

1
2
3
#ZEEBE
zeebe.client.broker.gateway-address=127.0.0.1:26500
zeebe.client.security.plaintext=true*

Burada verdiğimiz gateway address bilgisi Zeebe API’nın çalışmış olduğu ip-port bilgisi olmalıdır. Projemizde bu bağlantı sayesinde Zeebe ile iletişim sağlanarak ilgili durumlarda akış yönlendirilmektedir.

Şimdi akışımızı çizerken Service Task tanımlamalarında o taska ait vermiş olduğumuz “Task Definition Type” bilgisine ihtiyacımız olmaktadır. Çizimimizde her Service Task’a özel tanımlama yapmalıyız. Bizim akışımızda iki adet Service Task bulunduğundan ikisine de bu tanımlamayı yapmalıyız.

Loglama ile ilgili kullandığımız service için ilgili tanımlamayı çizimimiz için bu şekilde yapmıştık.

Aynı şekilde bildirim için kullandığımız servis için de bu tanımlamayı yaptık.

Şimdi Spring tarafından Zeebe’nin Task Definition’ı ile hangi servise gideceğini tanımlamalıyız. Bunun için “JobWorker” anotasyonunu kullanmamız gerekmektedir. JobWorker anotasyonu sayesinde Zeebe tanımlamış olduğumuz bağlantı bilgisi ve Type Definition’ını kullanarak ilgili Service Task ile tetiklenmesi gereken servisin hangisi olduğuna karar verecektir.

Akışımız ilgili Service Task activated durumuna yani önceki aşamalar tamamlanıp loglama için kullanmış olduğumuz Service Task’ı başlattığı anda Zeebe aracılığıyla map’lemiş olduğumuz servise giderek akışı devam ettirecektir. Akış içerisinde herhangi bir hata olmadığı sürece yani servis tarafından cevap döndüğü sürece akış tamamlandı durumuna geçecektir. Aksi durumda Runtime’da oluşan hatada task “Failed” durumuna düşecek akış o aşamada sonlanacaktır.

İlgili tanımlamalardan sonra akış içerisinde loglama için kullandığımız Service Task’a geldiğimizde ayakta olan Spring uygulamamıza Zeebe tarafından istek atılır. Cevap döndükten sonra ilgili task “Completed” olarak kod içerisinde eklemiş olduğumuz veriler akışımıza setlenir ve akış bir sonraki aşamaya geçer. Zeebe daha sonra yine bildirim için kullandığımız servise ait taskı başlatarak ilişkilendirmiş olduğumuz servise istek atarak cevap bekleyecektir. Bildirim için de basit bir endpoint tanımlayarak akışımızı tamamlayalım.

İlgili istek Zeebe tarafından atılarak cevap döndükten sonra akıştaki bildirime ait olan Service Task “Completed” durumuna geçer ve akış sonlanır.

Şekil 23’te Operate ekranı üzerinde akışın tamamlandığı görülür.

Camunda 7 Nedir?

Camunda 7, BPMN 2.0 standardıyla uyumlu olarak iş süreçlerini tasarlama, uygulama ve izleme yeteneklerini sunarak daha etkili bir süreç yönetimi deneyimi sunmaktadır. Bu bağlamda, Camunda 7 dijital otomasyon konusundaki çözümleriyle öne çıkan Java ile yazılmış açık kaynaklı güçlü bir platformdur. Camunda 7 ile kodlama yapılmadan BPMN süreçleri tasarlanabilmektedir.

Spring Boot ile Camunda 7 Projesi Oluşturma ve Kurulum

• İlk olarak Camunda bağımlılıklarının olduğu Spring Boot projesi oluşturmak için start.camunda.com kullanılabilir.
• start.camunda.com da örnek olarak aşağıdaki gibi konfigürasyonlar yapılır ve generate project butonuna basılarak proje indirilir.

Camunda projesi oluştururken REST API ve WebApps seçenekleri seçilmişti. Bu seçenekler ile oluşacak olan Spring Boot projesinin pom.xml dosyasına aşağıdaki gibi iki tane bağımlılık eklenmiş oldu.

1
2
3
4
5
6
<!-- [https://mvnrepository.com/artifact/org.camunda.bpm.springboot/camunda-bpm-spring-boot-starter](https://mvnrepository.com/artifact/org.camunda.bpm.springboot/camunda-bpm-spring-boot-starter) -->
<dependency>
<groupId>org.camunda.bpm.springboot</groupId>
<artifactId>camunda-bpm-spring-boot-starter</artifactId>
<version>7.20.0</version>
</dependency>

Bu bağımlılık Camunda BPM Platform’unu Spring Boot uygulamasına sorunsuz bir şekilde entegre etmeyi sağlar. Böylece Spring Boot projesi, Camunda BPM standartlarına uygun iş süreçlerini yönetme yeteneği kazanmış oldu.

Camunda BPM Platform’u web uygulama arayüzü sağlar. Eklenen camunda-bpm-spring-boot-starter bağımlılığı ile oluşturulan Spring Boot projesi bu web uygulaması arayüzüne sahip olur.

Aşağıdaki bağımlılık ile Camunda REST API kütüphanesi de Spring Boot projesine dahil edilmiş oldu.

1
2
3
4
5
6
<!-- [https://mvnrepository.com/artifact/org.camunda.bpm.springboot/camunda-bpm-spring-boot-starter-rest](https://mvnrepository.com/artifact/org.camunda.bpm.springboot/camunda-bpm-spring-boot-starter-rest) -->
<dependency>
<groupId>org.camunda.bpm.springboot</groupId>
<artifactId>camunda-bpm-spring-boot-starter-rest</artifactId>
<version>7.20.0</version>
</dependency>

Camunda REST API, Camunda BPM Platform’unun REST API’lerini kullanmamızı sağlayan bir kütüphanedir. Camunda BPM Platform’unun iş süreçlerini ve görevlerini yönetmek için sunduğu REST API’leri ile entegrasyon sağlar. Bu sayede, Java tabanlı uygulamalar, iş süreçlerini programatik olarak yönetebilir ve platformun özelliklerini kullanabilir.

Camunda REST API’leri, iş süreçlerini başlatma, görevleri yönetme, süreç durumlarını sorgulama gibi çeşitli işlevsellikleri destekler. Kütüphane, bu tür işlemleri daha kolay ve yapılandırılabilir hale getirmektedir.

Camunda projesi oluştururken girilen Admin Username ve Admin Password alanları da, WebbApps özelliğinden gelen Cockpit, Tasklist ve Admin ekranlarına erişim için gereken bilgilerdir.

• Çıkan Admin Username ve Admin Password alanları da doldurulur. Burada bilgiler proje ayağa kalktıktan sonra Cockpit ve Tasklist ekranlarının açılmasında kullanılacaktır.
• Generate Project butonuna basılıp proje indirilir ve maven clean-install operasyonlarından sonra ayağa kaldırılır.
• Camunda web ekranını açmak için tarayıcıdan http://localhost:8080/camunda/app/welcome/default/#!/login adresine gidilir ve proje generate edilirken girilen username ve password bilgileri doldurularak Login butonuna basılır.
• Ekranda Cockpit, Tasklist ve Admin seçenekleri bulunur. Çıkan seçeneklerin ne oldukları hakkında detaylar yazının devamında yer almaktadır.

Cockpit Ekranı

Camunda BPM standartlarına bağlı olarak oluşturulmuş iş akışlarını izleme ve yönetme amacıyla tasarlanmış arayüzdür. İş süreçlerinin gerçek zamanlı olarak takip edilmesini, detaylı işlem geçmişi, görevler, hatalar ve diğer önemli bilgileri görüntüleme olanağı sağlar. Bu özelliklerden dolayı kullanıcılar, süreçlerin akışını canlı olarak izleyebilir, geçmiş olayları inceleyebilir ve performansı etkileyebilecek herhangi bir sorun olursa tespitini yapabilir.

Ayrıca, Cockpit üzerinden iş süreçlerinin konfigürasyonunu değiştirmek, görevlere müdahale etmek veya süreçleri duraklatmak gibi yönetim görevlerini gerçekleştirmek de mümkündür. Bu sayede, kullanıcılar iş süreçlerini daha etkili bir şekilde yönetebilir ve gerektiğinde hızlı kararlar alabilirler.

Aşağıdaki ekran resmi proje ilk ayağa kalkarken default olarak görünen Cockpit ekranına aittir. Bu ekranda deploy edilen iş akışları görüntülenir. İş akışının detayını görüntülemek için Key ‘e basılır.

Henüz yeni bir iş akışı deploy edilmediği için default olarak Şekil 26’teki gibi bir iş akışı görüntülenir. Bu ekranda iş akışının başlama tarihi, mikroservislere gönderilen requestler ve mikroservislerden gelen response’ler, iş akışına setlenen parametreler gibi bir çok detay görüntülenebilir.

Tasklist Ekranı

Camunda Tasklist kullanıcıların iş süreçlerini yönetmelerine başlatılan iş akışlarını izlemelerine ve görevlerle etkileşimde bulunmalarına olanak tanıyan bir ekrandır. Tasklist, kullanıcıların görev atamalarını, süreç aşamalarını ve genel süreç durumlarını görselleştirmelerine yardımcı olur. Ayrıca, kullanıcıların görevleri tamamlamak veya süreçleri yönetmek için gerekli görevleri gerçekleştirmelerine olanak tanır. Aşağıdaki ekranda da gösterildiği üzere generate edilen proje daha başlangıç aşamasında olduğu için herhangi bir görev atanmamıştır. Atanan görevler bu ekranda görüntülenip yine bu ekranda görevle ilgili aksiyon alınabilir.

Admin Ekranı

Admin ekranı Camunda BPM platformunun yönetim arayüzüdür. Sistem yöneticileri tarafından kullanılır. Admin ekranının kullanım amacı kısaca aşağıdaki gibidir.

1. Camunda’nın genel sistem yapılandırmasını yönetme
2. Veri tabanı bağlantılarını ayarlama
3. Kullanıcı hesapları oluşturma, düzenleme ve silme
4. Kullanıcı grupları oluşturma ve yetkilendirme işlemlerini yapabilme
5. BPMN standartlarına uygun süreç tanımlarını oluşturma ve düzenleme
6. Süreçlere veya iş akışlarına özel kuralları tanımlama ve parametreleri atama
7. Görevleri izleme, atama, tamamlama ve iptal işlemlerini yapma
8. Süreçlerin performansını izleme ve analiz etme
9. Sistem ve süreç hatalarını izleme ve çözme

Camunda Admin ekranı, genel olarak BPM süreçlerinin ve uygulamalarının yönetimini sağlamak için gerekli olan araçları ve özellikleri içermektedir.

Flowable Nedir?

Flowable, BPMN 2.0 standardıyla uyumlu olarak çalışan, iş süreçlerini şeffaf ve etkili bir biçimde yönetilmesini sağlayan bir platformdur. Bu platform, kullanıcılarına iş süreçlerini tasarlama, uygulama, izleme ve sürekli olarak iyileştirme yeteneği sunar. BPMN standardının gücünü kullanarak, Flowable, karmaşık iş akışlarını anlamak ve yönetmek için kullanıcı dostu bir arayüz sağlar. İş süreçlerini görsel olarak modelleme ve bu modelleri hızlı bir şekilde uygulama, değiştirme veya optimize etme yeteneği, şirketlerin dinamik iş ortamına hızla adapte olmalarına olanak tanır.

Flowable, aynı zamanda açık kaynaklı bir yapıya sahiptir, bu da kullanıcıların esneklik ve özelleştirme konusunda geniş bir serbestliğe sahip olmalarını sağlar. Ayrıca, platformun güçlü bir yetenek yelpazesi, kullanıcılarına ölçeklenebilirlik, güvenlik ve performans gibi kritik konularda güvenilir bir çözüm sunar. Bu özellikleriyle Flowable, sadece süreç yönetimine odaklanan bir platform olmanın ötesine geçerek, iş süreçlerinin tam bir yaşam döngüsünü kapsayan kapsamlı bir çözüm sunmaktadır.

Kurulum

SpringBoot projesi oluşturmak için Spring initializr sayfasına gidilip aşağıdaki bilgiler referans alınarak Spring Boot projesi oluşturulabilir. Generate butonuna basılıp proje indirilir ve IDE ile açılır.

İndirilen Spring Boot projesinin pom.xml dosyasına aşağıdaki bağımlılıklar eklenerek maven clean/install komutları çalışıtırılır.

• Aşağıdaki bağımlılık Flowable iş akış motorunun temel işleyişini içerir.

1
2
3
4
5
<dependency>
            <groupId>org.flowable</groupId>
            <artifactId>flowable-engine</artifactId>
            <version>6.8.0</version>
 </dependency>

• Aşağıdaki bağımlılık, projede Flowable BPMN motorunun kullanılabilmesini sağlar. Bu bağımlılık, Flowable’ın temel özelliklerini ve Spring Boot ile uyumlu bir şekilde çalışabilmesi için gerekli yapılandırmaları içerir. Ayrıca projeye Flowable BPMN platformu entegre edilmiş olur. Böylece iş süreçlerini modelleme, yönetme, izleme ve uygulama yeteneklerinden yararlanılabilir. İlgili bağımlılık sayesinde Spring Boot’un hızlı geliştirme ve konfigürasyon kolaylıklarıyla Flowable’ın iş süreçleri yönetimini bir araya getirerek uygulama geliştirme süreci kolaylaşır.

1
2
3
4
5
<dependency>
    <groupId>org.flowable</groupId>
    <artifactId>flowable-spring-boot-starter</artifactId>
    <version>7.0.0</version>
</dependency>

• Aşağıdaki bağımlılık, Flowable BPMN platformunun Spring Boot projeleriyle entegrasyonunu sağlar. Bu bağımlılık ile Flowable BPMN platformunun REST API’leri projeye dahil edilmiş oldu. Bu sayede Flowable BPMN ile iş süreçlerini modelleme, yönetme ve uygulama yeteneklerini içeren RESTful servisleri projede kullanılabilir.

1
2
3
4
5
<dependency>
    <groupId>org.flowable</groupId>
    <artifactId>flowable-spring-boot-starter-rest</artifactId>
    <version>7.0.0</version>
</dependency>

• Aşağıdaki bağımlılık ise flowable-spring-boot-starter-rest bağımlılığına ek olarak süreç yönetimiyle ilgili daha spesifik REST API’lerine erişim sağlar.

1
2
3
4
5
<dependency>
    <groupId>org.flowable</groupId>
    <artifactId>flowable-spring-boot-starter-process-rest</artifactId>
    <version>7.0.0</version>
</dependency>

• Opsiyonel olarak bu bağımlılık kullanılabilir. Bu Maven bağımlılığı, Flowable BPMN platformunu Spring Boot projelerine entegre ederken Actuator özelliklerinin kullanılmasını sağlar. Actuator, bir Spring Boot uygulamasının çalışma zamanındaki durumu ve davranışını gözlemlemek, yönetmek ve teşhis etmek için bir dizi hazır servis sağlar. Bu özel bağımlılık, Flowable ile birleştirildiğinde, uygulamanın çalışma zamanındaki birçok önemli bilgiye ve yönetim özelliklerine erişim sağlar. Örneğin, HTTP endpoint’ler aracılığıyla uygulama metriklerini alabilir, uygulamanın durumunu kontrol edebilir ve diğer birçok Actuator özelliği kullanılabilir.

1
2
3
4
5
<dependency>
    <groupId>org.flowable</groupId>
    <artifactId>flowable-spring-boot-starter-actuator</artifactId>
    <version>7.0.0</version>
</dependency>

• Projeye veri tabanı olarak “H2” veri tabanı kurulabilir. Böylelikle Flowable Engine’nin veri tabanında default olarak oluşturduğu tablolar görüntülenebilir. H2 veri tabanı bağımlılığı şu şekildedir:

1
2
3
4
5
<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <scope>runtime</scope>
</dependency>

Yukarıdaki bağımlılık eklendikten sonra application.properties dosyasına datasource ve h2 veri tabanı konfigürasyonları aşağıdaki gibi eklenir:

1
2
3
4
5
6
7
8
spring.datasource.username=flowable
spring.datasource.password=flowable
spring.datasource.url=jdbc:h2:~/flowable-db/db
spring.datasource.driver-class-name=org.h2.Driver

spring.h2.console.enabled=true
spring.h2.console.path=/h2-console
spring.h2.console.settings.trace=true

• src/main/resources dizinine processes diye bir dizin oluşturulur. Oluşturulan dizinin içine bpmn20.xml uzantılı bir dosya oluşturulur (örneğin deneme.bpmn20.xml). İçine bpmn2.0 formatında örnek yazılabilir. Aşağıdaki gibi basit bir örnek olabilir.

1
2
3
4
5
6
7
8
9
10
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:flowable="http://flowable.org/bpmn" targetNamespace="Examples">
    <process id="oneProcess" name="task process">
        <startEvent id="start" />
        <sequenceFlow id="flow1" sourceRef="start" targetRef="task" />
        <userTask id="task" name="sample Task" flowable:assignee="test" />
        <sequenceFlow id="flow2" sourceRef="task" targetRef="theEnd" />
        <endEvent id="theEnd" />
    </process>
</definitions>

• Böylelikle bellek içi H2 veri tabanı oluşturuldu ve Flowable’in işlem motoru yapılandırmasına iletildi. Flowable ProcessEngine, CmmnEngine, DmnEngine, FormEngine, ContentEngine ve IdmEngine Bean’leri oluşturuldu.
• Ana sınıfa aşağıdaki kodlar eklenir ve proje çalışılır hale gelmiş olur.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
@SpringBootApplication  
public class SpringFlowableIntegrationApplication {  
	public static void main(String[] args) {  
	    SpringApplication.run(SpringFlowableIntegrationApplication.class, args);  
	}
	
	@Bean  
	public CommandLineRunner init(final RepositoryService repositoryService, 
									final RuntimeService runtimeService,  
									final TaskService taskService) {
		return new CommandLineRunner() {  
	        @Override  
			public void run(String... strings) throws Exception {  
	            System.out.println("Number of process definitions : "  
					+ repositoryService.createProcessDefinitionQuery().count());  
				System.out.println("Number of tasks : " + taskService.createTaskQuery().count());  
				
				runtimeService.startProcessInstanceByKey("oneProcess");  
				
				System.out.println("Number of tasks after process start: "  
					+ taskService.createTaskQuery().count());  
			}
		};
	}  
}

• Aşağıdaki gibi bir servis sınıfı oluşturulur ve startProcess metoduna daha önce oluşturulan örnek Bpmn’nin id’si verilir.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@Service  
public class MyService {
	@Autowired  
	private RuntimeService runtimeService;  
  
	@Autowired  
	private TaskService taskService;  
  
	@Transactional  
	public void startProcess() {  
	    runtimeService.startProcessInstanceByKey("oneProcess");  
	}  
  
    @Transactional  
	public List<Task> getTasks(String assignee) {  
	    return taskService.createTaskQuery().taskAssignee(assignee).list();  
	}  
}

• Http requestlerin handle edileceği bir controller sınıfı yazılır.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
@RestController  
public class MyRestController {  
	@Autowired  
	private MyService myService;  
  
	@PostMapping(value="/process")  
    public void startProcessInstance() {  
	    myService.startProcess();  
	}  
  
    @RequestMapping(value="/tasks", method= RequestMethod.GET, produces= MediaType.APPLICATION_JSON_VALUE)  
    public List<TaskRepresentation> getTasks(@RequestParam String assignee) {  
	    List<Task> tasks = myService.getTasks(assignee);  
		List<TaskRepresentation> dtos = new ArrayList<TaskRepresentation>();  
		for (Task task : tasks)
	        dtos.add(new TaskRepresentation(task.getId(), task.getName()));
        return dtos;  
	}  
  
    static class TaskRepresentation {
	    private String id;  
		private String name;  
  
		 public TaskRepresentation(String id, String name) {  
	         this.id = id;  
			 this.name = name;  
		 }  
  
	     public String getId() { return id; }  
	     
	     public void setId(String id) { this.id = id; }  
        
	     public String getName() { return name; }  
        
	     public void setName(String name) { this.name = name; }
    }  
}

• Postman’da aşağıdaki gibi process ucuna istek atılarak, oluşturulan örnek akış başlatılmış olur.

• Test kullanıcısına ait aktif User Task’ları sorgulamak için Şekil 31’deki gibi bir request atılabilir.

• H2 veri tabanı Şekil 32’deki gibidir. Daha önce akış başlatıldığı için aktif tasklar da görüntülenebilir.

• Source kod Github repository’sinden erişilebilir.

Activiti

Flowable, Activiti’nin kaynak kodları forklanarak yani aynı veya aynı işlevi yapan fakat isimleri farklı altyapı tanımlamalarını ve bileşenlerini kullanıp üzerinde ihtiyaçları doğrultusunda kendilerinin eklediği bazı metot ve bileşenlerle ortaya çıkmış bir üründür. Temel olarak Flowable için bahsettiğimiz çoğu özellik Activiti ürünü için de geçerlidir diyebiliriz. Bunun için Spring projemiz içerisinde ilgili dependency’leri eklemeliyiz.

1
2
3
4
5
6
7
8
9
10
11
12
13
<dependency>
    <groupId>org.activiti</groupId>
    <artifactId>activiti-spring-boot-starter</artifactId>
</dependency>
<dependency>
    <groupId>org.activiti</groupId>
    <artifactId>activiti-engine</artifactId>
    <version>7.1.0.M6</version>
</dependency>
<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
</dependency>

Activiti içerisinde Flowable’de olduğu gibi uygulama ayağa kaldırılırken defaultta H2 veri tabanı kullanıyor olsa da RDBMS veri tabanları arasından herhangi biri ile bağlantı sağlanarak uygulamamız ayağa kalkarken gerekli veri tabanı yapısı Activiti Engine tarafından oluşturulur.

Örnek olarak Şekil 33’deki gibi bir akışımızın olduğunu varsayalım. Tanımlama olarak bu akışın ID’sine “categorizeHumanProcess” diyelim.

Temel olarak iki API üzerinden süreç işletilir. “TaskRuntime API” ve “ProcessRuntime API” temel API’ler bu şekildedir.

Kod tarafında bu API’ler üzerinden, akış üstünde istediğimiz şekilde süreçleri yönetebiliriz.

1
2
3
4
5
6
7
8
9
10
@Autowired
private TaskRuntime taskRuntime;

taskRuntime.create(
            TaskPayloadBuilder.create()
                .withName("First Team Task")
                .withDescription("This is something really important")
                .withGroup("activitiTeam")
                .withPriority(10)
           .build());

Örnek olarak TaskRuntime interface’si üzerinden yeni bir taskı bu şekilde create edebiliriz.

1
2
3
4
5
6
7
8
9
10
@Autowired
private ProcessRuntime processRuntime;

ProcessInstance processInstance = processRuntime
        .start(ProcessPayloadBuilder
            .start()
            .withProcessDefinitionKey("categorizeHumanProcess")
            .withProcessInstanceName("Processing Content: " + content)
            .withVariable("content", content)
            .build());

Aynı şekilde bir ProcessRuntime interface’si aracılığıyla bir akışın başlatılmasını bu şekilde sağlayabiliriz. Burada “processDefinitionKey” olarak tanımlamış olduğumuz bilgi akışımızın key’i olmalıdır.

Bu metot çağırıldıktan sonra “categorizeHumanProcess” akışı başlatılarak ilk aşama olan “Process Content” User Task’ı Activiti Engine tarafından oluşturulmuş olur. Akışın ilerlemesi için TaskRuntime API kullanılarak bu task tamamlandı durumuna çekilmelidir. Bu task tamamlandıktan sonra akış içerisinde setlenmiş veriye göre yani arada bulunan “Exclusive Gateway” sayesinde akışın hangi Service Task üzerinden ilerleyeceğine karar verilir. Daha sonra akış ilerledikten sonra ilgili Service Task TaskRuntime API aracılığıyla “complete” edilerek akış tamamlanır.

Activiti kendisi bize bu akışları yönetmek ve izlemek için bir araç sunmuyor fakat ücretli bir şekilde Alfresco şirketine ait bir arayüz ürünü mevcuttur.

SonataFlow (Kogito) Nedir?

Kogito, Java tabanlı projelerde akıllı iş süreçleri ve kurallar yönetimi sağlayan açık kaynaklı bir platformdur. İş süreçlerini modelleme, yönetme ve optimize etme ihtiyacını karşılamak amacıyla geliştirilen Kogito, özellikle mikroservis mimarilerinde ve hafif konteyner ortamlarında etkin bir şekilde çalışmaya odaklanmıştır.

Önemli Not: Kurulum yapılırken belirli aşamalardan sonra dokümanın güncel olmaması, repository’e ait olan örnek uygulamaların yetersizliği, kullanılan eklentilerin versiyon uyumsuzluğu, ilgili teknolojiyi kullanan topluluğun az olması gibi nedenlerden dolayı yapılan çalışmalar tamamlanamadı. Ayrıca kurulumlarda karşılaşılan hatalar çözülemedi.

Kogito aşağıdaki teknolojilerle uyumlu olarak çalışabilmektedir:

• OpenShift, Kubernetes tabanlı, konteynerize uygulamaları oluşturmak ve yönetmek için hedef platformdur.
• Quarkus, Kogito hizmetleriyle uygulamaları oluşturmak için kullanabileceğiniz Kubernetes için özgün bir Java yığınıdır.
• Spring Boot da Kogito ile uyumludur, böylece Spring Framework’ü Kogito ile kullanabilirsiniz.
• GraalVM ile Quarkus, Kogito ile doğal derleme kullanmanıza olanak tanır, bu da hızlı başlatma süreleri ve minimum ayak izi sağlar. Örneğin, doğal bir Kogito servisi, yaklaşık 0.003 ms’de başlar, bu da doğal olmayan bir başlangıçtan yaklaşık 100 kat daha hızlıdır. Hızlı başlatma, özellikle küçük serverless uygulamalarda ihtiyaç duyulan bir özelliktir, özellikle de bulut ekosisteminde.
• Knative, ihtiyaca göre ölçeklendirebileceğiniz Kogito ile serverless uygulamalar oluşturmanıza olanak tanır.
• Prometheus ve Grafana, isteğe bağlı uzantılarla izleme ve analiz için Kogito hizmetleriyle uyumludur.
• Infinispan ve MongoDB, Kogito’nun kalıcılık için desteklediği ara yazılım teknolojileridir.
• Kafka ve Keycloak, Kogito’nun mesajlaşma ve güvenlik için desteklediği ara yazılım teknolojileridir.

Fakat, Kogito’nun resmi dokümantasyonunda (https://docs.kogito.kie.org/1.13.0/html_single/) yer alan bilgiye göre Kogito’nun alt yapısı Quarkus ile kulanıma daha uygundur. Bu sebeple Quarkus ile kullanılması önerilmektedir. Yapılan araştırmalar sonucunda birçok Kogito kaynağının Quarkus için yazıldığı tespit edilmiştir.

Spring Boot ile Kogito Projesi Oluşturma ve Kurulum

• İlk olarak terminalde projeyi oluşturmak istediğimiz dosya yoluna gidip aşağıdaki komutları çalıştırıyoruz:

1
2
3
4
5
6
$ mvn archetype:generate \
-DarchetypeGroupId=org.kie.kogito \
-DarchetypeArtifactId=kogito-spring-boot-archetype \
-DgroupId=org.acme -DartifactId=sample-kogito \
-DarchetypeVersion=1.13.0.Final \
-Dversion=1.0-SNAPSHOT

• Bu komutlar bize Kogito extension’larını içeren bir Maven projesi oluşturacaktır.
• Ayrıca projemizde kullanım alanına ve yapacağımız BPMN modellemesine göre aşağıdaki Kogito dependency’lerini de projemize ekleyebiliriz:
  • Kogito Starter

  1
  2
  3
  4
  5
  6
    <dependencies>
    <dependency>
    <groupId>org.kie.kogito</groupId>
    <artifactId>kogito-spring-boot-starter</artifactId>
    </dependency>
    </dependencies>
  

  • Kogito Decisions Spring Boot Starter

  1
  2
  3
  4
  5
  6
    <dependencies>
    <dependency>
    <groupId>org.kie.kogito</groupId>
    <artifactId>kogito-decisions-spring-boot-starter</artifactId>
    </dependency>
    </dependencies>
  

  • Kogito Predictions Spring Boot Starter

  1
  2
  3
  4
  5
  6
    <dependencies>
    <dependency>
    <groupId>org.kie.kogito</groupId>
    <artifactId>kogito-predictions-spring-boot-starter</artifactId>
    </dependency>
    </dependencies>
  

  • Kogito Processes Spring Boot Starter

  1
  2
  3
  4
  5
  6
    <dependencies>
    <dependency>
    <groupId>org.kie.kogito</groupId>
    <artifactId>kogito-processes-spring-boot-starter</artifactId>
    </dependency>
    </dependencies>
  

  • Kogito Serverless Workflow Spring Boot Starter

  1
  2
  3
  4
  5
  6
    <dependencies>
    <dependency>
    <groupId>org.kie.kogito</groupId>
    <artifactId>kogito-serverless-workflow-spring-boot-starter</artifactId>
    </dependency>
    </dependencies>
  

  # Visual Studio Code Kogito Bundle

  Kogito ile BPMN diyagramı oluşturabileceğimiz bir arayüz kullanmak için VSCode üzerinden extension eklememiz gerekmektedir.

  Kogito VSCode Uzantısı: BPMN modellerini, DMN modellerini ve test senaryo dosyalarını Visual Studio Code’da görüntülemenizi ve tasarlamanızı sağlar. Kogito Business Modeler Hub’daki VSCode uzantısı, VSCode 1.46.0 veya daha yeni bir sürümünü gerektirir.

  Kogito Business Modeler Hub olmadan Kogito VSCode uzantısını doğrudan VSCode’a yüklemek için, VSCode’daki “Uzantılar” menü seçeneğini seçin ve “Kogito Bundle” uzantısını arayıp yükleyin.

  Kogito Bundle ile çizilmiş bazı BPMN diyagram örnekleri:

SONUÇ

Bu blog yazımızda genel olarak BPMN’nin ne olduğundan, nasıl çalıştığından ve hangi teknolojiler ile implementasyonunun yapıldığından bahsettik. Ayrıca 5 farklı BPMN teknolojisini ve onların kullanım şekillerini örnekler vererek açıkladık. Bu teknolojiler Camunda 8, Camunda 7, Flowable, Activiti ve Kogito (SonatoFlow)’dur. Yazımızın sonuç kısmında tüm bu teknolojilerin lisans ve kullanım durumlarını aşağıdaki tabloda kıyaslayacağız:

KAYNAKÇA

• https://github.com/canchito-dev/spring-flowable-integration
• https://docs.camunda.org/manual/7.20/
• https://www.flowable.com/
• https://docs.camunda.org/enterprise/announcement/
• https://docs.kogito.kie.org/1.13.0/html_single/
• https://seysane.medium.com/bpmne-giriş-part-1-d23e0167dd81
• https://camunda.com/blog/2022/05/how-open-is-camunda-platform-8/
• https://kiegroup.github.io/kogito-docs/serverlessworkflow/latest/index.html
• https://docs.kogito.kie.org/1.13.0/html_single/#con-task-console_kogito-developing-process-services
• https://camunda.com/get-started
• https://docs.camunda.io/docs/
• https://www.activiti.org/userguide/