Full disclosure: I work on Kogito. This is a "rethinking" of our traditional engines (Drools, jBPM, OptaPlanner) especially meant for containerized/k8s/lightweight deployment, with support for native compilation through Quarkus.
Also you may want to take a look at our fresh new editors: they are available as VSCode extension, Chrome extension and stand-alone via bpmn.new and dmn.new :)
I came across Kogito some days ago as I was looking into some alternatives for our drools based engine. I'd like to build some kind of online editor for business people to manage drm rules easily. How would one go about doing something like that with Kogito?
our online editors + a ci/cd pipeline to build Kogito services would be great. The `kogito` cli can be used to get that kind of workflow -- you can point it to a git repo with, say, a BPMN or DMN file and get a working service out of that ( well bugs aside :^) -- it's all very in flux ) take a peek here https://github.com/kiegroup/kogito-cloud-operator#deploying-...
we are updating, reorganizing and refreshing our documentation :)
This is the exact use case we have as well. We tried business central but it seemed too heavy and it was hard to develop a streamlined experience for the users so we had to drop it. Looking for a more lightweight solution. Will definitely check this out
Could you please share your reasons for looking at alternatives to Drools? I am in the process of evaluating Drools and it will be great to understand why people move away from it.
"Looking for alternatives" was maybe a bit too much. As far I understood these are built pretty much on the same core? So using the same rule sets should work on Kogito too. We recently moved to micro services and I'd like to have the editor as part of another service instead of kie workbench so I've been looking around for ways to accomplish that.
I have no experience with Java/JVM, but found OptaPlanner online and immediately had a usecase for it.
Spent a weekend trying to get through it's documentation and example code, it was so heavy and complicated that I couldn't even get a basic concept or learning exercise written by myself. Reached out on their IRC, and it was dead.
Likely a rules engine bundled with some form of business process management/modeling tool.
The rules engine is used to constrain/model the edges (transitions) of the overall graph of states within your overall business workflow finite state machine. This is generally implemented by throwing said rules engine at reams of data in the form of data validation, and inferring information from the various contexts that make up a system.
It's usually quite boring. Once you've seen a few, you've basically seen them all. The only differences boil down to the specifics of the industry, data model, and implementation of your basic frameworks.
In actual businesses there's basically maybe 4 actual software buckets that just about everything seems to end up degenerating to.
BPMA(Business Process Management/Automation, I.e. case/customer relation management, stuff related to doing business as a whole), OLTP (On-Line Transaction Processing; how you get data in), AADPETLR (Accounting, Auditing, Data Processing, Extraction, Transformation, Loading, and Reporting; what you do with all that juicy data you've collected).
All of those as I understand it may tend to end up getting combined into something called an ERP, (Enterprise Resource... Platform, I think?)
Having worked on most individual parts at one point, it's a bloody drag reimplementing the same thing over and over again in different wrappers this time. It is, however, the glue that makes basically any modern business work. The funny bit is how pretty much everyone does the same bloody thing, but bends over backwards to protect info with regards to who they are doing/sharing it with; even from their own employees.
You’ve got to update your marketing page with some examples besides a small diagram and some java class names. I had to get all the way to mentioning drools before I knew WTF Kogito did.
It really strikes me how many times new products fail to describe efficiently what they do.
It often seems they're explaining what the project/service does to someone who already knows it rather than to someone who just landed on their website.
Many Apache products lack of proper explanation, in my opinion. Some times even AWS services.
Well, it could be I'm bad at understanding their explanation.
Am I the only one thinking this?
I hope you guys at Kogito take this in a constructive way.
For instance, once you want to know more and you read "examples", as user, I want to fully understand what does it do! Instead, I find a link to https://github.com/kiegroup/kogito-examples/releases .
I have no doubt your software is amazing, I just would like you to help me understand what it does and if it suits me. :)
we will! We are currently working on making our documentation and getting started experience more accessible. We welcome constructive feedback like this :)
We have two products in market. An "old" one (that actually paid the bills for a looong time). And another, newer one that was supposed to replace the old one way to long ago as well (That didn't happen yet, but to be honest... it's complicated).
Every time I was shown what the new product does, it was a demonstration of how it works, related to the old one.
The question "what does this product provides to our customers that the old one doesn't" hasn't been answered in years.
Epilogue: Couple years back we got a beast of a sales man, and he's shoving the new product down the customers throat as if it was heroin laced candy. I'm not complaining, but would we had dedicated the dev time to the old product, we would probably be a main competitor in our market.
In case people from this project are still checking this thread. I am actually looking into Drools at this moment so the timing cannot be better...
I have a few questions:
1. Is this a new skin/interface for existing tools like Drools / jBPM or re-implementing that functionality?
1a. If new skin: is it fair to say, once the business application is built (there maybe bugs along the way due to the stage of this project), since the foundation is Drools / jBPM, we can expect production quality that we would expect out of Drools/jBPM?
2. What is the KIE Group? Is this owned by Redhat? It is very hard to tell by reading the footer.
3. Does the team provide consulting services to use these tools for an enterprise adoption?
1. it's both :) we're keeping a lot of the features in place but we are taking the chance to renew some parts and drop or redesign some
2. KIE (Knowledge Is Everything) is the collective name of the development group that works on Kogito/Drools/jBPM/OptaPlanner. It's not a legal entity so it's not technically "owned" by RH, but the majority of us work for RH
3. RH provides subscription services and consulting
26 comments
[ 2.9 ms ] story [ 83.0 ms ] threadAlso you may want to take a look at our fresh new editors: they are available as VSCode extension, Chrome extension and stand-alone via bpmn.new and dmn.new :)
we are updating, reorganizing and refreshing our documentation :)
also, yes: Kogito is still based on Drools for the rules part
I have no experience with Java/JVM, but found OptaPlanner online and immediately had a usecase for it.
Spent a weekend trying to get through it's documentation and example code, it was so heavy and complicated that I couldn't even get a basic concept or learning exercise written by myself. Reached out on their IRC, and it was dead.
Will definitely be taking a look at this!
Yes, the IRC channel is dead - I 'll remove that link from the site. StackOverflow and our google group are very much alive.
The rules engine is used to constrain/model the edges (transitions) of the overall graph of states within your overall business workflow finite state machine. This is generally implemented by throwing said rules engine at reams of data in the form of data validation, and inferring information from the various contexts that make up a system.
It's usually quite boring. Once you've seen a few, you've basically seen them all. The only differences boil down to the specifics of the industry, data model, and implementation of your basic frameworks.
In actual businesses there's basically maybe 4 actual software buckets that just about everything seems to end up degenerating to.
BPMA(Business Process Management/Automation, I.e. case/customer relation management, stuff related to doing business as a whole), OLTP (On-Line Transaction Processing; how you get data in), AADPETLR (Accounting, Auditing, Data Processing, Extraction, Transformation, Loading, and Reporting; what you do with all that juicy data you've collected).
All of those as I understand it may tend to end up getting combined into something called an ERP, (Enterprise Resource... Platform, I think?)
Having worked on most individual parts at one point, it's a bloody drag reimplementing the same thing over and over again in different wrappers this time. It is, however, the glue that makes basically any modern business work. The funny bit is how pretty much everyone does the same bloody thing, but bends over backwards to protect info with regards to who they are doing/sharing it with; even from their own employees.
BTW rules[1] is pretty good.
[1] https://github.com/jruizgit/rules
this deep dive is also a nice overview of the project (also yay I am there) https://www.youtube.com/watch?v=KBkX6v57Jbo
Well, it could be I'm bad at understanding their explanation. Am I the only one thinking this?
We have two products in market. An "old" one (that actually paid the bills for a looong time). And another, newer one that was supposed to replace the old one way to long ago as well (That didn't happen yet, but to be honest... it's complicated).
Every time I was shown what the new product does, it was a demonstration of how it works, related to the old one.
The question "what does this product provides to our customers that the old one doesn't" hasn't been answered in years.
Epilogue: Couple years back we got a beast of a sales man, and he's shoving the new product down the customers throat as if it was heroin laced candy. I'm not complaining, but would we had dedicated the dev time to the old product, we would probably be a main competitor in our market.
I have a few questions:
1. Is this a new skin/interface for existing tools like Drools / jBPM or re-implementing that functionality?
1a. If new skin: is it fair to say, once the business application is built (there maybe bugs along the way due to the stage of this project), since the foundation is Drools / jBPM, we can expect production quality that we would expect out of Drools/jBPM?
2. What is the KIE Group? Is this owned by Redhat? It is very hard to tell by reading the footer.
3. Does the team provide consulting services to use these tools for an enterprise adoption?