rez_core 3.1.165 → 3.1.168

package/dist/utils/service/reflection-helper.service.js

@@ -51,8 +51,8 @@ let ReflectionHelper = class ReflectionHelper {
         }
     }
     async getEntityData(id, tableName) {
-        const entityList = await this.dataSource.query(`SELECT *
-                                                    FROM ${tableName}
+        const entityList = await this.dataSource.query(`SELECT *
+                                                    FROM ${tableName}
                                                     WHERE id = ?`, [id]);
         return entityList.length > 0 ? entityList[0] : null;
     }

package/docs/modules/event-driven-integration-design.md

@@ -1,92 +1,92 @@
-# Event-Driven Integration Module Design (NestJS)
-
-## 1. Goal
-Introduce **Event-Driven Architecture (EDA)** into the integration module to:
-- Decouple producers (e.g., order service, user service) from message delivery logic.
-- Support asynchronous message processing, retries, and multi-level fallback.
-- Allow smooth transition from in-memory events to external brokers like Kafka or RabbitMQ.
-
----
-
-## 2. Current State
-- **Database Tables**:
-    - `cr_integration_config` (stores provider configuration JSON and level mapping)
-- **Factory Pattern**:
-    - Uses `IntegrationFactory` to select strategies (e.g., Gmail API, Twilio SMS, WhatsApp Cloud).
-- **Service Layer**:
-    - Provides methods for sending messages (generic and type-specific).
-    - Currently invoked directly by producers.
-- **Fallback Hierarchy**:
-    - Resolution order: user → team → project → department → organization.
-
-### Limitation
-- Tight coupling between producers and `IntegrationService`.
-- Direct synchronous calls, no retry or async pipeline.
-- Fallback handled procedurally inside service.
-
----
-
-## 3. Event-Driven Proposal
-
-### Core Events
-- **IntegrationRequestedEvent** → emitted whenever any module requests integration.
-- **IntegrationSuccessEvent** → emitted when delivery succeeds.
-- **IntegrationFailedEvent** → emitted when delivery fails.
-- **FallbackRequestedEvent** → emitted when a level-specific config fails, triggering retry with the next fallback level.
-
-### Event Flow
-1. A producer (e.g., order service) emits a `IntegrationRequestedEvent`.
-2. The integration module listens for this event.
-3. Delivery attempt is made using the factory and service layer.
-4. Depending on outcome:
-    - Success → emit `IntegrationSuccessEvent`.
-    - Failure → emit `IntegrationFailedEvent`.
-5. If failure is due to invalid or unavailable provider, emit `FallbackRequestedEvent` and retry at the next level in hierarchy.
-6. Outcome events (`success`/`failed`) can be consumed by analytics, logging, monitoring, or retry queues.
-
----
-
-## 4. Components
-
-### Event Producers
-- Any module in the system (order, billing, onboarding, etc.) can raise integration requests without depending on the integration module.
-
-### Event Handlers
-- Dedicated handlers inside the integration module react to request events, coordinate with the factory and service layer, and trigger outcome events.
-
-### Subscribers
-- Separate subscribers for success/failure events handle logging, retries, notifications, and analytics.
-
----
-
-## 5. Multi-Level Fallback
-- Instead of handling fallback inside the service, use chained events.
-- When one provider fails, emit a `FallbackRequestedEvent` with the next priority level.
-- A fallback handler retries delivery using the new configuration.
-- This continues until a provider succeeds or the lowest-level configuration (organization) fails.
-
----
-
-## 6. Module Wiring
-- Use NestJS `EventEmitterModule` or `@nestjs/cqrs` for in-memory event handling.
-- Define event classes and handlers within the integration module.
-- Export the integration module to make it available across the application.
-- Future enhancement: swap in-memory event emitter with Kafka, RabbitMQ, or Redis for distributed systems.
-
----
-
-## 7. Benefits
-- **Loose coupling**: Producers only emit events, no dependency on the integration module.
-- **Resilience**: Fallback and retries managed via events rather than procedural logic.
-- **Scalability**: Easy to extend with new providers or migrate to distributed event brokers.
-- **Observability**: Success and failure events provide clear audit trails.
-- **Future-proof**: In-memory implementation today, external broker tomorrow without major refactor.
-
----
-
-## 8. Next Steps
-1. Define event classes and event bus integration.
-2. Implement core handlers for request, success, failure, and fallback.
-3. Add subscribers for logging and monitoring.
-4. Extend fallback logic into event-driven retry mechanism.
+# Event-Driven Integration Module Design (NestJS)
+
+## 1. Goal
+Introduce **Event-Driven Architecture (EDA)** into the integration module to:
+- Decouple producers (e.g., order service, user service) from message delivery logic.
+- Support asynchronous message processing, retries, and multi-level fallback.
+- Allow smooth transition from in-memory events to external brokers like Kafka or RabbitMQ.
+
+---
+
+## 2. Current State
+- **Database Tables**:
+    - `cr_integration_config` (stores provider configuration JSON and level mapping)
+- **Factory Pattern**:
+    - Uses `IntegrationFactory` to select strategies (e.g., Gmail API, Twilio SMS, WhatsApp Cloud).
+- **Service Layer**:
+    - Provides methods for sending messages (generic and type-specific).
+    - Currently invoked directly by producers.
+- **Fallback Hierarchy**:
+    - Resolution order: user → team → project → department → organization.
+
+### Limitation
+- Tight coupling between producers and `IntegrationService`.
+- Direct synchronous calls, no retry or async pipeline.
+- Fallback handled procedurally inside service.
+
+---
+
+## 3. Event-Driven Proposal
+
+### Core Events
+- **IntegrationRequestedEvent** → emitted whenever any module requests integration.
+- **IntegrationSuccessEvent** → emitted when delivery succeeds.
+- **IntegrationFailedEvent** → emitted when delivery fails.
+- **FallbackRequestedEvent** → emitted when a level-specific config fails, triggering retry with the next fallback level.
+
+### Event Flow
+1. A producer (e.g., order service) emits a `IntegrationRequestedEvent`.
+2. The integration module listens for this event.
+3. Delivery attempt is made using the factory and service layer.
+4. Depending on outcome:
+    - Success → emit `IntegrationSuccessEvent`.
+    - Failure → emit `IntegrationFailedEvent`.
+5. If failure is due to invalid or unavailable provider, emit `FallbackRequestedEvent` and retry at the next level in hierarchy.
+6. Outcome events (`success`/`failed`) can be consumed by analytics, logging, monitoring, or retry queues.
+
+---
+
+## 4. Components
+
+### Event Producers
+- Any module in the system (order, billing, onboarding, etc.) can raise integration requests without depending on the integration module.
+
+### Event Handlers
+- Dedicated handlers inside the integration module react to request events, coordinate with the factory and service layer, and trigger outcome events.
+
+### Subscribers
+- Separate subscribers for success/failure events handle logging, retries, notifications, and analytics.
+
+---
+
+## 5. Multi-Level Fallback
+- Instead of handling fallback inside the service, use chained events.
+- When one provider fails, emit a `FallbackRequestedEvent` with the next priority level.
+- A fallback handler retries delivery using the new configuration.
+- This continues until a provider succeeds or the lowest-level configuration (organization) fails.
+
+---
+
+## 6. Module Wiring
+- Use NestJS `EventEmitterModule` or `@nestjs/cqrs` for in-memory event handling.
+- Define event classes and handlers within the integration module.
+- Export the integration module to make it available across the application.
+- Future enhancement: swap in-memory event emitter with Kafka, RabbitMQ, or Redis for distributed systems.
+
+---
+
+## 7. Benefits
+- **Loose coupling**: Producers only emit events, no dependency on the integration module.
+- **Resilience**: Fallback and retries managed via events rather than procedural logic.
+- **Scalability**: Easy to extend with new providers or migrate to distributed event brokers.
+- **Observability**: Success and failure events provide clear audit trails.
+- **Future-proof**: In-memory implementation today, external broker tomorrow without major refactor.
+
+---
+
+## 8. Next Steps
+1. Define event classes and event bus integration.
+2. Implement core handlers for request, success, failure, and fallback.
+3. Add subscribers for logging and monitoring.
+4. Extend fallback logic into event-driven retry mechanism.
 5. Plan for integration with Kafka/RabbitMQ for production scalability.