Cuatro razones para usar Screen Scraping en lugar de un API

Uno de los  mecanismos más característicos que incluyen todas o la mayor parte de las soluciones de Automatización Robótica de Procesos para interaccionar con aplicaciones existentes, ya sean éstas aplicaciones corporativas o aplicaciones de terceros, típicamente en la web, es el Screen Scraping, es decir, la obtención de datos a partir de las propias pantallas de las aplicaciones con las que se necesita interactuar.

Es éste un mecanismo en cierto sentido atípico en la disciplina de integración de sistemas. Estamos acostumbrados a la integración de aplicaciones a partir de API ('Application Programmatic Interface') ofrecidos como servicios. Y desde hace años se propone SOA ('Service Oriented Architecture') como la mejor forma de estructurar la integración entre sistemas. Y SOA, propone, precisamente, la creación de esos servicios y esas APIs.

¿Entonces? ¿Por qué usar Screen Scraping? ¿No es ese mecanismo una suerte de rodeo a las buenas prácticas de arquitecturas¿ ¿No es casi, casi, una 'chapucita'?

Bueno, si y no.

Hay que dejarlo claro: desde un punto de vista de arquitectura de sistemas es claramente preferible, muy preferible, la integración a través de APIs y, si es posible, con arquitectura SOA. Sin embargo, a nivel práctico, cuando añadimos consideraciones de naturaleza temporal, presupuestaria y otras, hay ocasiones en que puede tener sentido, lo tiene de hecho, usar un método más relajado como es screen scraping, una de cuyas virtudes, probablemente la principal, y que traslada como propuesta de valor a RPA, es que no necesita modificar en absoluto la aplicación con que se integra, no pide ningún desarrollo concreto... ni siquiera la existencia de un API.

He iniciado la lectura del libro 'Web Scraping with Python' de Ryan Mitchell y en él, tras reconocer que las APIs son el mecanismo preferente de integración, la autora aporta cuatro razones, o cuatro situaciones en que se justifica utilizar Screen Scraping (en su caso,Web Scraping, es decir, la variante del Screen Scraping que se centra en pantallas Web). Son estas:

• Cuando lo que se quiere es recopilar conjuntos finitos de datos de una larga serie de aplicaciones web sin que exista un API coherente en todas ellas.


• Cuando los datos que se quieren recoger son de poco volumen y no muy habituales, por lo que las aplicaciones no disponen de un API para ello (y, añado yo, no vale la pena desarrollarla)


• La fuente ni dispone, por alguna razón, de la infraestructura o capacidad técnica (o, añado yo, temporal o presupuestaria) para desarrollar un API.


• Los datos a los que queremos acceder son valiosos o están protegidos y no se prevé distribuirlos de forma amplia.

Creo que, quizá, se podría añadir alguna situación más, pero la idea básica es bastante clara: en general es preferible usar APIs, pero Screen Scraping puede ser una alternativa razonable cuando, por un lado, no existe ese API y, por otro, no vale la pena desarrollarlo.