SAP Business WorkFlow
INDICE
1 Definición de Workflow 3
1.1 Algunas definiciones 3
2 Configuración del Sistema 4
3 Entrega de Work Item. 5
4. Asignación de Responsables 6
4.1 Asignación de Responsables usando la Estructura Organizacional. 7
5 Construcción de Workflows 8
5.1 Workflow Builder 8
5.2 Construyendo un workflow 10
5.3 Containers. 11
6. Business Objects 12
6.1 Bussines Object Builder (SWO1). 13
6.2 Test de Objeto 14
6.3 Creación de tipos de objeto 16
2
1. Definición de Workflow.
Workflow es la administración consistente de la automatización de procesos de negocios durante el cual
documentos, información o tareas son pasadas desde un participante a otro de una manera dirigida por reglas
o procedimientos.
1.1 Algunas definiciones.
Definición de Workflow : Es el set de reglas que determina la ruta que el proceso toma.
Instancia de Workflow : Corresponde a la definición de workflow en ejecución.
Tarea :Son los pasos en el proceso, las cuales deben ser ejecutadas ya sea por personas o
automáticamente por el software.
Work Item :Representación de una tarea o un paso en la definición de workflow.
Responsables : Son las personas quienes procesan las tareas mediante un work item.
Participantes : Son todas las personas involucradas en el proceso, incluyendo quienes simplemente
recibieron una notificación de que alguna cosa fué o no ha sido hecha.
Container : Es el lugar donde todos los datos usados por el workflow son almacenados.
3
2. Configuración del Sistema.
La configuración del sistema es el primer paso que debemos realizar para la utilización del workflow. El
customizing del workflow lo podemos realizar mediante la transacción SWU3. Las cruces en rojo indican qué
tareas de customizing no han sido desarrolladas.
SAP nos provee de un customizing automático ( ) el que se encargará de ejecutar las tareas no
configuradas.
Es importante tener autorización para ejecutar estas tareas y desarrollar la actividades individuales tales como
planificar un job o crear el usuario de background WF-BATCH.
4
3. Entrega de Work Item.
Los work items llegan al Bussines Workplace que es la casilla de correo de SAP (SBWP).
Cuando un work item llega a la casilla de los posibles responsables de ejecutar la tarea queda en espera de que
alguno de ellos lo ejecute. Al realizar esta acción el usuario responsable automáticamente reserva el work
item para sí mismo, así este desaparece de las otras casillas.
5
4. Asignación de Responsables.
Los responsables son las personas que hacen el trabajo dentro del workflow. Ellos deben procesar cada tarea
dentro del flujo. Existen tres tipos de responsables:
Posibles Responsables : Son las personas que están autorizadas para ejecutar work items. Están siempre
asignados a una tarea sobre la cual muchos work items pueden estar basados. Si un usuario no es un
posible responsable de un work item, no podrá ejecutarlo, es decir, si ningún posible responsable ha sido
asignado a la tarea, nadie podrá ejecutar algún work item basado en esta.
Responsables : Es la persona responsable de ejecutar una tarea en un caso particular. Estos responsables
normalmente son asignados a nivel de paso en el workflow, pero también puede ser asignados a nivel de
tarea por una regla de determinación de responsable en la definición de la tarea. También es posible
asignar responsables mediante una expresión, por ejemplo el iniciador del workflow el cual se encuentra
almacenado en el container del workflow. Otra forma de asignación es mediante una regla en donde los
responsables son calculados dinámicamente cuando el work item es creado.
Es importante destacar que los responsables deben estar definidos como posibles responsables en la tarea,
de lo contrario el workflow no les enviará sus workitems.
Responsables excluidos : Son las personas que no deberán ejecutar un particular workitem, aunque sean
posibles responsables o responsables.
Asignación de Responsable en tarea.
6
Asignación de Responsable en paso de workflow.
4.1 Asignación de Responsables usando la Estructura Organizacional.
Cada responsable de workflow debe tener un ID de usuario, así cuando se asigna un responsable a un work
item estamos asignando Ids de usuario. Debido a la alta rotación de personal en una organización este tipo de
asignación requiere una constante mantención, por esto se recomienda usar el plan organizacional.
El plan organizacional es a veces usado para asignar posibles responsables, pero puede también ser usada
para asignar responsables directamente o conjuntamente con una regla de determinación de responsables.
En el plan organizacional se distinguen los siguientes objetos organizacionales:
Unidad Organizativa: Cada unidad representa a un grupo de personas tales como un equipo, sección,
departamento, área de trabajo, etc.
Función: Es un rol funcional dentro de la organización. Ellos equivalen a la descripción de un trabajo.
Posición: Cada posición representa un cargo.
Usuario: Cada usuario es el ID de usuario actual de una persona en la organización.
Los objetos organizacionales y relaciones son mantenidos por las transacciones de Administración
Organizacional tales como PPOM.
7
5. Construcción de Workflows.
La herramienta central para la creación de workflows es el Workflow Builder (SWDD). Dentro de esta
herramienta es posible crear todas las componentes de un workflow, incluyendo todos los containers que
necesite para tomar datos desde un paso a otro.
Cada workflow tiene un número de pasos que ejecutan actividades o controla el workflow. Las actividades
son manipuladas dentro de las tareas. Es posible usar la misma tarea en diversos pasos de un workflow.
Una tarea posee su propio container, el cual contiene todos los datos necesarios para su ejecución. Para pasar
datos desde el container del workflow al container de la tarea o viceversa se debe definir un flujo de datos
como parte del paso de workflow.
Cada paso tiene una o más posibles salidas dependiendo del tipo de paso y la tarea subyacente si es que existe.
Las expresiones son variables usadas en el workflow para controlar el flujo o deliberar un resultado. Por
ejemplo una expresión puede ser un elemento de container o el atributo de un objeto.
5.1 Workflow Builder.
El Workflow Builder provee una vista gráfica de la definición de workflow. La pantalla esta dividida en los
siguientes frames:
Workflow: Aquí es posible insertar nuevos pasos dentro de la definición de workflow. Haciendo doble
click sobre um paso despliega la definición del paso asociada.
Vista Previa: La parte del workflow desplegada en el workflow frame es marcada con un rectángulo
verde. Cambiando el tamaño o posición del rectángulo cambia el despliegue en el workflow frame.
Tipos de pasos insertables: Muestra todos los tipos de pasos que pueden ser utilizados en la definición de
workflow
Información: Este frame muestra que workflow es desplegado, el estatus de el workflow, y el número de
versión de este workflow en el sistema. Para cargar una versión diferente o un nuevo workflow ID solo se
debe sobre escribir en este frame y presionar enter.
Navegación: Aquí se muestran todos los pasos utilizados en el workflow desplegado. Para insertar un
nuevo paso dentro del workflow se debe hacer clik en el tipo de paso e insertarlo dentro de la definición
de workflow.
Workflow Container: Todos los elementos del container del workflow son desplegados aquí. Es posible
crear nuevos elementos.
Mensajes: Todos los mensajes generados por chequeo de sintaxis son desplegados aquí. Haciendo click
sobre el mensaje es seleccionada la definición de paso con problemas.
8
Informació
n
Workflow
Navegació
n
Tipos de
pasos Vista
nsertabkle Previa
Pasos
Container
de
Workflow
Mensajes
9
5.2 Construyendo un workflow.
Cuando el Workflow Builder es llamado por primera vez o se opta por crear un nuevo workflow es creada una
definición de workflow inicial.
El workflow inicial posee las siguientes partes:
El comienzo de la definición de workflow es indicada por .
El fin de la definición de workflow es indicada por .
El área en el cual se insertará la nueva definición de workflow es indicada por un paso no definido con una
salida. Los pasos son representados por símbolos. El nombre de la salida es desplegada sobre la flecha
direccionada al siguiente paso en la vista estándar. Los posibles pasos a utilizar son los siguientes:
Tipo de paso Símbolo Descripción
Actividad Ejecución de una tarea o subworkflow. En ejecución los datos son pasados
desde la tarea o subworkflow al workflow container en el momento de la
creación del work item, y viceversa en finalización del work item
Ancla Ad Hoc En la definición es posible especificar workflows que puedan remplazar este
paso. En ejecución una usuario autorizado puede seleccionar uno de los
workflows especificados. Los pasos de este workflow reemplazan
dinámicamente el ancla ad hoc
Condición Dependiendo de el resultado de la condición se sigue la trayectoria del
resultado. En el editor de la condición es posible simular el resultado de la
10
condición para hacer testeo de condiciones complejas fácilmente.
Operación Usado para calcular operaciones aritméticas o asignación de valores a
Container elementos de container del workflow usando constantes y datos en el container
del workflow.
Documento de Un documento es creado desde una plantilla de documento usando variables en
modelo el texto las cuales son llenadas durante la ejecución del workflow usando los
elementos de container del workflow. El container del workflow recibe un
nuevo elemento de container que contiene el ID de documento.
Programa Ejecución de un evento. El container del evento es llenado desde el container
generador de del workflow
eventos
Vía de Usado para procesamiento paralelo. Es posible definir la cantidad de ramas
procesamiento paralelas y cuantas deben ser completadas para terminar y continuar con el
paralelo flujo.
Formulario Un elemento de container puede ser desplegado, procesado o aprobado como
una formulario.
Loop (UNTIL) Una secuencia de pasos es procesada al menos una vez y luego repetidamente
hasta que se cumpla la condición de termino definida.
Loop (WHILE) Una secuencia de pasos es procesada repetidamente tantas veces como la
condición definida sea verdadera.
Condición Basada en el valor de un elemento de container de workflow, una de varias
múltiple ramas definidas en la definición de workflow es procesada.
Control de Este puede ser usada para cancelar la ejecución de un work item o workflow.
proceso
Enviar Mail El texto ingresado en este tipo de paso es enviado como un email.
Decisión de El responsable debe tomar una decisión dentro de una lista de opciones. Cada
usuario opción definida es una rama en el workflow.
Esperar Evento El sistema espera por un específico evento. El work item es solamente
completado si el evento esperado ocurre.
Actividad Web Los elementos de container seleccionados son puestos en un XML usando
protocolo http.
Existen varias maneras de insertar nuevos pasos en un workflow, dependiendo lo que selecciono con el mouse
es donde el nuevo paso será ubicado. A continuación se muestran las maneras de insertar un nuevo paso.
¿Donde quiero insertar un paso? ¿Qué debo seleccionar?
Después de un paso La salida de el paso, la cual está ubicada en la rama
relevante de la definición de workflow.
Antes de un paso El paso
Como una nueva rama de un proceso paralelo El símbolo al comienzo de la bifurcación.
5.3 Containers.
Los principales containers usados son:
Un container de workflow para cada workflow y subworkflow. Solamente los elementos de container
clasificados como import pueden ser llenados cunado el workflow ha comenzado.
Un container para cada tarea. Elementos de container de entrada son llenados desde el container de
workflow y elementos de container de salida son transferidos de regreso.
11
Un container de método para cada método. Elemetos de container de entrada son llenados desde el
container de la tarea y elementos de container de salida son transferidos de regreso.
Un container de evento para cada evento. Todos lo containers de evento son solamente elementos de
export.
Un container de regla para cada regla. Los elementos de container de entrada son llenados desde el
container de workflow.
Un elemento de container puede mantener solo un valor o la referencia a un objeto, o pueden ser elementos
multilínea.
6. Business Objects.
Los objetos de negocio integran los datos y funciones de una aplicación de negocio dentro de un workflow.
Cuando hablamos de objetos de negocio es importante distinguir dos conceptos importantes:
Tipo de Objeto: Es el diseño e implementación del acceso a datos y funciones, es decir, el tipo de objeto
contiene el programa que lee o calcula datos y llama funciones de negocio. Por ejemplo, el objeto Cliente
define el acceso a todos los datos relacionados con éste incluyendo su ID y nombre y todas las funciones de
cliente relacionadas.
Instancia de Objeto: Es una copia en tiempo de ejecución de su tipo de objeto que contiene los datos o
accesos o las funciones relevantes a esta particular instancia del objeto. En este caso posee un identificador
único.
Cada tipo de objeto tiene los siguientes componentes:
Campos Clave: Los campos clave define únicamente cada instancia del objeto. Por ejemplo para el tipo de
objeto Cliente la clave es el Id de cliente.
Atributos: Los atributos describen a un tipo de objeto. Estos datos podrían ser extraídos desde de la base de
datos o valores calculados. Atributos pueden en si mismos ser referencias a otros objetos de negocios.
Métodos: Los métodos proveen acceso a funciones de negocio. El código de un método puede contener
transacciones, reportes, programas, módulos de funciones, BAPIs o batch input.
Eventos: Los eventos transmiten el cambio de estatus de un objeto.
Dos objetos pueden relacionarse mediante herencia. El tipo de objeto desde donde sus atributos y métodos son
heredados es llamado el supertipo. El subtipo hereda componentes desde el supertipo. El subtipo tiene los
mismos campos claves como su supertipo pero extendido funcionalmente.
12
6.1 Bussines Object Builder (SWO1).
Permite visualizar, modificar y crear objetos de negocio. Para accesar un tipo de objeto es necesario utilizar su
ID. Para buscar un objeto es posible usar el Business Object Repository (SWO3).
Al seleccionar un objeto podemos ver cada componente de un objeto los cuales poseen una codificación de
color. Las componentes son heredados de un supertipo o interface, las componentes de color blanco son
locales para este tipo de objeto.
Para ver el programa relacionado a cada componente individual se debe escoger la componente y presionar el
botón Programa. Esto nos llevará al programa del tipo de objeto, posicionado sobre la línea donde comienza
13
el código para este componente. Los campo claves y eventos no poseen código de programa . Los campos
claves son simplemente declarados dentro del onjeto y son llenados cuando un objeto es instanciado. La
implementación de un evento es codificada en la aplicación de negocio y no en la definición del objeto.
6.2 Test de Objeto.
Es posible realizar un test del objeto creando una instancia de éste. Todos los atributos serán extraidos de la
base de datos o calculados en tiempo de ejecución.
El procedimiento para ejecutar un objeto en modalidad test es el siguiente:
Presionar el botón para ingresar a modalidad test y luego presionar el botón para crear
una instancia del objeto.
14
Al crear la instancia todos los atributos son desplegados.
Cada método tiene una opción de ejecucíón la cual nos permite probar su ejecución para esto es necesario
completar sus parámetros.
15
6.3 Creación de tipos de objeto.
Existen dos maneras de crear un nuevo tipo de objeto:
Crear un tipo de objeto desde cero: Se puede crear un nuevo tipo de objeto usando la opción “Create” en la
pantalla inicial del Business Object Builder.
Extender un tipo de objeto existente: Es posible crear un tipo de objeto como un subtipo del tipo de objeto
existente ingresando el tipo de objeto existente y usando la opción de “Crear Subtipo” en la pantalla inicial
del Business Object Builder. La clave, atributos, métodos y eventos de el supertipo son inmediatamente
heredados por el subtipo. Todos los componentes heredados son marcados en rojo.
Cuando se crea un tipo de objeto se debe especificar la siguiente información.
Tipo Super: El objeto del cual se heredarán todos sus componentes.
Tipo Objeto: Este es el ID técnico del objeto que será creado.
Objeto: Este es el nombre que describe al objeto.
Denominación: Una descripción breve útil para la búsqueda del tipo de objeto.
Descripción Breve: Una descripción larga útil para la búsqueda del tipo de objeto.
Programa: Cada tipo de objeto tiene su propio programa.
Aplicación: Componente, por ejemplo S para Basis, M para logística.
16
El estatus inicial de un tipo de objeto es “Modelado”. Un tipo de objeto modelado está diseñado pero no
implementado, es decir, no puede ser usado todavía. Se deberá cambiar el estatus del objeto a
“Implementado” y luego a “Liberado”. Luego se debe generar el objeto con la opción y quedará listo
para ser usado.
Al crear un subtipo de un tipo de objeto es posible delegar el supertipo al subtipo. Esto significa que donde
quiera que el supertipo sea referenciado dentro de un workflow, el subtipo será utilizado en lugar del otro.
Para delegar un supertipo a un subtipo se debe escoger la opción Opciones – Delegación en la pantalla inicial
del Business Object Repository. Se debe ingresar el tipo de objeto original en Tipo Objeto y el subtipo al cual
será delegado en Tipo de Delegación.
17
