Back to ER Diagram
Integration Logging

Integration Logging System

Comprehensive documentation of the hybrid PostgreSQL + MongoDB logging architecture for external system integrations, API request tracking, and webhook delivery monitoring.

Hybrid Storage
6 PostgreSQL Tables
1 MongoDB Collection
Schema v2.3

Architecture Overview

ProKure uses a hybrid storage approach: PostgreSQL for configuration and metadata (external systems, endpoints, mappings), and MongoDB for high-volume API request/response logs. This allows transactional integrity for configuration while providing scalable, flexible storage for logs.

External API Call
integration.external_systems
integration.integration_endpoints
integration.integration_mappings
Transform Request
Execute HTTP Request
MongoDB: integration_logs
Success
Error + Retry

Why Hybrid Storage?

PostgreSQL: ACID compliance for configurations, foreign key relationships to business entities, critical for system setup.
MongoDB: Schema flexibility for varying request/response payloads, horizontal scaling for high-volume logs, TTL indexes for automatic expiration.

Storage Components

PostgreSQL Tables

  • Config integration.external_systems
  • Config integration.integration_endpoints
  • Config integration.integration_mappings
  • Summary integration.api_request_logs
  • Config integration.webhook_configurations
  • Status integration.webhook_deliveries

MongoDB Collections

  • Logs integration_logs
  • - Full request/response payloads
  • - Headers (redacted)
  • - Timing metrics
  • - Error details & stack traces
  • - 90-day TTL auto-expiration

PostgreSQL Tables

integration.external_systems

  • Configuration for external systems (SAP, Tally, Zoho, etc.)
  • Authentication credentials (encrypted)
  • Connection settings (timeout, retry, pool size)
  • OAuth token management
  • Health check status tracking

integration.integration_endpoints

  • API endpoint definitions per external system
  • Request/response schema and transformations (JSONata)
  • Rate limiting configuration
  • Retry policies per endpoint
  • Entity type mapping (VENDOR, ITEM, PO, etc.)

integration.integration_mappings

  • Maps internal codes/IDs to external system codes
  • Bidirectional sync support (INBOUND, OUTBOUND, BOTH)
  • Tracks last sync timestamp and status
  • Supports verification workflow

integration.api_request_logs (Summary)

  • Summary records for API requests (lightweight)
  • Links to MongoDB for full payload details
  • Indexed for business entity queries
  • Used for dashboard metrics and reports

MongoDB Collection: integration_logs

Collection Location

Database: prokure_logs | Collection: integration_logs
Schema file: scripts/mongodb/integration-logs-schema.js

Document Structure

Section Fields Description
Identifiers request_id, correlation_id, parent_request_id UUIDs for request tracking and correlation
System Reference system_code, endpoint_code External system and endpoint identification
Request http_method, request_url, request_headers, request_body Full request details (sensitive data redacted)
Response response_status, response_headers, response_body Complete response capture
Timing started_at, completed_at, duration_ms Performance metrics
Status status, is_success SUCCESS, FAILED, TIMEOUT, CANCELLED
Error error.type, error.message, error.stack_trace Detailed error information
Retry retry_info.attempt_number, retry_info.next_retry_at Retry chain tracking
Context context.entity_type, context.entity_id, context.operation_type Business entity reference
Actor actor.user_id, actor.triggered_by Who initiated the request

Key Indexes (20 total)

// Primary lookup
{ "request_id": 1 }                    // Unique
{ "correlation_id": 1 }

// Time-based queries
{ "started_at": -1 }
{ "system_code": 1, "started_at": -1 }

// Status queries
{ "status": 1, "started_at": -1 }
{ "is_success": 1, "started_at": -1 }

// Business context
{ "context.entity_type": 1, "context.entity_id": 1 }

// TTL index (auto-delete after 90 days)
{ "created_at": 1 }, { expireAfterSeconds: 7776000 }

Request Logging Flow

1

Pre-Request: Load Configuration

Fetch external system and endpoint configuration from PostgreSQL. Validate authentication tokens, check rate limits.

Tables Queried

  • integration.external_systems - Get connection details
  • integration.integration_endpoints - Get endpoint config
  • integration.integration_mappings - Resolve code mappings
2

Request Transformation

Apply JSONata transformations to convert internal data format to external system format. Map internal codes to external codes.

// Example: Transform PO to SAP format
{
  "request_transform": {
    "PurchaseOrder": {
      "VendorCode": $.vendor.external_code,
      "Items": $.items.{ "Material": item_code, "Qty": quantity }
    }
  }
}
3

Execute Request & Log to MongoDB

Execute HTTP request and immediately log to MongoDB with full request details. Start timing measurement.

MongoDB Document Created

  • request_id, correlation_id generated
  • Full request headers & body captured
  • status = "IN_PROGRESS"
  • started_at = current timestamp
4

Response Handling

Capture response, update MongoDB document with response details, calculate duration, determine success/failure.

// MongoDB update on response
db.integration_logs.updateOne(
  { "request_id": requestId },
  {
    $set: {
      "response_status": 201,
      "response_body": { "po_number": "4500012345" },
      "completed_at": new Date(),
      "duration_ms": 2500,
      "status": "SUCCESS",
      "is_success": true
    }
  }
);
5

Error Handling & Retry

On failure, log error details and determine if retry is needed based on endpoint retry policy.

Error Detected
Check Retry Policy
retry_count < max_retries?
Schedule Retry
Mark Failed
6

Summary to PostgreSQL (Optional)

Write summary record to PostgreSQL for dashboard queries and reports. Links to MongoDB via request_id.

integration.api_request_logs

  • Lightweight summary (no payloads)
  • Indexed by entity_type, entity_id
  • Foreign keys to business entities

Analytics & Monitoring

MongoDB aggregation queries power real-time dashboards and analytics. Views are pre-defined for common queries.

99.2%
Success Rate (24h)
847ms
Avg Latency
12,458
Requests (24h)
98
Failed (24h)

Pre-defined Views

View Name Purpose Refresh
v_failed_requests_24h Recent failed requests with error details Real-time
v_system_health Per-system success rate and latency (last hour) Real-time

Sample Aggregation: API Success Rate by System

db.integration_logs.aggregate([
  {
    $match: {
      started_at: { $gte: new Date(Date.now() - 24 * 60 * 60 * 1000) }
    }
  },
  {
    $group: {
      _id: "$system_code",
      total_requests: { $sum: 1 },
      successful: { $sum: { $cond: ["$is_success", 1, 0] } },
      avg_duration_ms: { $avg: "$duration_ms" }
    }
  },
  {
    $project: {
      system_code: "$_id",
      total_requests: 1,
      success_rate: {
        $multiply: [{ $divide: ["$successful", "$total_requests"] }, 100]
      },
      avg_duration_ms: { $round: ["$avg_duration_ms", 2] }
    }
  }
]);

Best Practices

Data Redaction

Always redact sensitive data (passwords, API keys, tokens) before logging. Use [REDACTED] placeholder in headers and body.

TTL Configuration

Default TTL is 90 days. Adjust based on compliance requirements. For audit-critical integrations, consider longer retention or archival to cold storage.

Payload Size

Large response payloads (>1MB) should be truncated. Store reference to full payload in object storage if needed for debugging.

Correlation IDs

Always propagate correlation_id across service boundaries. This enables end-to-end request tracing across microservices.