Criei um script em python para executar o import no arquivo DemoTrust.jks.
Download em: https://github.com/leonardosugahara/wlst_examples aquivo addCertToDemoTrust.py
Altere as varáveis para as configurações de seu ambiente. Ex:
MIDDLEWARE_HOME = "/app/oracle/Middleware_12.2.1.2"
JAVA_HOME = "/app/jdk/jdk1.8.0_131"
CERT_FILE="/app/mycert.crt"
CERT_ALIAS = "mycertalias"
Execute o comando:
python addCertToDemoTrust.py
Caso queira criar um certificado para teste (no linux), certifique-se que possui o openssl instalado e execute os comandos:
openssl req -newkey rsa:2048 -nodes -keyout mydomain.key -out mydomain.csr
openssl req -key mydomain.key -new -x509 -days 365 -out mydomain.crt
quinta-feira, 30 de agosto de 2018
terça-feira, 28 de agosto de 2018
Habilitando Result Caching - Business Service
Neste post irei mostrar como configurar o "result caching" de um business service.
O "result caching" é recomendado para serviços que não mudam com frequência suas respostas, assim ajudando a reduzir sobrecargas de rede, melhorando a escalabilidade e reduzindo cargas de servidores.
Esta configuração utiliza o Oracle Coherence, que está incluso no Weblogic.Para o correto funcionamento, precisamos configurar o "Cache Token", uma chave única para o Coherence efetuar o controle do cache.
Configurando "Result Caching" no Business Service.
Abra o Business Service e vá na sessão "Performance", click em "Enable Result Caching" e click em "expression"
Preencha com um valor que seja chave. Ex:
Em "Expiration Time", para teste, selecione "Duration" e coloque 15 segundos.
Default: utiliza o parâmetro "expiry-delay" do arquivo "osb-coherence-cache-config.xml" que está no arquivo resultcache.gar. O valor default é 5 minutos
Duration: permite que seja configurado hr:min:sec
Expression: Expressão XQuery para recuperar o tempo de expiração do resquest ou response.
Coloque uma atividade de "Replace" no pipeline para verificarmos as informações de cache na chamada do business.
<cache-info>
<cache-originated>{fn:data($outbound/ctx:transport/ctx:response/tp:cache-originated)}</cache-originated>
<cache-token>{fn:data($outbound/ctx:transport/ctx:response/tp:cache-token)}</cache-token>
</cache-info>
Teste:
Primeira execução:
Segunda execução:
Observe que na segunda execução, o parametro "cache-originated" retornou com o valor "true", indicando que foi recuperado do cache.
O cache-token e o tempo de expiração podem ser sobrescritos via pipeline, inclua uma atividade de insert e acrescente as informações em ./ctx:transport/ctx:request
O "result caching" é recomendado para serviços que não mudam com frequência suas respostas, assim ajudando a reduzir sobrecargas de rede, melhorando a escalabilidade e reduzindo cargas de servidores.
Esta configuração utiliza o Oracle Coherence, que está incluso no Weblogic.Para o correto funcionamento, precisamos configurar o "Cache Token", uma chave única para o Coherence efetuar o controle do cache.
Configurando "Result Caching" no Business Service.
Abra o Business Service e vá na sessão "Performance", click em "Enable Result Caching" e click em "expression"
Preencha com um valor que seja chave. Ex:
Em "Expiration Time", para teste, selecione "Duration" e coloque 15 segundos.
Default: utiliza o parâmetro "expiry-delay" do arquivo "osb-coherence-cache-config.xml" que está no arquivo resultcache.gar. O valor default é 5 minutos
Duration: permite que seja configurado hr:min:sec
Expression: Expressão XQuery para recuperar o tempo de expiração do resquest ou response.
Coloque uma atividade de "Replace" no pipeline para verificarmos as informações de cache na chamada do business.
<cache-info>
<cache-originated>{fn:data($outbound/ctx:transport/ctx:response/tp:cache-originated)}</cache-originated>
<cache-token>{fn:data($outbound/ctx:transport/ctx:response/tp:cache-token)}</cache-token>
</cache-info>
Teste:
Primeira execução:
Segunda execução:
Observe que na segunda execução, o parametro "cache-originated" retornou com o valor "true", indicando que foi recuperado do cache.
O cache-token e o tempo de expiração podem ser sobrescritos via pipeline, inclua uma atividade de insert e acrescente as informações em ./ctx:transport/ctx:request
segunda-feira, 27 de agosto de 2018
Flow ID, Instance ID e ECID
Existem alguns IDs que são gerados ao executar um composite, que nos ajuda a monitorar o mesmo. Neste post, vou explicar sobre "Flow ID", "Instance ID" e "ECID".
Flow ID - Id único gerado para um fluxo de uma instância, com este id, mais o ECID, o SOA Suite gera rastreabilidade nas tabelas com o owner <PREFIXO>_SOAINFRA.
Instance ID - ID gerado para cada instância de composite e component.
ECID (Execution Context Id) - É global, um identificador único associado a uma execução de uma determinada requisição.
É utilizado para correlacionar mensagens em arquivo de log e nos fluxos de instância do composite. É passado via header de um composite para outro, e de um componente para outro.
Vamos ver um exemplo na pratica. Para o fluxo de execução abaixo, veremos que só teremos um "ECID", dois "FLow ID", pois temos execução de dois composites, e um "Instance ID" para cada component.
Ao executarmos o fluxo, acessar a aba "Flow Instances" e consultarmos as instâncias recentes, vemos que o "Flow ID" é a chave para abrir a janela do fluxo de execução.
Click em "Show instance IDs" para exibir o id de cada componente.
Click em "Show XML" e irá encontrar o ECID.
Se executar a consulta das ultimas instâncias do outro composite, vemos um "Flow ID" diferente, mas que referencia os mesmos "Instance IDs" e o mesmo "ECID" do composite que fez a chamada deste.
Com esses id's conseguimos rastrear/monitorar as instâncias na base de dados e arquivos de log.
Arquivo de log:
Acesse o banco do owner <PREFIXO>_SOAINFRA.
Tabela SCA_FLOW_INSTANCE
Tabela CUBE_INSTANCE
Tabela AUDIT_TRAIL
Na versão 12c não é mais possível extrair o xml da coluna log da tabela audit_trail via sql, mas existem APIs JAVA do SOA Suite para acesso desta informação.
Flow ID - Id único gerado para um fluxo de uma instância, com este id, mais o ECID, o SOA Suite gera rastreabilidade nas tabelas com o owner <PREFIXO>_SOAINFRA.
Instance ID - ID gerado para cada instância de composite e component.
ECID (Execution Context Id) - É global, um identificador único associado a uma execução de uma determinada requisição.
É utilizado para correlacionar mensagens em arquivo de log e nos fluxos de instância do composite. É passado via header de um composite para outro, e de um componente para outro.
Vamos ver um exemplo na pratica. Para o fluxo de execução abaixo, veremos que só teremos um "ECID", dois "FLow ID", pois temos execução de dois composites, e um "Instance ID" para cada component.
Ao executarmos o fluxo, acessar a aba "Flow Instances" e consultarmos as instâncias recentes, vemos que o "Flow ID" é a chave para abrir a janela do fluxo de execução.
Click em "Show instance IDs" para exibir o id de cada componente.
Se executar a consulta das ultimas instâncias do outro composite, vemos um "Flow ID" diferente, mas que referencia os mesmos "Instance IDs" e o mesmo "ECID" do composite que fez a chamada deste.
Com esses id's conseguimos rastrear/monitorar as instâncias na base de dados e arquivos de log.
Arquivo de log:
Acesse o banco do owner <PREFIXO>_SOAINFRA.
Tabela SCA_FLOW_INSTANCE
Tabela CUBE_INSTANCE
Tabela AUDIT_TRAIL
Na versão 12c não é mais possível extrair o xml da coluna log da tabela audit_trail via sql, mas existem APIs JAVA do SOA Suite para acesso desta informação.
terça-feira, 21 de agosto de 2018
Estruturação de composites com partições
Podemos estruturar (agrupar) os composites utilizando partições no SOA Suite. E definir para estas partições um grupo de Work-Manager.
É sempre necessário
existir ao menos uma partição, por isso, quando criamos o dominio,
a partição "default" é gerada automaticamente. Você pode deletar a
partição default após criar uma partição. Documentação
Quando trabalhamos
com partições, podemos gerenciar os seguintes itens:
-
Agrupamente de composites
-
Shutdown/Start, Retire/Active composites desta partição
-
Estrategia de purge do metadados da partição
-
Criação e definição de Work-Manager para a partição
-
Criação de regras de acesso a partiçãoetc...
Vamos criar uma partição:
No Enterprise
Manager, clique com o direito em soa-infra, e depois selecione "Manage SOA Folders"
A tela de gerenciamento de partições será exibida. Vamos criar uma nova partição.
Click em "Create"
Adicione um nome, e vamos criar junto com a partição, um grupo de Work-manager, click no sinal de "+".
Adicione um nome e descrição, e depois clique em "DONE".
Click em "Create"
A partição foi gerada, se selecionar a partição, pode ser feito controle dos composites (Shutdown/ Start, Active/Retire, Deploy,Undeploy).
Vizualisar o Work-Manager gerado:
Click em "SOA Infraestructure" e selecione "Work Manager Groups"
Click na seta ao lado do Work-Manager gerado, para expandir e vizualizar as configurações geradas.
As configurações do Work-Manager, podem ser vizualisadas e editadas via console.
Verificando as "Application Roles" geradas com a criação da partição:
Click em "SOA Infraestructure" e selecione "Security" -> "Application Roles"
Em "Role Name", coloque o nome da partição gerada e depois click na seta para consultar, as Application Roles geradas para a partição serão mostradas. Inclua o grupo ou o usuário que poderá ter acesso em cada Application Role.
Adicionando um "group" a "Application Role".
Click em "Edit", em "Principal Name", preencha com "Adm", click na seta para executar a consulta, selecione "Administrator" e click em "OK".
Click em "OK" novamente:
O grupo "Administrator" foi adicionado a "Application Role"
Assinar:
Postagens (Atom)