apostila workflow - workshop 2008

SAP Business Workflow

Curso WorkFlow - Vagner Gomes Pág. 1

Índice

Introdução 02

SAP Business Workplace 05

Configurações básicas 06

Business objects 08

Estrutura organizacional 13

Workflow e Tarefas 17

Containers 25

Programação de objetos 28

Ampliação / Delegação de objetos 31

Roles: Regras para definição de responsáveis 34

Monitoramento de prazos 37

Monitoramento de workflow (log) 38

Ferramentas Úteis para trabalhar com WorkFlow 42

Dicas e práticas facilitadoras na interação WorkFlow / ABAP 46


Introdução

SAP Business Workflow é uma ferramenta utilizada para integrar as funcionalidades e complementar o entendimento dos processos do sistema R/3. Isso é concebido através da junção de processos com os usuários envolvidos em conjunto com as informações referentes ao processo. A utilização do workflow facilita o gerenciamento de processos eletrônicos, pois, abrange um série de atividades que geralmente ocorrem de forma idêntica, envolvendo várias pessoas ou departamentos, onde é necessário um alto grau de coordenação.

Os usuários são beneficiados com o acesso mais simples e rápido das informações, menos esforço com atividades administrativas e também devido à facilidade com aprendizado e entendimento dos processos. Do ponto de vista gerencial, existe um ganho no controle das informações, prazos, níveis de serviços e custos do processo, devido ao controle que a ferramenta possibilita, monitorando processos que anteriormente necessitavam de um controle fora do sistema R/3.

O workflow pode ser utilizado para auxiliar no andamento de processos, devido a possibilidade de combinar atividades de diferentes aplicações dentro de um mesmo processo, onde todas as informações necessárias são encaminhadas diretamente para o usuário final facilitando a execução de suas tarefas.

A seguir serão apresentados os principais elementos utilizados no desenvolvimento e na manutenção de processos de workflow:

Business Objects (Objeto): Cada processo dentro do R/3, possui um elemento central que por sua vez, tem suas características. Dentro do workflow, estes elementos são representados através de objetos, onde os objetos podem representar um material, um pedido de compra, uma fatura ou outros elementos chave dentro de um processo.

Tarefas: Geralmente os processos são compostos de várias atividades a serem executadas em uma determinada ordem. Estas atividades são interpretadas como tarefas dentro de um processo de workflow. Estas tarefas podem ser utilizadas para acessar uma transação, executar um programa em background, obter informações a serem utilizadas durante o processo e outras funcionalidades.

Métodos: Este é um dos elementos dos que compõe os objetos, cada objeto possui seus próprios métodos. O método é composto de um código ABAP que é acionado através das tarefas dos workflow. Todas as tarefas necessitam de um método para que seja identificado o código de programa ABAP a ser executado, ou seja, o método identifica a ação a ser tomada em uma determinada tarefa, como por exemplo, a liberação de um pedido de compra.


Atributos: Este é mais um dos elementos que compõe os objetos e como os métodos, cada objeto possui seus atributos. Os atributos são características dos objetos, que podem ser acessadas pelo workflow em tempo de execução para obter, por exemplo, a unidade de medida de um material ou os centros de custo de um pedido.

Estrutura Organizacional: Para que as tarefas sejam encaminhadas para os usuários, é necessário identificar os possíveis agentes para a tarefa. Estes possíveis agentes podem ser separados por organização, centro, departamento de acordo com a necessidade do processo. Esta separação é efetuada através da utilização de estruturas organizacionais, onde podemos separar os grupos de usuários, e assim utilizar estes grupos em conjunto com as tarefas.

Containers: Desde o início até o termino do processamento de um workflow, as informações utilizadas pelas tarefas do workflow ficam armazenadas em áreas de memória denominadas containers. Estas áreas são necessárias para que seja possível efetuar troca de informações entre as tarefas e também para armazenar o resultado de processamentos efetuados em background.


SAP Business Workplace

O SAP Business Workplace é a ferramenta de comunicação utilizada dentro do sistema R/3 para enviar e visualizar mensagens ou executar tarefas de workflow. Esta ferramenta pode ser acessada através da transação SBWP e possui características muito parecidas com programas de correio eletrônico conforme pode se observar na figura abaixo:

A “Caixa de Entrada” é onde se encontram todos os documentos e tarefas de workflow. Existem sub-pastas que permitem dividir os itens entre documentos (mensagens não executáveis) e workflow (mensagens executáveis). Dentro da pasta de workflow existem outras pastas que são utilizadas para separar as mensagens de workflow, onde podem ser facilmente identificadas as mensagens agrupadas por tarefa, mensagens que estão com sua execução atrasada e demais pastas. Para visualizar uma mensagem, basta seleciona-la e suas informações aparecerão no quadro direito inferior.

Para os documentos recebidos, estes podem ser eliminados da caixa de entrada, onde após selecionar o documento, basta clicar no botão de lixeira.

Para as mensagens de workflow, estas somente serão eliminadas da caixa de entrada após a sua execução. Estas mensagens podem ser executadas através de um duplo clique, ou selecionado a mensagem desejada pressionando o botão executar.


Configurações Básicas

Para que o workflow possa ser utilizado corretamente, é necessário executar o customizing do workflow para que sejam configuradas as interfaces de comunicação e algumas características referentes à novos workflows criados e jobs utilizados. Este customizing é efetuado através da transação SWU3 e deve ser feito para todos os clients que necessitarem da utilização do workflow. Segue abaixo a tela da transação de customizing do workflow:


Quando a transação é acessada pela primeira vez, muito provavelmente todos os itens referentes ao “Sistema Tempo Execução Workflow” e “Ambiente Desenvolvimento Workflow” não estarão customizados. Para agilizar o processo, pode ser

utilizado o botão “Customizing Automático”, assim 80% da customização necessária é efetuada automaticamente, restando apenas alguns itens a serem customizados. Caso ocorram problemas com o customizing automático será exibido um log com as mensagens de erro encontradas durante a customização.

Para verificar se o workflow já pode ser utilizado, executar um primeiro teste, através do botão “Testar Destino RFC”. Ao executar este teste,

deverá aparecer a seguinte mensagem:


Caso seja apresentada a mensagem acima, poderá ser efetuado outro teste através do botão “Executar Workflow Verificação”,

onde será encaminhada uma mensagem para a caixa de entrada do seu SAP Business Workplace. Após a clicar no botão, aparecerá uma tela informando que está disponível na caixa de entrada uma tarefa de decisão do usuário e algumas informações sobre o resultado do teste e como proceder para finaliza-lo. Basta clicar no símbolo para que seja acessada a sua caixa de entrada no SAP Business Workplace.

Se os testes efetuados não apresentarem problemas, o ambiente já estará pronto para executar workflows e encaminhar suas tarefas para os responsáveis envolvidos no processo. Caso contrário, verifique as mensagens do customizing automático e verifique quais itens não tiveram sucesso, tentando assim configurar separadamente os itens que apresentaram problemas.


Business Objects (Objetos)

O principal elemento dentro de um workflow é o Business object (objetos), pois, através dele podemos obter informações sobre o principal elemento tratado dentro de um processo. Objetos são compostos de informações que podem ser acessadas através de uma chave única que identifica sua instância. As características dos objetos são preenchidas em tempo de execução a partir do momento que elas recebem a instância a ser tratada, ou seja, é informada a identificação do objeto para que as informações possam ser acessadas. Os objetos são visualizados e editados através da transação SWO1, conforme tela abaixo:

Os objetos podem ser pesquisados (F4) de acordo com sua descrição ou também de acordo com a aplicação, pressionando o botão “Aplicações SAP”, onde poderá ser selecionado o módulo desejado e assim localizar o objeto desejado

conforme a figura a seguir.


Encontrado o objeto desejado, basta exibi-lo para que possam ser visualizados os seus elementos. Dentro de cada objeto encontramos os seguintes elementos: Interfaces, Campos-Chave, Atributos, Métodos e Eventos, conforme figura abaixo.


Observando a figura anterior, podemos identificar que o campo chave do objeto exibido é o número do material e abaixo encontram-se seus atributos. Com um clique duplo sobre o campo chave ou atributo, podemos exibir a sua definição (figuras abaixo), e com isso pode-se observar que é feita uma referencia ao dicionário de dados para identificar a origem das informações. O mesmo ocorre com os atributos, pois eles estão relacionados com o campo chave e também são associados ao dicionário de dados.

Os métodos contém as funcionalidades necessárias para executar as tarefas do workflow durante o processo. Selecionando um dos métodos e clicando no botão será exibido o código ABAP que será executado ao utilizar o método em uma tarefa. Todo objeto possui um programa onde estão definidos seus métodos. Os métodos são declarados através dos comandos BEGIN_METHOD e END_METHOD, sendo assim, é comum quando estamos visualizando ou editando um método que sejam encontradas as declarações de outros métodos.

Os eventos são declarações de avisos que o sistema envia de acordo com alterações no status do objeto, ou seja, um evento pode avisar que um material foi modificado ou que um pedido de compra foi liberado. Os eventos são utilizados como “gatilhos” para acionar o workflow e com isso executar uma seqüência de tarefas sempre que um evento ocorrer no sistema. Eventos podem ser utilizados também para encerrar um workflow, pois uma determinada ação no sistema pode significar o cancelamento de um processo, como por exemplo, a eliminação de um pedido de compras que está em processo de aprovação através do workflow. No caso do objeto exibido no exemplo anterior, podemos observar o evento Created que é disparado pelo sistema sempre que um material é criado.


Para detectar os eventos ocorridos no sistema e saber qual evento deverá ser utilizado para acionar um workflow, existem transações que permitem rastrear os eventos ocorridos ao executar uma determinada transação. Antes de tentar detectar o evento, deve ser identificada a transação onde deseja-se iniciar o workflow e então inicia-se o rastreamento. Segue abaixo o procedimento para verificar eventos no sistema R/3.

1- Através da transação SWELS ativa-se o rastreamento de eventos.2- Entrar na transação MM01 (por exemplo) e executa-la até o fim, da mesma forma que

o usuário faria trabalhando normalmente no sistema.3- Após finalizada a transação MM01 (por exemplo) deve ser desativado o rastreamento

de eventos através da transação SWELS.4- Para verificar os eventos ocorridos no sistema utilizar a transação SWEL. Se algum

evento ocorreu durante a execução da transação MM01 (por exemplo) será exibida uma lista conforme tela abaixo:

Na tela acima pode-se observar que durante a criação do material foram disparados dois eventos, ViewCreated e Created. Juntamente com o evento, podemos observar também o objeto BUS1001006 que deverá ser utilizado na definição do workflow.


Os objetos podem ser testados para que sejam verificados seus métodos e atributos, assim evitando erros posteriores no momento de sua utilização em conjunto com o workflow. Para testar um objeto, é necessário informar o seu código e clicar

no botão “Testar”.

Será exibida uma tela com alguns métodos e atributos que podem estar disponíveis mesmo que o objeto não esteja instanciado, mas para efetuarmos testes mais completos, é preciso informar a instância do objeto clicando no botão “Instância” e informando os

dados para o campo chave do objeto.

Assim que é informada uma instância válida para o objeto, seus atributos são preenchidos e os métodos passam a estar disponíveis para execução, conforme exibido na tela abaixo.

Para testar os métodos existentes em um objeto, é necessário entrar no código ABAP e colocar um break-point no início do método para possam ser passadas informações que são fornecidas pelo workflow e então em modo de debug, o método poder ser depurado e assim

identificar possíveis erros.


Estrutura Organizacional

Estruturas organizacionais são utilizadas para auxiliar no gerenciamento de cargos e responsabilidades atribuídas à todos usuários da empresa ou para um grupo de usuários de uma determinada área da empresa. Em conjunto com o workflow, as estruturas organizacionais são fundamentais para a distribuição de tarefas de acordo com cargos atribuídos aos usuários, onde pode ser utilizada uma estrutura organizacional já definida pelo departamento de RH ou utilizam-se estruturas criadas especificamente para atender aos processos do workflow. Estruturas organizacionais são divididas em:

Unidades Organizacionais e Sub-Unidades Organizacionais

Unidades Organizacionais são utilizadas no nível mais alto dentro de uma estrutura organizacional. Geralmente é atribuída a uma unidade organizacional algo que identifique o nível mais alto, seja a empresa ou o nome do processo que utilizará a estrutura. Sub-unidades são utilizadas para definir departamentos dentro das unidades organizacionais, ou seja, uma sub divisão para grandes estruturas organizacionais.

Posições

Posições são utilizadas para criar divisões dentro das unidades organizacionais, e às posições são associados os usuários respectivamente de acordo com suas responsabilidades. Por exemplo, dentro da unidade organizacional de vendas, podemos criar várias posições, para cada regional de vendas, e a cada posição associar os usuários.

Cargos

Cargos são utilizados como uma característica atribuída às posições, ou seja, conforme citado no exemplo de posições, podemos ter uma posição para a regional de vendas de SP, uma posição para a regional de vendas de SC e uma posição para a regional de vendas do PR. Apesar de serem posições distintas, onde cada uma tem seus usuários responsáveis atribuídos, podemos atribuir a todas elas o cargo Vendedores. Havendo a necessidade de encaminhar alguma mensagem para uma regional específica, devemos informar no workflow para qual posição deve ser encaminhada a mensagem. Com isso o workflow irá encaminhar a mensagem para a caixa de entrada de todos os usuários que estiverem associados à posição indicada. Se for preciso encaminhar uma mensagem para todas as regionais de vendas, devemos indicar no workflow o cargo Vendedores como destinatário da mensagem, ou seja, a mensagem será encaminhada para todas as posições que tiverem como atributo o cargo Vendedores e com isso a mensagem será encaminhada para todos os usuários associados às posições selecionadas de acordo com o seu cargo.

Usuários

Usuários são utilizados para definir as pessoas que integram o quadro de responsáveis atribuídos às posições da estrutura organizacional. Um usuário pode ser atribuído a uma ou mais posições dentro da estrutura organizacional.


Na figura abaixo, podemos observar o exemplo de uma estrutura organizacional e a utilização dos elementos citados anteriormente. Observe que existe uma unidade organizacional principal que representa a empresa e foram criadas duas sub-unidades organizacionais que representam o departamento de vendas e o departamento de compras. Dentro de cada sub-unidade, foram criadas posições para que sejam identificadas as divisões de cada departamento, como pode ser observado na sub-unidade organizacional de vendas onde existe uma posição para cada regional de vendas. No caso das posições de vendas foi atribuído a elas o cargo de Vendedores e para cada uma das posições está associado um usuário.

