Prepare a Working Directory
Create a project folder with the following files:
template file (for example, invoice.template)
data file in JSON (for example, data.json)
optional assets (images, CSS)
Example structure:
quickstart/
template.invoice.html
data.json
assets/
logo.png
styles.css
Create a Template
Use the token syntax supported by your template engine. Replace the placeholders below with your engine’s syntax (for example, {{variable}} or ${variable}).
Example HTML template (template.invoice.html):
Invoice {{invoice.number}}
Invoice {{invoice.number}}
Date: {{invoice.date}}
Bill To
{{customer.name}} {{customer.address}}
Items
Description
Qty
Unit
Total
{{#each items}}
{{description}}
{{quantity}}
{{unit_price}}
{{total}}
{{/each}}
Subtotal
{{summary.subtotal}}
Tax
{{summary.tax}}
Grand Total
{{summary.grand_total}}
Note: If your engine uses a different syntax, replace {{...}} and {{#each}} blocks accordingly.
Create a Data File
Create data.json aligned with your template variables.
Generate a Document via CLI
Use the CLI to merge the template with your data and produce an output file. Replace flags with the actual CLI options provided by .
--format can be pdf, html, or docx based on your product’s supported outputs.
--assets points to local files referenced by the template.
Ensure the output directory exists, or provide a flag to create it if supported.
Generate a Document via REST API
If your product offers a REST endpoint, submit a multipart or JSON request. The following is an example pattern; adjust to match your API’s specification.
Example with multipart form:
Command:
curl -X POST "<BASE_URL>/v1/render"
-H "Authorization: Bearer $_API_KEY"
-F "template=@template.invoice.html;type=text/html"
-F "data=@data.json;type=application/json"
-F "assets=@assets/logo.png;type=image/png"
-F "assets=@assets/styles.css;type=text/css"
-F "options={"format":"pdf"};type=application/json"
--output invoice-1001.pdf
Example with JSON and remote assets:
Command:
curl -X POST "<BASE_URL>/v1/render"
-H "Authorization: Bearer $_API_KEY"
-H "Content-Type: application/json"
-d '{
"template": {"content_base64": ""},
"data": { ... same as data.json ... },
"assets": [{"url": "https://example.com/logo.png"}],
"options": {"format": "pdf"}
}'
--output invoice-1001.pdf
Verify the Output
Open the generated PDF or HTML and confirm variable substitution, loops, and asset loading.
Check fonts and encoding (for example, non-Latin characters) appear correctly.
Common Errors and Resolutions
Missing variable: A placeholder remains unreplaced.
Action: Ensure the data key exists and matches the template’s variable name; check case sensitivity.
Template syntax error:
Action: Validate template against your engine’s syntax; remove unsupported constructs.
Malformed JSON:
Action: Validate data.json with a JSON linter.
Asset not found:
Action: Confirm relative paths and that CLI/API includes the assets directory or accessible URLs.
Permissions denied when writing output:
Action: Verify the output directory permissions or run with appropriate privileges.
PDF rendering issues (layout overflow, missing fonts):
Action: Add a font that supports required glyphs; apply CSS for page breaks; embed fonts if required by the renderer.
Security Considerations
Do not commit API keys or secrets to version control. Use environment variables or a secret manager.
Sanitize or validate template input if accepting user-provided templates to prevent template injection.
Restrict network access if remote asset loading is enabled.
Automation and CI
Run the CLI in CI pipelines to produce artifacts on merges or releases.
Cache dependencies and assets for faster builds.
Store outputs as build artifacts or publish to a document repository.
Next Steps
Explore template partials, layouts, and helpers provided by .
Configure page settings (margins, headers/footers, page size) for PDF outputs.
Set up localization and currency formatting.
Integrate webhooks or callbacks for asynchronous rendering.
Use version control for templates and establish a review process.
Support
Refer to the API reference for parameter details and limits.
Contact support with the following information: request ID (if available), CLI version, API endpoint, and a minimal reproducible example (template and data).
Replace , , <BASE_URL>, and any placeholders with your actual product values. Ensure flags and endpoints match the versions you deploy.
Guía de inicio rápido: Base de conocimiento para gestión de tickets
Objetivo
Proveer instrucciones precisas para poner en marcha, en corto tiempo, una base de conocimiento (KB) integrada al flujo de tickets de soporte, con controles de calidad, gobernanza y medición de valor.
Alcance
Creación inicial de estructura, roles, flujos y plantillas.
Publicación del primer contenido reutilizable.
Habilitación de vínculos KB↔ticket y ciclo de mejora continua.
Audiencia
Propietarios de proceso de soporte/ITSM.
Administradores de la plataforma de KB.
Editores/Agentes de soporte.
Requisitos previos
Acceso a la plataforma de tickets y a la KB con permisos de administración.
Definición mínima de catálogo de servicios o categorías de incidentes.
Aprobación de políticas de seguridad de datos (PII, credenciales, información confidencial).
Acuerdos de ANS de publicación (p. ej., revisión en 2 días hábiles).
Terminología clave
Artículo: unidad de conocimiento publicable.
Metadatos: atributos que facilitan búsqueda, filtrado y gobierno.
Flujo de trabajo: estados y transiciones (borrador, en revisión, aprobado, publicado, archivado).
Reutilización: veces que un artículo resuelve o ayuda a resolver tickets.
Roles y permisos (modelo recomendado)
Administrador de KB: configura estructura, flujos, permisos y metadatos.
Editor/Autor: crea y actualiza artículos.
Revisor/Aprobador: valida exactitud técnica, cumplimiento y estilo.
Agente: consulta y vincula artículos a tickets, sugiere mejoras.
Consumidor final: lee artículos publicados (según visibilidad).
Pasos de puesta en marcha (aprox. 60–90 minutos)
Configurar roles y permisos
Crear grupos por rol (Administrador, Editor, Revisor, Agente).
Establecer visibilidad por audiencia: interna (agentes) y externa (usuarios finales), según necesidad.
Definir estructura de la KB
Crear 5–10 categorías iniciales alineadas al catálogo de servicios (p. ej., Acceso/Identidad, Estaciones de trabajo, Redes, Aplicaciones corporativas).
Limitar profundidad a 2–3 niveles para facilitar navegación.
Establecer metadatos obligatorios
Título, Resumen, Categoría, Etiquetas, Audiencia, Idioma, Propietario, Fecha de revisión próxima, Versión, Estado.
Reutilización: número de tickets resueltos con un artículo.
Tasa de deflexión: consultas resueltas sin creación de ticket.
Tiempo de publicación: desde borrador hasta publicado.
Porcentaje de artículos con revisión vigente.
Utilidad percibida: calificación promedio > X.
Cobertura: porcentaje de categorías con al menos N artículos vigentes.
Mantenimiento continuo
Rutina semanal: revisar feedback nuevo, actualizar 10% de artículos más usados.
Rutina mensual: análisis de brechas (categorías con baja cobertura), limpieza de duplicados.
Rutina trimestral: auditoría de cumplimiento y accesos, revisión de taxonomía.
Lista de verificación de puesta en marcha
Roles y permisos creados.
Categorías y metadatos definidos.
Flujo de trabajo activo con aprobaciones.
Plantillas cargadas y comunicadas.
Primer artículo publicado y vinculado a tickets.
Sugerencias automáticas habilitadas.
Panel de métricas configurado.
Políticas de seguridad aplicadas.
Calendario de revisión establecido.
Con esto, la base de conocimiento queda operativa, conectada al ciclo de tickets y con controles para asegurar calidad, seguridad y mejora continua, alineada con prácticas de gestión del conocimiento ampliamente aceptadas (p. ej., centradas en reutilización y mantenimiento sistemático).
