Guía de la API del conector CMS
Nueva guía de la API del conector CMS
Este documento sirve como guía para ampliar la API del conector CMS para admitir nuevos sistemas de gestión de contenido (CMS) y file tipos. Describe el proceso de creación de nuevos paquetes CMS, la actualización de la lógica del validador y del mapeador, y el manejo de varios file extensiones y configuraciones de CMS en la ruta `/validator` y `handle`FileFunción de procesamiento. El objetivo es mantener una arquitectura modular e independiente del CMS, lo que permite una integración fluida de diferentes plataformas CMS mediante un enfoque estructurado para la validación, el procesamiento y el mapeo de datos.
Creación de un paquete CMS similar
Como migración-contenido, migración-sitecore, migración-wordpress
Para dar soporte a un nuevo CMS (por ejemplo, Drupal), cree un nuevo paquete como este:
Mecanografiado
migración-drupal/
Dentro de ella, implemente la estructura requerida:
Mecanografiado
// migración-drupal/index.js
constante validador = (datos) => {
// Validar file formato, estructura, campos obligatorios
};constante ExtractoFiles = asíncrono (fileRuta) => {
// Descomprimir o analizar contenido
};
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
constante tipos de contenido = {
// Definiciones de tipos de contenido específicos de Drupal
};
constante referencia = {
// Referencias de campos específicos de Drupal
};
constante extractLocales = (datos) => {
// Devuelve la matriz de configuración regional
};
módulo.exportaciones = {
validador,
ExtractoFiles,
tipos de contenido,
referencia,
extraerLocales
};
Dónde está enchufado
Una vez que su paquete (por ejemplo, migration-drupal) esté listo:
1. Agréguelo a package.json:
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
JSON
“migración-drupal”: “file:migración-drupal”
2. Actualice la lógica de su validador:
Mecanografiado
constante { validador: drupalValidator } = requerir('migración-drupal');
cambiar (Identificador CMS) {
caso 'drupal-zip':
devolver drupalValidator({ datos });
}
3. Actualice la lógica de createMapper y agregue el caso en el conmutador createMapper::
Mecanografiado
caso 'drupal':
devolver esperar createDrupalMapper(…);
✅ Resumen
Para agregar un nuevo CMS, simplemente:
- Andamiaje de un paquete como migration-drupal
- Seguir la estructura del método existente
- Agregarlo a los bloques de conmutación del validador y del asignador
Esto mantiene la arquitectura modular y agnóstica respecto a CMS, todas las explicaciones proporcionadas en subpestañas.
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
Ruta del validador
Esta ruta se utiliza para validar y procesar una file (local o desde AWS S3), según file Tipo y configuración del CMS.
✅ Funcionalidad terminadaview
- Acepta una solicitud GET a /validator
- Determina si el file La fuente es local o de S3
- Basado en el file extensión:
○ Si XML → se lee como cadena
○ De lo contrario (por ejemplo, ZIP) → se lee como búfer binario - Manejo de llamadas File Procesamiento con file datos
- En caso de éxito, se asigna el procesado file usando crear Mapper
Dónde agregar soporte para nuevos File Tipos
En esta ruta, file Las extensiones se determinan utilizando:
JavaScript
constante fileExtensión = file¿Nombre?.dividir?.('.')?.estallido() ?? ";
Entonces basado en file extensión, la lógica se maneja así:
JavaScript
if (fileExtensión === 'xml') {
// Procesar XML como cadena
} demás {
// Proceso como buffer (por ejemplo, zip)
}
Si desea agregar uno nuevo file tipo, puedes agregarlo dentro de esta condición: Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
JavaScript
if (fileExtensión === 'xml') {
// …
} De lo contrario si (fileExtensión === 'tuNuevaExtensión') {
// Agregue lógica para leer y manejar este nuevo file tipo
} demás {
// Procesamiento predeterminado para binario files
}
Es posible que también necesites extender el mango.FileProcesamiento para manejar lo nuevo file tipo.
Dónde agregar soporte para nuevos tipos de CMS
El cmsType se recupera de:
constante cmsType = config?.cmsType?.toLowerCase();
Posteriormente esta variable se pasa a:
datos constantes = esperar identificador File Procesando (file Extensión, file Datos, tipo cms, nombre);
Si desea agregar un nuevo CMS, puede extender la lógica dentro del controlador File Procesamiento o dondequiera que maneje el procesamiento específico de CMS.
También actualizar:
crearMapper(fileRuta, projectId, app_token, afijo, config); Para admitir su nuevo tipo de CMS, agregue lógica a createMapper para manejarlo adecuadamente.
✅ Resumen
● Puedes agregar nuevos file extensiones modificando el fileCondición ext. Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
● Puede agregar nuevos tipos de CMS ampliando el identificadorFileProcesamiento y createMapper
● El sistema ya separa el manejo de XML (cadena) y ZIP (búfer): siga esa estructura
Manejar File Tratamiento
Este documento explica cómo integrar una nueva plataforma CMS en la existente. file Flujo de validación y procesamiento utilizando las funciones:
● manejarFileTratamiento()
● validador()
Objetivo
El backend actualmente admite varios tipos de CMS (como Sitecore, Contentful, WordPress, AEM). El objetivo es validar los archivos subidos. files y transformarlos en un formato estructurado específico para cada CMS.
El sistema identifica un CMS + file Escriba par usando este formato:
extensión de tipo → p. ej., sitecore-zip, contentful-json, wordpress-xml
Dónde agregar un nuevo CMS
Paso 1: Actualizar la función validadora ()
Ubicado en el interior:
JavaScript
constante validador = ({ datos, tipo, extensión }: { datos: cualquiera; tipo: cadena; extensión: cadena }) => { … }
Busque la instrucción switch en CMSIdentifier. Cada caso maneja un tipo de CMS y file-combinación de extensión.
Para agregar un nuevo CMS, agregue un nuevo caso en este bloque de conmutación:
Exampen:
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
JavaScript
caso 'newcms-json': {
devolver newCMSValidator(datos); // Su nueva lógica de validación }
Cerciorarse:
● El formato de CMSIdentifier coincide con el {tipo}-{extensión} esperado
● La función de validación (por ejemplo, newCMSValidator) se importa o define
Puedes agregar múltiples variaciones, como:
caso 'newcms-zip':
caso 'newcms-xml':
Paso 2: Crear la función de validación
En su proyecto, defina la lógica del validador para el nuevo CMS. Por ejemplo:ampen:
JavaScript
constante newCMSValidator = (datos) => {
// Su lógica de validación personalizada para JSON, ZIP, etc.
devolver verdadero; // o falso si falla la validación
};
Entrada: Esto podría ser:
● Un objeto JSZip (para zip)
● Cadena XML sin procesar
● Objeto/cadena JSON
Salida: Booleano (verdadero = válido, falso = rechazado)
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
Paso 3: Prueba con el mangoFileTratamiento()
La función validator() se utiliza dentro del manejadorFileTratamiento():
JavaScript
if (esperar validador({ datos: zipBuffer, tipo: cmsType, extensión: fileExtensión })) { // …
}
Asegúrese de que su nuevo validador de CMS esté cubierto por la condición al pasar lo correcto:
● cmsType (de config.cmsType)
● fileExt (del archivo subido) file)
✅ Lista de verificación resumida
Descripción de la tarea
Agregar nuevo caso Actualizar bloque switch validator()
Implementar lógica Escribe tu propia función newCMSValidator
Devolver
verdadero/falso
Asegúrese de que el validador devuelva un valor booleano
Utilice la clave correcta Siga el formato de extensión de tipo (por ejemplo, newcms-zip)
�� Opcional: Consejos de depuración
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
● Registre el CMSIdentifier dentro de validator() para garantizar que se alcance su caso.
● Asegúrese de que el mango estéFileEl procesamiento está pasando correctamente fileExt y cmsType.
Cómo añadir compatibilidad con Mapper para un nuevo CMS
Después de validar y procesar un fileEl backend prepara los datos de mapeo mediante la función createMapper. Este paso transforma el contenido extraído a un formato estandarizado que permite generar datos ficticios y mapeos regionales en su CMS.
Cómo funciona el mapeo (flujo de alto nivel)
1. ✅ File se validó y guardó correctamente (ZIP, XML, JSON, etc.)
2. 
Ruta al procesado file se determina:
JavaScript
constante fileRuta = ruta.join(__nombredir, '..', '..', 'extraído_files', fileNombre);
3. Se invoca la función createMapper:
JavaScript
crearMapper(fileRuta, projectId, app_token, afijo, config);
4. 
Esta función enruta la lógica según el tipo de CMS (por ejemplo, Sitecore, Contentful, WordPress)
Función createMapper – Estructura
JavaScript
constante crearMapper = asíncrono (
fileCamino,
ID del proyecto,
token de aplicación,
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
afijo,
configuración
) => {
constante CMSIdentifier = config?.cmsType?.toLowerCase();
cambiar (Identificador CMS) {
caso 'Sitecore':
regreso en espera crearSitecoreMapper(fileRuta, projectId, app_token, afijo, config);
caso 'contento':
regreso en espera createContentfulMapper(proyectoId, token_de_aplicación, afijo, configuración); caso 'wordpress':
devolver crearWordpressMapper(fileRuta, projectId, app_token, afijo); por defecto:
devolver FALSO;
}
};
Cada caso corresponde a un CMS y llama a su función mapeadora.
Cómo agregar un nuevo CMS
Paso 1: Agregar caso en createMapper
Agregue un nuevo caso para su identificador de CMS:
JavaScript
caso 'nuevocms': {
regreso en espera crearNuevoCMSMapper(fileRuta, projectId, app_token, afijo, config);
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
}
Paso 2: Crear la función Mapper
Implementar una nueva función como:
JavaScript
constante crearNuevoCMSMapper = asíncrono (fileRuta, projectId, app_token, afijo, configuración) => {
// 1. Leer y transformar file contenido
// 2. Generar objeto de mapeo de campo
// 3. Enviar a /v2/mapper/createDummyData
// 4. Genere la asignación de configuración regional y llame a /v2/migration/localeMapper };
Paso 3: Realizar una llamada a la API de datos ficticios
Utilice axios como la implementación existente:
JavaScript
constante configuración = {
método: 'correo',
longitud máxima del cuerpo: Infinidad,
url:
`${process.env.NODE_BACKEND_API}/v2/mapper/createDummyData/${projectId}`, encabezados: {
token de aplicación,
'Tipo de contenido': 'aplicación/json'
},
datos: JSON.stringify(campoMapping),
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
};
constante { datos } = esperar axios.solicitud(config);
if (datos?.datos?.content_mapper?.longitud) {
deleteFolderSync(infoMap?.ruta);
registrador.info('Validación exitosa:', {
estado: HTTP_CODES?.OK,
mensaje: HTTP_TEXTS?.MAPPER_SAVED,
});
}
Paso 4: Manejar la asignación de configuración regional
Si su CMS admite la localización, agregue esto o agregue en-us como predeterminado:
JavaScript
constante mapperConfig = {
método: 'correo',
longitud máxima del cuerpo: Infinidad,
url:
`${process.env.NODE_BACKEND_API}/v2/migration/localeMapper/${projectId}`, encabezados: {
token de aplicación,
'Tipo de contenido': 'aplicación/json'
},
datos: {
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
lugar: Formación.from(datos locales) ?? []
}
};
esperar axios.solicitud(mapperConfig);
Ejecutando el API de carga Proyecto en cualquier sistema operativo
Las siguientes instrucciones le guiarán en la ejecución del API de carga carpeta en cualquier sistema operativo, incluidos Windows y macOS.
Comenzando el API de carga Proyecto
Hay dos métodos para iniciar el API de carga proyecto:
Método 1:
Ejecuta el siguiente comando desde el directorio raíz de tu proyecto:
Caparazón
npm run upload
Este comando iniciará directamente el API de carga paquete.
Método 2:
Navegar hasta el API de carga directorio manualmente y ejecutar el servidor de desarrollo:
Caparazón
cd API de carga
npm run start
Este enfoque inicia el API de carga desde dentro de su propio directorio.
Reiniciar después de la finalización
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
Si el proyecto finaliza inesperadamente, puede reiniciarlo siguiendo los mismos pasos descritos anteriormente. Elija el Método 1 o el Método 2 para reiniciar el servicio.
Si tiene alguna pregunta, comuníquese con nosotros. tso-migration@contentstack.com.
Documentos / Recursos
 |
Guía de la API del conector de CONTENTSTACK CMS [pdf] Guía del usuario Guía de la API del conector CMS, Guía de la API del conector, Guía de la API |