Actualog Technologies and Azure Deployment

This topic describes how Actualog is built and operated: the runtime stack, Azure deployment footprint, storage strategy, security controls, reliability practices, and AI integrations.

It is written for two audiences at once:

  • Business and ops users who want a clear explanation of “how the system works” and what to expect operationally.
  • IT and security reviewers who need concrete answers about authentication, data stores, secrets, network boundaries, observability, and service dependencies.

The goal is clarity: what components exist, what they do, and how they contribute to predictable operation.

1) What Actualog is (in practical terms)

Actualog is a Product Information Management (PIM) application designed to help manufacturing and distribution companies treat product data as a strategic asset.

In practice, that means:

  • Product information (technical, marketing, logistical) is centralized.
  • Changes are validated and often approved before being treated as canonical.
  • The platform supports multilingual content without exploding relational schemas.
  • Data can be prepared for downstream channels (e-commerce, marketplaces, partner feeds, internal systems) through controlled export and integration workflows.

2) Hosting model and Azure deployment overview

Actualog is deployed as a managed cloud application on Microsoft Azure. Azure services are used to isolate environments, scale compute, and rely on managed primitives for storage, messaging, and telemetry.

2.1 Typical Azure footprint

A common production footprint uses the following Azure building blocks:

  • Compute

    • Web application hosting (Azure App Service or equivalent)
    • Background worker hosting (hosted services and/or separate worker processes)

  • Data

    • SQL database (Azure SQL Database / SQL Server compatible)
    • Azure Storage account(s): Blob + Queue + Table

  • Messaging (optional by configuration)

    • Azure Service Bus for notifications and private messaging
    • Azure SignalR Service for real-time UI updates

  • Caching (optional by configuration)

    • Azure Cache for Redis (with safe fallback strategies)

  • Telemetry

    • Application Insights (when configured)
    • Centralized structured logging (Serilog)

  • Secrets

    • Environment-specific configuration values
    • Key Vault is a common deployment pattern (exact wiring depends on the environment setup)

Important operational behavior: several external dependencies (Redis, Service Bus, Azure SignalR, AI providers) are optional. When not configured, the application can keep core functionality online while specific subsystems remain offline.

3) Technology stack at a glance

3.1 Backend and runtime

  • .NET 10 runtime foundation for web workloads and hosted background services
  • ASP.NET Core MVC application model
  • Entity Framework Core for relational persistence
  • ASP.NET Core Identity for authentication + account lifecycle
  • Hybrid authentication: Cookies for browser sessions and JWT bearer tokens for API-style calls
  • System.Text.Json for consistent JSON serialization

3.2 Frontend

  • Bootstrap 5.3 and SB Admin 7.07 for responsive UI patterns
  • ES Modules + Webpack bundling
  • Vanilla JavaScript (ES6+) for predictable runtime behavior with a controlled dependency surface
  • A shared “common” JS foundation plus page-level bundles to avoid monolithic scripts

3.3 Platform services (as implemented)

  • Azure Table Storage for term/dictionary patterns (including multilingual term data)

  • Azure Blob Storage for assets (images, documents, generated media, uploads)

  • Lucene indexing for fast search and autocomplete experiences

  • Azure Queue Storage for background processing queues (e.g., email, indexing, uploads)

  • Azure Service Bus (optional) for notifications and private messaging

  • SignalR with a dual mode:

    • Azure SignalR when configured and reachable
    • In-process SignalR fallback when Azure SignalR is not available

4) Application architecture principles (why the codebase stays maintainable)

Actualog is organized to reduce accidental coupling and make operational behavior understandable.

4.1 Separation of concerns

  • Domain and service logic are kept out of Razor views.

  • The UI layer is split into:

    • shared layout and reusable components
    • page-level scripts for page-specific behavior

This reduces “hidden behavior” and makes reviews and debugging more direct.

4.2 Explicit contracts for complex paths

For integration-style flows and modernized endpoints, Actualog uses DTO-first patterns (Data Transfer Objects):

  • External payload shape is treated as a contract.
  • Internal persistence models can evolve without forcing breaking changes into consumers.

4.3 Incremental modernization

