Tarea Regla de Negocio

Una Tarea Regla de Negocio permite que el Proceso se comunique con un Motor de Reglas de Negocios. Le entrega al Motor de Reglas de Negocio los datos para que éste ejecute la Regla de Negocio y recibe los resultados.

Ejemplo: proceso sencillo. Explicación del ejemplo.

Ejemplo con Tareas Regla de Negocio.

Una Tarea Regla de Negocio permite que el Proceso se comunique, vía Mensajes, con un Motor de Reglas de Negocios.

Como las demás, Actividades, se representa con un rectángulo con esquinas redondeadas, dibujado con una línea delgada.

Una Tarea Regla de Negocio tiene la figura de una tabla de decisión en la esquina superior izquierda.

¿Qué es una Regla de Negocio?

Una regla de negocio define o condiciona algún aspecto del negocio. Por ejemplo:

• Sólo se realiza calificación crediticia a los clientes nuevos.
• Los clientes que gasten más de $1.000 en 24 horas recibirán un 10 % de descuento.
• Todo estudiante debe inscribir a lo menos 15 créditos, y a lo más 25 créditos por semestre.
• Para una compra por sobre $1.000.000 debe haber por lo menos tres oferentes.

Las reglas reglas de negocio existen en una organización, ya sea que estén documentadas o no. Sin embargo, es una buena práctica que las organizaciones expliciten sus reglas de negocio.

¿Cómo describir una Regla de Negocio?

Una regla de negocio puede ser descrita usando, entre otros:

• Lenguaje natural,
• Lógica de Predicados,
• Tablas de Decisión,
• Arboles de Decisión,
• BPMN.

¿Se puede usar BPMN para modelar reglas de negocio?

En la medida que BPMN permite describir acciones y decisiones, es posible describir cualquier regla de negocio, por complicada que ésta sea. Sin embargo, BPMN no siempre es la mejor opción, a veces hay notaciones más adecuadas y simples para describir las reglas de negocio.

La especificación de BPMN (pág. 20) dice:

BPMN is constrained to support only the concepts of modeling that are applicable to Business Processes... the following are aspects that are out of the scope of this International Standard:

• Definition of organizational models and resources,
• Modeling of functional breakdowns,
• Data and information models,
• Modeling of strategy,
• Business rules models.

La especificación no se refiere a que no sea posible describir reglas de negocio con BPMN, sino que hay notaciones especializadas para crear modelos de reglas de negocio (por ej.: Tablas de Decisión) que no son parte de BPMN.

¿Cuándo no conviene usar BPMN para describir una regla de negocio?

Hay cuatro situaciones en las que no conviene describir una regla de negocio en el diagrama BPMN:

1. Hay otra notación que permite crear, mantener y entender mejor la regla de negocio.
2. La regla de negocio ya está descrita en una forma alternativa, que los usuarios del proceso conocen y utilizan. Por ejemplo, en una guía o instructivo de trabajo.
3. La regla de negocio está sujeta a cambios frecuentes, lo que llevaría a permanentes cambios al diagrama.
4. La regla de negocio ya existe en un Motor de Reglas de Negocio.

Veamos un ejemplo.

Un banco tiene políticas sobre la aprobación de préstamos que dependen de los ingresos del solicitante y de si éste es o no empleado del banco.

• Si el ingreso es menor a $1.000 la solicitud es rechazada.
• Si el ingreso está entre $1.000 y $2.000, se aprueba sólo si el solicitante es empleado del banco.
• Si el ingreso es mayor a $2.000 la solicitud es aprobada.

IMAGEN CON DIAGRAMA BPMN CON COMPUERTAS EXCLUSICAS

Una Tabla de Decisión describe estas regla de manera simple y directa.

Ingreso	¿Es empleado?	Aceptada
ingreso < $1.000	SI/NO	NO
$1.000 ≤ ingreso ≤ $2.000	SI	SI
$1.000 ≤ ingreso ≤ $2.000	NO	NO
$2.000 < ingreso	SI/NO	SI

Si no es en el diagrama BPMN, ¿dónde colocar la regla de negocio?

Veamos tres casos.

Caso 1: La persona encargada evalúa la solicitud siguiendo una guía de instrucciones (en una copia impresa o digital). Posteriormente, el resultado de la evaluación lo ingresa al sistema.

IMAGEN CON DIAGRAMA BPMN CON TAREA MANUAL Y LUEGO UNA USUARIO

En la documentación de la Tarea Manual, el lector del diagrama puede acceder al detalle de las reglas que hay que seguir. Si la descripción de la tabla de decisión está en la guía de instrucciones, en la documetación de la Tarea Manual basta colocar un enlace a la guía en algún repositorio documental. Hay que evitar duplicidades, sobre todo si las reglas cambian con frecuencia.

Caso 2: La persona encargada evalúa la solicitud utilizando una aplicación. Normalmente, interactuando con la aplicación a través de un formulario.

IMAGEN CON DIAGRAMA BPMN CON TAREA USUARIO

En la documentación de la Tarea Usuario el lector del diagrama accede a la descripción general de la interacción y un enlace a la aplicación. En detalle de las reglas a seguir está en la documentación de la aplicación. Como siempre, hay que evitar duplicidades, sobre todo si las reglas cambian con frecuencia.

Caso 3: La regla de negocio es ejecutada por un Motor de Reglas de Negocio.

El Motor de Reglas de Negocio (BRE - Business Rules Engine) es un sistema de software que registra, define, clasifica y administra las reglas. Puede ser parte de un BPMS o ser un sistema independiente que presta un servicio a varias aplicaciones finales: BPMS, aplicaciones legadas, etc.

El proceso es ejecutado por un Motor de Procesos (BPMS). Al llegar a la Tarea Regla de Negocio, el BPMS se comunica con el BRE, le envía los datos para ejecutar la regla (identificador de la regla, ingreso y si es empleado o no), y espera la respuesta (si la solicitud es aceptada o no).

IMAGEN CON DIAGRAMA BPMN CON TAREA REGLA DE NEGOCIO

En cierto modo, la Tarea Regla de Negocio es una Tarea de Servicio especializada: el Participante que presta el servicio es un Motor de Reglas de Negocio.

Algunos BRE puede tener acceso a los datos del proceso. En este caso bastaría con enviarle la identificación de la regla, y el identificador del solicitante, y el BRE obtendría los datos reqeridos por la regla: ingreso y si es empleado o no.

En la documentación de la Tarea Regla de Negocio se entrega un enlace a la regla dentro del BRE. También se pueden enumerar los datos requeridos por la regla, y el resultado esperado.

Diseño de Procesos guiado por Reglas de Negocio

Identificar cuándo parte de la lógica del negocio debe ser una regla de negocio separada del flujo, y cuándo es parte de éste, no es trivial. Las cuatro situaciones descritas arriba ayudan a hacer la separación.

La separación del flujo del proceso, descrito con BPMN, de las reglas de negocio conduce a modelos más flexibles, robustos y evolucionables.

Normalmente, los flujo de los procesos y las reglas de negocio evolucionan por separado. Nuevas regulaciones y cambios en las políticas organizacionales conducen a cambios en las reglas de negocio, pero no en los flujos. Así mismo, puede haber cambios en los flujos actuales o incluso nuevos procesos que utilizan las mismas reglas de negocio.

Como hemos visto, la separación de las reglas de negocio no sólo aplica cuando el proceso es ejecutado por un BPMS que se comunica con un BRE que contiene las reglas, sino también para el modelado de procesos, donde las reglas de negocio son parte de Tareas Manuales y de Usuario.

Ejemplo más elaborado. Explicación del ejemplo.

Imagen ejemplo con Tareas Regla de Negocio.

Ejemplo más elaborado. Explicación del ejemplo.

Video ejemplo con Tareas Regla de Negocio.

Marcas

Como las demás Tareas, una Tarea Regla de Negocio puede ser repetitiva: Estándar a Multi-Instancia. (Ver Actividades-Iteración.)