Para criar estruturas organizacionais utiliza-se a transação PPOCE. Depois que a estrutura foi criada, é possível modifica-la através da transação PPOME. Ao acessar a transação para criar estruturas organizacionais, a primeira coisa que deve ser feita é informar os dados básicos para criação da unidade organizacional, ou seja, informar uma abreviação e sua descrição.


Para criar sub-unidades organizacionais ou posições, clicar com o botão direito sobre a unidade organizacional e selecionar a opção Criar. Então selecione a opção Unidade Organizacional ou Posição (ver figura abaixo) e informe os dados básicos da sub-unidade organizacional ou posição a ser criada.

Para a criação da posição devem ser informados seus dados básicos, ou seja, abreviação e descrição (ver figura abaixo). O cargo não é obrigatório e pode ser atribuído no momento da criação da posição, ou posteriormente em uma modificação. O mesmo aplica-se para o atributo Chefe da própria unidade organizacional , pois isto indicará se a posição é reservada para coordenadores, supervisores da unidade organizacional. A utilização deste atributo possibilita a identificação rápida dos principais usuários dentro de uma unidades organizacional através de regras utilizadas pelos workflow para definição de responsáveis. Para um melhor entendimento veja o capítulo que aborda as regras para definição de responsáveis.

Para criar cargos, deve ser acessado o menu Processar -> Criar Cargos. Será exibida uma tela para informar a abreviação e descrição do cargo (ver figura abaixo). Os cargos devem ser criados antes das posições para que no momento da criação da posição já seja associado o cargo, mas também pode ser criado depois e então modificar a posição para associar o cargo criado.


Para inserir usuários nas posições criadas, clicar com o botão direito sobre a posição desejada, e selecionar a opção Atribuir. Será exibida uma tela (figura abaixo) para selecionar o tipo de atribuição, onde deverá ser selecionado Titular do tipo Usuário.

Ao selecionar a atribuíção de um Titular do tipo Usuário, será exibida uma tela para pesquisa de usuários do R/3 onde poderão ser selecionados um ou mais usuários para a posição.

Para eliminar qualquer atribuilção, clicar sobre o elemento desejado, clicar com o botão direito do mouse e selecionar as opções Eliminar -> Atribuição. Dependendo do objeto selecionado, é possível desfazer a atribuição eliminando o elemento selecionado, através das opções Eliminar -> Objeto.


Workflow e Tarefas

Tarefas são o ponto principal na definição de um workflow, pois é através delas que as informações são acessadas e disponibilizadas para o usuário, possibilitando sua interação com o processo. É através das tarefas que definimos o que será feito, quando e quem executará uma determinada ação dentro dos processos de workflow. O que deve ser executado pela tarefa é definido através da associação de métodos existentes nos objetos. Quem executará as tarefas é determinado através da associação de agentes possíveis para sua execução. Quando será feito é determinado com a associação de eventos dos objetos com a definição do workflow, pois um evento significa uma alteração de status de um determinado objeto e esta alteração de status do objeto pode ser definida como uma condição de inicio para o workflow. A figura abaixo ilustra as associações necessárias para o funcionamento das tarefas e do workflow.

No workflow existem dois tipos de tarefas, as tarefas single-step (único passo) e as tarefas multi-step (workflow) compostas por várias tarefas single-step. A definição de um workflow é considerada como uma tarefa porque na definição de um workflow é possível efetuar a chamada de outro workflow como uma tarefa a ser executada durante o processo. As tarefas single-step são classificadas como tarefa standard (TS) e o workflow é classificado como modelo de workflow (WS).

A definição do workflow é composta por vários passos, onde estes passos podem conter uma tarefa a ser executada ou simplesmente ser um passo de decisão ou outros tipos de passos que não necessitam de uma tarefa a ser executada, como por exemplo um passo de condição (IF).

Para associar uma tarefa a um passo do workflow, existem dois tipos de tarefas que podem ser utilizadas: tarefas de dialogo ou tarefas background. Tarefas de dialogo são tarefas que devem ser executadas por um usuário, ou seja, é enviada uma tarefa para o usuário onde é necessário o acionamento manual para sua execução. Tarefas background são tarefas que não necessitam do acionamento de um usuário, ou seja, são executadas em background e ao final de sua execução podem ou não retornar dados para o workflow.


Objeto

Tarefa 1

Tarefa 2

Definição doWorkflow

Quando ?

O que ?

Quem ?

Inicio

Fim

Unidade Organizacional

Cargo

Posição

User ID

Regra

Eventos

Método

Estrutura Organizacional

Para criação ou alteração de um modelo de workflow ou de uma tarefa deve ser acessada a transação PFTC. Para workflow seleciona-se o tipo de tarefa Modelo Workflow e para tarefas utiliza-se Tarefa Standard. Para tarefas e para modelos de workflow já existem vários exemplos de aplicacoes standard para os vários módulos do sistema R/3, porque dependendo da necessidade pode ser utilizado um workflow standard ou se o standard não atender a necessidade por completo, podemos utilizar um workflow standard (copia) como base de definição de um novo workflow. Para consultar os fluxos standard podemos utilizar a pesquisa pelo nome do processo ou através da pesquisa pela estrutura de aplicações, conforme figura abaixo.

Desta forma é possível verificar modelos de workflow e tarefas pré-definidas de acordo com a aplicação. Para os desenvolvimentos de workflow costuma-se verificar o processo junto ao usuário, identificando as transações utilizadas, eventos acionadores e possíveis eventos terminadores para depois pesquisar os modelos de workflow standard e encontrar um que possa atender as necessidades do processo. Caso não seja encontrado nenhum modelo de workflow standard que atenda as necessidades do processo, é possível também criar um novo workflow.

O elemento principal para iniciar o desenvolvimento de um novo workflow é o objeto e seu evento acionador. Uma vez identificado o objeto (ver em Business Objects) devemos utilizar este objeto do inicio até o fim da definição do workflow, onde este objeto e seus elementos deverão ser utilizados em todos os passos do workflow.


Na definição de um modelo de workflow, existem algumas informações obrigatórias que devem ser informadas antes de iniciar o editor gráfico. É necessário preencher os campos de abreviação e denominação (ver figura abaixo) na pasta de Dados Básicos. Existe também a pasta de Descrição onde pode ser inserido um texto mais detalhado sobre o workflow, descrevendo os principais pontos abordados no processo.

Na pasta de eventos acionadores, devemos informar qual será o evento que dará inicio ao workflow (ver figura abaixo) de acordo com o objeto utilizado, onde podem ser definidos um ou mais eventos para o acionamento do workflow.


Para visualizar a definição gráfica do workflow, basta acionar o workflow builder que é a ferramenta utilizada para visualizar e editar a definição dos passos utilizados durante o processo de workflow. Ao clicar no botão Worklfow Builder será exibido

o desenho gráfico do processo (figura abaixo). À direita são exibidos todos os passos existentes no gráfico do workflow na parte superior e os elementos do container do workflow na parte inferior. Ao centro aparece o gráfico do workflow com os passos organizados e ligados logicamente de acordo com o processo e é neste local onde realmente editamos o workflow. À esquerda é possível observar uma visão macro de todo o fluxo.

