M ODELAÇÃO DE XRL

Um esquema routing XRL pretende descrever uma ordenação parcial de tarefas (processos) num determinado instante. A modelação de tarefas num determinado instante (instant level) é algo desejado, porque:

ƒ Um esquema pode ser facilmente transaccionado;

ƒ Um esquema pode ser alterado sem causar problemas a outras instâncias;

ƒ Fica resolvido um dos problemas nas linguagens de modelação de workflow, o tratamento de tarefas paralelas ou alternativas.

4.2.3 ARQUITECTURA DO XRL

O engine workflow da arquitectura XRL/flower está demonstrada na figura seguinte. O Routing slip define um routing schema (esquema de encaminhamento), é uma sequência simples de funções ou utilizadores que interagem com os documentos numa determinada sequência. Cada slip tem um identificado único (ID) que pode ser utilizado para traçar um routing slip.

O routing schema é recebido via e-mail, depois é realizado um parse utilizando um standard XML parser e é armazenado como um XML data structure. O engine lê essa estrutura e cria uma representação Petri-net, esta representação é utilizada pelo engine para determinar os próximos passos a serem realizados e apresentá-los ao utilizador pelo user interface. O utilizador introduz as acções necessárias para completar a tarefa e é realizado todo o processo inverso até a informação ser expedida via e-mail.

Figura 15. Arquitectura do XRL/flower

Existe um DTD (Document Type Definition) para especificar a sintaxe do XRL. Por vezes podem existir condições de execução ou conclusão de processos.

4.2.4 ELEMENTO ROUTE

Um routing slip ou schema começa pela tag <route> e termina com a tag </route>. O elemento route tem um atributo reference que contem um identificador único para o

1. Task – Tarefa a ser realizada;

2. Sequence – Conjunto de tarefas a serem realizadas numa ordem especifica;

3. Any_sequence – Conjunto de tarefas a serem realizadas sem qualquer ordenação;

4. Choice – Qualquer tarefa de um conjunto de tarefas;

5. Condition – Testa uma condição e determina o próximo passo consoante o resultado da condição;

6. Parallel_sync – Cria várias tarefas em paralelo de forma síncrona;

7. Parallel_no_sync – Cria várias tarefas em paralelo de não síncrona;

8. Parallel_part_sync – Cria várias tarefas em paralelo em que parte é síncrona;

9. Wait_all – Espera pela concretização de um conjunto de eventos;

10. Wait_any – Espera pela concretização de qualquer evento de um conjunto de eventos;

11. While_do – Repete uma tarefa enquanto a condição for verdadeira;

12. Stop – Termina a execução deste caminho do workflow;

13. Terminate – Termina o workflow.

4.2.5 CONCLUSÕES

Apesar dos benefícios demonstrados na utilização de XRL e na facilidade da sua implementação, hoje em dia os sistemas de gestão de workflow não têm ferramentas

ou técnicas avançadas para verificar o funcionamento correcto dos processos de definição do workflow, o que pode originar condições erradas como deadlocks ou livelocks que não são facilmente detectadas. Outro senão é a difícil ou quase inexistente troca de informação workflow entre as diferentes soluções existentes, que têm um formato proprietário o que dificulta as tais trocas de informação.

No entanto e apesar de tais dificuldades convém salientar que a grande vantagem na utilização do XRL é que permite relações ad-hoc e não está limitada para uma aplicação especifica nem para um determinado domínio.

4.3

B

T

Há quem diga que o BizTalk é uma ferramenta de EAI (Enterprise Application Integration) e de B2B (Business to Business). É dito também que é uma ferramenta de middleware. Na realidade é tudo isso e mais.

A Palavra BizTalk é um redutivo de Business Talk. O BizTalk Server da Microsoft é uma ferramenta que implementa o Framework BizTalk, que é uma iniciativa aberta de se padronizar trocas de informações entre empresas. Porém, mais do que somente implementar esse framework homónimo, o BizTalk integra aplicações, ou seja, ele distribui informações. Se executarmos essa tarefa dentro de uma organização, conectando duas ou mais aplicações distintas estamos fazendo o chamado EAI e se estas aplicações estiverem em duas ou mais empresas distintas seria o chamado B2B. O BizTalk funciona como "meio de campo" entre aplicações, ou seja o middleware [16].

Figura 16. Arquitectura do Biztalk

O funcionamento do BizTalk está dividido em dois produtos: um que faz o que chamamos de "troca de mensagens" e outro que faz automatização de processos. A troca de mensagens é feita pelo BizTalk Messaging e a automatização de processos é realizada pelo BizTalk Orchestration [17].

4.3.1 BIZTALK MESSAGING

O BizTalk Messaging, recebe uma informação de diversas formas através de serviços de recebimento, valida essa mensagem, transforma o formato dessa mensagem em outro (se for necessário) e entrega essa mensagem a um determinado destino. Este serviço tem ainda a funcionalidade de encaminhar a mensagem com informações que podem estar dentro da referida mensagem ou com informações de encaminhamento que são fornecidas quando submetemos a mensagem ao Messaging.

Podemos receber as mensagens de diversas fontes, tais como: pastas de directórios (file Server), servidores de filas (MSMQ, MQ Series), SMTP, HTTP, HTTPS, componentes, scripts ou mesmo Web Services. Podemos ainda recebê-las directamente de outras aplicações através de Adaptadores de Aplicativos ou de

legados diversos, tais como ADABAS, ORACLE, Paradox, etc, através dos Adaptadores de Tecnologia, já desenvolvidos pela própria Microsoft ou por terceiros.

Logo após o recebimento a mensagem é envolvida num processo de Parse onde, se for uma mensagem XML, é verificada para ver se é um XML bem estruturado. Se não for um XML (Flat File, EDI, ou outro qualquer), no processo de Parse a mensagem é transformada num XML, de modo que após o Parse temos a mensagem em XML.

A mensagem pode ser transformada noutro formato de documento (outro Schema) através do Mapper. Nesta fase cada campo do Schema de entrada é reencaminhado aos campos do Schema de saída ("de / para").

A mensagem já transformada no seu formato de saída é encaminhada ao Messaging Port. Já no Port, a mensagem passa por um processo de Serialize que transforma (se necessário) o XML de saída no formato de saída desejado (EDI, Flat File, etc.). Depois do Serialize a mensagem é encaminhada a um serviço de entrega onde está definido o protocolo (HTTP, HTTPS, SMTP, AIC, File System, etc) e o destino da mensagem.

4.3.2 BIZTALK ORCHESTRATION

Além de "entregar mensagens", é possível viabilizar a automatização de processos de negócio complexos com o BizTalk Orchestration.

Com essa ferramenta automatizamos complexos processos de negócios simplesmente desenhando o processo na forma de um DFD (diagrama de fluxo de dados). O DFD é normalmente usado para documentar sistemas e processos mas neste caso a documentação é a própria implementação. Cada uma das acções descritas no DFD podem ser implementadas enviando ou recebendo uma mensagem ou conectando e executando um componente.

Enviando e recebendo informações e accionando componentes, o BizTalk Orchestration gere o fluxo de um processo com toda a flexibilidade, podendo manipular inclusive com o controle transaccional das acções e desvios para fluxos alternativos, no caso de falhas.

4.3.3 CONCLUSÕES

O Biztalk surge nesta análise como uma plataforma que serve de intermediário na troca de mensagens nos processos de Workflow. Estas mensagens poderão ser codificadas em XML e convem realçar que este Web Service é um dos mais utilizados actualmente.