Ejemplo con Tareas Regla de Negocio.

Como las demás Tareas, una Tarea Regla de Negocio puede ser usada para Compensación. (Ver Compensación.)

Ejemplo con Tareas Regla de Negocio.

Una Tarea Regla de Negocio puede ser una Tarea Global. (Ver Tarea Global - Reutilizable.)

Ejemplo con Tareas Regla de Negocio.

Conectores

Texto.Texto.

Conexión a Flujos de Secuencia

Texto.Texto.

Conexión a Flujos de Mensaje

Texto.Texto.

Asociación

Texto.Texto.

¿Cómo funciona?

Texto explicando los dos enfoques y con referencias a otras páginas.

Texto explicando los dos enfoques y con referencias a otras páginas.

Modelado de Procesos

Semántica de ejecución en Modelado de Procesos.

Ejecución y finalización.

• Tras la activación, ...
• Una vez realizado el trabajo, la Tarea TIPO finaliza.

Video que muestra el detalle de la ejecución de la Tarea en Modelado de Procesos.

Nombre de Video.

Documentación

Texto.Texto.

Ejecución de Procesos

Tras la activación, la Tarea solicita al BRE que ejecute la regla de negocio y espera la respuesta. Cuando ésta llega, la Tarea es completada.

Video que muestra el detalle de la ejecución de la Tarea.

Nombre de Video.

Configuraciones

Ejemplo 1.

Ejemplo con Tareas Regla de Negocio.

Ejemplo 2.

Ejemplo con Tareas Regla de Negocio.

Temas Avanzados

Tecnología para comunicarse con el BRE.

La tecnología por defecto es Web Service.

Temporal

Texto.Texto.

Texto.Texto.

Texto.Texto.

Texto.Texto.

Texto.Texto.

Texto.Texto.

Texto.Texto.

Texto.Texto.

Texto.Texto.

Texto.Texto.

Fuentes

What Is a Business Rules Engine?

A business rules engine is software that evaluates rules against data and triggers the right outcome. Simple in theory. Not always simple in practice.

Instead of hardcoding decision logic into an app, teams put those rules in a separate layer. That makes changes easier to manage, especially when rules keep shifting because of compliance, pricing, risk checks, or internal policy updates.

Rules show up everywhere. Usually in places where people want consistency but don’t want to keep checking things manually.

1. E-commerce platforms: Product recommendations based on browsing or purchase history.
2. Insurance providers: Claims checks against policy terms and coverage limits.
3. Healthcare systems: Prescription validation against medical history and current medications.
4. Banking institutions: Fraud checks based on thresholds and transaction patterns.
5. Telecommunications companies: Billing adjustments tied to usage and promo eligibility.

Advantages of Using a Rules Engine

Improved Maintainability

Externalizing rules creates a clear separation of concerns. Business logic changes don't require application code changes. The codebase stays stable while rule behavior evolves.

Enhanced Flexibility

Rules can be updated in real-time. No development cycle, no deployment window. For organizations that change business logic frequently — promotional pricing, eligibility criteria, fraud thresholds — this is a meaningful operational advantage.

Increased Agility

Business users can directly manage rules in many implementations. This removes IT from the critical path for rule changes, which matters in industries where requirements shift faster than development cycles allow.

Improved Scalability

A well-designed rule engine handles growing rule sets without degrading performance. As the number of rules increases, the architecture absorbs the complexity rather than pushing it back into the application.

Better Governance and Compliance

Centralized rule management means centralized auditing. Changes are tracked. History is preserved. Compliance requirements that demand documented decision logic are easier to satisfy when that logic lives in one place.

Implementation in Real-World Applications

Pricing and Promotions Management

E-commerce platforms use rule engines to manage product pricing, discounts, and promotional conditions based on customer segments, inventory levels, and time-based triggers. The rules change constantly; externalizing them keeps marketing teams out of the deployment queue.

Loan Approval Workflows

Financial services applications use rule engines to evaluate applicant data against predefined criteria. Conditions like credit score thresholds, debt-to-income ratios, and employment history checks are defined as rules. Regulatory changes translate to rule updates, not code changes.