Com o editor gráfico do workflow é possível copiar, recortar, colar e também criar novos passos dentro do fluxo. Em certos casos é possível criar tarefas a partir da criação de um passo do tipo Atividade, onde é obrigatório informar uma tarefa. Como em um programa ABAP é possível efetuar uma verificação da consistência dos dados e o workflow também deve ser ativado antes de sua utilização.

No gráfico são exibidos os eventos acionadores como passos iniciais do workflow e também a execução do workflow como inicio do processo. Isto ocorre porque em certos casos não são encontrados eventos disparados automaticamente pelo sistema e desta forma podemos executar diretamente o workflow sem a utilização de eventos, utilizando a função SWW_WI_START_SIMPLE em user exits. Nestes casos também podem ser utilizados eventos, mas da mesma forma é necessário utilizar a função SWE_EVENT_CREATE em user exits, disparando o evento definido no workflow como evento acionador.


Na definição dos passos do workflow podem ser inseridos vários tipos de passos, onde é possível utilizar atributos do objeto em passos condições (IF) ou em passos repetição (loop). Segue abaixo uma relação com os principais tipos de passos utilizados na definição de um workflow.

Atividade Este tipo de passo é utilizado para efetuar processamentos através da chamada de métodos do objeto utilizado pelo workflow. Este é o único tipo de passo do workflow onde é obrigatório informar uma tarefa, pois é através da tarefa que será executado o método onde está associado o código ABAP utilizado para extrair informações ou efetuar a chamada a transações que devem ser executadas pelo usuário.

Condição Este tipo de passo funciona como um IF e utiliza elementos do container do workflow para montar a condição lógica que determinará o próximo passo a ser executado.

Condição Múltipla Este tipo de passo funciona como um CASE e utiliza elementos do container do workflow para montar as condições lógicas que determinarão o próximo passo a ser executado.

Gerador de Evento Este tipo de passo é utilizado para gerar eventos a partir de um workflow, ou seja, é possível startar outro workflow através da chamada de um evento.

Espera por Evento Este tipo de passo é utilizado para aguardar eventos do sistema. Geralmente é utilizado em conjunto com um passo de Seção Paralela para aguardar por eventos de encerramento.

Operação de Container Este tipo de passo é utilizado para manipular o conteúdo de elementos do container do workflow.

Decisão do Usuário Com este tipo de passo é possível encaminhar uma tarefa com condições para o usuário decidir o que deverá ser feito dentro do processo. De acordo com a resposta do usuário, é possível determinar caminhos diferentes a serem percorridos dentro do workflow.

Loop (until) Loop (while) Estes tipos de passos são utilizados para criar laços de repetição dentro do workflow, onde são utilizados elementos do container para criar as condições de repetição, e dentro do laço de repetição são inseridos os passos a serem executados.

Seção Paralela Este tipo de passo é utilizado para criar seções de processamento em paralelo, onde é informado o número de seções em paralelo e em cada uma das seções criadas é possível inserir passos a serem executados simultaneamente.

Enviar Correio Eletrônico Com este tipo de passo é possível encaminhar mensagens para o SAP Business Workplace ou para um endereço de e-mail da Internet.


Para visualizar as características de qualquer passo do gráfico do workflow, basta clicar duas vezes sobre o passo desejado e então suas informações serão exibidas. No exemplo abaixo, estão sendo exibidas as características de um passo do tipo Atividade onde na pasta de Controle podemos observar que existe uma tarefa (TS00008319) associada ao passo do workflow que terá a função de Processar a Nota de QM. Para cada tipo de passo é necessário informar a sua denominação e sempre que possível, preencher também a denominação de saída para que fique mais fácil a visualização e entendimento do desenho do workflow.

Pode-se observar que o responsável pelo processamento é atribuído através de uma função. Esta função é conhecida como regra (role), pois através dos parâmetros passados para a função, serão determinados os usuários responsáveis pela tarefa a ser executada. Para definir os responsáveis pelo processamentos de uma tarefa, podemos utilizar uma unidade organizacional, posição, cargo ou em último caso informar diretamente o login do usuário. Não é conveniente utilizar a associação direta com um usuário como responsável pela tarefa, pois havendo a necessidade de alterar o responsável, será necessário modificar a definição do workflow. A melhor forma é utilizar os elementos de uma estrutura organizacional como por exemplo indicar uma posição. Quando é atribuída uma posição no campo de responsável pelo processamento, todos os usuários que pertencem à posição são determinados como possíveis agentes para executar a tarefa e receberão a tarefa em sua caixa de entrada. O mesmo ocorre quando utilizamos uma unidade organizacional onde todos os usuários atribuídos às posições associadas à unidade organizacional indicada serão possíveis agentes responsáveis pela execução da tarefa. Ao utilizar um cargo, todas as posições que tem como característica o cargo indicado terão seus usuários selecionados como possíveis agentes responsáveis pela execução da tarefa.


Para criar uma tarefa existem algumas informações obrigatórias que devemos preencher, tais como abreviação, denominação e método utilizado pela tarefa (ver figura abaixo). Existe também o campo Texto de Work Item que é o texto referente ao título da mensagem exibida para o usuário no SAP Business Workplace.

Na pasta Descrição é inserido o texto descritivo da tarefa, exibido no corpo da mensagem no SAP Business Workplace. Tanto no titulo quanto no corpo da mensagem é possível inserir variáveis que serão substituidas em tempo de execução de acordo com os atributos do objeto ou de acordo com elementos do container da tarefa. Um exemplo de variáveis utilizadas pode ser o código e a descrição do material, pois para cada mensagem pode ser atribuido um material diferente.

A utilização destas variáveis são importantes para que a tarefa fique mais objetiva e fácil de entender, pois desta forma conseguimos passar o máximo de informações sobre o processo, com isso facilitando a tomada de decisões no momento da execução das tarefas do workfllow.

Na definição de um modelo de workflow também exite o campo Texto de Work Item, onde também é possível utilizar variáveis que serão substituidas em tempo de execução. Na definição do workflow é importante utilizar variáveis no texto de work item para que fique mais fácil a identificação do processo quando houver a necessidade de verificar os logs de workflow, pois um mesmo workflow pode ser executado inúmeras vezes durante o dia e se não houver algo que possa diferenciar cada processo executado fica muito dificil localizar itens específicos que possam ter apresentado problemas durante sua execução.


Para que as tarefas de diálogo sejam encaminhadas para seus respectivos responsáveis, existem duas formas de fazer a associação dos possíveis agentes. Ao editar a tarefa, acessar as opções do menu Dados Adicionais -> Atribuição de Responsáveis -> Atualizar. Neste momento será exibida uma tela (fig. abaixo) para as atribuições dos possíveis agentes responsáveis pela execução da tarefa.

Para fazer associações diretas com a tarefa, devem ser utilizados os botões utilizados para a criação e eliminação de atribuições de responsáveis pelo processamento. A partir daqui é possível informar um dos elementos utilizados nas estruturas organizacionais para definir os responsáveis pela tarefa. Para utilizar a associação de elementos de estruturas organizacionais nas características da tarefa dentro da definição do workflow, é necessário modificar a característica da tarefa, clicando no botão e selecionando a opção de Tarefa Geral, conforme tela abaixo. A partir deste momento, as associações de responsáveis pelo processamento da tarefa podem ser efetuadas dentro da definição do workflow.


