rez_core 5.0.38 → 5.0.39

package/dist/utils/service/reflection-helper.service.d.ts

@@ -4,7 +4,7 @@ export declare class ReflectionHelper {
     private moduleRef;
     private dataSource;
     constructor(moduleRef: ModuleRef, dataSource: DataSource);
-    getRepoService(entityName: string): Repository<any> | null;
+    getRepoService(entityName: string): Repository<any>;
     getBean<T>(beanName: string): Promise<T | null>;
     getEntityData(id: number, tableName: string): Promise<any>;
 }

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

@@ -24,14 +24,14 @@ let ReflectionHelper = class ReflectionHelper {
             (meta.target && meta.target.name === entityName));
         if (!entityMetadata) {
             console.error(`Entity "${entityName}" not found in TypeORM metadata`);
-            return null;
+            throw new common_1.BadRequestException();
         }
         try {
             return this.moduleRef.get((0, typeorm_2.getRepositoryToken)(entityMetadata.target), { strict: false });
         }
         catch (error) {
             console.error(`Repository for "${entityName}" not found:`, error.message);
-            return null;
+            throw new common_1.BadRequestException();
         }
     }
     async getBean(beanName) {
@@ -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 = $1`, [id]);
         return entityList.length > 0 ? entityList[0] : null;
     }

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

@@ -1 +1 @@
-{"version":3,"file":"reflection-helper.service.js","sourceRoot":"","sources":["../../../src/utils/service/reflection-helper.service.ts"],"names":[],"mappings":";;;;;;;;;;;;AAAA,2CAA4C;AAC5C,uCAAyC;AACzC,qCAAiD;AACjD,6CAAqD;AAG9C,IAAM,gBAAgB,GAAtB,MAAM,gBAAgB;IAC3B,YACU,SAAoB,EACpB,UAAsB;QADtB,cAAS,GAAT,SAAS,CAAW;QACpB,eAAU,GAAV,UAAU,CAAY;IAEhC,CAAC;IAED,cAAc,CAAC,UAAkB;QAC/B,MAAM,cAAc,GAAQ,IAAI,CAAC,UAAU,CAAC,eAAe,CAAC,IAAI,CAC9D,CAAC,IAAI,EAAE,EAAE,CACP,IAAI,CAAC,IAAI,KAAK,UAAU;YACxB,CAAC,IAAI,CAAC,MAAM,IAAK,IAAI,CAAC,MAAc,CAAC,IAAI,KAAK,UAAU,CAAC,CAC5D,CAAC;QAEF,IAAI,CAAC,cAAc,EAAE,CAAC;YACpB,OAAO,CAAC,KAAK,CAAC,WAAW,UAAU,iCAAiC,CAAC,CAAC;YACtE,OAAO,IAAI,CAAC;QACd,CAAC;QAED,IAAI,CAAC;YACH,OAAO,IAAI,CAAC,SAAS,CAAC,GAAG,CACvB,IAAA,4BAAkB,EAAC,cAAc,CAAC,MAAM,CAAC,EACzC,EAAE,MAAM,EAAE,KAAK,EAAE,CAClB,CAAC;QACJ,CAAC;QAAC,OAAO,KAAK,EAAE,CAAC;YACf,OAAO,CAAC,KAAK,CAAC,mBAAmB,UAAU,cAAc,EAAE,KAAK,CAAC,OAAO,CAAC,CAAC;YAC1E,OAAO,IAAI,CAAC;QACd,CAAC;IACH,CAAC;IAED,KAAK,CAAC,OAAO,CAAI,QAAgB;QAC/B,IAAI,CAAC;YACH,MAAM,QAAQ,GAAG,IAAI,CAAC,SAAS,CAAC,GAAG,CAAI,QAAe,EAAE;gBACtD,MAAM,EAAE,KAAK;aACd,CAAC,CAAC;YAEH,IAAI,CAAC,QAAQ,EAAE,CAAC;gBACd,OAAO,CAAC,KAAK,CAAC,SAAS,QAAQ,2BAA2B,CAAC,CAAC;gBAC5D,OAAO,IAAI,CAAC;YACd,CAAC;YAED,OAAO,QAAQ,CAAC;QAClB,CAAC;QAAC,OAAO,KAAK,EAAE,CAAC;YACf,OAAO,CAAC,KAAK,CAAC,SAAS,QAAQ,cAAc,EAAE,KAAK,CAAC,OAAO,CAAC,CAAC;YAC9D,OAAO,IAAI,CAAC;QACd,CAAC;IACH,CAAC;IAED,KAAK,CAAC,aAAa,CAAC,EAAU,EAAE,SAAiB;QAC/C,MAAM,UAAU,GAAG,MAAM,IAAI,CAAC,UAAU,CAAC,KAAK,CAAC;2DACQ,SAAS;kEACF,EAAE,CAAC,EAAE,CAAC,CAAC,CAAC;QAEtE,OAAO,UAAU,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC;IACtD,CAAC;CACF,CAAA;AAvDY,4CAAgB;2BAAhB,gBAAgB;IAD5B,IAAA,mBAAU,GAAE;qCAGU,gBAAS;QACR,oBAAU;GAHrB,gBAAgB,CAuD5B"}
+{"version":3,"file":"reflection-helper.service.js","sourceRoot":"","sources":["../../../src/utils/service/reflection-helper.service.ts"],"names":[],"mappings":";;;;;;;;;;;;AAAA,2CAAiE;AACjE,uCAAyC;AACzC,qCAAiD;AACjD,6CAAqD;AAG9C,IAAM,gBAAgB,GAAtB,MAAM,gBAAgB;IAC3B,YACU,SAAoB,EACpB,UAAsB;QADtB,cAAS,GAAT,SAAS,CAAW;QACpB,eAAU,GAAV,UAAU,CAAY;IAEhC,CAAC;IAED,cAAc,CAAC,UAAkB;QAC/B,MAAM,cAAc,GAAQ,IAAI,CAAC,UAAU,CAAC,eAAe,CAAC,IAAI,CAC9D,CAAC,IAAI,EAAE,EAAE,CACP,IAAI,CAAC,IAAI,KAAK,UAAU;YACxB,CAAC,IAAI,CAAC,MAAM,IAAK,IAAI,CAAC,MAAc,CAAC,IAAI,KAAK,UAAU,CAAC,CAC5D,CAAC;QAEF,IAAI,CAAC,cAAc,EAAE,CAAC;YACpB,OAAO,CAAC,KAAK,CAAC,WAAW,UAAU,iCAAiC,CAAC,CAAC;YACtE,MAAM,IAAI,4BAAmB,EAAE,CAAC;QAClC,CAAC;QAED,IAAI,CAAC;YACH,OAAO,IAAI,CAAC,SAAS,CAAC,GAAG,CACvB,IAAA,4BAAkB,EAAC,cAAc,CAAC,MAAM,CAAC,EACzC,EAAE,MAAM,EAAE,KAAK,EAAE,CAClB,CAAC;QACJ,CAAC;QAAC,OAAO,KAAK,EAAE,CAAC;YACf,OAAO,CAAC,KAAK,CAAC,mBAAmB,UAAU,cAAc,EAAE,KAAK,CAAC,OAAO,CAAC,CAAC;YAC1E,MAAM,IAAI,4BAAmB,EAAE,CAAC;QAClC,CAAC;IACH,CAAC;IAED,KAAK,CAAC,OAAO,CAAI,QAAgB;QAC/B,IAAI,CAAC;YACH,MAAM,QAAQ,GAAG,IAAI,CAAC,SAAS,CAAC,GAAG,CAAI,QAAe,EAAE;gBACtD,MAAM,EAAE,KAAK;aACd,CAAC,CAAC;YAEH,IAAI,CAAC,QAAQ,EAAE,CAAC;gBACd,OAAO,CAAC,KAAK,CAAC,SAAS,QAAQ,2BAA2B,CAAC,CAAC;gBAC5D,OAAO,IAAI,CAAC;YACd,CAAC;YAED,OAAO,QAAQ,CAAC;QAClB,CAAC;QAAC,OAAO,KAAK,EAAE,CAAC;YACf,OAAO,CAAC,KAAK,CAAC,SAAS,QAAQ,cAAc,EAAE,KAAK,CAAC,OAAO,CAAC,CAAC;YAC9D,OAAO,IAAI,CAAC;QACd,CAAC;IACH,CAAC;IAED,KAAK,CAAC,aAAa,CAAC,EAAU,EAAE,SAAiB;QAC/C,MAAM,UAAU,GAAG,MAAM,IAAI,CAAC,UAAU,CAAC,KAAK,CAAC;2DACQ,SAAS;kEACF,EAAE,CAAC,EAAE,CAAC,CAAC,CAAC;QAEtE,OAAO,UAAU,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC;IACtD,CAAC;CACF,CAAA;AAvDY,4CAAgB;2BAAhB,gBAAgB;IAD5B,IAAA,mBAAU,GAAE;qCAGU,gBAAS;QACR,oBAAU;GAHrB,gBAAgB,CAuD5B"}

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**:
-    - `frm_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**:
+    - `frm_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.