Pengembangan BPM tidak mudah. Hal ini disebabkan oleh fakta bahwa proses tersebut harus dapat dibaca dan dimengerti oleh pelanggan, dan tidak hanya benar dari sudut pandang teknis.
Tidak semua alat untuk mengembangkan proses bisnis memungkinkan Anda menemukan kompromi antara deskripsi yang jelas dan fungsionalitas teknis. Banyak alat pengembangan canggih dan deskripsi proses sering memiliki satu kelemahan lagi: mereka sangat keren, kuat, dan kompleks sehingga, ketika sedang dibuat, teknologi mengambil langkah besar ke depan dan pengembangan dengan alat seperti itu menjadi tidak relevan.
2018 secara fundamental mengubah pendekatan kami pada pengembangan proses bisnis. Di bawah ini adalah tentang bagaimana pendekatan ini telah berkembang dan bagaimana kami telah berubah.
Alih-alih prolog
Departemen kami bergerak dalam pengembangan proses bisnis - dari yang terkecil dan terkecil hingga besar dan sangat menguntungkan. Hingga baru-baru ini, kami menggunakan produk dari IBM untuk pengembangan, yang memungkinkan kami untuk dengan cepat meluncurkan proses bisnis yang berjalan dalam produksi.
IBM BPM adalah platform yang kuat yang mencakup serangkaian fitur yang kaya, seperti deskripsi proses itu sendiri, formulir UI, dan modul integrasi. Selain itu, platform ini memiliki ambang masuk yang agak rendah, yang memungkinkan pengembang pemula untuk segera membenamkan diri dalam proyek. Tetapi produk ini juga memiliki kelemahan yaitu, jika mereka tidak menghambat pengembangan, maka tentunya tidak berkontribusi terhadap kecepatan dan kualitas:
- Tidak ada kontrol versi waras. IBM BPM tidak memberikan kemampuan untuk menyimpan proses (kode) dengan benar dalam repositori dan menggunakan repositori sendiri, yang tidak tahu tentang konsep seperti penggabungan, misalnya.
- Berkembang di Jawa 6. Mungkin pada saat penulisan ini, sudah dimungkinkan untuk berkembang di Jawa 7, tetapi pada tahun 2019 ini sedikit menghibur.
- IBM BPM berputar di WebSphere, sebagai akibatnya, pengembang harus bersabar dengan setiap pembaruan modul mereka. Selain itu, ini adalah sakit kepala tambahan untuk administrator yang secara berkala harus menghidupkan kembali monster ini jika hang.
- Pengembangan modul integrasi di lingkungan Designer Integrasi, yang pada kenyataannya dikaburkan bukan untuk Eclipse yang lebih baik.
- Tidak ada kemampuan pengujian unit normal.
- Tingginya biaya platform.
Kekurangan-kekurangan ini, di samping ketidaknyamanan yang murni teknis dari pembangunan, telah menciptakan masalah lain, yang mungkin jauh lebih serius daripada semua hal di atas. Pada zaman Jawa 12, Kotlin, layanan mikro, dan tren dan karya mode lainnya, semua nuansa ini sangat menurunkan motivasi tim. Sulit untuk mengalami kegembiraan berkembang di Designer Integrasi yang selalu menggantung untuk Java 6 pada tahun 2019.
Dengan semua keterbatasan ini, sulit untuk tetap bertahan. Kurang dari setahun yang lalu, ada tawaran untuk mencoba mesin Camunda untuk menggambarkan proses bisnis. Untuk memulainya, dipilih proses yang tidak terlalu besar, tetapi agak penting untuk mendaftarkan terminal untuk badan hukum.
Karena kami benar-benar menulis ulang, hampir tidak ada kode lama, kami praktis tidak dapat membatasi diri pada apa pun, dan karena itu kami memilih Kotlin sebagai bahasa pengembangan. Sangat menarik untuk mencoba bahasa baru ini, yang didengar sebagian besar untuk ulasan positif. Pada beberapa proyek lain di departemen kami ada pengalaman implementasi yang sukses. Tumpukan terakhir ternyata seperti ini: Camunda, Spring Boot 2, Kotlin, Postgre.
Apa itu Camunda?
Camunda adalah platform pemodelan proses bisnis sumber terbuka yang ditulis dalam Java dan menggunakan Java sebagai bahasa pengembangan. Ini adalah satu set perpustakaan yang memungkinkan Anda untuk melakukan proses yang dijelaskan. Untuk mengintegrasikan Camunda ke dalam proyek, cukup tambahkan beberapa dependensi. Untuk menyimpan proses, Anda dapat memilih dalam memori atau DBMS persisten - tergantung pada tugas. Kami memilih Postgre, karena cerita itu penting bagi kami untuk "pembekalan." Secara default, platform menyebarkan ke H2.
Pengembangan terdiri dari dua bagian: membuat proses aliran dalam utilitas Camunda Modeler khusus dan menulis kode java yang memproses langkah-langkah proses yang dijelaskan dalam diagram. Untuk memanggil kode java dari proses, cukup untuk mengimplementasikan antarmuka JavaDelegate, naikkan Bean ini (Anda dapat menentukan delagate dengan nama lengkap, tetapi melalui Bean lebih mudah dan fleksibel) dalam konteks dan tentukan idnya pada langkah proses yang diinginkan. Di Kotlin, delegasi terlihat lebih ringkas. Logika para delegasi cukup sederhana: mereka mengurangi sesuatu dari konteks, melakukan beberapa tindakan dan memasukkannya kembali ke dalam konteks.
Jendela sembulan Camunda ModelerContoh delegasi Java:
import org.camunda.bpm.engine.delegate.DelegateExecution; import org.camunda.bpm.engine.delegate.JavaDelegate; public class JavaExampleDelegate implements JavaDelegate { @Override public void execute(DelegateExecution execution) { String someVar = (String) execution.getVariable("someVariable");
Contoh delegasi Kotlin:
import org.camunda.bpm.engine.delegate.DelegateExecution import org.camunda.bpm.engine.delegate.JavaDelegate class KotlinExampleDelegate: JavaDelegate { override fun execute(execution: DelegateExecution) { val someVar = execution.getVariable("someVariable")
Dalam delegasi, Anda dapat menggambarkan logika bisnis, integrasi, dan segala sesuatu yang diinginkan hati Anda.
Kami mencoba membuat lapisan dalam bentuk komponen bisnis dengan logika, dan menggunakan delegasi hanya sebagai tautan ke aliran proses sehingga kode dan proses tersebut dicampur sesedikit mungkin.
Dalam kebanyakan kasus, pendekatan ini mudah digunakan dan berhasil. Interaksi dengan proses terjadi melalui DelegateExecution, yang memungkinkan, misalnya, untuk bekerja dengan konteks, insiden, dan sebagainya.
Itukah yang kami inginkan?
Pada awalnya, ketika memilih alat, kami mencari solusi dengan fitur-fitur berikut:
- Pemulihan proses tepat dari tempat di mana kegagalan terjadi, dan diharapkan bahwa itu keluar dari kotak.
- Beberapa GUI tempat Anda dapat melihat apa yang terjadi pada proses secara umum.
- Kemampuan menulis tes unit tidak hanya untuk logika dan integrasi, tetapi juga untuk proses itu sendiri.
- Java 8 ke atas.
- Komunitas maju.
Camunda baik-baik saja dengan pemulihan kesalahan dan analisis.
Jejak yang mudah dibaca, kemampuan untuk mengatur jumlah upaya untuk mengambil langkah sebelum jatuh, penangan kustom saat jatuh - misalnya, jika selama jatuh kita ingin mengubah status beberapa entitas menjadi Kesalahan. Yang terakhir ini mudah dilakukan hanya dengan mengimplementasikan DefaultIncidentHandler. Benar, ada momen lucu ketika pawang ini bekerja: kode pemulihan kesalahan dipicu setiap kali Anda memasuki langkah proses. Saya tidak bisa mengatakan bahwa ini adalah super atau masalah. Sebaliknya, Anda hanya perlu mengingat dan mempertimbangkan ini ketika berkembang.
Kami menyelesaikannya seperti ini:
override fun resolveIncident(context: IncidentContext) { val incidentList = Context.getCommandContext().incidentManager.findIncidentByConfiguration(context.configuration) if (incidentList.isNotEmpty()) {
Camunda memiliki GUI dan itu tidak buruk.
Tetapi jika Anda ingin sedikit lebih, misalnya, migrasi instance antara versi proses, maka Anda harus bekerja keras. UI default hanya memiliki fungsi minimal, tetapi ada API Rest yang sangat kuat yang memungkinkan Anda membuat panel admin Anda sendiri - keren dan canggih.
Di sepanjang jalur panel admin kami, kami pergi. Arsitek proses bisnis kami dalam waktu yang agak singkat melihatnya turun, termasuk fungsi melihat sejarah proses yang sudah selesai, migrasi antar versi, dan sebagainya.
Camunda's Rest sangat kuat dan memungkinkan Anda melakukan apa saja dengan proses. Misalnya, Anda dapat memulai proses menggunakan
/ proses-definisi / kunci / aProcessDefinitionKey / mulai dengan permintaan sederhana seperti:
{ "variables": { "aVariable" : { "value" : "aStringValue", "type": "String" }, "anotherVariable" : { "value" : true, "type": "Boolean" } }, "businessKey" : "myBusinessKey" }
Contohnya diambil dari dokumentasi resmi, yang berisi uraian luas tentang berbagai kasus penggunaan API ini.
Untuk pengujian unit, kami menggunakan Junit yang biasa. Plus ada perpustakaan yang agak menarik untuk menguji proses itu sendiri - 'org.camunda.bpm.extension', nama: 'camunda-bpm-assert'. Dengan itu, Anda dapat mendeskripsikan tes untuk memverifikasi proses aliran.
Ini cukup nyaman, karena seringkali lebih sulit untuk mencari masalah dengan bug yang mengalir daripada dalam kode. Pengujian semacam itu melindungi, misalnya, dari refactoring yang tidak akurat dan sangat membantu kami beberapa kali.
Kebutuhan untuk Java 8 sebagian telah hilang, karena penggunaan Kotlin pada banyak proses menghilangkan kebutuhan untuk G8. Kotlin sangat cocok dengan proyek dan memungkinkan Anda untuk fokus hanya pada penulisan logika bisnis. Sulit dipercaya, tetapi pada dasarnya semua yang Kotlin katakan tentang kesejukan itu benar. Entitas dengan sejumlah besar bidang, yang dikenal untuk hampir semua aplikasi dengan integrasi, sekarang tidak terlihat begitu menakutkan, dan pemetaan antar entitas menjadi jauh lebih mudah dibaca. Seringkali dikritik null safety benar-benar berfungsi dan membantu dalam banyak kasus.
Komunitas di Camunda cukup berkembang. Ini dibuktikan oleh fakta bahwa pustaka baru di GitHub terus muncul untuk pengujian dan metrik.
Sangat menyenangkan bahwa Camunda terintegrasi sempurna dengan Spring. Tambahkan dependensi yang diperlukan, beberapa anotasi dan beberapa konfigurasi kacang - pada kenyataannya, itu semua integrasi! Sebagai hasilnya, kami menulis aplikasi pegas reguler yang digunakan semua orang, menambahkan alur proses bisnis. Interaksi berlangsung melalui Java API, yang memungkinkan Anda untuk memanipulasi proses dari kode java.
Misalnya, Anda dapat memulai proses hanya dengan satu perintah:
runtimeService.startProcessInstanceByKey( "MyTestProcess", "MyBusinessKey", mapOf( "key1" to "value1", "key2" to "value2", ) )
Di sini MyTestProcess adalah Id-shnik dari proses, bukan turunannya. MyBusinessKey adalah kunci unik untuk instance proses yang sedang berjalan. Kami biasanya menggunakan beberapa nilai bisnis untuk bidang ini - untuk navigasi yang lebih cepat antara instance dan pencarian.
Dengan cara yang hampir sama, Anda dapat membangunkan proses "mengantuk".
Minus yang terlihat atau masalah apa pun yang kami temui, khususnya tidak dapat ditarik kembali. Akibatnya, untuk jangka waktu yang cukup singkat, itu ternyata menjadi proses yang sepenuhnya bekerja dan aman membawanya ke dalam produksi. Proses lain sedang dilaksanakan pada platform dan cukup berhasil. Sekarang di Camunda kami telah meluncurkan sekitar 15 aplikasi di mana sekitar 100 ribu proses berputar sekaligus.
Alih-alih sebuah epilog
Berikut adalah beberapa sumber yang telah membantu dalam mengimplementasikan tumpukan yang dijelaskan di atas. Saya sarankan Anda membacanya jika Anda tertarik dengan informasi tambahan tentang topik tersebut.