The platform is being modernized in controlled increments rather than disruptive rewrites:

  • Runtime upgrades and component refactors are staged
  • Backward compatibility is protected where feasible
  • Operational verification stays part of the release discipline

5) Authentication, authorization, and account lifecycle

5.1 Identity foundation

Actualog uses ASP.NET Core Identity with an EF Core store.

Security behaviors are configured explicitly, including:

  • Password policy (length, non-alphanumeric requirements)
  • Lockout behavior (failed access attempts, lockout duration)
  • Token providers for account flows (reset, confirmation, etc.)

5.2 Authentication modes

Actualog supports a hybrid authentication strategy:

  • Cookie-based authentication for the web UI
  • JWT bearer tokens for API-style calls

A policy scheme selects the correct mechanism based on the request (presence of a bearer token vs standard browser session).

5.3 SSO and external identity providers (optional)

The application supports adding external authentication providers when configured, including:

  • Microsoft identity / Entra ID (OIDC)
  • Google / Microsoft / Facebook (as optional providers, configuration-driven)

This allows enterprise environments to standardize on SSO without rewriting the account system.

5.4 Authorization boundaries

Authorization is expressed with policies and roles (examples include Admin-only access and “internal-only” style boundaries). This keeps permissions reviewable and testable.

5.5 Bot and abuse controls

For public-facing forms, Actualog can use reCAPTCHA v3 (configuration-driven) to reduce automated abuse in unauthenticated workflows.

6) Transport security, cookies, and perimeter behavior

6.1 HTTPS and HSTS

The application enforces HTTPS redirection and enables HSTS in runtime configuration (including preload and subdomain coverage settings). This reduces the chance of downgrade attacks and establishes a consistent secure transport expectation.

Cookies are governed through a centralized cookie policy:

  • Domain scoping is set intentionally (for multi-subdomain deployments)
  • Secure / SameSite / HttpOnly policies are applied consistently
  • Authentication token cookies can be configured with bounded Max-Age behavior

These controls reduce session leakage risk and clarify cross-site behavior.

6.3 CORS policy (controlled origins)

CORS is configured with environment-aware logic:

  • Development can allow broad origins for local testing
  • Production restricts origins (including optional trusted CDN hostnames)

This helps prevent unintended cross-origin usage while preserving valid CDN and subdomain scenarios.

6.4 Reverse proxy awareness

Forwarded headers are enabled so that deployments behind Azure front doors / reverse proxies correctly interpret the original client protocol and IP information.

7) Data layer: relational storage (transactional backbone)

Actualog uses a SQL database for core entities and transactional workflows.

7.1 EF Core configuration (performance + resilience)

The application configures EF Core in a production-oriented way:

  • DbContext pooling to reduce allocation overhead under load
  • No-tracking behavior where appropriate for query performance
  • Retry-on-failure for transient database faults
  • Batched command execution for throughput

This improves stability in the face of transient network or service events and supports consistent performance.

7.2 What belongs in SQL

Relational storage is used for:

  • Core entities (products, categories, companies, communities, users)
  • Governance workflows and approvals
  • Operational records and state machines
  • Audit-friendly history structures (where relational integrity matters)

8) Multilingual terms without schema inflation (flat-table term storage)

A common scaling problem in multilingual systems is “language columns everywhere.” Actualog avoids that.

8.1 Storage model

  • Entities store:

    • English (default) values where appropriate
    • Stable identifiers (GUID-like) for translatable fields

  • Localized values are stored separately in a term repository (Azure Table Storage pattern)

This keeps the relational schema stable even when the number of supported languages grows.

8.2 Resolution flow (step-by-step)

When a request needs a localized value:

  1. The entity provides the term identifier (LangID / term key).

  2. If the requested language is English, the default value can be returned immediately.

  3. For other languages:

    • Local caches are checked first
    • Then a term lookup is performed

  4. If a translation is missing, the system falls back to English.

8.3 Why this matters operationally

  • Adding languages does not require schema changes across many tables.
  • Localization work remains isolated to the term pipeline.
  • Caching keeps term resolution fast under normal traffic.

9) Blob storage: assets, documents, and ingestion artifacts

