- We have corporate business rules developed and would like to use them for a new events project we are planning.
- We have our events project in production and would like to enhance it by adding some functionality, but these are the key business decisions and should be maintained by business users!
No matter the scenario, one can integrate business rules with business events and insights in multiple ways and there would be many factors to consider for an extensible architecture and performance enhancing. Here we would like to depict some of the technical aspects of these integrations. Rules and events naturally complement each other and when combined and provide a good mechanism for decision automation. Below are some approaches for such integration.
Using business rule data connection: With this approach, one can integrate any Decision Server Rules project from an Event designer workspace. This establishes a connection to allow the event runtime to call an existing ruleset. Multiple business objects will be created from the selected rules project and associated ruleset, which represent ruleset parameters. Once the business objects are generated by business rules data connection, Event Designer can be used to create event rules, filters and actions. At runtime, when the system recognizes a reference to a ruleset field, the rules data will be collected for all ruleset IN and IN_OUT parameters from the ruleset. The ruleset will be invoked and the ruleset parameters are loaded into the appropriate business objects that represent the out parameters. These populated fields will be used in filter execution, or action generation.
Invoking Decision Service using HTDS: This approach calls the rules service with parameters provided in Decision Server Events by using the SOAP connector. At runtime, when Decision Server Events receives an event that uses business objects with fields sourced from Decision Server Rules, a web service request will be sent to the Rule Execution Server runtime. The result of this call is then used to populate the appropriate business object fields. In this approach, it could take time after sending the request and before getting the results of a decision, which can require a significant amount of time due to network latency, but other events can still be processed in the meantime. Keep in mind, these events might be processed in an unexpected way if the processing is dependent on a pending decision from a previous event.
Using a data fetcher: This supports a single business object to supply the data for the decision logic and is used in older versions.
Using an OSGI service: This approach is used for integrating Decision Services with Decision Server Insights. An OSGI service is a service that is defined by a java interface and packaged within an OSGI bundle. This service can be called from a java agent or a rule agent to provide access to external systems or advanced computation capabilities.