Insurance Claim Processing

Claim handling logic — coverage evaluation, deductible calculations, eligibility checks — is complex and changes with policy updates. Rule engines let insurers update claim processing logic without touching the core claims system.

Content Personalization

Media and content platforms use rule engines to match users with content recommendations based on viewing history, preferences, and demographic signals. The targeting logic evolves continuously; rule engines make that evolution manageable.

What Is a Rule Engine Design Pattern?

Business logic just grows. You start with a couple of basic if statements. Six months later, it's a massive, nested mess of hardcoded thresholds. Usually, only one or two engineers even know how it works anymore (this is where things usually break).

The rules engine pattern is basically a way to rip that decision-making logic out of your core application so you can actually manage it.

Instead of baking rules into your compiled code, you keep them completely separate. An engine evaluates the rules, and the rules define the behavior. Neither messes with the other.

At its core, you just have an Evaluator. It loops through a set of rules. Each rule is nothing more than a condition and an action. If the condition matches the incoming data, it fires the action. The main app doesn't even need to know what rules exist or why.

This isn't just a refactoring trick to make your if/else chains look prettier. The rules live outside the application—usually in a database or some external config file. That means you can change them at runtime without kicking off a whole new deployment.

It comes in really handy when the same piece of data needs to trigger multiple different actions. Or when the business team wants to update the logic without begging a developer to write code.

Core pieces of Rule Engine

The parts that make up an engine are pretty standard across different languages.

First is the Engine itself. It takes the input, checks the conditions, and triggers things. Then you have the rule collection, usually pulled from a central datastore.

The input is just facts. Runtime data like user attributes, system states, or transaction amounts. That's what the rules evaluate against.

Trigger conditions decide when a rule activates. Data comparisons, timestamps, external signals, whatever. If the condition is met, the Action happens. That action might just flip a boolean flag, or it might trigger a whole downstream microservice.

Under the hood, you'll sometimes see specific services just to evaluate certain types of triggers. This keeps the logic somewhat composable. A processing engine combines all the ANDs, ORs, and NOTs to figure out if the whole rule actually passes. Once it does, execution services carry out the actual work.

Rules Engine Architecture

The architecture of a rule engine is layered. Each layer has a distinct responsibility; they communicate through defined interfaces.

Rule Repository

Where rules are stored and retrieved. Could be a relational database, a document store, a flat-file configuration, or a dedicated rule management system. The key requirement: rules must be retrievable at runtime without a deployment. If changing a rule requires a code push, the architecture isn't doing its job.

Rule Engine Core

The central orchestrator. Loads rule definitions from the repository, manages the evaluation lifecycle, and coordinates between the inference engine and execution layer. This is the piece that most implementations get wrong — it ends up taking on too many responsibilities. A clean core should be narrow: receive facts, coordinate evaluation, return results.

Inference Engine

Handles the logic evaluation. Takes the facts and the rule conditions and determines which rules match. Two evaluation strategies are common here. Forward chaining starts with the facts and works toward conclusions — standard for decision automation. Backward chaining starts with a goal and determines whether the facts support it — more common in expert systems. Most production rule engines use forward chaining.

Execution Layer

Carries out the actions for rules that have fired. Separated from inference deliberately — evaluation and execution are different concerns and fail in different ways. An evaluation error means a rule didn't match correctly. An execution error means an action failed after a valid match. Keeping these separate makes debugging significantly less painful.

API Layer

The interface through which the application interacts with the rule engine. Accepts facts as input, returns evaluation results or events. In microservice architectures, this is often a REST or gRPC endpoint. In embedded implementations, it's a library interface. The API layer is also where rule management operations are exposed — create, update, delete, version rules — for integration with admin interfaces.

Rule Engine System Design

System design for a rule engine looks different depending on where it sits in the architecture and what volume it needs to handle.

Embedded vs. standalone

