BPEL - Guia Rápido
SOA ou Arquitetura Orientada a Serviços é uma abordagem arquitetônica, que faz uso da tecnologia para apresentar processos de negócios como serviços reutilizáveis.
Ele está focado no negócio e permite a transformação de processos para novos níveis de integração, visualização, monitoramento e otimização.
Não é uma tecnologia, é um conceito e uma estratégia de uso de tecnologias para construir soluções de automação empresarial.
Agora veremos o que é BPEL e como ele ajuda no SOA.
O que é BPEL?
Business Process Engineering Language é uma tecnologia usada para construir programas em arquitetura SOA.
Adicionando um Componente de Serviço de Processo BPEL
Siga estas etapas para adicionar um componente de serviço de processo BPEL -
No Navegador de aplicativos, selecione Arquivo> Novo> Aplicativos> Aplicativo SOA.
Isso inicia o assistente Criar Aplicativo SOA.
Na caixa de diálogo Nome do aplicativo, insira um nome de aplicativo no campo Nome do aplicativo.
No campo Diretório, insira um caminho de diretório no qual criar o aplicativo composto SOA e o projeto.
Clique em Avançar.
Na caixa de diálogo Nome do projeto, insira um nome no campo Nome do projeto.
Clique em Avançar.
Na caixa de diálogo Configurações de SOA do projeto, selecione Composto com o processo BPEL.
Clique em Concluir.
Arquivos no Composto BPEL
O composto BPEL contém os seguintes arquivos -
composite.xml - Este arquivo descreve todo o conjunto composto de serviços, componentes de serviço, referências e ligações.
.bpel - Este arquivo contém o conjunto de atividades adicionadas ao processo.
.componentType - Este arquivo descreve os serviços e referências para o componente de serviço do processo BPEL.
.wsdl - Este arquivo define as mensagens de entrada e saída para este fluxo de processo BPEL, a interface e operações do cliente suportadas e outros recursos.
Conceitos usados no processo BPL
Nesta seção, aprenderemos os diferentes conceitos envolvidos no processo de BPL.
Orquestração
-
Normalmente usado em processos de negócios privados.
Um processo central (que pode ser outro serviço da Web) assume o controle dos serviços da Web envolvidos.
Coordena a execução de diferentes operações nos serviços web envolvidos na operação.
- Os serviços da Web envolvidos não "sabem" (e não precisam saber) que estão envolvidos em um processo de composição e que estão participando de um processo de negócios de nível superior.
Apenas o coordenador central da orquestração está ciente desse objetivo, portanto a orquestração é centralizada com definições explícitas de operações e a ordem de invocação dos serviços da Web.
Coreografia
Não conta com um coordenador central.
Cada serviço da Web envolvido na coreografia sabe exatamente quando executar suas operações e com quem interagir.
Cada serviço da Web envolvido na coreografia sabe exatamente quando executar suas operações e com quem interagir.
Todos os participantes da coreografia precisam estar cientes do processo de negócios, operações a serem executadas, mensagens a serem trocadas e o tempo das trocas de mensagens.
Neste capítulo, aprenderemos sobre as diferentes atividades que constituem os blocos de construção Os blocos de construção de um componente de serviço de processo BPEL.
O Oracle BPEL Designer inclui um conjunto de atividades que você arrasta para um componente de serviço do processo BPEL e clica duas vezes em uma atividade para definir seus atributos e valores de propriedade.
Atribuir atividade
Invocar atividade
Receber atividade
Vamos aprender mais sobre a atividade Invoke em nossa seção subsequente.
Invocar atividade
A atividade de chamada permite especificar uma operação que deve ser chamada para o serviço (identificada por seu link de parceiro). A operação pode ser unilateral ou solicitação-resposta em uma porta fornecida pelo serviço. As variáveis podem ser criadas automaticamente em uma atividade de chamada. Uma atividade de chamada invoca um serviço síncrono ou inicia um serviço da web assíncrono.
A atividade de chamada abre uma porta no processo para enviar e receber dados. Essa porta pode ser usada posteriormente para enviar os dados necessários e receber uma resposta. Para retornos de chamada síncronos, apenas uma porta é necessária para as funções de envio e recebimento.
Os Links de Parceiros são definidos como trocas de comunicação entre todas as partes com as quais o Processo BPEL interage.
Eles são as referências para as implementações reais, através das quais o processo BPEL interage com o mundo externo.
Links de parceiros invocados
Esses são links para serviços que são chamados pelo processo BPEL.
Links de parceiro cliente
Esses são links para serviços que podem chamar um processo BPEL.
Propriedades do link de parceiro
O Partner Link Property Editor permite que você estabeleça links de parceiros para seus processos BPEL. Com o Partner Link Property Editor, você pode especificar o seguinte -
Name - Especifica o nome do elemento Invoke.
WSDL File - Indica o arquivo WSDL associado ao link do parceiro.
Partner Link Type - Indica o tipo de Link de Parceiro definido no WSDL.
My Role - Indica a função do próprio processo de negócios.
Partner Pole - Indica a função do parceiro.
Documentation - Acessado na janela Propriedades.
Links de parceiros são definidos no arquivo .bpel.
Um BPEL pode interagir com os serviços das três maneiras a seguir -
- Serviços que invocam um processo BPEL
- Serviços que são invocados pelo processo BPEL
- Serviços que atuam nos dois sentidos
Neste capítulo, aprenderemos como criar um link de parceiro.
Siga as etapas mostradas abaixo para criar um link de parceiro -
No Editor Composto SOA, clique duas vezes no componente de serviço do processo BPEL.
Ao clicar no componente de serviço, o Oracle BPEL Designer é exibido.
Na Paleta de componentes, expanda Serviços BPEL.
Arraste um link de parceiro para a raia de links de parceiro apropriada.
Preencha os campos desta caixa de diálogo conforme mencionado acima nas Propriedades do link do parceiro.
Os adaptadores permitem integrar o componente de serviço de processo BPEL com acesso a sistemas de arquivos, servidores FTP, tabelas de banco de dados, filas de banco de dados, sockets, Java Message Services (JMS), MQ e Oracle E-Business Suite. Este assistente permite configurar os tipos de adaptadores mostrados na figura abaixo para uso com o componente de serviço de processo BPEL -
Tipos de adaptadores
A imagem a seguir mostra os diferentes tipos de adaptadores -
Enfileiramento avançado (AQ)
Para interação com uma fila. AQ fornece um mecanismo flexível para comunicação bidirecional assíncrona entre os aplicativos participantes.
Oracle Business Activity Monitoring (BAM)
Para publicar dados em objetos de dados em um servidor Oracle BAM.
Base de dados
Para interação com bancos de dados Oracle e não Oracle por meio de JDBC e Oracle Business Intelligence (que é um tipo de fonte de dados especial).
FTP e arquivo
Para troca de arquivos (leitura e gravação) em sistemas de arquivos locais e remotos (por meio do protocolo de transferência de arquivos (FTP)).
Serviço de mensagens Java (JMS)
Para interação com JMS. A arquitetura JMS usa uma interface de cliente para a arquitetura de vários servidores de mensagens.
Fila de mensagens (MQ)
Para troca de mensagens com sistemas de enfileiramento do WebSphere MQ.
Aplicativos Oracle
Para interação com o conjunto de aplicativos de negócios integrados do Oracle Application.
Oracle B2B
Para navegar em metadados B2B no repositório de serviços de metadados (MDS) e selecionar definições de documentos.
tomadas
Para modelar protocolos padrão ou não padrão para comunicação em soquetes TCP / IP.
Nome do serviço do adaptador
A janela Nome do serviço solicita a inserção de um nome quando o tipo de adaptador é selecionado no palete. Para este exemplo,File AdapterFoi selecionado. Quando o assistente for concluído, um arquivo WSDL com este nome de serviço aparecerá no Navegador de Aplicativos para o componente de serviço do processo BPEL (neste exemplo, denominadoReadFile.wsdl) O nome do serviço deve ser exclusivo no projeto. Este arquivo de configuração inclui as definições de configuração do adaptador especificadas com este assistente. Outros arquivos de configuração (como arquivos de cabeçalho e arquivos específicos para o adaptador) também são criados. Esses arquivos são exibidos no Navegador de aplicativos.
Os monitores de processo BPEL no Oracle BPEL Designer podem ser configurados selecionando Monitor na parte superior do Oracle BPEL Designer.
Nesse estágio, o Oracle BAM Adapter precisa ser configurado.
O Processo BPEL do Cliente envia uma mensagem para o Processo BPEL do Serviço e o Processo BPEL do Serviço não é obrigado a responder conforme mostrado na figura abaixo -
O processo BPEL do cliente precisa de um link de parceiro válido e uma atividade de chamada.
O processo BPEL de serviço precisa de uma atividade de recebimento.
Como acontece com todas as atividades do parceiro, o arquivo Web Services Description Language (WSDL) define a interação. O arquivo WSDL é mostrado abaixo.
<wsdl:portType name = "BPELProcess">
<wsdl:operation name = "process">
<wsdl:input message = "client:BPELProcessRequestMessage" />
<wsdl:output message = "client:BPELProcessResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
O Processo BPEL do Cliente envia uma solicitação ao Processo BPEL do Serviço (d1 na figura abaixo) e recebe uma resposta imediata (d2 na figura abaixo). Por exemplo, um usuário solicita a assinatura de um formulário de inscrição online para admissão em uma faculdade e recebe imediatamente a confirmação por e-mail de que sua solicitação foi aceita.
O processo BPEL do cliente precisa de uma atividade de chamada. A porta do lado do cliente envia a solicitação e recebe a resposta.
O Processo BPEL de Serviço precisa de uma atividade de recebimento para aceitar a solicitação de entrada e uma atividade de resposta para retornar as informações solicitadas ou uma mensagem de erro (uma falha; f1 na figura abaixo) definida no WSDL.
Como acontece com todas as atividades do parceiro, o arquivo Web Services Description Language (WSDL) define a interação. O arquivo WSDL é mostrado abaixo.
WSDL File
<wsdl:portType name = "BPELProcess">
<wsdl:operation name = "process">
<wsdl:input message = "client:BPELProcessRequestMessage" />
<wsdl:output message = "client:BPELProcessResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
O Processo BPEL do Cliente envia uma solicitação ao Processo BPEL do Serviço (d1 na figura abaixo) e espera até que o serviço responda (d2 na figura abaixo).
Por exemplo, um usuário solicita uma assinatura de um formulário de inscrição online para admissão em uma faculdade e a solicitação não pode ser confirmada a menos que seja aceita no escritório de admissão.
O processo BPEL do cliente precisa de uma atividade de chamada para enviar a solicitação e uma atividade de recebimento para receber a resposta.
O processo BPEL de serviço precisa de uma atividade de recebimento para aceitar a solicitação de entrada e uma atividade de chamada para retornar as informações solicitadas ou uma falha.
Note - A diferença entre responder de um processo BPEL síncrono e assíncrono é que o serviço síncrono usa uma atividade de resposta para responder ao cliente e um serviço assíncrono usa uma atividade de chamada.
Como acontece com todas as atividades do parceiro, o arquivo Web Services Description Language (WSDL) define a interação. O arquivo WSDL é mostrado abaixo.
WSDL File
<wsdl:portType name = "BPELProcess">
<wsdl:operation name = "process">
<wsdl:input message = "client:BPELProcessRequestMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name = "BPELProcessCallback">
<wsdl:operation name = "processResponse">
<wsdl:input message = "client:BPELProcessResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
O Processo BPEL do Cliente envia uma solicitação para o Processo BPEL do Serviço (d1 na figura abaixo) e espera até que o serviço responda ou até que um determinado limite de tempo seja atingido, o que ocorrer primeiro. (d2 na figura abaixo).
Por exemplo, um usuário solicita uma assinatura de um formulário de inscrição online para admissão em uma faculdade e a solicitação é cancelada se o usuário não receber uma resposta de confirmação dentro de um determinado período de tempo.
O processo BPEL do cliente precisa de uma atividade de chamada para enviar a solicitação e uma atividade de seleção com duas ramificações - uma onMessage filial e um onAlarmramo. Se a resposta chegar depois que o limite de tempo expirou, a mensagem irá para a fila de devoluções.
O processo BPEL de serviço precisa de uma atividade de recebimento para aceitar a solicitação de entrada e uma atividade de chamada para retornar as informações solicitadas ou uma falha.
Como acontece com todas as atividades do parceiro, o arquivo Web Services Description Language (WSDL) define a interação.
Neste capítulo, aprenderemos sobre interações assíncronas com um cronômetro de notificação. Considere os seguintes pontos relacionados às interações assíncronas -
O Processo BPEL do Cliente envia uma solicitação ao Processo BPEL do Serviço e aguarda uma resposta, embora uma notificação seja enviada depois que um cronômetro expira.
O processo BPEL do cliente continua aguardando a resposta do processo BPEL do serviço mesmo depois que o cronômetro expirou.
O processo BPEL do cliente precisa de uma atividade de escopo contendo uma atividade de chamada para enviar a solicitação e uma atividade de recebimento para aceitar a resposta. oonAlarm o manipulador da atividade do escopo tem um limite de tempo e instruções sobre o que fazer quando o cronômetro expirar.
Por exemplo, aguarde 60 segundos e envie um aviso indicando que o processo está demorando mais do que o esperado.
O processo BPEL de serviço precisa de uma atividade de recebimento para aceitar a solicitação de entrada e uma atividade de chamada para retornar as informações solicitadas ou uma falha.
Como acontece com todas as atividades do parceiro, o arquivo Web Services Description Language (WSDL) define a interação.
Neste capítulo, aprenderemos sobre o conceito de One Request e Multiple Responses.
O processo BPEL do cliente envia uma única solicitação ao processo BPEL do serviço e recebe várias respostas em troca.
Por exemplo, a solicitação pode ser para solicitar um produto online e a primeira resposta pode ser o tempo estimado de entrega, a segunda resposta uma confirmação de pagamento e a terceira resposta uma notificação de que o produto foi enviado. Neste exemplo, o número e os tipos de respostas são esperados.
O processo BPEL do cliente precisa de uma atividade de chamada para enviar a solicitação e de uma atividade de sequência com três atividades de recebimento.
O Processo BPEL de Serviço precisa de uma atividade de recebimento para aceitar a mensagem do cliente e um atributo de sequência com três atividades de chamada, uma para cada resposta.
Como acontece com todas as atividades do parceiro, o arquivo Web Services Description Language (WSDL) define a interação.
Neste capítulo, aprenderemos sobre o conceito de uma solicitação e uma das duas respostas possíveis.
O processo BPEL do cliente envia uma única solicitação ao processo BPEL do serviço e recebe uma das duas respostas possíveis.
Por exemplo, a solicitação pode ser para pedir um produto online e a primeira resposta pode ser uma mensagem em estoque ou uma mensagem de falta de estoque.
O processo BPEL do cliente precisa do seguinte -
Uma atividade de chamada para enviar a solicitação.
Uma atividade de seleção com dois ramos: um onMessage para a resposta em estoque e instruções sobre o que fazer se uma mensagem em estoque for recebida.
Um segundo onMessage para a resposta de falta de estoque e instruções sobre o que fazer se uma mensagem de falta de estoque for recebida.
O Processo BPEL de Serviço precisa de uma atividade de recebimento para aceitar a mensagem do cliente e uma atividade de troca com duas ramificações, uma com uma atividade de chamada enviando a mensagem em estoque se o item estiver disponível e uma segunda filial com uma atividade de chamada enviando a mensagem de falta de estoque se o item não estiver disponível.
Como acontece com todas as atividades do parceiro, o arquivo Web Services Description Language (WSDL) define a interação.
Neste capítulo, entenderemos o conceito de uma solicitação, uma resposta obrigatória e uma resposta opcional.
O serviço BPEL do cliente envia uma única solicitação ao processo BPEL do serviço e recebe uma ou duas respostas.
Aqui, o pedido é para encomendar um produto online. Caso haja atraso no produto, o serviço envia uma mensagem avisando o cliente. Em qualquer caso, o serviço sempre envia uma notificação quando o item é enviado.
O serviço BPEL do cliente precisa de uma atividade de escopo contendo a atividade de chamada para enviar a solicitação e uma atividade de recebimento para aceitar a resposta obrigatória. Para a mensagem opcional, oonMessageO manipulador da atividade do escopo é definido junto com as instruções sobre o que fazer se a mensagem opcional for recebida (por exemplo, notificar que o produto foi atrasado). O Processo BPEL do Cliente espera receber a resposta obrigatória. Se a resposta obrigatória for recebida primeiro, o processo BPEL continuará sem esperar pela resposta opcional.
O Processo BPEL de Serviço precisa de uma atividade de escopo contendo a atividade de recebimento e uma atividade de chamada para enviar a mensagem de envio obrigatória, e o escopo onAlarm manipulador para enviar a mensagem atrasada opcional se um cronômetro expirar (por exemplo, enviar a mensagem atrasada se o item não for enviado em 24 horas).
Como acontece com todas as atividades do parceiro, o arquivo Web Services Description Language (WSDL) define a interação.
Agora, aprenderemos o conceito de processamento parcial em BPEL.
O processo BPEL do cliente envia uma solicitação ao processo BPEL do serviço e recebe uma resposta imediata, mas o processamento continua no lado do serviço.
Esse padrão também pode incluir retornos de chamada múltiplos disparados, seguidos por processamento de longo prazo.
Por exemplo, o cliente envia uma solicitação de compra de um pacote de férias e o serviço envia uma resposta imediata confirmando a compra e, em seguida, continua reservando o hotel, o voo, o carro alugado e assim por diante.
O processo BPEL do cliente precisa de uma atividade de chamada para cada solicitação e uma atividade de recebimento para cada resposta para transações assíncronas ou apenas uma atividade de chamada para cada transação síncrona.
O processo BPEL de serviço precisa de uma atividade de recebimento para cada solicitação do cliente e uma atividade de chamada para cada resposta. Assim que as respostas forem concluídas, o Processo BPEL do Serviço como o serviço pode continuar com o seu processamento, usando as informações coletadas na transação para executar as tarefas necessárias sem qualquer entrada adicional do cliente.
Como acontece com todas as atividades do parceiro, o arquivo Web Services Description Language (WSDL) define a interação.
Aprenderemos sobre as múltiplas interações de aplicativos com BPEL neste capítulo.
Quando há mais de dois aplicativos envolvidos em uma transação.
Este padrão de transação de A para B para C para A pode lidar com muitas transações ao mesmo tempo. Portanto, é necessário um mecanismo para rastrear qual mensagem vai para onde.
Isso pode ser tratado usando WS-Addressing ou conjuntos de correlação.
Discutimos em um dos capítulos anteriores que o Synchronous Web Service é um serviço que fornece uma resposta imediata a uma chamada.
Na captura de tela mostrada abaixo, criamos um processo BPEL síncrono que tem uma atividade de recebimento para aceitar a solicitação do usuário. A atividade de resposta envia simultaneamente a resposta de volta.
Conforme discutido antes, o Serviço Web Assíncrono é aquele que envia uma solicitação a outro serviço da Web e espera pela resposta.
Na captura de tela mostrada abaixo, criamos o processo BPEL assíncrono, que tem uma atividade de recebimento para aceitar a solicitação do usuário. A atividade de atribuição também atribui valores aos diferentes elementos da solicitação.
Em seguida, a atividade invoke invoca o aplicativo HelloWorld que envia a resposta simultaneamente e que é capturada na atividade de recepção.
Além disso, temos a atividade de retorno de chamada que finalmente gera saída e envia resposta de forma assíncrona.
Se você clicar duas vezes no receiveInput ou callbackClient, você verá que cada um deles tem apenas uma variável.
receiveInput → inputVariable
callbackClient → outputVariable
Neste capítulo, vamos entender como o fluxo paralelo funciona no BPEL.
O que é atividade de fluxo?
Uma atividade de fluxo normalmente contém muitas atividades de sequência, e cada sequência é executada em paralelo. Uma atividade de fluxo também pode conter outras atividades.
Por exemplo, dois retornos de chamada assíncronos são executados em paralelo, de forma que um retorno de chamada não precise esperar que o outro seja concluído primeiro. Cada resposta é armazenada em uma variável global diferente.
Na atividade de fluxo, o código BPEL determina o número de ramificações paralelas. No entanto, muitas vezes o número de ramos necessários é diferente, dependendo das informações disponíveis.
O que é atividade FlowN?
A atividade flowN cria vários fluxos iguais ao valor de N, que é definido no tempo de execução com base nos dados disponíveis e na lógica do processo. Há um incremento da variável do índice cada vez que um novo ramo é criado, até que a variável do índice alcance o valor de N.
A atividade flowN executa atividades em um número arbitrário de elementos de dados. Conforme o número de elementos muda, o processo BPEL se ajusta de acordo.
As ramificações criadas por flowN executam as mesmas atividades, mas usam dados diferentes. Cada ramo usa a variável de índice para pesquisar variáveis de entrada. A variável de índice pode ser usada na expressão XPath para adquirir os dados específicos para essa ramificação.
BPEL aplica lógica para fazer escolhas por meio de ramificação condicional. As duas ações diferentes com base na ramificação condicional são mostradas abaixo -
Mudar de atividade
Neste método, você configura duas ou mais ramificações, com cada ramificação na forma de uma expressão XPath. Se a expressão for verdadeira, a ramificação será executada. Se a expressão for falsa, o processo BPEL passa para a próxima condição de ramificação, até encontrar uma condição de ramificação válida, encontrar outra ramificação ou ficar sem ramificações. Se mais de uma condição de ramificação for verdadeira, o BPEL executará a primeira ramificação verdadeira.
Enquanto atividade
Você pode usar uma atividade while para criar um loop while para selecionar entre duas ações.
Para entender como usar o tratamento de falhas, precisamos aprender a arquitetura básica de um Service Composite no Oracle SOA Suite.
Service components- Processos BPEL, Regra de Negócios, Tarefa Humana, Mediador. Eles são usados para construir um aplicativo composto SOA.
Binding components - Estabelecer conexão entre um composto SOA e o mundo externo.
Services - Fornece um ponto de entrada para o aplicativo composto SOA.
Binding - Define os protocolos que se comunicam com o serviço como SOAP / HTTP, adaptador JCA, etc.
WSDL - Define a definição de serviço de um serviço web.
References - Permite que um aplicativo composto SOA envie mensagens para serviços externos
Wires - Permite a conexão entre os componentes do serviço.
Tipos de Falhas
Vamos agora ver os diferentes tipos de falhas.
Falhas de negócios
Ocorre quando o aplicativo executa a atividade THROW ou um INVOKE recebe falha como resposta. O nome da falha é especificado pelo componente de serviço do processo BPEL. O manipulador de falhas usando o nome da falha e a variável de falha detecta essa falha.
Falhas de tempo de execução
Isso é acionado pelo sistema. Essas falhas estão associadas aRunTimeFaultMessage e estão incluídos em
http://schemas.oracle.com/bpel/extensionnamespace.
Formas de tratamento de falhas
Nesta seção, aprenderemos sobre as diferentes formas de tratamento de falhas.
Jogue atividade
Jogue a atividade explicitamente lança a falha. O bloco catch detecta essa falha e as ações correspondentes são executadas desse modo.
Usando a atividade de lançamento, você pode lançar falhas de negócios e dentro do escopo criado, você pode detectar essa falha e redirecionar para o chamador (consumidor) para agir.
Em vez da abordagem acima, você lança a mesma falha detectada na atividade de captura do escopo criado. No escopo principal, você pode detectar essa falha usando a atividade catchall.
Estrutura do manipulador de erros (EHF)
Os 2 principais arquivos usados em EHF são -
- Fault-Policy.xml
- Fault-Bindings.xml
Sempre que o processo BPEL gerar um erro, o EHF verificará se o erro existe nos arquivos Fault-Bindings.xml. Nesse caso, a ação no arquivo Fault-Policy.xml será executada. Se a ação não for encontrada, a falha será lançada e será tratada no bloco de recepção.
A estrutura de gerenciamento de falhas (Fault-Policy.xml e Fault-Bindings.xml) é mantida dentro de um SOA Composite.
Manipuladores de falhas como catch e catchall estão dentro de um BPEL para capturar todas as falhas, mas fault policies will only be executed when an invoke activity fails.
Neste capítulo, veremos diferentes cenários relacionados ao reenvio de um processo com falha.
Cenário A
O código BPEL usa uma política de falha e uma falha é tratada usando a atividade “ora-intervenção humana”. A falha é então marcada como Recuperável e o estado da instância é definido como “Em execução”.
Cenário B
O código BPEL usa uma política de falha e uma falha é detectada e lançada novamente usando a ação “falha ora relançar”. A falha é então marcada como Recuperável e o estado da instância é definido como “Com falha”; desde que a falha seja recuperável (como se o URL não estivesse disponível).
Existem vários métodos para incorporar código Java e Java EE em processos BPEL. A seguir estão alguns métodos importantes -
Wrap as a Simple Object Access Protocol (SOAP) serviço
Incorpore snippets de código Java em um processo BPEL com a tag bpelx-exec
Use uma fachada XML para simplificar a manipulação de DOM
Use os métodos integrados bpelx - exec
Use o código Java empacotado em uma interface de serviço
A atividade Java Embedding nos permite adicionar atividades em um processo BPEL. Podemos escrever um snippet Java usando bibliotecas JDK padrão, as APIs BPEL, classes Java customizadas e de terceiros incluídas em arquivos JAR em compostos SCA implantados (no diretório SCA-INF / lib) e classes e bibliotecas Java disponíveis no Classpath para o SOA Tempo de execução da suíte.
Embedding Java significa funcionalidade escondida dentro, de uma forma não muito dissociada. O código Java é difícil de manter. Ao incorporar Java em BPEL (orientado por XML), começamos a misturar tecnologia, que exige diferentes habilidades, bem como XML caro para empacotamento e descompactação de objetos Java.
Os melhores casos de uso para Java Embedding parecem ser para registro / rastreamento avançado ou para validações / transformações especiais. No entanto, não substitua os recursos integrados do mecanismo BPEL, bem como dos outros componentes do SOA Suite 11g e dos adaptadores que o acompanham.
XPath é usado principalmente para manipular XMLs no processo BPEL. Existem algumas funções Xpath valiosas que podem ser usadas para manipular XML. Vamos ver as funções abaixo.
bpel: getVaribleData (varName, partName, xpathStr)
Isso pode ser usado para extrair um conjunto de elementos de uma variável, usando uma expressão XPath.
<bpel:copy>
<bpel:from>
<![CDATA[count(bpel:getVariableData(‘$Variable','$partName')/ns:return)]]>
</bpel:from>
<bpel:to variable = "itemNumber">
</bpel:to>
</bpel:copy>
bpel: getLinkStatus ()
Isso pode ser usado para avaliar e retornar um booleano se um link específico está ativo ou inativo.: getVariableProperty (string, string)
Isso é útil para extrair propriedades em variáveis.: doXSLTTransform ()
Isso executa as transformações XSLT.corda ()
Isso pode ser usado para extrair conteúdo de texto de elementos, em vez de usar / text ().string-length ()
Esta função é usada para calcular o comprimento da string. Mas o operador! = Parece não funcionar com a saída desta função. Portanto, você pode usar> ou <, em vez disso, usar! =Valores Booleanos
Você pode atribuir valores booleanos com a função booleana XPath.
<assign>
<!-- copy from boolean expression function to the variable -->
<copy>
<from expression = "true()"/>
<to variable = "output" part = "payload" query="/result/approved"/>
</copy>
</assign>
Atribuindo uma data ou hora
Você pode atribuir o valor atual de um campo de data ou hora usando a função Oracle BPEL XPath getCurrentDate, getCurrentTime ou getCurrentDateTime, respectivamente.
<!-- execute the XPath extension function getCurrentDate() -->
<assign>
<copy>
<from expression = "xpath20:getCurrentDate()"/>
<to variable = "output" part = "payload"
query = "/invoice/invoiceDate"/>
</copy>
</assign>
Strings de concatenação
Em vez de copiar o valor de uma variável de string (ou parte variável ou campo) para outra, você pode primeiro executar a manipulação de string, como concatenar várias strings.
<assign>
<!-- copy from XPath expression to the variable -->
<copy>
<from expression = "concat('Hello ',
bpws:getVariableData('input', 'payload', '/p:name'))"/>
<to variable = "output" part = "payload" query = "/p:result/p:message"/>
</copy>
</assign>
Atribuição de literais de string
Você pode atribuir literais de string a uma variável no BPEL.
<assign>
<!-- copy from string expression to the variable -->
<copy>
<from expression = "'GE'"/>
<to variable = "output" part = "payload" query = "/p:result/p:symbol"/>
</copy>
</assign>
Atribuição de valores numéricos
Você pode atribuir valores numéricos em expressões XPath.
<assign>
<!-- copy from integer expression to the variable -->
<copy>
<from expression = "100"/>
<to variable = "output" part = "payload" query = "/p:result/p:quantity"/>
</copy>
</assign>
Note - Algumas funções XSLT foram usadas para transformar um documento XML.
A correlação BPEL corresponde às mensagens de entrada com uma instância de processo específica. Quando você precisa associar dados específicos a uma instância específica de um processo de negócios, você usa a correlação.
Por exemplo, ao criar um processo que verifica o número de uma conta e o limite de crédito da conta. Quando verificado, o processo faz uma chamada para outro sistema para verificar o estoque e, caso o item esteja em estoque, gera um pedido de compra. Como o pedido de compra sabe qual conta deve ser debitada? A resposta a esta pergunta é correlação.
Conjuntos de Correlação
Conjuntos de correlação são usados para identificar exclusivamente instâncias de processo. Você fornece a cada conjunto de correlação um nome exclusivo e, em seguida, o define por uma ou mais propriedades. Cada propriedade possui um nome e um tipo (por exemplo, string ou inteiro).
Alias de propriedade
O alias de propriedade para cada propriedade no conjunto de correlação precisa ser definido. Um alias de propriedade é um mapeamento que vincula a propriedade aos valores de entrada ou saída.
Pontos importantes
Considere os seguintes pontos importantes relacionados ao Correlation Sets and Message Aggregation -
Um processo que contém mais de uma atividade de recepção ou seleção deve ter um conjunto de correlações.
Os conjuntos de correlação são inicializados com valores das mensagens de entrada ou saída do processo.
Se você tiver grupos de mensagens associados a um processo específico, poderá configurar um ou mais conjuntos de correlação para tratar.
Os serviços da web assíncronos geralmente demoram muito para retornar uma resposta e, como tal, um componente de serviço de processo BPEL deve ser capaz de atingir o tempo limite ou desistir de espera e continuar com o restante do fluxo após um determinado período de tempo. Você pode usar a atividade de seleção para configurar um fluxo BPEL para aguardar um determinado período de tempo ou para continuar executando suas funções. Para definir um período de expiração para o tempo, você pode usar a atividade de espera. Para gerenciar mensagens, os eventos podem ser usados principalmente quando o processo de negócios está aguardando retornos de chamada de serviços da Web de parceiros.
Eventos
BPEL suporta dois tipos de eventos -
Eventos de mensagem
Esses eventos são acionados por mensagens de entrada por meio de invocação de operação em tipos de porta.
Eventos de Alarme
Esses eventos são relacionados ao tempo e são disparados após uma certa duração ou em um momento específico.
Freqüentemente, porém, é mais útil aguardar mais de uma mensagem, da qual apenas uma ocorrerá.
Os eventos de alarme são úteis quando você deseja que o processo espere por um retorno de chamada por um determinado período de tempo, como 15 minutos.
Se nenhum retorno de chamada for recebido, o fluxo do processo continua conforme projetado.
Útil em arquiteturas orientadas a serviços fracamente acopladas, nas quais você não pode contar com serviços da Web disponíveis o tempo todo.
Escolha a atividade
A atividade de seleção tem 2 ramos -
onMessage - o código nesta ramificação é igual ao código para receber uma resposta antes de um tempo limite ser adicionado.
onAlarm - esta condição possui código para um tempo limite de um minuto.
Esperar atividade
A atividade de espera permite que um processo espere por um determinado período de tempo ou até que um limite de tempo seja atingido. Exatamente um dos critérios de expiração deve ser especificado.
O processo BPEL pode ser usado para serviço de notificação. O processo pode ser projetado para enviar o seguinte -
- mensagem de voz
- mensagens instantâneas (IM) ou
- notificações de serviço de mensagens curtas (SMS)
Para os serviços mencionados acima, você pode configurar o canal para a mensagem de entrada e saída.
Sensores compostos em um aplicativo SOA fornecem a capacidade de definir campos rastreáveis em mensagens e permite que você encontre uma instância composta específica procurando um campo ou campos em uma mensagem. Por exemplo, um sensor pode ser definido para um número de pedido dentro de uma mensagem, permitindo-nos encontrar a instância onde o número do pedido em questão é encontrado.
Sensores compostos podem ser definidos dentro de um aplicativo SOA em vários componentes -
Componente de serviço (serviço exposto)
Componente de referência (referência externa)
Mediador ou componente BPEL que se inscreveu em um evento de negócios (publicar um evento não pode ter um sensor)
Diferentes maneiras de definir sensor composto
Existem diferentes maneiras de definir um sensor composto -
- Especificando uma variável existente como o sensor.
- Por uma expressão com a ajuda do construtor de expressão.
- Usando propriedades (por exemplo, propriedades do cabeçalho da mensagem).
Sensores no Enterprise Manager
Definir um sensor permite uma pesquisa rápida de dados em uma instância composta no console EM.
No painel do EM Console, um usuário pode pesquisar instâncias por nome e valor do sensor.
Na guia “Instâncias de fluxo”, você pode selecionar sensores nos menus suspensos e pode usar valores semelhantes a curingas para o valor do sensor.
Novas atividades foram adicionadas em 2.0, substituindo as de 1.1.
<forEach>
Esta atividade ajuda a repetir o conjunto de atividades. A atividade substitui a atividade FlowN na versão BPEL 1.1.
<repeatUntil>
Esta atividade é útil se o corpo de uma atividade deve ser executado pelo menos uma vez. A condição de expressão XPath na atividade repeatUntil é avaliada após a conclusão do corpo da atividade.
<if> - <elseif> - <else>
Esta atividade substitui a atividade de switch no BPEL 2.0. A atividade permite definir o comportamento condicional para atividades específicas para decidir entre duas ou mais ramificações. Apenas uma atividade é selecionada para execução de um conjunto de ramificações.
<compensateScope>
Esta atividade ajuda a compensar o escopo filho especificado.
<rethrow>
Esta atividade foi adicionada aos manipuladores de falhas. Ele permite relançar uma falha originalmente capturada pelo manipulador de falhas imediatamente envolvente.