Executing decision services
The decision runtime enables decision services to be executed with a simple REST API.
The decision runtime comes with a set of REST API for executing decision service archives remotely in a Kubernetes server.
The following figure shows the decision runtime architecture:
A decision runtime instance is deployed as a Kubernetes pod that is based on WebSphere® Application Server Liberty. The runtime archive repository can be any HTTP-based server that is able to store files. The runtime downloads decision service archives from the runtime archive repository.
Each decision runtime instance is able to execute multiple distinct decisions. The runtime caches decisions to lower the cost of loading the decision service archives.
Loading a decision service archive into the cache is done only when the corresponding archive with the same decisionId is not already in the cache. If the decision service archive in the runtime archive repository is replaced by a newer version, but still with the exact same name, then the newer version won't be loaded for a new execution, unless the runtime cache doesn't contain the previous version anymore.
For more information about the decisionId parameter, see Calling decision services.
For more information about the runtime cache, see the decision_runtime_service.cache.config.expiry and decision_runtime_service.cache.config.resources parameters in IBM Automation Decision Services parameters.
You can deploy any number of decision runtime replicas to scale and resist infrastructure failures. It can be done because they communicate only with the runtime archive repository and do not need to communicate with each other.
Sample
A sample is provided to build a web application to execute a decision service.
New in 20.0.3 Click Automation Decision Services samples to be redirected to the GitHub repository. Check the Loan Validation application sample.
For 20.0.2 Click Sample: Loan Validation application to be redirected to the GitHub repository.