⚡ D365FO cambia los tiers por AOS elásticos calculados con PPR

En los nuevos entornos unificados de Finance and Operations ya no elegimos un Tier 2, 3, 4 o 5. Microsoft ha documentado un modelo de elastic compute en el que producción y sandbox parten de una topología intermedia y escalan horizontalmente según la carga, hasta un límite calculado con los Power Platform Requests (PPR) del tenant.

El cambio no es solo administrativo. Modifica cómo dimensionamos una implantación, cómo interpretamos una prueba de rendimiento y qué compramos cuando necesitamos más capacidad. Además, el 10 de septiembre de 2026 Microsoft añadió una consulta PowerShell oficial para leer el entitlement del tenant mediante Power Platform API y traducirlo a AOS.

La precisión sobre disponibilidad es importante: este modelo aplica a entornos unificados administrados sin huella de LCS. A 13 de septiembre de 2026, Microsoft todavía identifica las plantillas ERP de Finance y Supply Chain Management como preview. No debemos trasladar estas reglas a un entorno heredado de LCS ni presentar la experiencia unificada como GA universal.

Qué cambia frente a LCS

AspectoEntornos LCSEntornos unificados
Unidad de capacidadTier contratado por entornoPool de PPR del tenant
Producción y sandboxTopologías diferentesMismo modelo y mismo techo de escala
Aumentar capacidadCambio contractual o soporteAumentar entitlement de PPR
Scale-outAsociado al tierAutomático según demanda
Límite publicado3–12 AOS según tierHasta 80 AOS: 40 interactivos y 40 batch
Crear entornosSlots contratadosCondicionado principalmente por almacenamiento

Esto complementa, y concreta técnicamente, la unificación de administración de F&O y Power Platform. No significa que todos los entornos reciban 80 AOS ni que comprar PPR reserve servidores permanentemente. Los PPR definen el techo de capacidad que el servicio puede utilizar al escalar.

Arquitectura de elastic compute para entornos unificados de D365FO.

Diagrama original. Los PPR fijan el techo; la telemetría de carga determina cuándo escala el entorno.

Arquitectura: AOS stateful y dos velocidades de escala

El Application Object Server sigue ejecutando la lógica X++, las sesiones de usuario, servicios OData y personalizados, integraciones y procesos batch. Microsoft confirma que los AOS mantienen estado de sesión en memoria y que un balanceador interno conserva afinidad de sesión.

Esa característica explica la asimetría del modelo:

  1. Scale-up sin parada. Si suben las sesiones concurrentes, el tráfico API, el batch o las llamadas desde tablas virtuales, la plataforma puede añadir AOS y repartir carga sin desconectar usuarios.
  2. Scale-down durante mantenimiento. Retirar un AOS exige drenar sesiones. Por eso el servicio reduce la topología durante una ventana de mantenimiento o un despliegue de personalizaciones, cuando ya existe una interrupción planificada.
  3. Vuelta al baseline. El entorno vuelve a su topología intermedia, no a un mínimo dinámico. Microsoft no publica el número exacto de AOS de ese baseline ni los umbrales del autoscaler.

Los datos persistentes permanecen fuera de los AOS, en Azure SQL, cachés y almacenamiento de blobs. El aumento es horizontal: no debemos asumir que un único proceso X++ lento se acelera por disponer de más AOS.

La fórmula de capacidad

Microsoft publica una equivalencia directa:

AOS calculados = floor(PPR concedidos / 650.000)
AOS permitidos = max(2, min(80, AOS calculados))

Cada tenant acumula PPR mediante:

  • una base de 500.000 PPR incluida con una compra de Dynamics 365;
  • 5.000 PPR por licencia de usuario asignada;
  • paquetes adicionales de 50.000 PPR.

También aportan PPR licencias de Power Apps Premium, aplicaciones Dynamics 365 Customer Engagement y Finance and Operations. Todo se acumula en un pool único del tenant que utilizan Power Platform, Dataverse y F&O.

Ejemplos con la base y licencias, sin add-ons:

LicenciasPPRCálculoTecho
20600.000floor(600.000 / 650.000)2 AOS por mínimo
1001.000.000floor(1.000.000 / 650.000)2 AOS por mínimo
5003.000.000floor(3.000.000 / 650.000)4 AOS
1.0005.500.000floor(5.500.000 / 650.000)8 AOS

El máximo técnico publicado, 80 AOS, equivale a 52 millones de PPR. Se divide en hasta 40 AOS interactivos y 40 procesadores batch. Microsoft no documenta que podamos asignar manualmente el reparto ni reservar una cantidad concreta para un entorno.

Consultar el entitlement del tenant

La documentación utiliza GET /licensing/tenantCapacity de Power Platform API, versión 2024-10-01. El tipo de capacidad que representa PPR es ApiCallCount.

1. Preparar la identidad

  1. Registra una aplicación de un solo tenant en Microsoft Entra.
  2. Añade Power Platform API usando el identificador oficial 8578e004-a5c6-46e7-913e-12f58912df43.
  3. Configura el permiso mínimo de lectura necesario y el consentimiento definido por vuestra política.
  4. Para el ejemplo interactivo, configura el redirect URI de aplicación móvil/escritorio.
  5. Aplica Conditional Access y limita quién puede ejecutar la consulta.

La guía de autenticación diferencia permisos delegados para llamadas con usuario y RBAC para un service principal. El ejemplo de Microsoft usa inicio interactivo; no copies ese patrón a una automatización desatendida con secretos incrustados.

2. Leer PPR y calcular AOS

Este ejemplo reducido mantiene el cálculo separado de la llamada para que pueda probarse sin acceso al tenant:

