⌚ D365 SCM abre su app de almacén al hardware de terceros

Microsoft ha publicado un contrato de integración bidireccional para la aplicación móvil de Warehouse Management. El nuevo form bridge permite que una aplicación Android de un proveedor reciba el formulario de almacén que el operario tiene abierto y devuelva entradas o acciones a la app de Microsoft. Así, unas gafas, una pantalla de antebrazo, un sistema de voz o un wearable industrial pueden presentar el proceso y manejarlo sin duplicar la lógica de D365 Supply Chain Management.

El cambio importante no es el soporte de un dispositivo concreto. ProGlove es el primer proveedor integrado, pero el protocolo es independiente del fabricante: cualquier proveedor puede implementarlo sin añadir código específico a Warehouse Management mobile app.

A 30 de septiembre de 2026, la integración requiere Warehouse Management mobile app 4.2.0.0 o posterior y solo funciona en Android. La versión 4.2.0.0 se publicó en Microsoft App Center el 29 de septiembre; el despliegue progresivo en las tiendas está previsto a partir del 6 de octubre. No es una preview, pero que el paquete esté publicado no implica que ya aparezca en todos los dispositivos administrados.

Diagrama original. El puente es local al dispositivo Android; la app de Microsoft conserva el flujo de almacén y la comunicación con D365 SCM.

Qué cambia realmente

Hasta ahora, las integraciones habituales se concentraban en enviar lecturas de códigos de barras o señales hápticas. El form bridge expone la estructura del formulario actual y acepta una respuesta que puede modificar controles, pulsar botones, enviar la página o cerrar una instrucción.

Integración	Dirección	Alcance
Salida de escáner	Hardware → app	Introduce normalmente un valor en el control activo.
Feedback háptico	App → wearable	Comunica éxito, aviso o error.
Form bridge v1	App ↔ proveedor	Entrega formularios, controles, instrucciones e imágenes; devuelve entradas y acciones.

La aplicación del proveedor se convierte en una segunda experiencia de interacción, pero no ejecuta el proceso de almacén. Warehouse Management mobile app sigue interpretando la respuesta, enviando el formulario a Supply Chain Management y recibiendo el siguiente paso.

Arquitectura y contrato de mensajes

El puente intercambia Android broadcast intents entre dos aplicaciones instaladas en el mismo dispositivo. El intercambio local no necesita una llamada de red adicional. Cada mensaje transporta una cadena JSON en el extra:

com.microsoft.aierpmobile.extra.PAYLOAD

Los cuatro actions del contrato son sensibles a mayúsculas y minúsculas:

Action	Dirección	Efecto
com.microsoft.aierpmobile.FORM_DATA	WMA → proveedor	Envía el formulario actual.
com.microsoft.aierpmobile.CONTROL_CHANGES	Proveedor → WMA	Aplica cambios y envía inmediatamente el formulario.
com.microsoft.aierpmobile.SUBMIT_FORM	Proveedor → WMA	Envía el formulario sin cambiar controles.
com.microsoft.aierpmobile.CLOSE_NOTIFICATION	Proveedor → WMA	Cierra la notificación o instrucción actual sin enviar el formulario.

Todos los payloads declaran "version": "v1". Esta versión identifica el contrato, no la versión 4.2.0.0 de la aplicación móvil. Diseña el parser para tolerar campos desconocidos: Microsoft recomienda registrar una advertencia si cambia la versión e intentar procesar los campos compatibles.

Hay además una advertencia de compatibilidad. Integraciones anteriores usaban FORM_RENDER o el namespace com.microsoft.wma.*. Deben migrar a los nombres actuales; conservar los antiguos deja de entregar formularios.

Qué contiene FORM_DATA

El mensaje incluye screenId, título localizado, controles y, cuando existen, una imagen o una instrucción. Un payload reducido podría ser:

{
  "version": "v1",
  "screenId": "Default",
  "pageTitle": "Introducir matrícula",
  "controls": [
    {
      "controlType": "text",
      "name": "WHSWorkLicensePlateId",
      "label": "Matrícula",
      "data": "",
      "enabled": "1",
      "Status": "1",
      "DisplayArea": "PrimaryInputArea",
      "PreferredInputMode": "Scanning"
    }
  ]
}

No conviene tratarlo como un modelo de dominio estable:

• screenId es una pista de presentación, no una clave de negocio;
• el identificador que debe devolverse es name, nunca el label ni la posición;
• muchos flags y prioridades que parecen números o booleanos son cadenas;
• los nombres de campos son case-sensitive: Status y enabled no siguen la misma capitalización;
• una imagen es JPEG en Base64, sin prefijo data: y con un límite codificado de 150 KB;
• image e instruction se omiten cuando no existen, no llegan necesariamente como null;
• el dispositivo debe disponer de una presentación genérica para tipos o patrones desconocidos.

