Incluso los usuarios experimentados de DecisionRules se preguntan a menudo: "¿Qué método debo utilizar para invocar otras soluciones de reglas desde las propias reglas: la función SOLVE integrada o una llamada a la API utilizando la funcionalidad HTTP POST?". Este artículo aclarará los casos en los que cada método resulta ventajoso.
Las solicitudes HTTP POST ofrecen un método versátil para integrar DecisionRules con sistemas externos. Este enfoque permite a cualquier aplicación capaz de recibir peticiones HTTP el interactuar con DecisionRules. Al enviar una carga útil JSON estructurada desde dentro de una regla, los usuarios pueden utilizar directamente las salidas de DecisionRules en otros sistemas suyos. Sin embargo, también puede utilizarse para realizar llamadas al solver de DecisionRules cuando se configura adecuadamente. Dicha llamada se realiza a través de la Internet pública y de regreso a DecisionRules para su resolución.
La función SOLVE, diseñada específicamente para su uso en reglas DecisionRules. Es especialmente útil para crear orquestaciones de reglas complejas en casos de uso en los que el Rule Flow podría quedarse corto. Llama internamente a otro servidor DecisionRules a través de la red troncal para resolver la regla especificada. La función permite la invocación dinámica de otras reglas, utilizando únicamente el ID de regla de destino (o Alias), los datos de entrada y un objeto de opciones opcional.
Tanto la función SOLVE como las solicitudes HTTP POST resuelven en última instancia la regla deseada y devuelven los resultados a la regla invocadora. Sin embargo, hay que tener en cuenta varias diferencias clave:
Como se ha ilustrado anteriormente, utilizar el método SOLVE() es muy fácil, mientras que conseguir que el método HTTP_POST() sea sintácticamente correcto puede ser molesto. Sin embargo, a diferencia del método SOLVE(), el método HTTP_POST() nos permite llamar a reglas situadas en Espacios diferentes al de la regla invocadora, ya que proporcionamos explícitamente a la llamada cabeceras que contienen la Clave API del Solver del Espacio de destino. Ten en cuenta que esto puede suponer un riesgo para la seguridad, ya que quizás no quieras que tus claves API sean accesibles para todo aquel que tenga acceso a tus reglas.
Otra diferencia importante es que las llamadas realizadas con el método SOLVE() sólo cuentan como una llamada a la API, ya que se considera una llamada "interna", mientras que la llamada HTTP_POST() cuenta como "externa" y, por tanto, da lugar a dos llamadas a la API. Esto es especialmente importante si te preocupa alcanzar el límite mensual de llamadas a la API.
Sobre el tema de las llamadas internas y externas, cuando tu regla se resuelve genera un Registro de Auditoría para una regla invocada a través del método SOLVE(), el correlationId de dicho Registro de Auditoría será el mismo que el de la regla invocadora. Este no es el caso del método HTTP_POST().
Además, la función SOLVE ofrece una cómoda opción de ruta, que permite a los usuarios especificar una ruta JSON para recuperar directamente una parte específica de los datos de salida. Esto puede simplificar el proceso cuando sólo se necesita un subconjunto de la salida de la regla, haciendo que la función SOLVE sea aún más eficiente y adaptada a necesidades específicas.
En casi todos los casos, es preferible utilizar el método integrado SOLVE() que el método HTTP_POST(). A menos que estés invocando reglas ubicadas en diferentes Espacios o Entornos (para soluciones On-Premise), vas a querer quedarte con el enfoque más fácil e integrado de la función SOLVE().
%20(1).svg){kind=logo}
