Bom dia.
Por gentileza, eu gostaria muito da opinião de vocês.
Eu possuo uma aplicação que busca no CRM todos os contatos de todas as contas, além de produtos e outras informações que acabam tornando chamadas ao Web Services muito demoradas.
Atualmente, o sistema está implementado para buscar essas informações no Web Services, na inicialização do potlet, aplicação, etc. Isso torna a aplicação pouco amigável para o usuário, já que demora até cinco minutos para que a resposta seja retornada.
Bem, não seria uma solução elegante, ao meu ver, criar uma tabela no banco que atualizasse esses dados diariamente, por exemplo, porque o banco do portal é criado através de engenharia reversa, ou seja, quando eu precisasse recriar o schema, teria que criar essas tabelas customizadas, enfim, eu não quero manter essas informações persistidas no banco de dados.
Alguém pode sugerir uma solução ou material que indique a melhor pratica para esse tipo de problema?
Muito obrigado a todos!
[]'s
Prezado, você mencionou que o banco de dados é criado através de engenharia reversa. Seria uma reversão baseada em algum diagrama UML ou seria das anotações JPA/Hibernate das próprias classes da aplicação?
Caso o schema do banco de dados seja criado automaticamente pela engine de persistência, você poderia criar essa tabela customizada através de um script sql que seria aplicado automaticamente pelo JPA/Hibernate no momento do deploy da aplicação, bastando para isso adicionar a seguinte tag no persistence.xml
<properties>
<property name="hibernate.hbm2ddl.import_files" value="/sql/import.sql"/>
</properties>
Considerando outras opções que não utilizem o armazenamento no bano de dados:
1) Armazenamento em arquivo xml
Uma opção poderia ser a utilização do recurso de schedule do Java EE para acessar o webservice periodicamente e armazenar os dados em um arquivo XML no servidor. Esse arquivo seria utilizado como fonte dos dados para carregar o portlet.
2) Armazenamento em um Bean com @ApplicationScope
Caso sejam poucas informações e elas não sejam sensíveis ao perfil do usuário logado na aplicação, uma outra opção poderia ser a utilização do recurso de schedule do Java EE para acessar o webservice periodicamente e armazenar os dados em um objeto EJB com o escopo @ApplicationScope. Com isso, os dados armazenados nesse bean estaria acessíveis para toda a aplicação.
[color=red]Caso as informações sejam sensíveis ao perfil do usuário, não utilize o scopo @Session. Essa opção não é escalável e pode gerar problemas de consumo excessivo de memória.[/color]
Ambas opções trariam maior velocidade no carregamento das informações já que os dados do webservice foram previamente processados. Também é importante avaliar qual a periodicidade correta de atualização das informações baseando-se nas necessidades do usuário e na carga de trabalho que esse procedimento ira gerar no Portal e na aplicação CRM.