Rule Execution API

  • Updated

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.

Was this article helpful?

0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.