-
Notifications
You must be signed in to change notification settings - Fork 0
Rules and Workflow
#Rules and Business Process Automation
This couldn't be easier now - its all about calculating new state - we are going to SPIN rules expressed as discrete transforms (actually SPARQL CONSTRUCT statements) until no more new facts are inferred.
Algorithm is:
while we have expanded the data
for-each CONSTRUCT in repository
execute the CONSTRUCT statement and merge the result back into the original
Rules are here:
https://gist.github.com/johnataylor/942a0b28ddc493188ccd
and example is here:
https://gist.github.com/johnataylor/ad7d21689b79a6134402
and this is running in the service - just POST an instance and the update(s) to the eval endpoint and you'll get back the new instance. Fully worked example in the pipeline
For now we have an eval endpoint on the transformation service. The eval endpoint is similar to the merge endpoint except that it also "spins" a set of rules implemented as graph transformations (actually using SPARQL CONSTRUCT queries).
Needless to say the service doesn't understand the rules nor the data. Its all completely data driven.
In order to implement a workflow progression, take the definition (i.e. the initial instance state) from gist with a simple GET and then POST it along with the event(s) to the "eval" endpoint and you'll get back the updated instance state. Save this away somewhere and next time you have an event and need to evaluate to a new state.
Hints on cURL. use -k on windows (I don't seem to need this on my Mac) and -X for verb (GET is the default) send multiple files in MIME using -F "file=@" and use -o if you want the response dumped to a file.
Here is my test flow:
First grab the definition/initial-instance and events. Note the instance and the events are all graphs.
There are many ways to grab the data from the gist. For example, click on raw view and copy paste or cURL that URL. Note the gist raw view will be a link to the commit on that gist (gists are git repos.) You can alternatively clone the repo, if you prefer.
Now you can apply events to the instance and get back its new state:
curl -X POST -F "[email protected]" -F "[email protected]" -F "[email protected]" http://transformwebapplication.azurewebsites.net/eval/942a0b28ddc493188ccd
You probably would only be applying one event at a time. And you would probably be saving the new state of the instance in a local file. Anyhow you can apply as many events at a time as you like, it makes no difference the state will naturally progress to the right place.