Containers

Containers são áreas de memória utilizadas para troca de informações durante o processamento de um workflow. Estas áreas de memória são formadas por elementos definidos de acordo com referências feitas à campos do dicionário de dados ou objetos. Esta troca de informações é necessária para a execução das tarefas e outros passos definidos no workflow. Existem cinco tipos de containers que podem ser utilizados, são eles:

- Container de WorkflowÉ o principal container utilizado em um processo de workflow, pois as informações permanecem armazenadas nele do início ao fim do processo, podendo assim distribuir informações para todos os passos contidos na definição do workflow.

- Container de TarefaÉ utilizado para efetuar a troca de informações com o container do workflow e o container do método. Através do container de tarefa é possível receber e enviar informações para o container do workflow, pois é através dele que as informações são enviadas para o método e após o processamento do método o resultado do processamento pode ser retornado para o container do workflow. Os elementos deste container são inicializados toda vez que a tarefa é encerrada, desta forma a área de memória utilizada pela tarefa está sempre pronta para um novo processamento dentro do workflow.

- Container de EventoÉ utilizado para enviar informações do evento acionado para o workflow, com isso é possível enviar informações para o workflow sobre o objeto que está sendo processado naquele instante.

- Container de MétodoÉ utilizado para trocar informações com o container de tarefa, pois é através dele que as informações são recebidas e enviadas para o container da tarefa após o processamento do código ABAP contido no método do objeto.

- Container de Role (regras)É utilizado para receber informações do container do workflow, pois é através dele que a regra de definição de responsáveis receberá as informações necessárias para definir quais agentes serão os responsáveis pela execução da tarefa.


Para criar elementos dentro dos containers citados anteriormente, clicar no botão Container para que sejam exibidos os elementos do container. Ao acessar os elementos do container de workflow ou tarefas, podemos observar que existem alguns

elementos Standard já criados automaticamente, pois estes elementos são utilizados internamente pelo workflow e podem também ser utilizados por nós, dependendo da necessidade. Estes elementos standard podem ser identificados facilmente, pois todos eles contém o caracter “_” no inicio do nome do elemento, como por exemplo o elemento do container do workflow _WF_Initiator criado para armazenar o user id da pessoa que estava utilizando a transação que acionou o workflow.

Para criar um novo elemento dentro de um container, clicar no botão Criar e informar os dados do elemento (ver figura abaixo), ou seja, o nome do elemento, características e

referência de categoria de dados.

Além do nome e descrição, devemos informar nas características se o elemento vai receber informações (Importação), se o elemento vai enviar dados para outro container (Exportação), se este elemento é obrigatório e por fim se é um elemento de várias linhas (tabela).

Como referência de categoria de dados podemos definir um elemento do dicionário de dados ou a uma categoria de objeto. Esta definição serve somente para determinar o tamanho da informação que será armazenada no elemento do container, como por exemplo caso seja necessário armazenar uma informação com 40 caracteres, podemos informar como referência a tabela MAKT e o campo MAKTX. Apesar do campo ser destinado a armazenar a descrição de um material, dentro do workflow podemos armazenar qualquer coisa dentro deste elemento, e não obrigatóriamente a descrição de um material, pois a tabela e o campo informado é só um referencial para o tamanho e tipo de informação que será armazenada.


A troca de informações existente dentro de um workflow é chamada de Binding e para cada tipo de container existem direções de binding realizadas durante o processamento (fig. Abaixo). Esta troca de informações só é permitida entre elementos que tenham a mesma referência de categoria de dados.

O binding entre o container do workflow e o container da tarefa pode ser observado clicando no botão Fluxo de Dados que está na pasta de controle das características do passo, onde será exibida uma tela (figura abaixo) com os elementos de cada

container envolvido e a direção da troca de informações. Na parte superior é exibido o fluxo de informações do container do workflow para o container da tarefa e na parte inferior é exibido o fluxo de informações do container da tarefa para o container do workflow.

Sempre que uma atividade é inserida ao workflow, é gerada uma proposta de binding, ou seja, o editor do workflow verifica as informações que a tarefa necessita e as informações retornadas pela tarefa, e gera uma proposta com o fluxo de informações. Esta proposta pode ser gerada

também através do botão de Definição Automática Fluxo de Dados encontrado nas características do passo.


ContainerWorkflow

ContainerWorkflow

Container Evento Container Role Container Método

ContainerTarefa

ContainerTarefa

Programação de Objetos

Neste tópico serão apresentados os principais comandos utilizados na programação dos métodos utilizados pelas tarefas do workflow. Estes comandos são utilizados no código ABAP juntamente com comandos já utilizados normalmente em relatórios e interfaces, onde a principal diferença é que estes comandos são utilizados para acessar o conteúdo do container do método e atributos do objeto utilizado. Para verificar o programa executado pelo método, devemos acessar o objeto através da transação SWO1 e selecionar o método desejado. Após selecionado o item, clicar no botão Programa. Segue abaixo uma relação dos principais comandos e sua sintaxe:

SWC_GET_ELEMENT CONTAINER ‘Elemento’ v_Variavel.

Este comando é utilizado para obter informações contidas no container do método. Sempre que uma tarefa é executada, as informações que a tarefa recebeu do container do workflow, são passadas do container da tarefa para o container do método. Através deste comando é possível acessar as informações do container do método de acordo com o nome do elemento informado. O nome do elemento do container deve ser colocado entre aspas simples e a variável deve ser criada com o mesmo tipo do elemento do container para que não sejam perdidas informações.

SWC_SET_ELEMENT CONTAINER ‘Elemento’ v_Variavel.

Este comando é utilizado para enviar informações para o container do método. Após a execução do método as informações contidas em seu container podem ser retornadas para o container da tarefa. Através deste comando é possível modificar o conteúdo de um elemento do container do método de acordo com o nome do elemento informado. O nome do elemento do container deve ser colocado entre aspas simples e a variável deve ser criada com o mesmo tipo do elemento do container para que não sejam perdidas informações.

SWC_GET_TABLE CONTAINER ‘Elemento’ t_TabelaInterna.

Este comando é utilizado para obter informações contidas no container do método, mas com uma diferença em relação aos comandos apresentados anteriormente, é utilizado somente para elementos do container que tem em suas características a armazenagem de múltiplas linhas de informação (característica de várias linhas deve estar marcada). Através deste comando é possível acessar as informações do container do método de acordo com o nome do elemento informado e armazena-lo em uma tabela interna. O nome do elemento do container deve ser colocado entre aspas simples e a tabela interna deve ser criada com a mesma estrutura do elemento do container para que não sejam perdidas informações.

SWC_SET_TABLE CONTAINER ‘Elemento’ t_TabelaInterna.

Este comando é utilizado para enviar informações para o container do método, mas com uma diferença em relação aos comandos apresentados anteriormente, é utilizado somente para elementos do container que tem em suas características a armazenagem de múltiplas linhas de informação (característica de várias linhas deve estar marcada). Através deste comando é possível modificar o conteúdo de um elemento do container do método de acordo com o nome do elemento informado. O nome do elemento do container deve ser colocado entre aspas simples e a tabela interna deve ser criada com a mesma estrutura do elemento do container para que não sejam perdidas informações.


SWC_GET_PROPERTY SELF ‘Atributo’ v_variavel (ou) t_TabelaInterna.

