D365FO en PPAC: cómo calcular y verificar la capacidad AOS

La transición de Dynamics 365 Finance and Operations desde topologías fijas administradas en Lifecycle Services hacia entornos unificados en Power Platform cambia una pregunta fundamental: ¿cómo se determina y verifica ahora la capacidad de Application Object Server (AOS)?

El artículo de Rakesh Darge, “The AOS Math That Kept One Admin Up At Night”, plantea el problema desde una situación práctica observada en la nueva experiencia de detalles de Finance and Operations en Power Platform Admin Center (PPAC). Esta guía conserva ese caso como punto de partida y contrasta sus conclusiones con la documentación oficial de Microsoft.

Del tier fijo al cómputo elástico

En los entornos unificados, los ambientes sandbox y productivos ya no se dimensionan eligiendo un tier fijo. Microsoft utiliza un modelo de cómputo elástico: los entornos parten de una topología base y pueden escalar horizontalmente cuando aumentan las sesiones concurrentes, el tráfico de servicios, el procesamiento batch o las solicitudes procedentes de Power Platform y las tablas virtuales de Dataverse.

El escalamiento hacia arriba puede realizarse sin interrumpir las sesiones activas. La reducción de instancias requiere drenar sesiones y se ejecuta durante ventanas de mantenimiento o despliegues de personalizaciones.

Cómo se calcula la capacidad AOS

Power Platform Requests (PPR) funciona como unidad de capacidad de cómputo para Finance and Operations en entornos unificados. La fórmula documentada por Microsoft es:

Capacidad AOS = floor(PPR disponibles ÷ 650.000)

La plataforma aplica además estas reglas:

Base de 500.000 PPR por tenant con una compra de Dynamics 365.
Acumulación de 5.000 PPR por licencia de usuario elegible.
Paquetes adicionales de 50.000 PPR.
Mínimo de dos AOS para sandbox y producción: uno interactivo y uno batch.
Máximo de 80 AOS por entorno: hasta 40 interactivos y hasta 40 batch.

Los PPR se acumulan en un conjunto compartido a nivel de tenant. La capacidad calculada representa el techo disponible para el escalamiento de los entornos; no significa que todas las instancias estén activas permanentemente.

Capacidad máxima y consumo observado no son lo mismo

La experiencia administrativa y las interfaces de Power Platform distinguen entre el máximo configurado y las instancias observadas recientemente. El conector oficial Power Platform for Admins V2 expone cuatro propiedades especialmente útiles:

maxAOSCount: máximo de AOS interactivos.
lastObservedAOSCount: última cantidad observada de AOS interactivos.
maxBatchAOSCount: máximo de AOS batch.
lastObservedBatchAOSCount: última cantidad observada de AOS batch.

Por tanto, un valor máximo no debe interpretarse como consumo permanente ni como garantía de rendimiento. Indica hasta dónde puede crecer el entorno dentro de la capacidad autorizada; la plataforma activa instancias de acuerdo con la demanda.

Cómo interpretar Interactive AOS y Batch AOS

Los AOS interactivos atienden sesiones de usuario, solicitudes OData, servicios personalizados y otros flujos sincrónicos. Los procesadores AOS batch ejecutan cargas en segundo plano. Microsoft permite que la capacidad batch crezca de forma independiente dentro de los límites del entorno.

En el caso descrito por Rakesh Darge, PPAC mostraba máximos de 10 AOS interactivos y 10 AOS batch. La interpretación práctica es que existen dos límites diferenciados cuya suma representa una capacidad total potencial de 20 AOS, no un conjunto compartido de solo 10. El ejemplo específico procede de la observación del autor; la separación de las propiedades sí está respaldada por la API y el conector oficiales.

La excepción de UDE

Unified Developer Environment (UDE) no participa en el escalamiento elástico. Microsoft limita este tipo de ambiente a una única instancia AOS porque el depurador de Visual Studio debe conectarse a un proceso específico y estable.

Por ello, visualizar un AOS interactivo y cero procesadores batch dedicados en un UDE no implica necesariamente una falla. El ambiente utiliza su única instancia para soportar el desarrollo y la depuración. Las pruebas que necesiten múltiples AOS, concurrencia o comportamiento representativo de producción deben ejecutarse en un sandbox unificado.

