Consulta o recuperación de datos en la base de datos en la nube
Los implementadores de sistemas (SI) y los administradores que trabajan en la solución IBM Sterling® Order Management System en la nube tienen requisitos para consultar o recuperar datos de la base de datos con diversos fines, como examinar los datos rellenados en la base de datos, investigar problemas con los datos empresariales, solucionar problemas, realizar comprobaciones cruzadas o análisis con otros sistemas de su pila, extraer datos con fines analíticos, proporcionar rellenos posteriores, etc.
Acerca de esta tarea
Los requisitos pueden ser durante las fases de desarrollo o prueba de la aplicación y después de que las aplicaciones estén disponibles para el usuario final. En algunos escenarios, es posible que deseen probar las consultas de base de datos que ejecutan las API de aplicación para determinar si la aplicación funciona como se esperaba o no. De forma similar, el personal de soporte de IBM que tenga en cuenta los problemas notificados por SI puede necesitar datos de base de datos para resolver los problemas de forma eficaz. Estos requisitos se basan en la demanda y, por lo general, no captan un gran volumen de datos. Existen otros requisitos como extraer datos en canales de información continuos casi en tiempo real o de forma diferida. Las soluciones de canal de información continuo realizan un seguimiento del canal de información anterior y extraen lo que se acaba de añadir o modificar después del último extracto.
Además, algunas implementaciones pueden requerir extraer los datos completos de la tabla. Pueden tener herramientas internas para el análisis y se encontró un valor significativo al extraer y analizar tales datos. Las características de este requisito son diferentes de las anteriormente mencionadas. En primer lugar, no significa como un canal de información continuo, los usuarios lo ejecutan como y cuando lo necesitan. El mismo requisito puede o no volver a surgir. En segundo lugar, estas pueden ser solicitudes independientes, no tienen ninguna relación con los intentos anteriores incluso si las consultas son las mismas y, por lo tanto, se extraen de todos los datos de la tabla. En tercer lugar, no tiene por qué ser un extracto ciego. Es para que las herramientas internas las analicen y quieren que solo se extraigan los datos relevantes de la base de datos en la nube basándose en alguna cláusula o criterio. En cuarto lugar, debido a todos los aspectos mencionados, no hay control sobre el volumen de registros coincidentes. Podría ser numeración de un dígito o dos dígitos, unos cientos, en miles o puede ser 100 mil o incluso más. Depende únicamente de la cláusula o criterios que desee invocar.
Hay otros temas a considerar, como la entrega de los resultados de la consulta. Existen restricciones en el entorno de nube para almacenar los resultados en un sistema de archivos y descargarlos por separado. Aunque la infraestructura de definición de servicios da soporte a muchos mecanismos de entrega, algunos de ellos no son los más adecuados para el entorno de nube. Por lo tanto, las opciones son, o bien enviar los resultados como una respuesta HTML al navegador donde los usuarios realizaron la solicitud o realizarla de forma asíncrona y FTP a un servidor remoto accesible para el SI (también puede ser un sitio de cliente) utilizando una configuración SFTP preconfigurada. Otro aspecto es dónde ejecutar este tipo de solicitudes. Es posible que el proceso de estas solicitudes en el servidor de aplicaciones se pueda bloquear porque no hay ninguna garantía de que estas solicitudes capten sólo un volumen de datos viable. Por lo tanto, la solución IBM Sterling Order Management System recomienda que la recuperación de grandes volúmenes de datos se ejecute de forma asíncrona en una JVM independiente, como el Agente o el servidor de Integración. Estas transacciones asíncronas requieren un mecanismo para alertar al usuario cuando se realiza el trabajo o cómo el usuario puede saber si la solicitud se ha completado.