Este comando é utilizado para obter informações referentes ao objeto onde o método está sendo processado, ou seja, sempre que um método é executado através de uma tarefa do workflow, significa que o objeto já possui uma instância válida e que seus atributos estão preenchidos com suas respectivas informações. Um exemplo é o objeto BUS1001006, que é o objeto utilizado para materiais, onde sua instância é o código do material (campo chave). Uma vez que este objeto está instanciado, é possível acessar seus atributos dentro do método utilizado o comando acima. O nome do atributo deve estar entre aspas simples e utilizando uma variável ou uma tabela interna para receber as informações de acordo com o atributo desejado. Para a utilização de uma variável ou tabela interna, devemos cria-las com a mesma referência que o atributo do objeto foi criado para que não sejam perdidas informações.

Segue abaixo um exemplo prático da utilização destes comandos, onde as informações são obtidas através do container do método e do atributo do objeto, e ao final as informações selecionadas são enviadas para o container do método. Este exemplo poderia ser aplicado na utilização de uma tarefa background que utiliza o objeto BUS1001006 para obter a descrição do material.

BEGIN_METHOD exemplo CHANGING CONTAINER.

DATA: v_texto(60) TYPE c, “ Texto para retornar ao container v_matnr LIKE mara-matnr, “ Código do Material

v_maktx LIKE matk-maktx, “ Descrição do Material v_meins LIKE mara-meins. “ Unidade de Medida do Material

* Obtém o código do material através do container do método SWC_GET_ELEMENT CONTAINER ‘Material’ v_matnr.

* Seleciona a descrição do material SELECT SINGLE maktx INTO v_maktx FROM maktx WHERE matnr EQ v_matnr AND spras EQ ‘PT’.

* Obtém a unidade de medida do material através do atributo do objeto SWC_GET_PROPERTY SELF ‘BaseUnitOfMeasure’ v_meins.

* Monta o texto a ser enviado CONCATENATE ‘Material:’ v_maktx ‘comercializado em’ v_meins

INTO v_texto SEPARATED BY SPACE.

* Envia texto para o container do método SWC_SET_ELEMENT CONTAINER ‘Texto’ v_texto.

END_METHOD.


Para métodos utilizados em tarefas de diálogo, ou seja, a tarefa é encaminhada para um usuário executa-la, podemos utilizar a chamada de uma transação, um relatório, BAPI ou outro tipo de processamento que necessite da interação do usuário. Da mesma forma que os comandos foram apresentados no exemplo anterior, são utilizados também para obter informações utilizadas na chamada de uma transação e podem ser utilizados para retornar o resultado do processamento efetuado.

Quando utilizamos, por exemplo a chamada de uma transação em uma tarefa de diálogo, ao executar o workflow o código ABAP é executado em background até a chamada da transação. No momento que a transação é executada, usuário responsável pela tarefa deve executar as ações necessárias, onde ele terá controle do processamento até que a transação seja encerrada. No momento que a transação é encerrada, o processamento do método continua a ser efetuado em background pelo workflow e somente quando o método é encerrado a tarefa do workflow é considerada como concluída. Um exemplo que pode ser observado para verificarmos um método que utiliza a chamada de uma transação é o método Create do objeto BUS2078, onde é executada a transação QM01.


Ampliação / Delegação de Objetos

Como podemos observar nos tópicos abordados anteriormente, métodos, atributos e eventos estão diretamente relacionados com o workflow e suas tarefas. Quando estamos desenvolvendo um novo workflow ou uma nova tarefa utilizamos as características de um objeto standard, porém sempre surge a necessidade de acrescentar mais informações ao workflow (novos atributos) ou executar uma transação que não estava prevista na definição de um objeto standard (novos métodos).

Podemos criar nossos próprios atributos, métodos e eventos dentro de um objeto, mas não podemos fazer isso no objeto standard, pois os objetos standard funcionam como os programas e são alterados somente em caso de correções (aplicação de nota). Nestes casos devemos fazer uma “cópia” do objeto standard e então criar os itens necessários para completar a funcionalidade do objeto de acordo com a nossa necessidade.

Para fazer esta cópia, utilizamos a transação SWO1 onde informamos o objeto que utilizaremos e então criamos uma “cópia” clicando no botão Subinfotipo. Neste momento será criado um novo objeto que terá exatamente as mesmas características do objeto

standard informado na transação. Preencha os campos necessários (ver fig. Abaixo) para que seja feita a criação do novo objeto.

Ao confirmar, será criado o novo objeto onde podemos criar as novas caracteristicas necessárias para completar o desenvolvimento do workfllow e suas tarefas. Este objeto poderá ser acessado através da transação SWO1, informando o seu nome e selecionando o modo de exibição ou modificação. Sempre que criamos um novo objeto ou uma nova caracteristica dentro do objeto aparece o símbolo ao lado do objeto ou do novo item criado. Este símbolo representa que o item em questão está com status de Modelado, o que significa que ele ainda está em desenvolvimento. Uma vez que seu desenvolvimento está finalizado, antes de utiliza-lo devemos modificar seu status para Liberado, pois somente com o status de liberado será possível utiliza-lo.

Para modificar o status do objeto, devemos selecionar as opções do menu Processar -> Modif. Status Liberaç. -> Categoria do Objeto -> Implementado. Neste momento o símbolo que aparece ao lado do objeto desaparecerá e então ele estará pronto para ser liberado através das opções do menu Processar -> Modif. Status Liberaç. -> Categoria do Objeto -> Liberado. Ao liberar o objeto aparecerá o símbolo indicando que o objeto está pronto para utilização.

Para criar novos elementos em um objeto, deve ser selecionado qual o tipo de elemento a ser criado, posicionando o cursor sobre Atributos, Métodos ou Eventos e em seguida clicando no botão Criar.


Ao criar um novo atributo, devemos informar se o atributo será criado com base de campos do dicionário de dados. Caso seja confirmada a criação através de campos do dicionário de dados, aparecerá uma tela para informar qual a tabela será usada como referência e então deve ser selecionado o campo desejado. Se não utilizar a criação do atributo através de campos do dicionário de dados, será exibida uma tela (figura abaixo) para que sejam informadas as características do atributo.

Ao criar um novo método, devemos informar se o método será criado baseado em um módulo de função com modelo. Caso seja selecionada a criação do método a partir de uma função devem ser seguidos os passos de criação do método onde serão exibidos os parâmetros necessários para chamada da função dentro do método e com isso será gerado o código do método com a chamada da função. Se o método não for criado com base em um modelo de função (recomendado) será exibida uma tela (Fig. abaixo) para que sejam preenchidas as características do método, tais como nome do método, denominação e descrição breve. Neste momento definimos também se o método será utilizado em tarefas background ou de diálogo, marcando ou desmarcando o flag Diálogo.


Ao criar um novo ebento, devemos preencher uma tela (Fig. abaixo) com as características do evento, tais como nome do evento, denominação e descrição breve. Após criado o método, a única coisa que deve ser feita é a sua liberação para utilização. Este método deve ser acionado através do código ABAP de um programa ou através de um workflow com a utilização do passo do tipo Gerador de Eventos.