Procedimiento para verificar la capacidad

Identificar los PPR disponibles para el tenant y las licencias que aportan capacidad.
Calcular el techo teórico usando 650.000 PPR por AOS, respetando el mínimo y el máximo documentados.
Abrir el entorno en PPAC y revisar la información de Finance and Operations disponible para la topología.
Registrar por separado los máximos y los valores observados de AOS interactivos y batch.
Consultar la operación Get Finance and Operations environment properties del conector Power Platform for Admins V2 para obtener los mismos datos de forma automatizada.
Cuando se requiera una validación de tenant, consultar licensing/tenantCapacity mediante Power Platform API y aislar la capacidad ApiCallCount.
Comparar los resultados con los picos reales de usuarios, integraciones, OData, servicios personalizados y batch.
Ejecutar pruebas de carga en sandbox antes de asumir que el techo calculado cubre un escenario productivo.

Automatización y gobierno

El conector Power Platform for Admins V2 permite construir un inventario recurrente de capacidad por ambiente mediante Power Automate, Power Apps, Logic Apps o Copilot Studio. También admite autenticación OAuth y, para muchas acciones, Service Principal.

Un control reutilizable puede guardar por fecha:

Identificador y tipo del entorno.
Versión de aplicación y plataforma.
Máximo y valor observado de AOS interactivos.
Máximo y valor observado de AOS batch.
Capacidad PPR del tenant.
Diferencia entre capacidad y consumo observado.
Incidentes de operación y ventanas de mantenimiento.

La conexión con Service Principal debe aplicar mínimo privilegio, rotación de secretos o certificados, separación entre lectura y operaciones de cambio, y trazabilidad de cada ejecución. El conector documenta además un límite de 100 llamadas por conexión cada 60 segundos, por lo que una recolección multientorno debe incorporar paginación, control de frecuencia y manejo de errores.

PPR de capacidad y límites de solicitudes

Microsoft advierte que los PPR cumplen dos funciones relacionadas, pero independientes:

Determinar el techo de cómputo AOS.
Establecer límites de solicitudes para operaciones de Power Platform, como llamadas de Dataverse, complementos y flujos.

Comprar capacidad adicional puede elevar ambos límites, pero un escalamiento AOS provocado por tráfico de tablas virtuales no elimina por sí mismo las reglas de throttling. Ambos indicadores deben revisarse por separado.

Acceso SQL en sandbox: estado actual

El artículo comunitario menciona el acceso SQL de escritura en sandbox como una capacidad próxima. La documentación oficial actual ya permite solicitar credenciales temporales desde Visual Studio para UDE y Unified Sandbox Environment (USE). En USE, la escritura queda limitada al rol db_datawriter; además, el usuario debe tener el rol System Administrator y el acceso se restringe mediante direcciones IPv4 autorizadas.

Esta capacidad sirve para diagnóstico y tareas controladas, pero no reemplaza los mecanismos soportados de integración, entidades de datos ni procedimientos formales de mantenimiento.

Qué debe incorporarse al runbook de migración

Inventario de consumo actual en LCS y cargas críticas.
Cálculo de capacidad PPR del tenant.
Lectura separada de máximos y valores observados.
Validación específica de cargas interactivas, batch e integraciones.
Pruebas de rendimiento en un sandbox unificado.
Automatización de inventario mediante API o conector.
Responsables y umbrales para revisar capacidad adicional.
Procedimiento de escalamiento a soporte cuando la demanda no coincide con los valores observados.

Conclusión

La nueva visibilidad de Finance and Operations en PPAC reduce una parte importante de la incertidumbre que existía al comparar tiers de LCS con entornos unificados. Sin embargo, la lectura correcta exige distinguir capacidad autorizada, máximos interactivos y batch, instancias observadas y rendimiento real.

El mejor enfoque no consiste en trasladar directamente el número de AOS de LCS. Conviene combinar la fórmula oficial de PPR, los datos visibles en PPAC, las propiedades del conector administrativo y pruebas representativas de las cargas reales.