#Herramienta para simplificar la interacción con la API de ZeroQ.

Instalacion

Puede importarse como un módulo de npm de la siguiente forma:

npm install --save zeroq-sdk # o yarn add zeroq-sdk

También se puede importar directamente en el HTML:

<!-- para importar una versión en específico -->
<script src="https://cdn.zeroq.cl/sdk/zeroq-sdk-v1.1.6.js"></script>

<!-- para importar la última versión -->
<script src="https://cdn.zeroq.cl/sdk/zeroq-sdk-latest.js"></script>

Proceso de obtención de tickets

Para obtener un ticket, el usuario debe haber seleccionado:

1. Una oficina
2. Una línea (o trámite) dentro de esa oficina

Obtener el listado de oficinas

import ZeroQ from 'zeroq-sdk'

// En el caso del bundle: const zq = new ZeroQ.default({token:"1234"});

const zq = new ZeroQ({ token: '1234' })

// o por medio de vanilla
//<script src="https://cdn.zeroq.cl/sdk/zeroq-sdk-v1.1.4.js"></script>
const zeq = new ZeroQ.default({ token: '1234' })

// Obtiene todas las oficinas
const offices: Promise<Array<Office>> = zq.getOffices()

Ejemplo de filtrar una oficina

const offices = await getOffices()
const aguasAndinasOffice = offices.filter(
  (o) => o.officeSlug === 'aguas-andinas'
)

El arreglo de oficinas puede ser mapeado a una lista de elementos HTML entre los que el usuario podrá elegir (como referencia, ver las oficinas en https://zeroq.cl/search?category=demos)

Cada oficina cuenta con un método getLines() para obtener un arreglo de líneas.

const lines: Array<Line> = office.getLines()

Crear un ticket

El ticket siempre estará vinculado a una línea. Al llamar al método pickTicket(), se obtiene un ticket para dicha línea:

line.pickTicket({
  onSuccess(t) {
    console.log('ticket was picked', t)
  },
  onCall(t) {
    console.log('ticket was called', t)
  },
  onError(e) {
    console.error('an error occurred', e)
  },
})

Internamente, la librería espera que se gatille el evento de confirmación de un ticket, lo que es representado en el código por una función callback que se ejecuta cuando se recibe este evento.

Es importante diferenciar, tanto para tickets como para reservas, los eventos de creación y confirmación:

• Creación: la API en la nube reconoce la intención de un usuario de obtener un ticket en una oficina y guarda este registro en su base de datos. En este momento, el ticket todavía no es válido para ser atendido.

• Confirmación: la API se comunica exitosamente con el local y este guarda un ticket o reserva para ser atendido.

// Obtiene las reservas del usuario
const reservations: Promise:<Array<Reservation>> = zq.getUserReservations();

// Obtiene las líneas (trámites) de la oficina
const lines: Array<Line> = office.getLines();

// Se suscribe a los eventos de creación de ticket, error y llamada
// del ticket
line.pickTicket({
    onSuccess(t) { console.log("ticket was picked", t) },
    onCall(t) { console.log("ticket was called", t) },
    onError(e)  { console.error("an error occurred", e) }
});

// Obtiene los bloques horarios
const blocks: Array<TimeBlock> = line.getTimeBlocks(new Date())

// Efectúa una reserva y se suscribe
blocks[0].reserve({
    onSuccess(t) { console.log("ticket was picked", t) },
    onCall(t) { console.log("ticket was called", t) },
    onError(e)  { console.error("an error occurred", e) }
});

Tenant dedicado

El SDK apunta por defecto a la plataforma compartida (zeroq.cl). Si una organización se migra a un tenant dedicado (por ejemplo cajalosandes.zeroq.cl), la integración no cambia nada: al inicializar, el SDK consulta una sola vez GET https://zeroq.cl/api/v3/organizations/{organization} (público, sin token) y, si la organización trae options.tenantConfig, todo el flujo —login de usuario temporal, API, socket, tickets web, bloques de reserva y meet— se va al tenant. Las claves son URLs base (esquema + host + ruta), así se cubren tanto los subdominios (aws., services.) como las rutas distintas de cada servicio.

Caso típico — un tenant detrás de un solo ingress con las rutas estándar: basta api, y de él se derivan socket, ticket y blocks; meet sigue siendo el compartido.

{ "tenantConfig": { "api": "https://cajalosandes.zeroq.cl" } }

Equivale a, y cualquier clave explícita gana sobre la derivada:

{
  "tenantConfig": {
    "api": "https://cajalosandes.zeroq.cl",
    "socket": "wss://cajalosandes.zeroq.cl/socket",
    "ticket": "https://cajalosandes.zeroq.cl/services/turn-o-matic",
    "blocks": "https://cajalosandes.zeroq.cl/services/reservations/api/v3",
    "meet": "https://meet.zeroq.cl"
  }
}

| Clave | Qué cubre | Compartido | | -------- | --------------------------------------------------------------------------------------------------- | --------------------------------------------------- | | api | /api/*, /services/* (organizations, reservations, forms), /login/v3/temporary, /meet/verify | https://zeroq.cl | | socket | Phoenix (tickets en vivo) | wss://zeroq.cl/socket | | ticket | turn-o-matic (tickets web) → {ticket}/offices/{id}/tickets/new | https://aws.zeroq.cl/services/turn-o-matic | | blocks | bloques de reservas v3 → {blocks}/blocks/... | https://services.zeroq.cl/reservations/api/v3 | | meet | sala de meet → {meet}/{tuid} | https://meet.zeroq.cl |

Reglas:

• URLs absolutas sin query ni hash, https: (wss: para socket) y solo dominios *.zeroq.cl; un valor inválido descarta todo el tenantConfig con un console.warn y se usa el compartido.
• Si la consulta falla (timeout 3 s, red, 404) el SDK sigue apuntando al compartido, igual que hoy.
• Ninguna request ni conexión de socket sale antes de resolver el tenant.
• Con typeHost (QA, LAB, DEV, STAGING) la consulta se hace contra ese ambiente, así el switch se puede ensayar en QA poniendo la option en la organización de QA.

Ejecutar ejemplo

1. git clone https://github.com/rafael180496/example-sdk-call.git
2. npm install
3. npm start

Consumir Bundle Local

1. npm install -g http-server
2. cd dist/
3. http-server ./
4. <script src="http://127.0.0.1:8080/bundle.js" type="text/javascript"></script>