The Rule Execution API is an upgraded version of the classic irServer Rule Execution Service. It is backward compatible and has been improved to provide a better experience for executing decisions and rules. Since the Rule Execution API is intended to replace the classic Rule Execution Service, it contains the same endpoint definitions and request attributes for ease of upgrading.
The Rule Execution API differs from the Decision API in that it gives you a complete set of runtime options allowing you to add runtime overrides, additional metadata in the response, and more. For the full description of available options and how to use them, please explore the documentation for calling the irServer - Rule Execution Service.
For existing InRule SaaS users, both the Rule Execution API and the classic Rule Execution Service will be available for a limited period to allow for transitioning over time.
Rule execution API endpoints
The Rule Execution API provides the following endpoints. Again, these are the same endpoints that exist in the classic Rule Execution Service and accept the same request body and headers. Links to example requests are provided below for each endpoint. All HTTP methods are POST.
Execute decision
/HttpService.svc/ExecuteDecision
Execute rule set
/HttpService.svc/ExecuteRuleSet
Apply rules
/HttpService.svc/ApplyRules
Execute independent rule set
/HttpService.svc/ExecuteIndependentRuleSet
Additional information describing all request attributes can be found in the article, HTTP Request Member Definitions.
Rule execution API vs. classic irServer
Additional options
When specifying the ruleEngineServiceOutputTypes on a request, the Rule Excution API now includes the option: executionStatistics.
Setting executionStatistics to TRUE will generate a summary containing statistics regarding the rule execution that will be included in the response.
Encoding/Decoding
- The Rule Execution API allows entities to be passed in as JSON objects and no longer requires encoding. IrServer required the embedded JSON data in the EntityState and InputState attributes to be encoded as a string representation when passed in as part of a request.
- Encoding is still supported on the Rule Execution API for backward compatibility. The response encoding will be determined by the request encoding.
Content types
- XML content type is no longer supported with the Rule Execution API. Please use JSON content types only for requests and responses.
Comments
0 comments
Please sign in to leave a comment.