An embedded rule engine runs inside the application process. Rules are loaded on startup or fetched on demand. Lower latency, simpler deployment, but the rule engine scales with the application and can't be independently managed or monitored.
A standalone rule engine runs as a separate service. The application makes calls to it via API. Higher latency per call, more deployment complexity, but the engine can scale independently, be versioned separately, and serve multiple applications. For organizations where rule logic is shared across several products, this is usually the right call.

State and persistence

Rule engines are stateless by design — each evaluation takes in facts and returns results without reference to prior evaluations. If your use case requires tracking state across evaluations (how many times a rule has fired for a given user, cumulative thresholds), that state lives outside the engine in a database or cache.

Performance considerations

Rule evaluation is generally fast for individual calls. Where it gets expensive is at scale — evaluating large rule sets against high-frequency input. Two optimizations matter here. Rete algorithm (used by Drools and similar engines) builds a network representation of the rule conditions that avoids redundant evaluation across overlapping conditions. Lazy fact loading defers fetching expensive data (external API calls, database lookups) until a rule actually needs it, rather than loading everything upfront.

Versioning

Rules change. Sometimes a rule change needs to apply immediately; sometimes it needs to be scheduled. Sometimes a bad rule update needs to be rolled back in minutes. The system design needs to account for rule versioning from the start — not retrofitted later. At minimum: rule versions should be immutable records, in-flight evaluations should complete against the version they started on, and rollback should be a first-class operation.

Rule Engine Design Pattern Example

A concrete implementation — user permissions and access control — illustrates how the pattern works in practice.

The problem. An application has multiple user roles (admin, manager, employee, customer), each with different permissions. These permissions change as the product evolves. Hardcoding them means every permission change requires a deployment.

The rule-engine approach.

Define each permission check as a rule:

// Rule definition (stored externally)
{
  "id": "rule_manager_approve",
  "conditions": {
    "all": [
      { "fact": "userRole", "operator": "equal", "value": "manager" },
      { "fact": "resourceType", "operator": "equal", "value": "purchase_order" },
      { "fact": "orderValue", "operator": "lessThanInclusive", "value": 50000 }
    ]
  },
  "event": {
    "type": "PERMISSION_GRANTED",
    "params": { "action": "approve" }
  }
}

The rule says: if the user is a manager AND the resource is a purchase order AND the order value is under $50,000, grant approval permission. Changing the threshold from $50,000 to $75,000 is a rule update. No deployment required.

Otro texto

A business rules engine is a software system that executes one or more business rules in a runtime production environment. The rules might come from legal regulation ("An employee can be fired for any reason or no reason but not for an illegal reason"), company policy ("All customers that spend more than $100 at one time will receive a 10% discount"), or other sources. A business rule system enables these company policies and other operational decisions to be defined, tested, executed and maintained separately from application code.

Rule engines typically support rules, facts, priority (score), mutual exclusion, preconditions, and other functions.

Rule engine software is commonly provided as a component of a business rule management system which, among other functions, provides the ability to: register, define, classify, and manage all the rules, verify consistency of rules definitions (”Gold-level customers are eligible for free shipping when order quantity > 10” and “maximum order quantity for Silver-level customers = 15” ), define the relationships between different rules, and relate some of these rules to IT applications that are affected or need to enforce one or more of the rules.

Many organizations' rules efforts combine aspects of what is generally considered workflow design with traditional rule design. This failure to separate the two approaches can lead to problems with the ability to re-use and control both business rules and workflows. Design approaches that avoid this quandary separate the role of business rules and workflows as follows:

• Business rules produce knowledge
• Workflows perform business work

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Texto.

Especificación BPMN

A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The InputOutputSpecification of the Task (see page 210) will allow the Process to send data to and receive data from the Business Rules Engine.

A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).

A Business Rule Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that distinguishes the shape from other Task types (as shown in Figure 10.19).

Task execution and completion. Upon activation, the associated business rule is called. On completion of the business rule, the Business Rule Task completes.

Attribute implementation. This attribute specifies the technology that will be used to implement the Business Rule Task. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol. The default technology for this task is unspecified.

solocastellano