Para utilização de qualquer elemento criado em um objeto é necessário modificar seu status para liberado, pois todos os elementos são criados com status de modelado. Para modificar o status de um elemento do objeto devem ser selecionadas as opções do menu Processar -> Modif. Status Liberaç. -> Componente da Categoria Objeto -> Implementado. Neste momento o símbolo que aparece ao lado do elemento do objeto desaparecerá e então ele estará pronto para ser liberado através das opções do menu Processar -> Modif. Status Liberaç. -> Componente da Categoria Objeto -> Liberado. Ao liberar o elemento do objeto aparecerá o símbolo indicando que o objeto está pronto para utilização.

Sempre que uma modificação for efetuada em um objeto, este objeto deve ser gerado para que a sua nova versão esteja disponível para utilização. Esta geração do objeto deve ser feita através do botão Gerar que está na barra de ferramentas da transação SWO1.

Na definição de um workflow e suas tarefas devemos utilizar sempre o mesmo objeto do início ao fim. Desta forma, devemos utilizar sempre o objeto standard, pois nele já estão incorporados todos os elementos standard e também é possível visualizar os elementos criados em um objeto criado através de um “subinfotipo”. A visualização dos novos elementos criados na “cópia” do objeto é possível através da delegação feita entre o objeto standard e seu subinfotipo. Esta delegação é feita através da primeira tela da transação SWO1 acessando as opções do menu Opções -> Delegação -> Em Todo Sistema. Será exibida a tabela onde são cadastradas todas as delegações entre objetos do sistema e deverá ser incluído um novo registro referente à delegação do objeto criado, onde serão preenchidos os campos com o nome dos objetos envolvidos e o responsável pela delegação. Veja exemplo abaixo.

Uma vez que a delegação entre os objetos foi gravada, conforme exemplo acima, todos os elementos que forem criados e estiverem com status de liberado no objeto ZBUS2078 poderão ser utilizados através do objeto BUS2078, com isso facilitando a utilização dos objetos e seus elementos.


Roles: Regras para Definição de Responsáveis

Conforme mencionado nos tópicos anteriores, os responsáveis pela execução de uma tarefa podem ser obtidos através dos elementos de uma estrutura organizacional ou através de uma regra. Utilizamos regras para definir os responsáveis pela execução de uma tarefa em casos onde não é possível especificar um elemento da estrutura organizacional, pois em certos casos os aprovadores podem variar de acordo com centros de custo, montante do documento a ser aprovado ou grupo de mercadorias entre outros exemplos onde aplica-se uma regra para definição dos responsáveis.

A regra para definição de responsáveis é atribuída com as características do passo de atividade do workflow e deve ser inserida na área de responsáveis pelo processamento, selecionando o tipo de responsável como Função e informando a função standard a ser utilizada (ver figura abaixo). Existem algumas funções standard prontas para utilização, onde deve ser verificada a regra aplicada para seleção de responsáveis e identificar se alguma delas atende as necessidades da tarefa.

Para as regras de definição de responsáveis também é utilizada a troca de informações entre o container do workflow e o container da função, da mesma forma que as informações são enviadas para o container da tarefa. Através do botão Fluxo de Dados esta troca de informações pode ser definida ou modificada para a regra utilizada pela tarefa.


Podemos também desenvolver nossas próprias regras através da transação PFAC (Funções Standard) onde podemos criar uma nova função. Ao criar uma nova função, devemos informar seus dados básicos, tais como abreviação, denominação e descrição sobre a regra criada (figura abaixo). Na função devem ser criados os elementos do container de acordo com as informações necessárias para a seleção dos responsáveis e também deve ser associado um módulo de função onde é realmente feito o processamento para a seleção dos responsáveis. Este módulo de função pode ser criado através da transação SE37 e deve ter em sua definição as tabelas AC_CONTAINER do tipo SWCONT e ACTOR_TAB do tipo SWHACTOR. A tabela AC_CONTAINER armazenará os dados referentes ao container da regra e na tabela ACTOR_TAB são inseridos os responsáveis selecionados pela função.

Este módulo de função contém o código ABAP executado para efetuar a leitura de tabelas onde podem ser acessadas as informações utilizadas para selecionar os responsáveis pela tarefa. Dentro deste módulo de função utilizamos o comando abaixo para obter as informações do container da regra e também podem ser utilizados os comandos ABAP normalmente utilizados em um módulo de função. Este comando funciona da mesma forma que o comando utilizado dentro dos métodos para ler as informações do container do método.

SWC_GET_ELEMENT AC_CONTAINER 'Elemento' v_variável.


Para que os dados retornem para o workflow deve ser preenchida a tabela ACTOR_TAB, onde podem ser inseridos registros referentes uma unidade organizacional, posição ou preenche-la com uma relação de usuários. No campo OTYPE da tabela informamos o tipo de elemento que está sendo utilizado, onde podemos usar US para usuários, S para posições e O para unidades organizacionais. O campo OBJID é preenchido com a identificação de acordo com o tipo de elemento utilizado, ou seja para usuários utilizamos o UserId, para posições ou unidades organizacionais devemos utilizar seu ID (OBJID) que pode ser obtido através da leitura da tabela HRP1000 onde estão as informações das estruturas organizacionais.

Uma vez preenchida a tabela ACTORS_TAB automaticamente seus registros são transferidos para a tarefa do workflow e então os responsáveis são atribuídos à tarefa de acordo com seu conteúdo.


Monitoramento de Prazos

Dentro do workflow é possível estipular e monitorar prazos para a execução de suas tarefas. Através do monitoramento de prazos o sistema de workflow automaticamente pode enviar notificações ou executar ações programadas, assim que é excedido o prazo para execução de uma tarefa. Este monitoramento de prazos é configurado dentro das características do passo do tipo Atividade do workflow. Ao acessar as características da tarefa (dois cliques sobre a tarefa no gráfico do workflow), selecione a pasta Prazo onde são inseridas as informações para monitoramento (figura abaixo).

Para definir o prazo para execução de uma tarefa podemos estipular a quantidade em minutos, horas, dias, semanas, meses e anos que devem ser contados a partir da data/hora de referência. Para data/hora de referência existem três opções para defini-la: Geração do Work Item, Geração do Workflow ou Impressão. Ao definir que a referência será baseada na geração do work item, significa que será utilizada a data que a tarefa foi encaminhada para o responsável. Se referência for baseada na geração do workflow, significa que será utilizada a data que o workflow foi iniciado, ou seja o prazo começa a contar a partir do inicio do processo. A opção Impressão significa que a data/hora de referência será informada através de elementos do container do workflow. Para isso devemos criar elementos no workflow que sejam utilizados exclusivamente para a definição da data de referência para o controle de prazos e antes que a tarefa seja encaminhada, é necessário definir os valores para estes elementos do container.

Uma vez definida a data/hora de referência e o tempo para execução da tarefa, devemos definir o que será feito, caso o prazo seja alcançado. Existem duas opções para as ações possíveis em caso de vencimento do prazo. Podemos encaminhar uma notificação ou disparar outras tarefas (background ou diálogo).

Para encaminhar a notificação, na pasta Exibir Texto informe qual será o destinatário da mensagem e o texto da mensagem. Para o destinatário da mensagem utilizamos os mesmos elementos atribuídos ao campo de responsável pela execução de uma tarefa, ou seja, pode ser atribuído uma unidade organizacional, posição, usuário ou uma regra. Para criar o texto, existe um link em azul que levará automaticamente para a tela onde deve ser inserido o texto exibido quando for alcançado o prazo da tarefa.


