Consultando ou recuperando dados no banco de dados em nuvem
Os implementadores de sistema (SI) e administradores que trabalham com a solução IBM Sterling® Order Management System na nuvem têm requisitos para consultar ou recuperar dados do banco de dados para várias finalidades, como examinar os dados preenchidos no banco de dados, investigar problemas com dados comerciais, solucionar problemas, fazer verificações cruzadas ou análises com outros sistemas em sua pilha, extrair dados para fins analíticos, fornecer preenchimentos de volta e assim por diante.
Sobre esta tarefa
Os requisitos podem ser durante as fases de desenvolvimento ou de teste do aplicativo e após os aplicativos estarem disponíveis para o usuário final Em alguns cenários, eles podem desejar testar as consultas de banco de dados que são executadas pelas APIs do aplicativo para verificar se o aplicativo funciona conforme esperado ou não. Da mesma forma, a equipe de Suporte IBM que considera os problemas relatados pelo SI pode precisar de dados do banco de dados para solucionar os problemas de forma efetiva Esses requisitos são baseados sob demanda e geralmente não buscam um volume enorme de dados. Existem outros requisitos, como extrair dados em feeds contínuos quase em tempo real ou de forma adiada. As soluções de alimentação contínua acompanham o alimento anterior e extraem o que foi adicionado ou modificado após o último extrato.
Além disso, algumas implementações podem exigir a extração de todos os dados da tabela. Eles podem ter ferramentas internas para análise e valor significativo foi encontrado a partir da extração e análise desses dados. As características desse requisito são diferentes das mencionadas anteriormente. Em primeiro lugar, não significa como um feed contínuo, os usuários executam isso como e quando precisam. O mesmo requisito pode ou não surgir novamente. Em segundo lugar, elas podem ser solicitações independentes, não têm relação com as tentativas anteriores, mesmo se as consultas forem as mesmas e, portanto, extrai dos dados da tabela inteira. Em terceiro lugar, não precisa ser um extrato cego. Cabe às ferramentas internas analisar e elas desejam que apenas os dados relevantes sejam extraídos do banco de dados de nuvem com base em alguma cláusula ou critério. Em quarto lugar, devido a todos os aspectos mencionados, não há controle sobre o volume de registros correspondentes. Pode ser numeração de dígitos simples ou duplos, algumas centenas, em milhares ou pode ser 100 mil ou até mais. É puramente dependendo da cláusula ou critérios que você deseja chamar.
Há outros assuntos para ponderar, como a entrega dos resultados da consulta. Há restrições no ambiente de nuvem para armazenar os resultados em um sistema de arquivos e fazer o download deles separadamente Embora o Service Definition Framework suporte muitos mecanismos de entrega, alguns deles não são mais adequados para o ambiente de nuvem. Portanto, as opções são: enviar os resultados como uma resposta HTML para o navegador no qual os usuários fizeram a solicitação ou executá-la de forma assíncrona e FTP para um servidor remoto acessível para o SI (também pode ser um site do cliente) usando uma configuração de SFTP pré-configurada. Outro aspecto é onde executar esses tipos de pedidos. É possível que o processamento dessas solicitações no servidor de aplicativos possa travar sozinho, pois não há garantia de que essas solicitações busquem apenas um volume de dados viável. Portanto, a solução IBM Sterling Order Management System recomenda que a recuperação de grandes volumes de dados seja executada de forma assíncrona em um JVM separado, como o Agent ou o servidor de integração. Essas transações assíncrona requerem um mecanismo para alertar o usuário quando a tarefa for concluída, ou como o usuário pode saber se a solicitação está concluída ou não.