Mostrando postagens com marcador OSB. Mostrar todas as postagens
Mostrando postagens com marcador OSB. Mostrar todas as postagens

quinta-feira, 24 de janeiro de 2019

Utilizando Split-Join no OSB 12c

Neste post, irei demonstrar a criação de um Split-Join e o ganho ao executar chamadas em paralelo.

O Split-Join é um componente que ajuda a melhorar a performance de um serviço processando em paralelo varias atividades em uma unica chamada.

Passos:

Primeiro criei 3 composite com 1 BPEL Process em cada, e configurei a atividade do tipo "wait" com 5s em cada.


No OSB Application, crie 3 business com os respectivos WSDL dos BPEL Process criado no passo anterior.




Crie um WSDL para o Slit-Join, o response será um elemento com todos os response dos 3 BPEL Process.


Com o WSDL gerado, click com o botão direito no diretório, vá em New -> Split-Join. Este mesmo processo pode ser feito arrastando o componente Split-Join para "External Service".



Em "Service Name" preencha com "TestSplitJoin" e click em "Next"


Escolha o WSDL gerado no passo anterior e click em "Finish"



Arraste o "Flow Control" do tipo "Parallel"




Arraste o "Communication" do tipo "Invoke Service" e aponte para um Business Service criado anteriormente.

Para a variável de request crie como "local".


Para a variável de response crie como "global", pois iremos utilizar ao final do fluxo para compor o response.

Arraste o "Assign Operations" do tipo "Assign" antes do "Invoke Service" e preencha com o payload para a chamada do BPEL Process.




Faça o mesmo procedimento para os outros dois Business Service.


Crie uma XQuery que receba como parâmetro os 3 responses e preenche o response do Split-Join.




Arraste o "Assign Operations" do tipo "Assign" antes de "Reply" e em "value", selecione "XQuery resources"


Selecione a xquery que foi gerado no passo anterior "splitjoin.xqy" e selecione as variáveis dos respectivos responses.




Crie um pipeline com as mesma chamadas, sequenciais para fazer uma comparação com os tempos de respostas.



Resultado dos testes:

Assim como os pipeline, podemos reutilizar o Split-Join em outros pipeline e não estar exposto como serviço.

Os fontes podem ser baixados aqui.

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





sábado, 13 de maio de 2017

Rest Adapter - SOA Suite 12c

Neste post irei consumir o mesmo serviço Rest criado no post "IntelliJ, Spring Boot and Rest" no SOA Suite 12c usando o "Rest Adapter".
Crie um "Application" e um projeto do Service Bus para fazer este exemplo. Caso tenha duvida de como criar veja no post "Criando e testando Proxy Service no JDeveloper 12c".

Passos:

1-) Arraste o componente "Rest" para "External Service".


2-) Irá abrir uma popup preencha com os seguintes valores:

  • Name: "MyTestReference"
  • Type: "Reference"
  • Reference will beinvoked by components using WSDL interfaces: "true"

Click em "Next"




3-) Na próxima tela, preencha os valores:
Base URI: "http://localhost:8090/mytest"
Resource edite para "/myPostMethod"



4-) Em "Methods" clck no sinal de "+", irá aparecer a seguinte popup:


5-) Preencha os campos com os seguintes valores:
Method: "myPostMethod"
Http Verb: "POST"


6-) Na aba "Request", click na engrenagem "Difine Schema for Native Format" de "Schema URL" e irá aparecer a seguinte popup, click em "Next":



7-) Em "File Name" preencha "myPostRequest.xsd" e click em "Next":



8-) Click em "Next":



9-) Em "Sample" preencha com {"firstName":"string","lastName":"string"} e click em "Next":



10-) Click em "Next":



11-) Click em "Finish":


12-) Voltamos para a popup anterior, selecione o xsd gerado em "Schema URL".
Agora vamos comfigurar o response. Click na aba "Response", em "Payload" selecione "JSON" e execute os mesmos passos (6 a 11) mas para as seguintes configurações:

File Name: "myPostResponse.xsd"
Sample: "{"welcome":"string"}"


Click em "OK".

13-) Click em "Finish":


14-) Foi gerado o business  MyTestReference.bix, click com o botão direito nele selecione "Run" para testarmos:


Na tela de teste, repare que podemos testar tanto em SOAP quanto REST

Teste SOAP:



Teste Rest: