Pub/Sub Processor

Event-driven processor that consumes messages from Google Cloud Pub/Sub topics and sends them to external ERP systems.

Purpose

  • Consumes messages from Google Cloud Pub/Sub topics (optional, configurable)

  • Polls comerzzia database for pending documents

  • Validates and processes entity data

  • Sends data to ERP systems via HTTP

  • Supports concurrent processing with configurable parallel pull

  • Comprehensive retry logic with DLQ support

Prerequisites

This application requires an existing Google Cloud Pub/Sub setup. It does not include topic or subscription creation.

Ensure: - Google Cloud project is configured - Required topics and subscriptions are created (main and DLQ) - Service account credentials are available

Configuration

Application Settings

See application.yml for full configuration.

Key settings: - Project ID: Google Cloud project identifier - Topic configuration: Main topic and DLQ topic - Subscription configuration: Main subscription with credentials - Processing settings: Timeouts, retries, flow control - Retry configuration: Max attempts (default: 3) - Server configuration: Server port and context path - Actuator endpoints: Monitoring dashboard, metrics and health

Important Notes

Credentials Configuration

Requires service account JSON keys in credentials/ directory for Pub/Sub authentication.

Database Configuration

Requires comerzzia database configuration via comerzzia.xml.

Pub/Sub Message Structure

Messages consumed from configured main subscription with entity metadata attributes. Failed messages (after max retries) published to DLQ topic.

Error Handling and Retry Logic

Retry Mechanism

  • First failure: Error registered in database, message republished to main topic with retry-count=1

  • Subsequent failures: Message republished with incremented retry-count

  • Max retries reached: Message sent to DLQ topic and ACKed

Message Validation

  • Entity type validation against registry

  • Message size validation (default: 10MB max)

  • Timeout protection (default: 120 seconds)

Flow Control

  • Parallel pull count: 2 concurrent message receivers

  • Max outstanding elements: 5 messages buffered

  • ACK extension period: 60 seconds max processing time per message

Processing Flow

Diagram