Apostila SAP Workflow 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
Tarefas
e 17
Containers 25
Programação
de
objetos 28
AmpliaçãoDelegação
/ deobjetos 31
Roles:Regrasparadefiniçãoderesponsáveis 34
Monitoramento
de
prazos 37
Monitoramentodeworkflow(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 asexecução.
mensagensEstas
de workflow,
mensagensestaspodem
somente
serserão eliminadas
executadas da caixa
através de de
umentrada
duplo após
clique,a sua
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 srcem 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 clicand o 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 workflo w. 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 tr ansaçã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 dentr o 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
Cargosnosão
citado utilizados
exemplo como umapodemos
de posições, característica atribuída
ter uma àspara
posição posições, ou seja,
a regional conforme
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
ou às posições
mais posições dentrodadaestrutura
estruturaorganizacional.
organizacional.Um usuário pode ser atribuído a uma

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.
Definição do
Objeto Workflow
Estrutura Organizacional
Eventos Quando ? Inicio
Unidade Organizacional
Cargo
Método O que ? Tarefa 1
Posição
User ID
Tarefa 2 Quem ? Regra
Fim
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.

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.
Este tipo para

Condição workflow de passo funciona
montar comológica
a condição um IFque
e utiliza elementos
determinará do container
o próximo passo adoser
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
selecionados as possíveis
como posições que tem responsáveis
agentes como característica o cargo indicado
pela execução da tarefa.terão seus usuários

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 instante.
naquele enviar informações para o workflow sobre o objeto que está sendo processado
- 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.
Container
Container Container
Container
Workflow
Workflow Tarefa
Tarefa
ContainerEvento ContainerRole ContainerMétodo
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.

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 uma
que comando
tarefaé éutilizado para obter
executada, informações
as informações contidas
que no recebeu
a tarefa containerdo
docontainer
método. Sempre
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, atributo s 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
uma “cópia” dosomente em casoede
objeto standard correções
então criar os(aplicação de nota). para
itens necessários Nestes casos devemos
completar fazer
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 desaparec erá 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 segui dos 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.todos
incorporados Desta
os forma, devemos
elementos utilizar
standard sempreé opossível
e também objeto visualizar
standard,ospois nele jácriados
elementos estão
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 centr os de custo, monta nte 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
(ver o tipo Existem
figura abaixo). de responsável
algumascomo Função
funções e informando
standard a função
prontas para standard
utilização, a ser
onde deveutilizada
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 D enominaçã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 inser idos 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 identifi car 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 excedidos

SWI2_DURA – Work Itens segundo duração de processamento

Ferramentas Úteis para trabalhar com WorkFlow
TRANSAÇÕES DESCRIÇÃO
SWLD SAPBUSINESSWORKFLOW
SBWP BusinessWorkPlace
SWU3 ConfiguraçãodeWorkFlow(BASIS)
SWUS TestarWorkFlow
SWEL RastreadordeEventos
SWELS Ativar/DesativarRastreadordeEventos
SWWL EliminarLogdeExecuçãodeWorkFlow
SW12_FREQ LogdeWorkFlow
SWO1 CategoriasdeObjetos
PFTC DesenvolvimentodeWorkFlow
SOST SAPconeect–Ordensdeenvio
SCOT SAPconeect–Administracão
SWB_COND CondiçãodeIniciodoWorkFlow
SWE2 AcoplamentodeTiposdeEventos
SM50 SíntesedeProcessos

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
APPEND = sy-uname.
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 RASTREAMENTO

APÓS EXECUTAR UMA TRANSAÇÃO DETERMINADA
SWEL - VERIFICA O RASTREAMENTO DA TRANSAÇAO EXECUTADA

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

Apostila SAP Workflow 2008

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apostila SAP Workflow 2008

Caricato da

Copyright:

Formati disponibili

SAP Business Workflow

Curso WorkFlow - Vagner Gomes Pág. 1

Ferramentas Úteis para trabalhar com WorkFlow 42

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

Curso WorkFlow - Vagner Gomes Pág. 2

SAP Business Workflow é uma ferramenta utilizada para integrar as funcionalidades e

O workflow pode ser utilizado para auxiliar no andamento de processos, devido a

A seguir serão apresentados os principais elementos utilizados no desenvolvimento e na

Tarefas: Geralmente os processos são compostos de várias atividades a serem

Curso WorkFlow - Vagner Gomes Pág. 3

Estrutura Organizacional: Para que as tarefas sejam encaminhadas para os usuários, é

Containers: Desde o início até o termino do processamento de um workflow, as

Curso WorkFlow - Vagner Gomes Pág. 4

O SAP Business Workplace é a ferramenta de comunicação utilizada dentro do sistema

A “Caixa de Entrada” é onde se encontram todos os documentos e tarefas de workflow.

Curso WorkFlow - Vagner Gomes Pág. 5

Curso WorkFlow - Vagner Gomes Pág. 6

Para verificar se o workflow já pode ser utilizado, executar um primeiro

Curso WorkFlow - Vagner Gomes Pág. 8

Se os testes efetuados não apresentarem problemas, o ambiente já estará pronto para

Curso WorkFlow - Vagner Gomes Pág. 9

Curso WorkFlow - Vagner Gomes Pág. 10

Curso WorkFlow - Vagner Gomes Pág. 11

Os métodos contém as funcionalidades necessárias para executar as tarefas do workflow

Curso WorkFlow - Vagner Gomes Pág. 12

1- Através da transação SWELS ativa-se o rastreamento de eventos.

Curso WorkFlow - Vagner Gomes Pág. 13

Curso WorkFlow - Vagner Gomes Pág. 14

Unidades Organizacionais e Sub-Unidades Organizacionais

Curso WorkFlow - Vagner Gomes Pág. 15

Curso WorkFlow - Vagner Gomes Pág. 16

Curso WorkFlow - Vagner Gomes Pág. 17

Curso WorkFlow - Vagner Gomes Pág. 18

Tarefa 2 Quem ? Regra

Curso WorkFlow - Vagner Gomes Pág. 19

Desta forma é possível verificar modelos de workflow e tarefas pré-definidas de acordo

O elemento principal para iniciar o desenvolvimento de um novo workflow é o objeto e seu

Curso WorkFlow - Vagner Gomes Pág. 20

Curso WorkFlow - Vagner Gomes Pág. 21

No gráfico são exibidos os eventos acionadores como passos iniciais do workflow e

Curso WorkFlow - Vagner Gomes Pág. 22

Este tipo para

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

Curso WorkFlow - Vagner Gomes Pág. 23

Pode-se observar que o responsável pelo processamento é atribuído através de uma

Curso WorkFlow - Vagner Gomes Pág. 24

Na pasta Descrição é inserido o texto descritivo da tarefa, exibido no corpo da mensagem

Curso WorkFlow - Vagner Gomes Pág. 25

Curso WorkFlow - Vagner Gomes Pág. 26

Containers são áreas de memória utilizadas para troca de informações durante o

É o principal container utilizado em um processo de workflow, pois as informações

- Container de Role (regras)

Curso WorkFlow - Vagner Gomes Pág. 27

Além do nome e descrição, devemos informar nas características se o elemento vai

Como referência de categoria de dados podemos definir um elemento do dicionário de

Curso WorkFlow - Vagner Gomes Pág. 28

ContainerEvento ContainerRole ContainerMétodo

Curso WorkFlow - Vagner Gomes Pág. 29

SWC_GET_ELEMENT CONTAINER ‘Elemento’ v_Variavel.

SWC_SET_ELEMENT CONTAINER ‘Elemento’ v_Variavel.

SWC_GET_TABLE CONTAINER ‘Elemento’ t_TabelaInterna.

SWC_SET_TABLE CONTAINER ‘Elemento’ t_TabelaInterna.

Curso WorkFlow - Vagner Gomes Pág. 30