rest - How to manipulate guided decision table from Java API in Drools?

Question

I have requirement in my project where I need to manipulate Drools guided decision table content (just data not structure) from a custom web based UI.

I have searched a lot but I'm not able to find any Java or REST API in Drools which gives access to guided decision table.

Any help would be appreciated.

Answer 1

I'm assuming you are talking about guided decision tables in the kie-workbench.

As far as I know, there is no public API to manipulate a guided decision table, but there is another thing you can do. Each project in the kie-workbench is in reality a maven project persisted in a local git repository. The good news is that you can actually make a clone of that repository.

Once you have a local clone of your project, you can locate the guided decision table you want to modify as a file with .gdst extension.

For example, this is the directory structure of the uf-playground sample project coming with the kie-workbench:

In the screenshot above you can see a Pricing loans.gdst file. The content of this file is an xml containing both, the structure and the data of the "Pricing loans" guided decision table.

And here is where things get interesting. If you dig deep down into the kie-workbench code, I'm sure you will find some kind of undocumented and very volatile API to handle these .gdst files. After all, the kie-workbench is actually creating and modifying these files. The challenge here are:

1. Find this API
2. Understand this API

Another solution that, from the technical point of view may not be the best, - but that is easier to implement for simple things such as data manipulation - is to parse and modify those .gdst files using an XML library.

Once you are done with the changes you can push them back to the kie-workbench and they will be available for the GUI users.

Of course none of these 2 proposed solutions are ideal. Using an undocumented API that was not meant to be used by third parties and that will certainly change in the future may not sound like a good idea. But manually parsing an XML file whose semantic may probably change on different versions of the kie-workbench also presents some challenges.

Hope it helps,