Los controles documentados incluyen texto, password, botones, detours, comboboxes y variantes de fast validation. Las áreas y prioridades permiten adaptar el formulario a una pantalla reducida sin cambiar el orden lógico suministrado por WMA.

Implementación paso a paso

1. Preparar el dispositivo y la aplicación

Necesitas:

1. Android con Warehouse Management mobile app 4.2.0.0 o posterior.
2. La aplicación del proveedor instalada en el mismo dispositivo.
3. Conexión de prueba a un entorno de Supply Chain Management.
4. Flujos de almacén representativos.
5. Capacidad administrativa para autorizar el package Android del proveedor.

No confundas el form bridge con el inicio de sesión mediante QR publicado también para 4.2.0.0. Son funciones independientes: una conecta hardware con formularios; la otra autentica trabajadores mediante Entra ID y PIN.

2. Autorizar el package en cada equipo

Desde la pantalla de acceso de WMA abre Connection setup → Client settings → Allowed apps y añade el package exacto. Se pueden separar varios con punto y coma:

com.contoso.warehousebridge; de.proglove.integrationkit.intenthub

La lista se almacena localmente en cada dispositivo. No se propaga por configurar un terminal, por lo que una flota exige un procedimiento de provisión y auditoría. Una lista vacía deshabilita el puente en ambas direcciones.

3. Declarar el receptor de formularios

El proveedor debe registrar un BroadcastReceiver exportado en AndroidManifest.xml:

<receiver
    android:name=".WarehouseFormReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="com.microsoft.aierpmobile.FORM_DATA" />
    </intent-filter>
</receiver>

No basta con registrar el receiver únicamente en runtime. En Android 11 o posterior, la declaración del manifest también permite que WMA descubra el package mediante su consulta de visibilidad por action.

Al recibir el intent:

1. comprueba el action;
2. recupera com.microsoft.aierpmobile.extra.PAYLOAD;
3. valida JSON y versión;
4. presenta solo controles soportados y respeta enabled, longitud y tipos;
5. evita guardar payloads completos o credenciales en logs.

4. Identificar el emisor de las acciones

WMA solo acepta acciones si puede atribuirlas a una aplicación autorizada:

• Android 14 o posterior proporciona la identidad del sender;
• Android 13 o anterior requiere un PendingIntent inmutable creado por el proveedor en el extra caller_id_intent.

Adjunta ese identificador en las tres acciones entrantes para todas las versiones Android. Este esqueleto Kotlin cambia un control:

private val callerId = PendingIntent.getActivity(
    context,
    0,
    Intent(),
    PendingIntent.FLAG_IMMUTABLE
)

fun submitChange(controlName: String, value: String) {
    val payload = JSONObject()
        .put("version", "v1")
        .put("changes", JSONArray().put(
            JSONObject().put("name", controlName).put("value", value)
        ))

    context.sendBroadcast(
        Intent("com.microsoft.aierpmobile.CONTROL_CHANGES")
            .putExtra("com.microsoft.aierpmobile.extra.PAYLOAD", payload.toString())
            .putExtra("caller_id_intent", callerId)
    )
}

Si decides dirigir explícitamente el broadcast, el application ID real es com.Microsoft.WarehouseManagement, no el namespace del action. En Android 11 o posterior tendrás que declararlo también en <queries>.

5. Devolver la acción correcta

CONTROL_CHANGES recibe únicamente los controles modificados y envía el formulario de inmediato. No es una actualización de borrador: no lo dispares por cada tecla ni lo sigas con SUBMIT_FORM, porque provocarías dos envíos.

{
  "version": "v1",
  "changes": [
    { "name": "WHSWorkLicensePlateId", "value": "LP-000123" }
  ]
}

Para pulsar un botón se devuelve su name con "value": "1", incluso si el data original está vacío. Para un combobox, el valor debe pertenecer a _comboboxItems.

Usa SUBMIT_FORM solo para confirmar sin cambios y CLOSE_NOTIFICATION para cerrar una instrucción. Esta última es idempotente y no envía el formulario; dontShowAgain: true persiste la supresión de la instrucción para esa pantalla.

Seguridad: el punto crítico del diseño

La aplicación autorizada recibe datos operativos del formulario y puede enviar acciones en nombre del trabajador. Por tanto, Allowed apps no es una lista de conveniencia: es una frontera de confianza.

Aplica como mínimo estas medidas:

1. Permite únicamente packages firmados y distribuidos por un canal corporativo controlado.
2. Gestiona instalación, actualización y retirada mediante MDM cuando sea posible.
3. Revisa la lista efectiva en toda la flota; una errata impide la entrega sin mostrar error.
4. Enmascara controles password y evita registrar formularios completos, imágenes o datos personales.
5. Valida longitud, tipos, opciones de combobox y nombres contra el último FORM_DATA recibido.
6. Considera inválida cualquier respuesta construida con un formulario anterior.
7. Prueba por separado Android 13 y 14, porque la garantía de identidad no es idéntica.

Microsoft advierte que los broadcasts no dirigidos pueden ser recibidos por otras apps que registren los mismos actions. En Android 13 o anterior, caller_id_intent demuestra quién creó el PendingIntent, no necesariamente quién emitió un broadcast concreto; otra aplicación que lo obtenga podría reutilizarlo. No lo equipares a la identificación de sender que ofrece Android 14.

Estas limitaciones recomiendan dispositivos gestionados, catálogo de apps reducido, distribución controlada y análisis de amenazas específico antes de producción.

Plan de pruebas

Prueba el puente contra procesos reales, no solo con una pantalla de matrícula:

• recepción de FORM_DATA tras cada transición;
• labels localizados, valores, prioridades y controles deshabilitados;
• password enmascarado y ausencia de datos sensibles en telemetría;
• texto, botón, detour y combobox;
• fast validation y multiscan cuando se utilicen;
• formularios con y sin imagen e instrucción;
• imagen omitida cuando supera el límite;
• CONTROL_CHANGES ejecutado una sola vez;
• SUBMIT_FORM sin cambios;
• cierre temporal y persistente de instrucciones;
• caller identity en Android 13 y Android 14;
• retirada del package de Allowed apps y bloqueo efectivo del flujo;
• pérdida de red entre WMA y SCM, aunque el puente local siga activo;
• actualización y rollback de la app del proveedor mediante MDM.

Para diagnóstico de identidad durante el desarrollo, Microsoft documenta:

adb logcat -s IntentScanner

Una integración que funciona en Android 14 pero no en Android 13 suele indicar que falta caller_id_intent. Un warning Sender identity mismatch indica que el sender y el creator del identificador no coinciden.

Disponibilidad, soporte y licenciamiento

La versión 4.2.0.0 está released en Microsoft App Center desde el 29 de septiembre de 2026. El rollout a Google Play está programado dentro del despliegue de tiendas que comienza el 6 de octubre. Controla la actualización con un grupo piloto antes de distribuirla a terminales productivos.

El protocolo solo está documentado para Android. No extrapoles el bridge a Windows o iOS aunque WMA se ejecute en esas plataformas.

La documentación no identifica una licencia adicional de Microsoft para usar el form bridge. Siguen aplicando los derechos de Dynamics 365 Supply Chain Management y de la aplicación móvil, mientras que hardware, software del proveedor, MDM y soporte pueden tener costes y contratos propios. Confirma esos elementos comercialmente antes de seleccionar un wearable.

Limitaciones y decisiones de diseño

• El proveedor no recibe una API remota ni acceso directo a D365; comparte dispositivo con WMA.
• El contrato actual es v1 y puede ampliarse con campos desconocidos.
• El bridge no sustituye la lógica de Process Guide ni evita validar extensiones del flujo en SCM.
• La lista de packages es local a cada terminal.
• Las imágenes pueden omitirse y nunca deben ser requisito para completar el paso.
• CONTROL_CHANGES combina cambio y submit; no existe un modo draft documentado.
• Los identificadores visuales no son claves de negocio estables.
• La seguridad del sender es más débil en Android 13 o anterior.

Recomendación práctica

El mejor primer caso no es rehacer toda la experiencia móvil, sino un proceso repetitivo y medible: picking manos libres, confirmación de matrículas o conteo donde el hardware reduzca movimientos y errores. Construye un adaptador que traduzca FORM_DATA a un modelo interno tolerante a extensiones, conserva el name original de cada control y encapsula las cuatro actions del protocolo.

Pilota en dispositivos Android 13 y 14, mide tiempo por paso, errores y reintentos, y verifica el modelo de amenaza antes de ampliar. La novedad merece atención porque transforma una integración específica con wearables en un contrato implementable por terceros sin acoplar su hardware al backend de D365 SCM.

Referencias

• Integrar hardware con Warehouse Management mobile app
• Commit oficial que publica el contrato
• Calendario de versiones de Warehouse Management mobile app
• Instalar y configurar Warehouse Management mobile app
• Configuración avanzada de escáneres
• Feedback háptico con wearables