Automatización de Procesos de Negocio con Flowable en la industria del Broadcasting - Parte 1
La industria del broadcasting es una de las industrias que mas ha evolucionado en los últimos años. En algo menos de 10 años, ha pasado de tener flujos de trabajo en los que se intercambiaba algún material físico, a ser completamente digital y basados en contenidos (content-centric workflows). Pero ahora, gracias a plataformas como Netflix o Amazon Prime Video, esta industria necesita ser mas ágil a la hora de adaptarse a lo que su audiencia está demandando.
Con la ayuda de un gestor de flujos, las cadenas o canales de televisión, proveedores de servicios de vídeo bajo demanda (VOD), difusión o telecomunicaciones, pueden gestionar sus flujos de trabajo, y con ello, pueden ser más rápidos a la hora de hacer cambios, y ajustarse a lo que su audiencia está exigiendo.
En los flujos basados en contenidos, los encargados de la transmisión deciden cómo y cuándo poner el contenido disponible para el que lo vea. El contenido se puede lanzar en varios y diferentes servicios y plataformas, así como en televisión lineal o canales de radio. Algunos solamente gestionan servicios por demanda, mientras que otros solamente gestionan canales lineales. Y obviamente, aquellos que tienen la capacidad, gestionan ambos para darle el máximo valor a su contenido.
En este artículo, repasaremos a nivel general los diferentes procesos de negocios que participan en los servicios de Broadcasting, para luego pasar a hablar sobre la solución técnica, en la que mostramos cómo Flowable puede ayudar en la automatización de la ingesta de material nuevo.
Figura #1: Flujo de Broadcasting
Todo comienza con la adquisición del material audiovisual que pueden ser películas, series, o programas en vivo por decir alguno. Normalmente el material se adquiere una vez visualizado algún programa piloto o demo que fue enviada por las casas de producción. Una vez adquirido, se crea un registro en la librería de contenidos digitales (Sintec OnAir por ejemplo), y se le añade a cada uno metadatos descriptivos, así como sus respectivos derechos de transmisión y el medio en el que esos derechos de transmisión son válidos(televisión lineal, catch-up y/o VOD).
La finalización de la compra también es el disparador de dos cosas importantes. Una de ellas, es que los encargados de hacer las diferentes programaciones del material según el servicio o plataforma, pueden ir incluyéndolo en los borradores. Por ejemplo, en la televisión lineal, los encargados de programar las listas de reproducción diarias pueden ya ir incluyendo este material en borradores de las mismas.
La segunda acción que se dispara, es que las casas productoras envíen ese material. Habitualmente, el envío se hace por algún medio de transporte digital, ya sea por discos duros, protocolos de transmisión (FTP), o por algún acelerador de transferencias (Aspera).
Los borradores de las diferentes programaciones, permiten a los operadores de control de calidad, priorizar el orden en que el material se almacenará internamente (en un MAM por ejemplo). Así mismo se prioriza el versionado del material dependiendo de la región en el que se vaya a transmitir.
A partir de aquí, el flujo de trabajo cambia según el servicio o plataforma en donde se publique el material. En un siguiente artículo, analizaremos a detalle los flujos para preparar el material audiovisual según este se utiliza para la televisión lineal o para servicios por demanda.
La Arquitectura
Figura #2: Arquitectura
La arquitectura sigue el patrón de diseño conocido como saga, y donde Flowable es el orquestador de todo, teniendo como responsabilidad, la de decirle a cada participante qué hacer y cuándo, ofrecer flexibilidad para adaptar la solución a las necesidades del negocio en cada momento y definir las transacciones de negocio y los mecanismos de rollback en caso de error.
Y en el centro de la arquitectura, encontramos Kafka como medio de transmisión de los mensajes para los diferentes eventos. Gracias a esta pieza desacoplamos los microservicios y podemos adoptar el paradigma de programación reactiva, habilitando al negocio a reaccionar ante cualquier evento.
Adicionalmente, tenemos los siguientes microservicios:
- Delivery Service: Para nuestro ejemplo, este micro detecta la entrega de algún material audiovisual. Pero en la práctica, el micro también es el encargado de entregar material.
- Scheduling App: Aplicación que un usuario utiliza para crear las listas de reproducción diarias de un canal lineal.
- QC Service: Servicio que ejecuta un control de calidad automatizado sobre algún material, y que ha sido previamente configurado.
- Metadata Service: Servicio que recolecta información técnica y descriptiva sobre algún material.
- Transcoding Service: Micro encargado de convertir el material de un formato a otro.
- Storage Service: Servicio encargado de gestionar el almacenamiento local y en la nube.
- Content Library: Aplicación de terceros donde se almacena información descriptiva sobre los materiales.
- Media Assets Management (MAM): Aplicación de terceros donde se puede gestionar el material físico, ver información técnica asociada, y pre visualizar una copia del mismo en baja resolución.
- Flowable App: Aplicación Spring Boot con el motor de Flowable integrado para gestionar los flujos de trabajo.
Nota: El intercambio de mensajes que se describe a continuación, es para el caso en el que se espera que la ingesta del material nuevo fluya sin problema alguno.
Cuando un nuevo material es recibido por Delivery Service, este envía dos mensajes. El mensaje Move file to a temp storage hace que el micro Storage Service mueva el archivo recibido a un almacenamiento temporal de mayor capacidad. Al terminar envía el mensaje File moved.
El segundo mensaje enviado es el Check file is already scheduled, el cual es detectado por Scheduling App. El Scheduling App, analiza si ese material ya está añadido a una lista de reproducción diaria, sin importar si es un borrador o definitiva. Si lo está, envía un mensaje Is scheduled.
Al detectarse los mensajes Check file is already scheduled y Is scheduled, el micro Flowable App levanta el flujo de ingesta de material.
Como primer paso, Flowable App envía los mensajes Execute automatic quality control y Gather technical / descriptive metadata. El primer mensaje es capturado por el micro QC Service, el cual al terminar el control de calidad automatizado, envía de vuelta el mensaje QC ended. El segundo mensaje, es recibido por el micro Metadata Service. Al terminar de recolectar la información técnica y descriptiva, envía el mensaje Metadata gathered.
Al confirmar el operador de QC que el material está bien y que ha pasado correctamente el control de calidad, Flowable App prosigue a enviar los mensajes Add descriptive metadata y Add technical metadata para que se añada la información descriptiva a la Librería de Contenidos (Content Library), y la técnica al gestor de activos (Media Assets Management – MAM).
Al mismo tiempo Flowable App le indica al micro Transcoding Service que genere una copia del archivo original en baja resolución mediante el mensaje Generate low-res. La recepción del mensaje Low-res generated por parte de Flowable App, indica que la baja se ha creado, y que se debe de continuar subiendo tanto el archivo de alta como de baja resolución a su almacenamiento final.
Los comandos Upload high- y Upload low-res to MAM storage enviados por Flowable App, le ordenan al micro Storage Service que los suba a su almacenamiento definitivo. Dependiendo del tamaño de los archivos, esto puede llevar unos cuantos minutos, por lo que al terminar, el micro Storage Service debe de enviar los mensajes High- y low-res uploaded.
Finalmente, es importante que el Media Assets Management sepa la ubicación exacta del archivo, para que pueda recuperarlo y enviarse a los diferentes proveedores de servicios que lo necesiten. Es por ello, que se envían los mensajes Mark high- y low-res as uploaded to MAM storage.
Ingesta de Material Adquirido
Figura #3: Caso: Ingesta de material
El flujo de ingesta de material es muy sencillo. En la fase “Quality Control Stage”, se recolecta información descriptiva y técnica sobre el material (Metadata Service), y también se le pasa un análisis automatizado para detectar errores (QC Service) – ver subproceso Gather Material Metadata and Automatic QC. Una vez finalizado, un operador de QC, es quien determina si el material es apto para su transmisión o no, o si necesita una edición previa.
Figura #4: Proceso Recolección de metadatos y control de calidad automático
Si por alguna razón, el material tiene algún defecto como un drop-frame por ejemplo, se pasa a la fase de “QC Not Passed” – ver subproces Material Ingestion Rejection. A efectos de demo, en esta fase simplemente se notifica que el material ha sido rechazado, pero perfectamente podría solicitarse automáticamente el reenvío del material a la casa distribuidora.
Figura #5: Proceso Material rechazado
Por otro lado, en ocasiones el material recibido requiere de alguna edición, en estos casos, se pasa a la fase de “Need Editing”. Estando en esta fase, seguramente el operador de QC editará el archivo original utilizando alguna herramienta de edición, y al finalizar tiene como resultado un nuevo archivo, que se considera como que ha pasado el control de calidad.
Finalmente, pasamos a la fase de “QC Passed”. Es en esta fase, donde la información previamente recolectada es añadida al Content Library, y al Media Assets Management (MAM). Al mismo tiempo, el servicio Transcoding Service genera una copia del archivo original de menor resolución.
Figura #6: Proceso Material aceptado
Para finalizar, el servicio Storage Service sube tanto el archivo en alta resolución como el de baja al almacenamiento utilizado por el Media Assets Management (MAM), para que esté disponible.
Resumen
En este artículo, y tomando como ejemplo el proceso de ingesta de material adquirido, hemos mostrado cómo puede ser una arquitectura con múltiples microservicios para la industria del Broadcasting, utilizando Flowable como gestor de procesos de trabajo, y Kafka para enviar mensajes entre los diferentes servicios.
Así mismo, hemos podido ver cómo gracias a la orquestación realizada por Flowable, podemos automatizar varias tareas, y con ello, hacer que el usuario tenga mas tiempo para las tareas que realmente no pueden ser automatizadas, e interactuar con el sistema únicamente cuando sea estrictamente necesario.
En nuestro siguiente artículo, analizaremos a detalle los flujos para preparar el material audiovisual según este se utiliza para la televisión lineal o para servicios por demanda. Y veremos rol que Flowable puede llegar a ocupar en la publicación automática de material según el servicio o plataforma.
El código ejemplo lo hemos subido a GitHub.