#Requires -Modules MSAL.PS

$TenantId = '<tenant-id>'
$ClientId = '<application-client-id>'
$ApiBase  = 'https://api.powerplatform.com'

$token = Get-MsalToken `
    -TenantId $TenantId `
    -ClientId $ClientId `
    -Scope "$ApiBase/.default" `
    -Interactive

$headers = @{ Authorization = "Bearer $($token.AccessToken)" }
$uri = "$ApiBase/licensing/tenantCapacity?api-version=2024-10-01"
$capacity = Invoke-RestMethod -Method Get -Uri $uri -Headers $headers

$pprCapacity = $capacity.tenantCapacities |
    Where-Object capacityType -eq 'ApiCallCount' |
    Select-Object -First 1

if (-not $pprCapacity) {
    throw 'El tenant no devuelve capacidad ApiCallCount.'
}

$ppr = [double]$pprCapacity.totalCapacity
$aos = [math]::Floor($ppr / 650000)
$aos = [math]::Max(2, [math]::Min(80, $aos))
$next = if ($aos -lt 80) { (($aos + 1) * 650000) - $ppr } else { 0 }

[pscustomobject]@{
    PPRConcedidos = $ppr
    TechoAOS      = $aos
    PPRHastaSiguienteAOS = [math]::Max(0, $next)
}

Revisa también capacityEntitlements para saber qué licencias forman el total. No uses maxCapacity de la respuesta como si fuera el límite de AOS: Microsoft corrigió expresamente ese supuesto y fija el máximo de plataforma en 80.

PPR tiene dos efectos distintos

Los PPR cumplen dos funciones relacionadas, pero independientes:

  • entitlement de compute: determina hasta cuántos AOS puede escalar F&O;
  • límite de solicitudes: gobierna throttling de operaciones de Power Platform, como llamadas Dataverse, plug-ins y flows.

Comprar más PPR eleva ambos límites, pero una cifra alta de PPR no elimina un mal diseño de integración. Las tablas virtuales pueden generar carga que dispare scale-up y, simultáneamente, consumir solicitudes sujetas a throttling. Debemos medir ambos planos.

Requisitos y excepciones

El modelo publicado distingue tres tipos:

TipoUsoElastic compute
UPEProducciónHasta 80 AOS
USEUAT, staging, formaciónHasta 80 AOS
UDEDesarrollo X++ individualUn AOS fijo

UDE no escala porque el depurador de Visual Studio debe adjuntarse a un proceso AOS concreto. No es válido para pruebas de rendimiento o desarrollo multiusuario. Además, una USE no puede convertirse en UDE ni al revés.

La disponibilidad depende de la región de Azure. Europa Norte y Europa Oeste admiten UPE, USE y UDE, pero otras ubicaciones secundarias solo admiten UDE y trial. Antes de provisionar, revisa la tabla oficial; Microsoft advierte que la validación preventiva de todas las regiones aún está en desarrollo.

Cómo cambia una prueba de rendimiento

Que sandbox y producción compartan modelo y techo elimina una diferencia histórica, pero no convierte cualquier prueba en representativa. Un plan mínimo debería:

  1. usar USE, nunca UDE;
  2. registrar versión, PQU, personalizaciones y datos;
  3. generar por separado carga interactiva, API y batch;
  4. observar latencia, throttling, SQL, batch y número de sesiones;
  5. repetir después de una ventana de mantenimiento para evaluar el baseline;
  6. probar el crecimiento gradual y también los picos;
  7. documentar los PPR concedidos en el momento de la prueba.

No podemos controlar cuándo escala ni consultar en la documentación pública todos los umbrales internos. Por tanto, el resultado válido es el comportamiento extremo a extremo observado, no una inferencia basada únicamente en el techo matemático.

Seguridad y gobierno

  • Protege la aplicación que consulta capacidad con mínimo privilegio y Conditional Access.
  • Para automatizaciones, usa certificado o identidad segura; no guardes secretos en scripts o repositorios.
  • Trata el detalle de licencias y capacidad como información administrativa del tenant.
  • Separa monitorización de capacidad, consumo de solicitudes y rendimiento F&O: son indicadores diferentes.
  • Establece alertas antes de llegar al techo y un proceso de compra aprobado; el autoscaler no puede superar el entitlement.
  • Revisa el pool tras altas, bajas y cambios de licencias, porque la capacidad no depende únicamente de usuarios F&O.

Límites que Microsoft no publica

  • número exacto de AOS del baseline inicial;
  • métricas y umbrales concretos que activan scale-up;
  • tiempo garantizado para añadir capacidad;
  • algoritmo de reparto cuando varios entornos demandan capacidad a la vez;
  • reserva manual de AOS por entorno;
  • precio del add-on, que depende del acuerdo comercial y debe confirmarse en el tenant;
  • SLA específico de elasticidad separado del SLA del servicio.

No rellenemos esos huecos con reglas heredadas de los tiers de LCS. Si un proyecto necesita una garantía concreta, debe validarse contractualmente con Microsoft.

Recomendación práctica

Incluye la consulta de PPR en el assessment técnico de cada entorno unificado. Guarda el resultado junto al plan de rendimiento, calcula la distancia hasta el siguiente AOS y correlaciónalo con telemetría real. Si aparece un cuello de botella, determina primero si es paralelizable: más AOS ayudan a repartir usuarios, API y batch, pero no corrigen una consulta SQL ineficiente, contención o un proceso monolítico.

La novedad importante no es llegar a 80 AOS. Es que la capacidad deja de ser una propiedad fija del entorno y pasa a depender de un entitlement compartido del tenant, con escalado automático y una API que permite incorporarlo al gobierno técnico.

Referencias