Binary content behaves differently from relational data. Actualog stores binary content in Azure Blob Storage and keeps metadata / governance state in the relational store.

9.1 Logical containers (as configured)

Actualog commonly separates blob containers by purpose, for example:

  • Assets (general binary resources)
  • Images (product and entity images)
  • Documents (PDFs, specs, manuals)
  • Temporary containers (staging for processing)
  • Data load artifacts (import-related files)

This separation supports lifecycle control, retention decisions, and operational clarity.

9.2 Access patterns

Typical blob access patterns include:

  • Upload to temporary storage for processing pipelines
  • Promotion to durable containers once validated
  • Controlled delivery via a CDN (optional) for public/static assets
  • Application-layer authorization for sensitive documents

10) Caching strategy: fast reads without correctness loss

Actualog uses a layered caching model.

10.1 Memory cache always available

In-memory cache is always enabled and provides the fastest local response for repeated reads.

10.2 Redis optional with safe fallback

Redis is supported when configured and reachable. The application can operate in modes such as:

  • Memory-only caching
  • Hybrid caching (memory + distributed cache)

This avoids hard dependency on Redis for baseline operation.

10.3 Hybrid cache behavior

Hybrid caching provides:

  • Local cache speed for hot items
  • Distributed consistency for multi-instance deployments
  • Centralized expiration and entry sizing policies

10.4 Invalidation discipline

Cache invalidation is treated as a first-class design problem:

  • Keys and tags can be systematically derived from entity identifiers
  • Updates can invalidate affected cache segments rather than wiping broad regions

The goal is consistent views without performance collapse under load.

11) Search and discovery: Lucene indexing

Actualog uses Lucene for fast search across data-heavy catalogs.

11.1 What Lucene is used for

  • Full-text search across entity projections
  • Autocomplete and suggestion experiences
  • Scoped search for domain-specific workflows

11.2 Index maintenance

Indexes require maintenance discipline:

  • Index refresh routines ensure new or updated content appears in search results
  • Health checks and maintenance services reduce drift between source-of-truth data and index projections

Operationally, search is treated as a maintained subsystem rather than a one-time feature.

12) Background processing: queues, workers, and workload isolation

Interactive web requests and long-running jobs have different latency and failure characteristics. Actualog isolates heavy work.

12.1 Azure Queue Storage usage

Azure Queue Storage is used for background tasks such as:

  • Email queueing
  • Indexing jobs
  • Upload processing jobs

These queues allow work to be retried and processed asynchronously without blocking user-facing requests.

12.2 Azure Service Bus usage (optional)

When configured, Azure Service Bus supports higher-level messaging flows such as:

  • Notifications
  • Private messaging

The application validates connectivity and can keep these workers offline if the namespace is not reachable, rather than causing application startup failure.

12.3 Hosted services

Actualog registers hosted background services, including:

  • “All workers” coordinator service
  • AI pipeline scheduler (when enabled)
  • Worker services tied to configured subsystems

This model keeps background processing operationally visible and configurable.

13) Real-time updates: SignalR (Azure or in-process)

Actualog supports real-time UI updates via SignalR.

13.1 Dual-mode configuration

  • If Azure SignalR is configured and reachable, the application uses it.
  • If not, the application can fall back to in-process SignalR transport.

This allows production-grade scale-out when needed, while preserving a minimal dependency footprint for smaller environments.

14) Observability: logs, telemetry, diagnostics

14.1 Structured request logging

Actualog uses structured request logging (Serilog) with practical noise control (e.g., downgrading overly chatty endpoints like SignalR hubs).

14.2 Application Insights (when configured)

When telemetry is enabled, the application can send:

  • dependency events (database, startup tasks)
  • request traces and metrics
  • operational signals useful for alerting and incident response

14.3 Error handling and safe failures

The request pipeline includes:

  • centralized error handling middleware
  • status-code handling behavior (including reroutes to user-friendly error pages)
  • explicit behavior differences between development and production (e.g., API explorers enabled only in development)

15) Reliability and scaling behavior

15.1 Stateless web tier (horizontal scaling)