Sempre que é encaminhada uma notificação referente ao prazo da tarefa, o usuário que está com a sua tarefa em atraso, observará que as tarefas em atraso aparecem também na sub pasta do workflow de Entradas em Atraso. A tarefa continua disponível para execução na pasta de workflow, mas selecionando a pasta de entradas em atraso o usuário consegue visualizar somente as tarefas que estão com seu prazo de execução esgotado.

Para que sejam executadas outras tarefas caso o prazo seja alcançado, devemos informar a Denominação de Saída na pasta Modelado. Uma vez informada a denominação de saída, será criada mais uma ramificação abaixo da tarefa que indica o lugar onde o fluxo seguirá caso seja esgotado o prazo da tarefa (figura abaixo). Neste caso a tarefa será exibida também na sub pasta do workflow de Entradas em Atraso. Conforme a figura abaixo, podemos observar que em determinado ponto do workflow foi criada a tarefa Exibir Material onde foi criada uma saída caso o prazo de execução da tarefa seja alcançado. Caso a tarefa seja executada dentro do prazo, o fluxo seguirá normalmente através da saída indicada como Material Exibido. Na ramificação a direita (Prazo Alcançado) devem ser inseridos os passos a serem executados caso o prazo seja alcançado e após a execução destes passos o fluxo retornará para a tarefa em atraso.


Monitoramento de Workflow (Log)

Sempre que um workflow é executado, suas informações permanecem armazenadas em tabelas dentro do sistema de workflow. As informações de cada processo executado no workflow é identificada nestas tabelas através de uma chave de identificação chamada Work Item. Cada passo de um workflow recebe uma identificação (work item) gerando assim um histórico de todos os passos executados no processo.

Através destas tabelas é possível acessar as informações de cada workflow executado e com isso identificar possíveis falhas na troca de dados entre as tarefas e o workflow ou verificar quais ações foram tomadas durante o processo e quem executou as tarefas necessárias.

Para acessar essas informações devemos utilizar a transação SWI2_FREQ, onde podemos selecionar o período a ser analisado, o tipo de tarefa a ser pesquisada e podemos também especificar qual tarefa será selecionada (figura abaixo).


Após executar a transação será exibida uma tela com todos as tarefas executadas de acordo com os dados da tela inicial (figura abaixo). As tarefas que tem o prefixo TS são tarefas standard e as tarefas com o prefixo WS são modelos de workflow. A última coluna à direita indica a quantidade de vezes que a tarefa foi executada. Para visualizar as execuções de cada tarefa, basta clicar duas vezes sobre a linha desejada.

Selecionando uma das linhas para visualizar as ocorrências da tarefa, é possível identificar o que foi processado cada vez que a tarefa é executada. Esta identificação é feita através do texto da tarefa (titulo work item), que é definida nas características da tarefa. No exemplo abaixo, podemos verificar que entre as seis execuções da tarefa, uma foi referente ao material XCAPAZ e as outras cinco referentes ao material P100. Neste momento, pode ser visualizado o responsável pelo processamento, data de geração e status da tarefa.

Para visualização de um log um pouco mais detalhado, devemos selecionar uma das linhas na tabela apresentada e clicar no botão de Log do Workflow. Neste momento serão exibidas todas as tarefas executadas ou prontas para execução relacionadas ao processo de workflow da tarefa selecionada. Na tela de log do workflow (figura abaixo) são exibidas as tarefas de acordo com sua ordem de execução e através desta tela podemos acessar as informações enviadas aos usuário, tais como textos das tarefas e características das tarefas executadas, clicando sobre as tarefas apresentadas.


A partir da tela de log do workflow é possível acessar informações mais detalhadas pressionando o botão de Lista de Detalhes Técnicos onde podemos visualizar as informações de cada passo do workflow. Na lista de detalhes técnicos (figura abaixo) podemos identificar o usuário que executou as tarefas, data e hora de execução, dados do container das tarefas em cada passo entre outras informações.

A lista de detalhes técnicos é uma lista dinâmina que apresenta uma série de links onde podemos acessar as informações de acordo com o local onde clicamos com o mouse. Através do símbolo podemos acessar as informações do container de cada tarefa. Através do símbolo podemos verificar os usuários responsáveis pela execução de uma tarefa que ainda não foi encerrada.

Existem outras ferramentas para analisar o processamento de um workflow, entre elas estão as transações:

SWI2_DEAD – Log de Work Itens com prazos excedidosSWI2_DURA – Work Itens segundo duração de processamento


Ferramentas Úteis para trabalhar com WorkFlow

TRANSAÇÕES DESCRIÇÃOSWLD SAP BUSINESS WORKFLOWSBWP Business WorkPlaceSWU3 Configuração de WorkFlow (BASIS)SWUS Testar WorkFlowSWEL Rastreador de EventosSWELS Ativar/Desativar Rastreador de EventosSWWL Eliminar Log de Execução de WorkFlowSW12_FREQ Log de WorkFlowSWO1 Categorias de ObjetosPFTC Desenvolvimento de WorkFlowSOST SAPconeect – Ordens de envioSCOT SAPconeect – AdministracãoSWB_COND Condição de Inicio do WorkFlowSWE2 Acoplamento de Tipos de EventosSM50 Síntese de Processos


SE38 : Executar RSWUWFML2


TRANSAÇÃO SOST


TRANSAÇÃO SCOT / SE38 => RSCONN07


Dicas e práticas facilitadoras na interação WorkFlow / ABAP

√ Através da SWUS (Teste de WF) é possível criar pontos para debugar ativando o Debug pela SM50, desta forma facilita encrontrar o erro na pesquisa ou na alimentação de algum Container.

√ Utilizar na criação de um WF sempre o Objeto de Negócio standard e o Objeto de Negócio criado ( Z ) delegado ao standard.

√ Sempre quando utilizar um método para buscar um aprovador, verificar se o mesmo não se encontra vazio, caso ocorra e não é previsto erro, será enviado Work Item para todos os usuários. Segue exemplo abaixo de como evitar este problema:

IF t_zfapd[] IS INITIAL. N_MENS = 100. EXIT_RETURN N_MENS SPACE SPACE SPACE SPACE. ENDIF.

√ Segue abaixo um exemplo de como disparar um workflow, quando não possuir o Objeto de Negócios.

DATA: it_container LIKE swcont OCCURS 0 WITH HEADER LINE, lc_event LIKE swetypecou-event, lc_objkey LIKE sweinstcou-objkey, lc_creator LIKE swhactor .

lc_creator-otype = 'US'. lc_creator-objid = sy-uname. APPEND lc_creator.

lc_objkey = zazcot002-zform. lc_event = 'CREATED'. CALL FUNCTION 'SWE_EVENT_CREATE' EXPORTING objtype = 'YBUS2075_F' objkey = lc_objkey event = lc_event creator = lc_creator start_recfb_synchron = 'X' TABLES event_container = it_container.

SWELS – ATIVAR RASTREAMENTOAPÓS EXECUTAR UMA TRANSAÇÃO DETERMINADASWEL - VERIFICA O RASTREAMENTO DA TRANSAÇAO EXECUTADA

SE37 - Z_HR_WRITE_INFOTYPE_9006 ( exemplo de chamada de WF por RFC )


apostila workflow - workshop 2008

Documents