Agregar objetos y fuentes al Data Service

Q: Mi nuevo tipo de registro devuelve «no se encontraron mapeos». ¿Por qué?

Sus filas de mapeo deben coincidir tanto con el tipo de registro como con el segmento exacto de la fuente de datos en la dirección que utilizó. Un nombre de fuente que no coincide es la causa habitual — verifique que las filas y el endpoint usen la misma fuente.

Administrador 8 min de lectura Actualizado en julio de 2026

El Data Service viene configurado de fábrica para las consultas web, pero el motor que hay detrás es genérico: puede dirigirlo a un tipo de registro distinto —solicitudes de servicio, por ejemplo— o dividir dos familias de formularios en fuentes separadas, y todo es cuestión de configuración. No hay que escribir código, solo una fila de permiso para el tipo de registro y una pequeña fila de mapeo por cada campo. Este artículo es la receta. Después de leerlo podrá abrir un nuevo tipo de registro a la recepción web, crear sus mapeos de campos con valores predeterminados, elegir un nombre de fuente de datos y probar la nueva conexión de forma segura antes de apuntar hacia ella un formulario en producción. Se asume que ya leyó Conecte sus formularios, donde se explican el endpoint, la forma de la solicitud y la autenticación.

Dónde encontrarlo. Las filas de permiso y los mapeos de campos del Data Service son configuraciones de administrador que residen en la configuración de su org, junto con los demás registros de configuración de REDA — no dentro de las aplicaciones REDA en sí. Su administrador los gestiona de la misma forma que los demás registros de configuración de REDA.
Acceso que necesitará. Este es trabajo de administrador: necesita la capacidad de gestionar los registros de configuración de su org. Ningún conjunto de permisos de REDA por sí solo lo otorga — es una capacidad de administrador a nivel de org.

Nunca publique una clave de API. Cada tipo de registro que abra tiene su propia clave — un secreto específico del entorno. Defina una clave nueva en cada fila de configuración nueva, nunca reutilice la clave de demostración de un org de prueba, y mantenga las claves reales fuera de páginas, repositorios y capturas de pantalla.

¿Usas la edición Sales Cloud de REDA? Este artículo muestra la edición Platform, donde las solicitudes de mantenimiento y servicio son registros Solicitud de servicio (el objeto estándar Caso). Todo lo demás — los campos, los pasos y el comportamiento — es igual salvo que se indique lo contrario. Consulta Ediciones de REDA.

Los tres componentes básicos

Configurar el Data Service significa trabajar con tres tipos de registro. El primero ya está hecho por usted; los otros dos son los que va a construir:

Componente	Cuántos hay	Tipo de metadatos personalizados	Qué hace
Interruptor principal	Uno, para toda la org	`Data Service Config`	Activa todo el Data Service. Ya está activado en un org funcional — no lo toque.
Fila de configuración	Una por tipo de registro	`Data Service Setup`	Indica qué tipo de registro acepta la recepción y cómo: interruptores de lectura y envío, los interruptores Crear registro y Editar registro, y la clave de autenticación que activa la autenticación.
Filas de mapeo	Una por campo, por fuente	`Data Service Mapping`	Traduce cada clave de la solicitud a un campo del registro, con un valor predeterminado opcional.

REDA procesa el registro a partir de estas filas exactamente igual que con la integración web incluida de fábrica: aplica primero el valor predeterminado de cada mapeo, lo sobrescribe con los valores que envió su formulario y guarda el registro. Si no existen filas de mapeo para el tipo de registro y la fuente que utilizó, REDA devuelve un error; si el guardado falla, el fallo queda registrado en el Registro asincrónico junto con la carga completa. Ese comportamiento es heredado — usted no lo configura.

Paso 1 — Cree o desbloquee la fila de configuración

La fila de configuración es lo que hace que un tipo de registro sea alcanzable. Para un tipo de registro completamente nuevo, cree una fila para él; para un tipo de registro que viene de fábrica en pausa (como la Solicitud de servicio), desbloquee la fila que ya existe.

Asigne un nombre al tipo de registro. La fila identifica qué tipo de registro gobierna; cada tipo de registro obtiene exactamente una fila de configuración.

Elija las operaciones. Active los tipos de solicitud que desea permitir — una solicitud de envío para formularios — y las operaciones que autorizará: Crear registro para registros nuevos, Editar registro si los formularios actualizarán registros existentes.

Defina una clave de autenticación. Ingrese una clave nueva. Una vez definida, cada solicitud a este tipo de registro debe llevar un encabezado x-api-key que coincida con ella — la diferencia entre una puerta cerrada y una abierta.

Defina una clave de autenticación en todo tipo de registro expuesto a internet. La fila de Solicitud de servicio incluida de fábrica viene con todos los interruptores apagados — el estado en pausa seguro. Cada vez que abra un tipo de registro a la web pública, asígnele una clave antes de activar su interruptor de creación, para que nunca quede accesible sin autenticación.

La conexión pública debe tener permiso para escribir el nuevo tipo de registro. Se llega al endpoint a través de la conexión web pública que configuró su administrador (la misma que utiliza la recepción de consultas incluida de fábrica). Esa conexión crea registros como su propia cuenta — así que, para un tipo de registro completamente nuevo, esa cuenta necesita permiso para crearlo y editarlo, y para escribir los campos que apuntan sus mapeos, exactamente igual que ya lo hace con las consultas. Si se acepta un envío de prueba pero no aparece ningún registro y el Registro asincrónico muestra un error de permisos, esta es la causa habitual. Confirme el acceso de la conexión con su administrador antes de apuntar un formulario en producción hacia un tipo de registro nuevo.

