DMN Technology Compatibility Kit

[wvanderdeijl]

Have you ever looked at running the DMN tck with your library?
For more info see https://github.com/dmn-tck/tck

We are looking for a rule engine are don't really like the java route and would much prefer a JavaScript solution. Your library seems like a great fit but we would like to get a feel for how mature or feature complete the library is. Having TCK results might give some insight.

I could spend some time to see if I can run the TCK with this library, but would like to get your gut feeling for the chance of success first.

Thanks

[deostroll]

I can confidently admit the running the TCK tests will fail at present. I do not have the full understanding of TCK as of the moment. I am aware of its significance, but unsure of how to get started. I don't know who to reach out to in order to get started. Seems that information isn't available anywhere at the time I researched it many months back.

There are many reasons. Most of them stem from our poor understanding of the specification during the initial phases of this project, and, also creating something that catered more to our in-house stakeholder corpus.

What we have today just "works" for our stakeholders somehow. We welcome you to try it also.

I will highlight some problems below, but TLDR we are just not there yet today and we need your collaboration to get through this one.

Understanding the specs

The specs mainly deal with three things:

1. How to model rules? Various ways to represent decisions and logic, etc...
2. How to persist them in a suitable exchange format so that it can be shared among organizations? (XML)
3. Syntax and grammar rules for FEEL - Friendly Enough Expression Language.

Our implementation

I am sparing lengthy details of the above aspects, and I will focus on our implementation next:

1. We have not implemented the XML bits of specification. Hence with regards to rule persistence I assume some TCK tests will fail.

2. We have two different APIs - one for executing standalone decision tables, and the other for decision services. As per specification there are only "decision services". The story behind stand alone decision tables in short was inspired from DROOLS. A lot of our customers were using DROOLS hence decision tables...its only a lot later we realized about decision services.

3. We have code currently that parses excel files which have rules. Its only later I understand they are never meant to be there in the first place. (Why? Because XML!!!) (Was tempted to say "Batman", but...)

4. Don't use excel. We have a designer. Currently this is part of oe-cloud. There was a standalone designer I made, but the oe-cloud one is simply better. I will make it available if required. With regards to decision services it makes sense composing decisions visually instead of within excel workbooks. And the library we use for parsing excel workbooks is somewhat not mature at the moment. I mean there may be a better way to use those APIs but that is not the point. It is always XML, remember...

5. There are a lot of in built functions we have not implemented. There is a section inside the specs which deal with string manipulations. We don't have code to that effect. There are other functions too I can't recollect now. There are some grammar issues to we need to take care of.

6. During the initial phases, when our comprehension of specs was actually unknowingly "low", and our stakeholders were excited with what we had (decision tables). To that end we did some implementations that support oe-cloud use cases. They work extremely well. But later I realize they are non-compliant with specs.

7. For decision services, our present APIs take in a JSON representation of a decision graph. And this works quite well. Ideally this should be XML, but frankly speaking I hate having to implement XML here and wish to debate. But that is an exercise for another time.

8. And regarding the above point, the JSON representation doesn't cater to every decision element mentioned in the specs. For e.g. input nodes. In our API we pass in a payload; the engine looks into this payload and resolves variables in FEEL that reference input. But this is WRONG. Ideally the APIs should not accept a payload. The payload should be encoded in the rule document. So in a sense the rule is a self-contained document, and, the engine is also self contained. It only has to search the graph for what it needs; ideally it never has to "search the payload". Hence an ideal API should accept a rule document (XML). But...ah JSON is much better to work with...any day. We can workaround this, and still make this engine DMN compliant, but, I am as of present undecided what to do here...Similarly we have some confusion regarding knowledge sources...

So as you see...there are many issues. But we have evolved in our understanding of the specs relatively better; we realize many things need to be undone.

I am only one now maintaining this. Not in position to commit to a timeline. Would be glad if you could also pick this up, we can work together...let me know.

[wvanderdeijl]

Thank you for the very candid and honest answer. I agree with most of the points; rule authoring should be outside of the library. If people somehow want to do it in Excel or any other tool, is up to them. It shouldn't be mandated by (or included with) the engine itself.

Running TCK would mean we would have to accept the rules in DMN XML files as well as input and outputs. I agree with your sentiment that it would be much nicer if this library would stay in the JSON domain and not bother with XML. With regards of the inputs and DMN rules file we could make some sort of preprocessor that accepts XML and transform it to the JSON needed by the engine. The other way around (JSON answer back to XML output) might be more challenging but should still be do-able.

The TCK itself runs in java, but the use of java is not mandated. So we should be safe there as well. It would make for a great test suite for this library. But I understand that this library would probably need quite some love and care (and perhaps breaking changes) to confirm to the TCK.

We'll have a look if it makes sense for our project to go for this library, I feel that having TCK compliance would go a long way to convince stakeholders of the quality and maturity of this library, Without it, people might not "trust:" a library with relative few downloads. At least we now have a better understanding of the work we would have to invest in this library if we go this route.

PS. Some more information about the TCK process can be found at https://social-biz.org/2017/09/01/update-on-dmn-tck/ His blog has a number of posts on the TCK in case you're interested

[deostroll]

Thanks for sharing the link. It was informative. I feel the next order of business should be implementing the XML parts of the specification.

I am mildly shocked to know that the test cases are rather simple. They only test FEEL in-built functions, and some decision table hit policies. Perhaps "that" is the scope of tck; I am not sure. I am not the proper authority on that knowledge.

I guess its time to hit the specs again...