Otimização de arquitetura de importação de usuários CRM/Portal

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.