The web application is designed to be scaled horizontally by adding instances. Shared state is pushed into:

  • SQL (transactional state)
  • distributed caches where needed (Redis)
  • storage and messaging systems for asynchronous work

15.2 Vertical scaling

Compute can be increased for known heavy operations (large imports, indexing, AI batch tasks) without requiring architectural change.

15.3 Workload separation

Long-running tasks (imports, indexing, AI workflows) are moved off the request path using queues and workers. This protects UI responsiveness under operational load.

15.4 Dependency-aware startup

Several subsystems validate configuration and connectivity at startup:

  • AI providers are validated for required credentials when enabled
  • Azure SignalR and Service Bus are probed before activation
  • Redis can fall back depending on configured cache mode

This reduces “partial broken runtime” behavior where the app starts but fails later unpredictably.

16) AI capabilities and governance boundaries

Actualog includes AI-related components as optional, configuration-driven capabilities. The implementation is designed so that AI does not bypass deterministic rules and governance workflows.

16.1 Provider model

Actualog supports multiple AI-related integrations (depending on configuration):

  • Azure OpenAI (chat and image generation endpoints)
  • Azure AI Content Safety for moderation-style checks
  • OpenAI API usage for specific tasks (e.g., translation service wiring)
  • Azure AI services for language workflows (e.g., translation, document translation, text analytics)

16.2 AI pipeline architecture (as implemented)

AI work is modeled as tasks and conversations:

  • An AI settings section controls enablement and polling behavior
  • AI tasks are stored/retrieved via repositories (including outbox patterns)
  • A scheduler/worker mechanism processes tasks asynchronously
  • Retention services manage lifecycle policies for AI-related artifacts

16.3 Governance and safety controls

AI workflows are designed to remain within platform governance:

  • AI features can be enabled/disabled per environment
  • Content safety checks can be applied where configured
  • Human review gates remain compatible with AI-assisted enrichment flows
  • Core business validations remain deterministic and enforced server-side

17) Deployment lifecycle (environment-based discipline)

Actualog is typically operated with environment separation, such as:

  • Development (fast iteration)
  • Staging / pre-production (verification)
  • Production (controlled promotion)

A practical lifecycle looks like this:

flowchart TD
  A[Design change] --> B[Implement + review]
  B --> C[Build + package]
  C --> D[Deploy to staging]
  D --> E[Verify: functional + operational]
  E --> F[Promote to production]
  F --> G[Monitor telemetry + logs]
  G --> H[Iterate]
  H --> A

Key operational behaviors that support predictability:

  • Configuration validation at startup (fail-fast where necessary)
  • Non-production verification before production promotion
  • Observability active from the moment a build is deployed
  • Subsystems can be enabled progressively by configuration

18) “IT review” checklist (quick answers)

This section summarizes questions commonly asked during security and architecture review.

18.1 Authentication and SSO

  • Web UI supports cookie authentication.
  • API-style calls support JWT bearer tokens.
  • Enterprise SSO can be enabled using OIDC (Entra ID / Azure AD pattern).

18.2 Data stores

  • SQL database for transactional domain entities and workflows.
  • Azure Table Storage for term/dictionary patterns (including multilingual terms).
  • Azure Blob Storage for binary assets and ingestion artifacts.
  • Lucene indexes for search projections.

18.3 Encryption and transport

  • HTTPS is enforced; HSTS is enabled.
  • Azure managed services commonly provide encryption at rest as a platform feature (exact posture depends on the Azure resource configuration).

18.4 Network boundaries

  • CORS policy restricts allowed origins in production scenarios.
  • Forwarded headers support deployment behind reverse proxies and managed ingress.

18.5 Operations and auditability

  • Structured logging via Serilog.
  • Application Insights telemetry can be enabled.
  • Background queues provide traceable processing for uploads/indexing/email.
  • Security-relevant actions can be tracked via audit-style subsystems (where configured in the application features).

18.6 Optional dependencies and graceful degradation

  • Redis is optional (memory-only cache mode available).
  • Azure SignalR is optional (in-process fallback).
  • Service Bus messaging is optional (subsystems can remain offline if not configured).
  • AI providers are optional (disabled unless configured and enabled).