Skip to content

Introduce Generic Batch / Task Execution Framework for Cross-Tenant Operations #128

@iumy

Description

@iumy

🔎 Background

CCMS manages customers, tenants, and environments across multiple Business Central SaaS deployments. As lifecycle operations grow more complex (e.g., update scheduling, environment preparation, upgrade orchestration), there is an increasing need for a structured way to execute:

  • Cross-tenant operations
  • Multi-step processes
  • Scheduled recurring activities
  • Controlled, logged automation

Currently, such processes must either be:

  • Implemented as isolated job queue codeunits
  • Executed manually
  • Hardcoded into specific features

This PR proposes introducing a generic Batch / Task Execution framework to provide a reusable orchestration layer within CCMS.

🎯 Objective

Introduce a lightweight, extensible task execution module that:

  • Supports scheduling via Job Queue
  • Enables multi-step task execution
  • Tracks execution state and results
  • Is environment-aware (customer / tenant / environment)
  • Is extensible via interfaces and events

Does NOT introduce breaking changes
This framework will serve as foundation for future automation scenarios (e.g., update scheduling, sandbox preparation, upgrade validation).

🏗 Proposed Architecture

The framework consists of:
1️⃣ Task Definition (metadata)
Defines reusable task types.
Example:

  • Set Environment Update Date
  • Copy Production to Sandbox
  • Schedule/Validate Environment update

2️⃣ Task Instance (execution record)
Represents one execution of a task:

  • Target Customer
  • Target Tenant
  • Target Environment
  • Status
  • Execution timestamps
  • Error message
  • Result metadata

3️⃣ Task Step (optional)
Allows multi-step workflows:

  • Prerequisite check
  • External API call
  • Validation
  • Result collection

Each step:

  • Has independent status
  • Stores execution result (JSON)
  • Enables retry handling

4️⃣ Execution Engine
A dispatcher codeunit that:

  • Loads pending tasks
  • Resolves appropriate handler
  • Executes logic via interface pattern
  • Updates status
  • Handles failure and logging

🧠 Design Principles
This module is designed to:

  • Be generic
  • Be reusable across CCMS features
  • Avoid tight coupling to specific scenarios
  • Integrate with Job Queue
  • Support idempotent task execution
  • Allow extension via interfaces

🔄 Example Future Use Cases
The following use cases could be supported:

  • Periodic update date synchronization
  • Sandbox preparation workflows
  • Major upgrade orchestration
  • Extension compliance checks
  • Cross-tenant validation routines

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions