Envío de datos a un punto de conexión gRPC con la versión preliminar del Procesador de datos de Azure IoT
Importante
Operaciones de IoT de Azure, habilitado por Azure Arc, está actualmente en VERSIÓN PRELIMINAR. No se debería usar este software en versión preliminar en entornos de producción.
Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
Usa el destino de gRPC para escribir datos procesados y limpiarlos en un punto de conexión gRPC para su posterior procesamiento.
Al enviar datos a un punto de conexión de gRPC desde una fase de destino:
- Actualmente, la fase solo admite el tipo RPC de Unary.
- Solo puedes usar el formato Protobuf. Debes usar Protobuf con la fase de llamada gRPC.
- Dado que esta fase es un destino de canalización, se descarta la respuesta.
Requisitos previos
Para configurar y usar una fase de canalización de destino, necesita:
- Una instancia implementada de La versión preliminar del procesador de datos de Azure IoT que incluye el componente opcional del procesador de datos.
- Un servidor de gRPC accesible desde la instancia del procesador de datos.
- La herramienta
protoc
para generar el descriptor.
Configuración del conmutador de destino
La configuración JSON de la fase de destino de gRPC define sus detalles. Para crear la fase, puedes interactuar con la interfaz de usuario basada en formularios o proporcionar la configuración JSON en la pestaña Opciones avanzadas:
Nombre | Escribir | Descripción | Necesario | Valor predeterminado | Ejemplo |
---|---|---|---|---|---|
Nombre | cadena | Un nombre para mostrar en la interfaz de usuario del procesador de datos. | Sí | - | MLCall2 |
Descripción | cadena | Descripción fácil de comprender de la fase de destino. | No | Call ML endpoint 2 |
|
Dirección del servidor | String | Dirección del servidor gRPC | Sí | - | https://localhost:1313 |
Nombre de RPC | cadena | El nombre RPC al que se va a llamar | Sí | - | GetInsights |
Descriptor1 | String | Descriptor codificado en base 64 | Sí | - | CuIFChxnb29nb |
Autenticación | cadena | Tipo de autenticación que se debe usar. None /Metadata . |
Sí | None |
None |
Clave de metadatos | cadena | Clave de metadatos que se va a usar cuando Authentication se establezca en Metadata . |
No | authorization |
authorization |
Secreto | cadena | Referencia secreta que se va a usar cuando Authentication se establezca en Metadata . |
No | - | mysecret |
Volver a intentar | Reintentar | Directiva de reintento que se va a usar. | No | default |
fixed |
Ruta de acceso del cuerpo > de la solicitud de la API | Path | Ruta de acceso a la parte del mensaje del procesador de datos que se debe serializar y configurar como el cuerpo de la solicitud. Deje este campo vacío si no necesita enviar un cuerpo de solicitud. | No | - | .payload.gRPCRequest |
> Metadatos > clave2 de la solicitud de la API | Campo estático/dinámico | Clave de metadatos que se va a establecer en la solicitud. | No | Campo estático/dinámico | |
> Metadatos > valor2 de la solicitud de la API | Campo estático/dinámico | Valor de metadatos que se va a establecer en la solicitud. | No | Campo estático/dinámico |
1Descriptor: para serializar el cuerpo de la solicitud, necesita un descriptor codificado en base 64 del archivo .proto.
Usa el comando siguiente para generar el descriptor, reemplaza <proto-file>
por el nombre del archivo .proto:
protoc --descriptor_set_out=/dev/stdout --include_imports <proto-file> | base64 | tr '\n' ' ' | sed 's/[[:space:]]//g'
Usa la salida del comando anterior como descriptor
en la configuración.
2Metadatos > de la solicitud de la API: cada elemento de la matriz de metadatos es un par de valores clave. Puedes establecer la clave o el valor dinámicamente en función del contenido del mensaje entrante o como una cadena estática.
Contenido relacionado
Comentarios
https://aka.ms/ContentUserFeedback.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea:Enviar y ver comentarios de