Paso 2 — Asigne un nombre a su fuente de datos

Una fuente de datos es una etiqueta que agrupa un conjunto de mapeos. Es el último segmento de la dirección del endpoint, y permite que el mismo tipo de registro sirva a varios formularios distintos sin que sus campos choquen entre sí. Las consultas web incluidas de fábrica usan la fuente Web; usted podría usar Web para su primera familia de formularios y un nombre específico de campaña para otra.

Elija ahora un nombre de fuente — lo estampará en cada fila de mapeo en el siguiente paso, y su formulario lo incluirá en la dirección a la que envía. Use una fuente por familia de formularios: los formularios que envían el mismo conjunto de claves y quieren los mismos valores predeterminados comparten una fuente; los que necesitan un conjunto de claves distinto o valores predeterminados distintos obtienen la suya propia.

Paso 3 — Cree las filas de mapeo

Ahora traduzca cada campo del formulario a un campo de REDA. Agregue una fila de mapeo por campo, cada una con:

En cada fila de mapeo	Qué debe definir
Fuente de datos	El nombre de fuente que eligió en el Paso 2 — debe coincidir exactamente con la dirección.
Tipo de registro	El mismo tipo de registro que la fila de configuración.
Clave de la solicitud	La clave que envía su formulario (por ejemplo, `subject`).
Campo de destino	El campo de REDA que llena.
Valor predeterminado (opcional)	Un valor que se usa cuando el formulario omite esa clave — útil para dejar constancia del origen.

Vale la pena conocer dos patrones. Use valores predeterminados para dejar constancia del origen — el conjunto web incluido de fábrica, por ejemplo, define por defecto la fuente de la consulta como Web para que todo registro creado desde la web quede etiquetado desde su creación. Y agregue un mapeo de recordId solo si quiere actualizaciones desde el lado web: mapee recordId al identificador del registro, y combínelo con Editar registro en la fila de configuración. Sin ese mapeo, cada envío crea un registro nuevo.

Pruebe cualquier campo de fecha, número o lista de selección antes de confiar en él. Los valores que envía su formulario llegan como texto y se colocan en los campos del registro. Los campos de texto simple son directos; para un campo de destino de fecha, número o lista de selección, envíe una muestra real mediante el Paso 4 y confirme que llega correctamente antes de apuntar un formulario en producción hacia él — un valor que el campo no puede aceptar queda registrado en el Registro asincrónico en lugar de guardarse.

Paso 4 — Pruebe

Antes de apuntar un formulario en producción hacia la nueva conexión, envíele usted mismo una solicitud de prueba:

Envíe el arreglo de clave/valor a .../dataservice/<Tipo de registro>/<Su fuente> con el encabezado x-api-key llevando su nueva clave.

Confirme el registro. A una respuesta exitosa le sigue, un momento después, el nuevo registro — ábralo y verifique que los campos llegaron donde indican sus mapeos.

Fuerce un fallo. Envíe una solicitud que omita un campo obligatorio y luego busque la entrada resultante en el Registro asincrónico — así confirma que, cuando un formulario real falla, podrá ver exactamente qué envió.

Ejemplo práctico: un formulario de "reportar un problema"

Meridian Properties quiere un formulario público de "reportar un problema" en su sitio de marketing — separado del flujo de solicitudes autenticadas dentro del portal de residentes — que cree una Solicitud de servicio de REDA. Como la fila de configuración de la Solicitud de servicio ya viene en pausa de fábrica, la receta es corta:

Paso	Qué hace Meridian
Desbloquear la fila de configuración	Activa la solicitud de envío y Crear registro en la fila de Solicitud de servicio; define una clave de autenticación nueva.
Asignar nombre a la fuente	Usa `Web` para esta familia de formularios.
Agregar mapeos	Mapea las claves `subject`, `description` y `email` del solicitante del formulario a los campos correspondientes de la solicitud de servicio, y agrega un valor predeterminado que marca la fuente como web.
Probar	Envía una muestra; aparece una solicitud de servicio. Envía una a la que le falta un campo obligatorio; aparece una entrada en el Registro asincrónico con la carga enviada.

El formulario en producción ahora registra solicitudes de servicio directamente en REDA, y el formulario público del sitio de marketing permanece completamente separado del formulario autenticado del portal.

Qué sigue

REDA Data Service: conecte sus formularios — el motor, el endpoint y el conjunto de consultas web incluido de fábrica.
Descripción del Registro asincrónico de REDA — dónde quedan los envíos fallidos y cómo priorizarlos.
Consultas web y solicitudes de recorrido — la recepción de consultas incluida de fábrica que esta receta generaliza.

Preguntas frecuentes

Sus filas de mapeo deben coincidir tanto con el tipo de registro como con el segmento exacto de la fuente de datos en la dirección que utilizó. Un nombre de fuente que no coincide es la causa habitual — verifique que las filas y el endpoint usen la misma fuente.

No — las claves residen en la fila de configuración de cada tipo de registro, una por fila. Defina una clave independiente para cada uno. El objetivo son claves independientes: puede rotar una sin afectar las demás.

No. Las reglas de validación propias del tipo de registro se aplican al guardar el registro, exactamente igual que con un registro creado a mano. Un envío que incumple una regla no crea un registro — queda registrado en el Registro asincrónico junto con los datos enviados.

Ambas pasan por la misma verificación, pero los formularios deben enviar (POST) — que es el tipo de solicitud que lleva un cuerpo con los valores de los campos. Las lecturas son para consultar, no para crear.

¿Te resultó útil?