Curso Workflow

SAP Business WorkflowIntroducción

2

Objetivos del Curso

ObjetivosSon objetivos de este curso

� Explicar la terminología utilizada en el sistema de workflow� Explicar las herramientas y conceptos de workflow� Explicar las capacidades del sistema de workflow y lo que realmente puede

proporcionar a la empresa� Explicar los detalles para definir y mantener la estructura organizativa de la

empresa� Mostrar como analizar la implementación de los diferentes workflow de la

empresa� Mostrar los diferentes reportes que permiten monitorizar el sistema de workflow� Permitir encontrar rápidamente la documentación relacionada con el tema

3

Contenidos

• Definición de Workflow

• Ventajas al utilizar Workflow

• Terminología Workflow

• Arquitectura del Sistema Workflow

• Ejemplos y Documentación

4

Definición

• Los sistemas de workflow son herramientas que permiten la implementación técnica de procesos de negocio. Permiten dar soporte y agilizar el proceso de negocio ganando tiempo. Permite a la gente involucrada llevar a cabo procesos de negocio complejosindependientemente del tiempo y el lugar.

• El flujo de trabajo es controlado y coordinado activamente por el sistema de workflow. El control incluye el monitoreo de pasos de trabajo individuales y el inicio de procesos para escalar las tareas que lleguen a su fecha de vencimiento.

• En el sistema SAP, el sistema de workflow se integra completamente con las funciones de negocio del sistema R/3 a través de sus Business Objects.

• Adicionalmente el sistema de workflow de SAP permite su integración con la gestión organizacional lo que permite relacionar personas o estructuras organizativas a las tareas del workflow.

5

Definición

• El sistema de workflow cubre todos los aspectos del proceso…

El Flujo(actividades)

La Gente(organización)

Los Efectos(información)

6

Definición

CaracterísticasLas siguientes son características comunes a todos los workflows

� Incluyen un numero finito de actividades� Las actividades siempre se llevan a cabo de la misma manera� Involucran a diferentes personas y departamentos� Requieren un alto grado de coordinación

Otras CaracterísticasLos sistemas de workflow controlan los procesos

� Basándose en un modelo� Y son particularmente útiles en organizaciones bien estructuradas

7

Definición

• Workflow no es:– Un sistema de gestión de documentos (trabaja con ellos)

– Un sistema de e-mail o groupware (trabaja con ellos)

– Un sistema de distribución de datos entre sistemas (para ello workflow utiliza ALE, EDI, WebForms-XML, etc.)

– Una transacción para secuenciar pantallas

– Administración de datos temporales

– Una herramienta que se utilice para realizar funciones no existentes en el sistema (si no se puede ejecutar la función manualmente en el sistema, entonces el sistema de workflow tampoco lo hará)

8

Contenidos





• Ejemplos

9

Ventajas del Workflow

• Para los usuarios– Tan pronto como una tarea aparezca se le enviará electrónicamente a su

inbox

– La información, explicaciones e instrucciones se envían todas juntas en un mismo documento

– El sistema workflow lleva al usuario directamente a la transacción

– Permite escalar trabajos automáticamente y determina los responsables y superiores directamente utilizando la estructura organizativa

• Para la empresa– Aumenta la productividad

– Agiliza los procesos

– Aumenta la satisfacción de los clientes (mejores flujos de información, mayor rapidez en responder)

10

Ventajas del Workflow

Coordinar Visita

Ajustar Limite de Crédito

Cambiar Plan Producción

Representante de Ventas

Gestión de Créditos

Jefe de Producción

Nuevo Cliente Importante

Televentas

Cambia el maestro de

clientes

Evento

Change document

WorkFlow

11

Contenidos






12

Terminología Workflow

Business Object

Paso

Tarea

Evento

Workflow

Business Workplace

Actividad

Papel

Agentes

13


• Existen 5 preguntas clave para cada parte de un proceso de negocio

¿Quién? ¿Qué?

¿Cuando? ¿Con que Objeto?

¿En quéorden?

14


• ¿En qué orden?

• El workflow controla el flujo del proceso• Consiste en un conjunto de pasos• Puede ser lanzado mediante eventos

• La definición del workflow describe el proceso de negocio a implementar

• Cada workflow se compone de una serie de pasos enlazados– Cada paso tiene un tipo y un símbolo propio para que sea mas fácil de leer.

– Cada paso del workflow procesa datos que se van pasando de paso a paso a través de contenedores.

• Un workflow se activa mediante uno o mas eventos. El evento depende del workflow y debe estar activamente relacionado a él.

• El workflow se crea y modela mediante el Workflow Builder (SWDD)

Workflow

15


• ¿Qué?

• Una actividad puede ser: Ejecutar una transacción, ejecutar un reporte, ejecutar un modulo de funciones, ejecutar una tarea en un sistema remoto, modificar un documento local, etc.

• Generación y envío de documentos• Toma de decisiones• Control de flujo

• Por razones prácticas y por cuestiones de reusabilidad y consistencia de la lógica implementada, las actividades siempre utilizan tecnología orientada a objetos.

• Las actividades pueden ser ejecutadas por el sistema o por una persona (esto ultimo requerirá de la técnica de determinación de agentes).

• En tiempo de ejecución la actividad o tarea se denomina workitem, y le indica al responsable lo que debe hacer, así como también la información necesaria para ejecutar la actividad.

Actividad / Tarea

16


• ¿Con qué objeto? Business Object

– Los objetos consisten en un conjunto de información relacionada que puede ser accedida mediante una clave o conjunto de claves

– Los objetos se crean en tiempo de ejecución y son instancias especificas de un tipo de objeto definido previamente al cual se le ha asignado valores

– Los componentes de un objeto son;• Atributos (son los campos que identifican el objeto)• Métodos (indican operaciones que se pueden aplicar sobre el objeto)• Eventos (indican cambios de estado en el objeto: impreso, liberado, creado,

eliminado, etc.)

– En el workflow se utilizan los métodos de los tipos de objetos para modelar las actividades

– A su vez se utilizan los eventos de los tipos de objetos para iniciar, finalizar o marcar eventos en el workflow.

– Los tipos de objeto se crean y definen mediante el Business Object Builder (SWO1)

17


• ¿Quién? Agentes

– Todas las tareas requieren la definición de agentes posibles. Los agentes posibles son todas aquellas personas que pueden recibir esa tarea, excluyendo de esta manera a todos los que nunca la recibirán.

– Las tareas adicionalmente pueden definirse como tareas generales. En este tipo de tareas no existe restricciones en cuanto a las personas que puedan recibirla.

– Luego se definen los agentes responsables. El agente responsable es quien recibirála tarea en su Business Workplace . Siempre un agente responsable es un agente posible.

– Los agentes responsables se determinan siempre en tiempo real mediante papeles.

– En un papel se definen ciertos criterios mediante los cuales se determinara en tiempo real quien es el usuario del sistema responsable por ejecutar la tarea. Existen varios tipos de papeles: por competencias, por función, por estructura organizativa o por atributos organizativos.

– En la determinación de agentes juega un papel muy importante la estructura organizativa de la empresa

18


• ¿Cuándo? Evento

– Los eventos informan al workflow que algo ha sucedido. El workflow a su vez puede reaccionar al evento si la relación entre ambos esta activada

– Los eventos los publica el sistema para que puedan ser evaluados por todos los workflows.

– Todas las tareas pueden dejar como resultado uno o mas eventos (por ejemplo la tarea aprobar pedido puede dejar los eventos aprobado, rechazado, modificado). De esta manera el flujo del workflow puede subdividirse en esa tarea en tres caminos diferentes.

– Existe un tipo de paso que implica esperar por un evento y otros pasos que permiten generar eventos

– Los eventos se configuran en los tipos de objeto y pueden generarse por:• Por programa (mediante funciones especificas de la API de workflow)• Mediante documentos de cambio (Change Documents)• Mediante el sistema de mensajes (utilizado en SD y MM)• Mediante la gestión de status de documentos (utilizado en PP, PM, QM, etc.)• Mediante el sistema de información logística (alertas)• Mediante documentos de cambio del modulo RH

19

Contenidos






20

Arquitectura del Workflow

• Arquitectura General del Sistema de Workflows

21


• Arquitectura General del Sistema de Workflows– Definition tools

• Componentes para implementer una definición de workflow (Workflow Builder, Business Object Repository - BOR)

• En el tiempo de ejecución, la definición del workflow forma las bases de las ejecuciones de workflows basadas en ello. (workflow instances).

– Runtime system • Componentes de ejecución• Controla y coordina el proceso del workflow (workflow manager)• Para gestionar la ejecución de los work items individuales (individual work steps)

incluyendo asignaciones a agentes y monitorizando fechas limite (work itemmanager)

• Para evaluar los eventos recibidos vínculos de tablas y para gestionar los eventos recibidos registrados como un evento (event manager)

• Para la gestión de los datos requeridos de la ejecución de las tareas definidas en la definición del workflow.

22


• Componentes del Sistema Workflow

23


• Componentes del Sistema Workflow– Business Workplace – Interacción con usuarios en el tiempo de ejecución

y provision de las funciones de aplicación.

– El workflow manager arranca el tiempo de ejecución del workflow “en primer lugar” y representa funciones de control para procesos automáticos a lo largo de los módulos de aplicación de R/3:• Control• Monitoring• Coordinación• Sincronización

– El workitem manager interactúa con la aplicación llamada en el método de la tarea.

24


• Tareas / Workflows– Las tareas son los bloques de construcción para los workflows.

– La clave para tareas y workflows se compone de la siguiente manera: • XX (código de dos caracteres que representa el tipo de tarea• yyyyyyyy (número de ocho cifras secuencial)

– Tareas (código TS) y workflows (codigo WS) son independientes de mandante.

– Desde la Release 4.5 en adelante, la opción del menú “Crear tarea” solo ofrece la creación de tareas y workflows estandar (TS y WS).

– Los códigos para tareas en el sistema son T (tareas de cliente) y WF (tareas de workflow), pero estas son dependientes de mandante.

– Existiendo WF y T en un sistema todavía pueden ser ejecutadas. Pero no deberías, sin embargo, crear nuevos WF y T, por que WF y T no se van a desarrollar más.

– Una plantilla de workflow (WS) no puede contener tareas de cliente (T).

– Para encontrar el mantenimiento de tareas en el sistema, escoge:• SAP EASY ACCESS -> Herramientas -> Business Workflow -> Desarrollo -> Herramientas

de Definición -> Tareas/Grupos de Tareas

25


• Definición de una Tarea (General)– Las Tareas identifican una acción que necesita ser ejecutada. Ellas siempre se

refieren a un método de un tipo de objeto.– La acción puede ser un paso que el sistema ejecuta independientemente en fondo.

En este caso, ningún representante/agente es asignado.– La acción puede ser una tarea de dialogo. En este caso, la tarea tiene agentes

responsables. Encontrará la asignación de los representantes/agentes escogiendo la opción del menú ‘Additional data -> Maintain agent assignment’.

– Las tareas poseen un titulo y una descripción que se muestra en el work itemprevisto y en el detalle de la visualización del work item.

– Una notificación puede ser enviada a la bandeja de entrada de mensajes cuando el procesamiento del work item está completo.

– Si el control o monitorización de la fecha limite es activado para un paso del workflow y Visualizar Texto es activado como reacción, si las fechas tope no son cumplidas, los textos a enviar deberían ser definidos.

– Se pueden incluir variables en todos los textos, los cuales son suministradas con valores desde la interfaz de workflow en el tiempo de ejecución (runtime).

26


• Definición de una Tarea (General)

27


• Business Objects– Tipo de Objeto (en tiempo de definición)

• Descripción genérica (definición) de los componentes (claves, atributos, eventos, métodos) de un objeto

– Objeto (en tiempo de ejecución)• Un objeto es un ejemplo de un tipo de objeto (instancia) con particulares valores

atributos.• Los valores atributos son entradas en tabla en la base de datos de R/3, o son

determinados desde valores conocidos en el tiempo de ejecución.• Puede acceder a un objeto usando una clave de identificación única.

– Métodos: Funciones permitidas para un objeto.• Los métodos encapsulan las funciones familiares y de conjunto del sistema R/3

haciéndolas accesibles al sistema de workflow. • Los métodos del objeto se refieren a la disponibilidad de funciones ABAP

(transacciones, módulos de función, módulos de dialogo, y demás).

28


• Business Objects

29


• Agentes– Un lista de posibles agentes son requeridas para una tarea (TS). Esta lista contiene

los empleados en tu empresa los cuales están autorizados a recibir este work item(representación de una tarea en el tiempo de ejecución).

– Cuando se define la tarea pude crear una "tarea general", o escoger "Asignación agente - Crear" y crear una relación con un objeto organizacional. Cualquier usuario del sistema puede ejecutar tareas generales.

– Los destinatarios del work item son determinados en el tiempo de ejecución.

30

Contenidos






31

Ejemplos

• Algunos de los Worflows estándares de SAP para ver– Liberación de un pedido de compras (20000075)

– Liberación general de una solicitud de pedido (20000077)

• Algunos desarrollos propios para ver– Envío de notificaciones a compras por exceso de importes (90000001)

– Liberación de pedidos de nuevas inversiones – grandes reparaciones (90000006)

– Envío de notificaciones a responsables de NI – GR (90000007). Este es un ejemplo de una tarea múltiple aplicada al workflow 90000006.

32

Documentación

• Para ver más Workflows estándares revisar la documentación de cada módulo en SAP o bien entrar en la ayuda de SAP para Workflows y ver escenarios de Workflows en aplicaciones (http://help.sap.com)

Documentación General – Demos - Tutoriales

33

Documentación

• Para mayor información acerca de workflow recomiendo leer el libro “SAP Practical Workflow, de Alan Rickayzen.” que puede comprarse en http://www.sap-press.com o en la pagina de SAP-Shop.

• Algunos sitios web de interés– www.workflowing.com - Pagina con algunos trucos para WF– www.asug.com – Es el grupo de usuarios SAP que tiene un area dedicada a WF– www.e-workflow.org - Información de WF en general– www.sap.com/notes

• 322526 - Recomendaciones para el análisis de errores• 80948 - Idiomas en las tareas• 27848 - Idiomas en los workitems• 77607 - Transporte de estructura organizativa con copia de mandante• 217229 - Para hacer preguntas sobre WF al MIT• 63480 - Como unir WF con MS Exchange

November 25, 2008

SAP Business WorkflowCustomizing

2

Contenidos

• Customizing en el sistema workflow– Autocustomizing

– Rangos de números

– Responsable del sistema workflow

– Jobs

– Prefijos de tareas

– Verificación del customizing

• Customizing de workflows estándar (Ejemplo)– Customizing automático de tareas

– Activación de workflows estandard

3

Configuración del Sistema

• El customizing del sistema workflow en SAP R/3 es una tarea sencilla si se siguen algunos consejos básicos.

• Principalmente la configuración del sistema de workflow posee las siguientes actividades básicas:– Definir un rango de números para los objetos workflow que se vayan a

crear nuevos (workflows, tareas, papeles, etc.)– Definir una versión de plan activa para la estructura organizativa– Definir un usuario batch para las tareas que deben ejecutarse por el

sistema– Definir un destino RFC para las tareas batch– Definir uno o mas usuarios responsables del sistema workflow (adm.)– Crear los jobs para la supervisión de tareas vencidas y erróneas

• Para acceder al customizing de workflow seguir la siguiente ruta desde la IMG: Base – Business Management – SAP Business Workflow

4


• Configuración automática:– El sistema de workflow viene con una herramienta muy útil para configurarlo

automáticamente. Esta herramienta se ejecuta con la transacción SWU3, o desde la IMG: actualizar parametrizaciones standard para SAP Business Workflow

-Para ejecutar el customizing automático simplemente se presiona el botón Customizing Automático, y se deja que el sistema haga su trabajo.

- Luego de ejecutar esta transacción deberemos repasar a mano algunas configuraciones.

- Una vez terminada toda la configuración podremos probar el sistema de workflow presionando el botón Iniciar workflow de verificación

5


• Configuración manual:– Responsable del workflow

• En este punto se configura un usuario o grupo de usuarios responsables de administrar el sistema de workflow. Por defecto la configuración automática colocará el usuario de quien este configurando el sistema.

• Tarea Standard y Unidad de Tiempo standard. Dejar la tarea por defecto y colocar la unidad de tiempo que se desee. Esta unidad de tiempo solo afectara en el momento del desarrollo por que será la que aparecerá por defecto.

6


• Configuración manual:– Jobs

• Existen 2 jobs que deben programarse para monitorear tareas vencidas y erróneas. El primero que configuraremos es el de tareas vencidas. Este tiene dos opciones configurar un job aislado (para que se ejecute en el momento o dejar uno planificado (ver la imagen y el nombre del job es SWWDHEX)

• En el caso del job para workitems erróneos (SWWERRE) además del intervalo de ejecución hay que configurar la cantidad de intentos fallidos de un workitem antes de enviar una notificación al administrador del workflow.

7


• Configuración manual:– Prefijos para objetos estándar

• Al desarrollar workflows nuevos (workflows, tareas, papeles, etc.) el sistema asignara un numero interno al objeto desarrollado. Este debe ser univoco entre todos los sistemas de desarrollo que tengamos, es por ello que para cada sistema y mandante de desarrollo que posea la empresa se debe colocar un prefijo de 3 dígitos y la clase de desarrollo que se este utilizando para desarrollos workflow.

• Previamente se debe definir la clase de desarrollo.

• De esta manera aseguraremos la consistencia de los desarrollos entre sistemas.

8


• Configuración manual:– Rangos de números

• Si se va a crear una estructura organizativa ligada a una versión de plan especifica, se debe indicar un rango de números para cada tipo de objeto a crear (unidad organizativa, puesto de trabajo, función, etc.).

• Primero debemos ver cual es la versión activa del plan (que se configuro mediante la configuración automática) y la cual podremos cambiar (aunque no es recomendable).

• Luego podremos asignar los rangos de números que deseemos para todo el plan.

9

Contenidos

• Customizing en el sistema workflow– Autocustomizing

– Rangos de números

– Responsable del sistema workflow

– Jobs

– Prefijos de tareas

– Verificación del customizing

• Customizing de workflows estándar (Ejemplo)– Customizing automático de tareas

– Activación de workflows estandard

10

Configuración de Workflows Estandard

• Customizing Workflow– El acceso al customizing de workflow desde la SPRO se alcanza a través del

siguiente paso:• BASE � Business Management � SAP Business Workflow

• La configuración de los workflows estándar de SAP se base principalmente en realizar 2 actividades:

– Asignar responsables a las tareas del workflow que corresponda

– Activar la relación entre el workflow y el evento que lo inicia

• Estas actividades se configuran en el “customizing específico de tareas” dentro de las opciones específicas de customizing de workflow.

11

Configuración de Workflows Estándar

• Ejemplo: Configuración del workflow estándar para la liberación general de solicitudes de pedido.

– Aparecerá un árbol con todos los módulos del sistema y los submódulos.

– Seleccionamos el elemento funcional que deseamos (en nuestro caso gestión de materiales – compras)

– Aparecerán 2 opciones • Asignar tareas a responsable• Activar acoplamiento de eventos

12


• Asignar tareas a responsables– Para asignar una tarea la marcamos y

presionamos el botón “propiedades”.

– Se podrá marcar la tarea como tarea general si “cualquiera” puede ejecutarla.

– Si solo algunos puestos de trabajo, unidades organizativas, usuarios, etc. pueden ejecutar la tarea entonces deberán asignarse con el botón de asignación que es el botón que esta mas a la izquierda en la barra de herramientas. (ver demo)

13


• Activar acoplamiento de eventos– Para activar el evento que inicia el

workflow marcamos el workflow que deseamos activar y luego presionamos el botón de activación que esta en la barra de herramientas.

– Una vez activado el estatus del acoplamiento quedará en “activado”.

– Una vez finalizado esta configuración podremos probar en la aplicación si el workflow funciona ejecutando el programa que lanza el evento (depende de cada workflow en particular y de la aplicación propia que lo ejecuta).

November 25, 2008

SAP Business WorkflowDesarrollo

2

Objetivos del Curso


� Identificar todos los puntos en workflow donde se requiere programación� Crear tipos de objetos nuevos y extender los existentes� Crear módulos de funciones para determinación de papeles� Programar eventos� Programar módulos de funciones para el control de eventos� Gestionar y monitorear el sistema de workflow en tiempo de ejecución

PerfilesA quienes va dirigido este curso

� Analistas programadores con muy buen conocimiento y experiencia ABAP� Analistas programadores con muy buen conocimiento en OOP

3

Contenidos

• Introducción

• Definición e Implementación de Business Objects

4

Introducción

• Repaso: ¿Qué es un sistema workflow? – Es un sistema que entrega trabajos (tareas)

• En la secuencia correcta• Con toda la información necesaria• En el momento correcto• A la gente responsable

– Relacionando estas tareas de manera automática.– Control independiente de la aplicación, de las actividades entre las

transacciones.

• Repaso: Que cosas NO hace el sistema Workflow.– Simplificar transacciones complejas (menús, pantallas, etc.)– Proveer procesos de negocio eficientes de manera automática (esta tarea

se la dejamos a los modeladores del sistema de workflow)– Una vez que una aplicación es llamada por el sistema de workflow el

control lo tendrá la aplicación y no el sistema de workflow.

5

Introducción

• Tareas en el sistema de workflow

– Definición del proceso• “¿Qué sucede y en qué orden?”• Utilización del Workflow Builder y Definición de Tareas• Resultado: el proceso se ejecuta en la secuencia correcta

– Modelización de la organización• “¿Quién hace que?”• Modelo Organizativo y Definición de Papeles• Resultado: El trabajo es realizado por las personas responsables

– Encapsulación de la Aplicación• “¿Cuáles son los objetos que se necesitan?• Business Object Builder y Business Object Repository• Resultado: El trabajo se envía con la información necesaria

6

Introducción

• Tareas en el sistema de workflow

– Soporte al usuario final• “¿Qué tengo que hacer hoy?”• Herramientas: Business Workplace• Resultado: El trabajo se envía a la gente que corresponde en el momento que

corresponde

– Control del proceso• “¿Qué pasa cuando…?”• Herramientas: Workflow Manager y Workitem Manager• Resultado: El trabajo es realizado en la secuencia correcta en el momento

correcto

– Evaluación del proceso• “¿Quién hizo que y cuando?• Herramientas: Reportes y Análisis

7

Introducción

• Arquitectura

Nota: A� B significa que el elemento A utiliza el elemento B

8

Introducción

• Áreas de la arquitectura donde requeriremos programación

Nota: otras áreas donde puede requerirse programación son:

- Administración- Reportes - Creación de Workitems.

9

Contenidos

• Introducción

• Definición e Implementación de Business Objects

10

Definición e Implementación de Business Objects

• Comprende el desarrollo en los siguientes elementos de la arquitectura

• Las herramientas que se aprenderán a utilizar en esta unidad son:– El BOR (Business Object Repository) para navegar entre los datos– El BOB (Business Object Builder) como herramienta de desarrollo

11


• ¿Por qué utilizamos tecnología orientada a objetos?– Principalmente por 2 motivos:

• Permite simplificar el proceso de modelado del workflow• Es una interfase estándar para el entorno de ejecución del workflow

– Esto se resume en la encapsulación. Los “datos” utilizados en el workflow (tablas) se encapsulan en elementos clave y atributos del objeto, mientras que los programas, funciones, transacciones, etc. se encapsulan en métodos.

12


• ¿Dónde se utilizan los objetos en un workflow?

– Los objetos se utilizan en:

• Tareas: para ejecutar métodos• Estructuras de control: para consultar atributos• Operaciones en los contenedores: para consultar atributos• Pasos de espera o disparadores de eventos: recibiendo o generando eventos• Funciones de verificación y de determinación de agentes: para consultar atributos• Funciones receptoras: para consultar atributos• Papeles: para consultar atributos• Métodos secundarios: para ejecutar métodos

13


• Relaciones entre objetos

– Herencia• Se utiliza para realizar extensiones funcionales.• La relación responde a la frase “es un tipo de”.• Por ejemplo: Documento � Documento Contable

– Composición• Se utiliza para componer un objeto con otros objetos• La relación responde a la frase “es parte de”• Por ejemplo: Orden � Posicion de la orden

– Asociación• Se utiliza para relacionar dos objetos a través de una clave externa• La relación responde a la frase “en relacion a”• Por ejemplo: Material � Solicitud de pedido

14


15


• Object-Type (Tipo de Objeto): Definición

– Los tipos de objetos pueden consultarse a través del Business Object Repository(BOR) la cual es independiente de mandante.

– Cada tipo de objeto esta asociado a una clase de desarrollo y, no obstante, a un componente de la aplicación

16

Definición e Implementación

• La estructura interna de los Business Objects responde a un conjunto de leyes.

• Un business object está definido por los siguientes elementos: – ID del Objeto: Identificador único

– Campo clave: Número

– Nombre: Designación semántica única

– Componentes: Estructura interna diferenciada para los objetos de relación“es parte de”

– Subtipos: Especialización de un objeto “es un”

– Atributo: Fecha de entrada, aprobado por, ingresado por, etc.

– Métodos: Implementación de los métodos aplicable al objeto

– Eventos: Eventos que generan al objeto

17


• Object-Type (Tipo de Objeto): Propiedades

– En la metodología de desarrollo orientada a objetos las clases tienen determinadas propiedades de las cuales enumeramos:

• Encapsulamiento de datos: consiste en abstraer los datos al modelador del workflow (que puede no ser un programador). Quiere decir que el que este diseñando el workflow no tiene por que saber que tablas, programas, transacciones, etc. están detrás de la ejecución del workflow.

• Herencia: esto significa que los elementos clave, los atributos, métodos y eventos de un tipo de objeto se pasaran a los subtipos que definamos para que de esta manera podamos “extender” la definicion del objeto. Esta propiedad esta orientada a la “reusabilidad” del codigo.

• Polimorfismo: dependiendo del tipo de objeto, el “object manager” siempre selecciona la implementacion de los atributos o metodos que correspondan. Estos elementos siempre se desarrollan utilizando el principio de “late binding”.

– La definición de los tipos de objetos se hace a través del Business Object Builder (BOB).

18


• Business Object Repository (BOR)– El BOR es un entorno de desarrollo y ejecución completo, que permite manejar los

siguientes tipos de objetos:• Objetos del negocio: Incluyen objetos como "Cliente", "Material", y "Código de Compañía".

Proveen tanto una visión de alto nivel orientada a los negocios como una interface de programación del sistema R/3.

• Objetos técnicos: Incluyen textos, notas, ítems de trabajo y documentos, así como objetos de escritorio como textos, gráficos y hojas de cálculo.

• Metaobjects: Cada objeto tiene un atributo “Tipo de Objeto” que hace referencia al metaobjectsal que está asignado. Los métodos, atributos y eventos disponibles para un objeto en particular pueden ser recuperados desde su “Tipo de Objeto”.

19

Definición e Implementacion de Business Objects

• Instancias (Objectos)– Un tipo de objeto (clases) describe un objeto

de negocio abstracto, los datos que le pertenecen, métodos, etc.

– Los tipos de objetos pueden ser hederados.Los tipos de objetos heredados contienentodos los métodos y campos de datos de losobjetos de los cuales heredan.

– Esto permite el polimorfismo, que combinalos atributos de distintos objetosespecializados. El polimorfismo puede ser utilizado también por interfaces definidas(atributos y métodos) de objetos.

– La herencia múltiple no es actualmentesoportada directamente por los objetos de negocio de SAP. Un objeto puedeimplementar varias interfaces.

– Las instancias de un objeto de negociocontienen datos actuales, por ejemplo, unaorden de cliente. Asi pueden existir muchasinstancias de un tipo de objeto.

20


• Instancias (Objectos)– Para trabajar con un objeto de negocio,

debe primero crearse una instancia del objeto.

– Cuando se crea una instancia, existendos tipos de objetos: persistente y no persistente.

– Los objetos persistentes contienendatos de las bases de datos R/3. Tienen un identificador únicodeterminado por el campo clave.

– Los objetos no persistentes no estánligados a entradas concretas de base de datos. Por ejemplo, son utilizadospara visualizar datos, o para crearnuevos objetos de negociopersistentes.

21


• Interfases: Definición

– La utilización de interfaces en el desarrollo de tipos de objetos nos permitirá asegurar un entorno común para todos los objetos.

– La definición de una interfase es similar a la definición de un tipo de objeto con la diferencia que no se implementaran ninguno de los elementos contenidos en la interfase (es decir que es un molde que no contiene código ABAP)

– Un tipo de objeto que “implemente” una inteface deberá entonces definir (codificar) todos los atributos y metodos que la interface propone.

– Las interfaces se heredan

– Las interfaces en SAP se utilizan para reemplazar la herencia multiple. Esto se da por que es mas sencillo de mantenerlas que un tipo de objeto.

22


• Interfases: Ejemplos

BUS2069 DocumentocontableBUS2029 PreciosEKKO Documento de comprasVBAK Documento de ventasBUS2032 Orden de venta

IFSTATUS Genera eventos para gestion de statusIFARCH21 Interface para archive linkIFIDOCOUT Procesamiento de salida de IDOCs

23


• Tipos de Objetos – Elementos: Campos Clave (Key)

– Un objeto se identifica “univocamente” de otro a través de su clave.

– Una clave puede estar compuesta de uno o mas campos

– Hacen referencia a un campo clave de una tabla de la aplicación subyacente

– El mandante no es necesario en las claves

– Deben ser campos tipo carácter (CHAR).

– Los campos clave concatenados pueden contener un máximo de 70 caracteres.

24


• Tipos de Objetos – Elementos: Atributos

– Un atributo de un objeto representa determinada característica que este objeto puede llegar a tener.

– En SAP los atributos pueden ser de base de datos o virtuales.

– En cuanto a su definición pueden estar relacionados a un tipo de dato de la base de datos o a un tipo de objeto (para asociaciones o composiciones)

– Pueden ser de una línea o varias líneas (single-line o multiple-line)

25


• Tipos de Objetos – Elementos: Atributos Virtuales

– Un atributo virtual es un atributo “calculado”, es decir que se requiere programación para poder obtenerlo (no viene directamente de la base de datos).

– El Business Object Builder no puede generar el código para un atributo virtual automáticamente (como sucede con los atributos de base de datos) por lo que deben ser “explicitamente” codificados.

– Ejemplos donde son necesarios atributos virtuales:• Datos dependientes de lenguaje• Datos dependientes del tiempo• Referencias a objetos• Calculo de valores netos - brutos

– Por razones de rendimiento del sistema deberíamos utilizar atributos virtuales para leer atributos en pasos de fondo (background). Pero esto no es estrictamente obligatorio.

26


• Tipos de Objetos – Elementos: Atributos Multi-lineales (multi-line)

– Se corresponden a lo que en ABAP denominamos “tablas internas”

– Pueden contener campos de base de datos u objetos.

– Generalmente son atributos virtuales.

27


• Tipos de Objetos – Elementos: Métodos (Sincrónicos y Asincrónicos)

– Los métodos son las actividades que podemos llevar a cabo sobre un objeto

– Pueden ser sincrónicos o asincrónicos• En los “Sincrónicos” el resultado es enviado directamente al programa que lo ejecuto. Además

es posible la utilización de excepciones.• En los métodos “Asincrónicos” el resultado siempre es enviado de vuelta al programa llamador

en la forma de un evento. Solo se permiten algunas exceptiones (restringidas). El método en si mismo no espera un posible evento finalizador.

– Ambos tipos de métodos pueden recibir datos a través de parámetros (parámetros de importación)

28


• Tipos de Objetos – Elementos: Métodos Asincrónicos (detalle)

– Notas• Las líneas azules continuas representan el control del flujo• Las líneas azules punteadas representan transferencias de datos • La línea punteada roja representa el tiempo de espera del programa llamador.

– Se necesita una sincronización de los procesos controlada por el programa llamador.– El método debe enviar eventos al programa llamador para que este se sincronice.– Todos los métodos que hacen escrituras en la base de datos a través de tareas de

actualización.

29


• Tipos de Objetos – Elementos: Método (comunicación)

– Comunicación vía parámetros• Import• Export

– Comunicación a través de resultados

– Comunicación vía excepciones• Error temporal• Error de Sistema• Error de Aplicación

– Comunicación vía eventos

• Los métodos sincrónicos se comunican mediante parámetros, resultados y excepciones.

• Los métodos asincrónicos se comunican mediante parámetros y luego mediante un evento.

30


• Tipos de Objetos – Elementos: Método (comunicación)

– Los parámetros de tipo export deberían prohibirse. Lo mejor es comunicarse a través de resultados.

– Si durante la ejecución del método el objeto al que se esta haciendo referencia cambia en la base de datos, este objeto debe refrescarse (una manera de comunicar el resultado) para ello existe la macro SWC_REFRESH_OBJECT.

– El tipo de excepción que se envíe al sistema de workflow determinara la manera en que se continúe o no la ejecución del workflow (dejando el workitem en estado erróneo o en proceso)

– Los resultados por excepciones se programan mediante la macro EXIT_RETURN. Otras macros utilizadas para crear excepciones son EXIT_OBJECT_NOT_FOUND y EXIT_CANCELLED. Esta última se utiliza cuando el usuario cancela la ejecución de un método (generando un error temporal).

31


• Tipos de Objetos – Elementos: Eventos

– Un evento se utiliza principalmente para indicar que algo a sucedido. Estos son indispensables para iniciar o terminar workflows.

– La definición del evento se hace en el Business Object Builder, pero su implementación se hace con otras herramientas, por ello la documentación de los eventos es “indispensable”.

– Los eventos llevan y traen parámetros. Los parámetros pueden ser definidos por el usuario (explícitamente) o standards los cuales no se definen (objeto lanzador, usuario que lanza el objeto, fecha, hora, etc.).

32


• Estado de un Tipo de Objeto

– Modelado• En este estado el tipo de objeto no se puede “instanciar”. Es decir no se puden generar

objetos para este tipo.

– Implementado• Solo para pruebas, uso interno o posiblemente inestable

– Liberado• Liberado para ser utilizado por el cliente. Solo se podrán realizar ampliaciones pero no

modificar radicalmente el tipo.

– Obsoleto• El tipo de objeto ha sido reemplazado por otro.

33


• Desarrollo de un Tipo de Objeto: Datos Generales– Nombre del objeto

• Debe ser un nombre descriptivo para todos los objetos de este tipo. Cuando utilicemos un objeto como elemento del contenedor de workflow este será el nombre que nos aparecerápara definir la variable del contenedor.

– Método por defecto• Este método es el que se utiliza para visualizar el objeto (por ejemplo cuando tenemos el

objeto como un link en el workplace del workitem y al hacer doble click nos muestra el contenido de ese objeto o nos lleva a la pantalla para visualizar el objeto)

– Atributo por defecto• Es un atributo identificativo del objeto instanciado. Se utiliza para cuando se quieren emitir

listados de objetos para que aparezca ese dato por defecto.

34


• Desarrollo de un Tipo de Objeto: Campos Clave

– Cada tipo de objeto tiene un programa que lo implementa.

– El desarrollo de un tipo de objetos se basa en MACROS que se encuentran en el include <OBJECT>, por eso todos los programas que implementan un tipo de objeto empiezan con la sentencia “include <object>.”

– El Business Object Builder siempre utiliza referencias a objetos para trabajar. Estas referencias las utiliza para leer y manipular los datos de la aplicación. En el programa del tipo de objeto podemos crear una referencia a un objeto con la macro SWC_CREATE_OBJECT.

– El programa del tipo de objeto puede utilizar una referencia del objeto que e esta ejecutando, es decir una referencia a si mismo. Esta variable se llama SELF.

– Las claves se definen con el Business Object Builder y el programa se genera automáticamente (no es necesario programar la definición de las claves).

35


• Desarrollo de un Tipo de Objeto: Campos Clave

– Para crear una clave debemos indicar el nombre (en ingles) una descripción (en cualquier idioma), y una referencia a un tipo de dato de una tabla de la aplicación.

– Luego en el programa del tipo de objeto vemos que la clave se define entre las sentencias BEGIN OF KEY y END OF KEY.

36


• Desarrollo de un Tipo de Objeto: Atributos de Base de Datos

- Cuando creamos un atributo de base de datos el sistema automáticamente nos propondrá un código básico que podremos terminar para que funcione.

- Para crear el atributo le damos un nombre (en ingles), una descripción (en cualquier idioma), marcamos el atributo como base de datos y le damos una referencia a una tabla y un campo de la tabla.

- Si colocamos como referencia un objeto deberemos tener en cuenta que el objeto tenga como clave un solo campo (que este definido en la tabla que en los campos tabla y campo indiquemos.

37


• Desarrollo de un Tipo de Objeto: Atributos de Base de Datos

– Al crear el atributo el sistema nos propone definir automáticamente el programa.

– Luego este programa podrá ser reutilizado para todos los atributos que apunten a la misma tabla.

– El atributo estará definido por las sentencias GET_TABLE_PROPERTY y END_PROPERTY.

– De no encontrar nada el sistema utiliza la excepción EXIT_OBJECT_NOT_FOUND.

38


• Desarrollo de un Tipo de Objeto: Atributos Virtuales

- Al crear el atributo virtual el sistema no generara el código automáticamente pero si nos presentara donde debemos colocar el programa (entre las clausulasGET_PROPERTY y END_PROPERTY.

- El atributo se crea mediante el programa (como una variable) y luego se coloca como resultado en el container del objeto mediante la macro SWC_SET_ELEMENT.

- En el caso de que el atributo virtual sea un objeto deberemos instanciar un objeto (conociendo como completar la clave) mediante la macro SWC_CREATE_OBJECT.

39


• Desarrollo de un Tipo de Objeto: Atributos de Múltiples Líneas

- Al crear el atributo de múltiples líneas el sistema tampoco generara el código automáticamente pero si nos presentara donde debemos colocar el programa.

- En el caso de los atributos múltiples se trabaja al atributo como una tabla interna.

-El atributo se colocará en el contenedor con la macro SWC_SET_TABLE.

40


• Desarrollo de un Tipo de Objeto: Métodos Sincrónicos

- Para crear un método sincrónico debemos marcarlo como tal en la pantalla de atributos del método.

- En el programa del tipo de objeto la definición del método se encuadra dentro de las sentencias BEGIN_METHOD y END_METHOD.

- En el caso que el método modifique algún atributo del objeto deberemos ejecutar la macro SWC_REFRESH_OBJECT para borrar el buffer del objeto.

- En el ejemplo se muestra como llamar a una transacción con un método.

41


• Desarrollo de un Tipo de Objeto: Métodos Asincrónicos

- En el caso de los métodos asincrónicos no será necesario llamar la macro SWC_REFRESH_OBJECT por que el contexto del objeto siempre se pierde al llamar el método.

- La ejecución del evento terminador debe darse en la transacción o el programa que ejecuta el método.

- La tarea de workflow que llame a un objeto asincrónico SIEMPRE esperará el evento terminador. Por este motivo debemos tener cuidado que el programa / transacción / modulo de funcione / etc que ejecute el método siempre lance un evento.

42


• Desarrollo de un Tipo de Objeto: Implementando excepciones en los métodos

- Las excepciones se definen para cada método. El sistema no generará ningún tipo de código para la excepción.- La excepción se debe corresponder a un mensaje tipo T100 (con 4 parámetros).- Para llamar la excepción se usa la macro EXIT_RETURN.

43


• Desarrollo de un Tipo de Objeto: Completando parámetros de los métodos

- Para cada método puede o no definirse uno o mas parámetros de entrada y salida.- Para leer elementos del container se utilizan las macros SWC_GET_ELEMENT (para elementos de una línea) o SWC_GET_TABLE (para los multilínea). A su vez la macro SET PARAMETER ID la utilizaremos para copiar los datos extraídos al parámetro deseado.

44


• Desarrollo de un Tipo de Objeto: Completando resultados de los métodos

- Los parámetros de resultado se completan con la macro SWC_SET_ELEMENTy el elemento siempre se llama “RESULT”. El elemento RESULT esta dentro del include OBJECTS por lo que no es necesario definirlo explicitament.

45


• Utilizando un Objeto en un programa: Accediendo a los Atributos

- Para utilizar un Business Object en un programa es necesario incluir el include<CNTN1>. Este include es utilizado en el include <OBJECT> por lo que no se incluye en el programa del tipo de objeto.

- Antes de acceder a un atributo debemos crear una instancia de un tipo de objeto. Para ello usamos la macro SWC_CREATE_OBJECT.

- Una vez creado el objeto podremos acceder a sus atributos con las macros SWC_GET_PROPERTY o SWC_GET_TABLE_PROPERTY (para atributos multi-linea)

- Los atributos no pueden modificarse por macros. Solo podrán modificarse llamando a métodos que implementen el cambio.

46


• Utilizando un Objeto en un programa: Accediendo a los Métodos

- Para utilizar un Business Object en un programa es necesario incluir el include<CNTN1>. Este include es utilizado en el include <OBJECT> por lo que no se incluye en el programa del tipo de objeto.

- Antes de acceder a un método debemos crear una instancia de un tipo de objeto. Para ello usamos la macro SWC_CREATE_OBJECT.

- Antes de llamar el método debemos completar los parámetros de entrada (import)

-Se llama al método con la macro SWC_CALL_METHOD.

- Finalmente se consultan los resultados o los parámetros de salida (export).

47


• Resumen de MACROS

– Todas las macros para manipular objetos se encuentran en el programa include<CNTN01>.

– Todos los objetos pueden manipularse fuera del sistema workflow via macros.

• Referencia a un Objeto– Declaración

• DATA: <OBJ_REF> TYPE SWC_OBJECT

– Creación• SWC_CREATE_OBJECT <OBJ_REF> <OBJ_TYPE> <OBJ_CLAVE>

• Acceso a Atributos– SWC_GET_[TABLE]_PROPERTY <OBJ_REF> <ATRIBUTO> <VALOR>

• Acceso a un Metodo– SWC_CALL_METHOD <OBJ_REF> <METODO> <CONTAINER CON VARIABLES>

48


• Resumen de MACROS

• Disparando Excepciones– EXIT_RETURN <NRO_EXCEPCION> <VAR1> ….. <VAR4>

– EXIT_OBJECT_NOT_FOUND

– EXIT_CANCELLED

• Tomar el tipo y la clave de un objeto– SWC_GET_OBJECT_TYPE <OBJ_REF> <OBJ_TYPE>

– SWC_GET_OBJECT_KEY <OBJ_REF> <OBJ_KEY>

• Refrescar el objeto– SWC_REFRESH_OBJECT <OBJ_REF>

49


• Resumen de MACROS – macros para manejar el contenedor de datos

• Definición e Inicialización– SWC_CONTAINER <variable>

– SWC_CREATE_CONTAINER <variable>

• Leer y Escribir en el contenedor– SWC_GET/SET_ELEMENT <contenedor> <elemento> <valor>

– SWC_GET/SET_TABLE <contenedor> <elemento> <tabla interna>

50


• Delegación

– Problema• Como podemos crear nuestras propias extensiones de objetos para poder usar en tareas,

eventos, etc. De un objeto creado por SAP sin tener que cambiar TODAS las tareas, eventos, etc.?

– Solución• Definir un Sub-Tipo (herencia) y delegarlo en el supertipo• La delegación hace que el sub-tipo “cubra” al supertipo• De esta manera podemos seguir haciendo referencia al supertipo en las tareas, eventos, etc.

– Si creamos un sub-tipo y no lo delegamos entonces los programas, tareas, eventos, etc que usen al supertipo no se enterarán de las extensiones que hagamos en el sub-tipo.

51


• Delegación

52


• Es posible utilizar la DELEGACIÓN pararealzar la funcionalidad de los tipos de ojetos SAP.

• Los subtipos ofrecen la oportunidad de – Atributos adicionales– Métodos adicionales– Eventos adicionales

• Cada tipo de objeto y todos loscomponentes tiene asignado uno de los cuatro estados posibles:

– Modelado: no existe programa paraasignado aún.

– Implementado: el programa ha iniciadopero no finalizado oficialmente.

– Liberado: el programa puede ser ejecutado por todos

– Obsoleto: no utilizar más.

53


• Tipos de Objetos Específicos– SELFITEM provee la funcionalidad para enviar un correo desde el workflow.

– SOFM para implementar objetos SAPOffice

– STD_TEXT puede ser utilizado para integrar texto SAP en un correoenviado en un workflow.

– Use el tipo de objeto TSTC para ejecutar una transaccón en un paso de workflow.

– Use el tipo de objeto TRDIR para ejecutar un reporte o programa en un paso workflow.

November 25, 2008

SAP Business WorkflowWorkflow Builder

2

Contenidos

• Introducción al Workflow Builder

• Definición de Pasos

• Definición de Tareas

• Grupo de Tareas

• Contenedores

• Temas Adicionales– Transacciones de Inicio

– Traducciones

• Ejemplo de definición de un workflow con el Workflow Builder

3

Introducción al Workflow Builder

• El Workflow Builder es la herramienta utilizada para crear y editar la definición de un workflow

• El Workflow Builder permite definir entre otras cosas:– Pasos– Disparadores de eventos– La interface de datos (definida en el container del workflow)

4


• El objetivo del Workflow Builder es la definición del workflow

5


• Acceso al Workflow Builder– Transacción SWDD

• Características del Workflow Builder– Área de navegación y visualización– Modelo orientado a bloques– La modelización top-down es posible– Funciones especiales como cortar,

pegar, mover, copiar– Imprimir– Verificación y activación– Funcionalidad drag and drop– Los pasos y eventos se muestran

gráficamente en una red– Cada definición de workflows tiene

asignado un usuario responsable de su administración

6


• Area de objetos• Permite visualizar cada uno de los pasos, con su número de nodo y

descripción.

• Es también utilizada para la administración del contenedor de workflow. Usando el menu de contexto, es posible crear, cambiar, visualizar, borrar, renombrar elementos del contenedor.

• Permite el mantenimiento del contenedor de workflow directamente en el Workflow Builder.

• Provee una visión general de plantillas de documentos.

• Aumenta la velocidad en la búsqueda de objetos existentes por el uso del Explorer.

• Area de tareas• Es posible utilizar tareas ya existentes en la definición de un workflow,

solo es necesario encontrarlas.

• Permite visualizar todas las tareas y otros workflows relevantes.

7


Navegación gráfica

Caja de herramientas

Navegación y mantenimiento de

datos

Caja de herramientas de

tareas disponiblesRepresentación

gráfica de la definición del

workflow

Colector de mensajes con capacidad de navegación

8

Contenidos




• Grupo de Tareas

• Contenedores


– Traducciones


9

Definición de Pasos

• La definición de un workflow está compuesta por pasosindividuales.

• Al crear un paso, primero se debe especificar el tipo de paso. Estospueden ser:– pasos que hacen referencia a las actividades de negocio: actividad,

desición de usuario, documento desde plantilla.

– pasos que son usados para el monitoreo y control de procesosinternos: condición, condición múltiple, loop, bucle, operación de contenedor, evento creador, espera de evento.

• Cada paso es el elemento determinante de “su” bloque. Las operaciones en pasos individuales siempre conciernen a la totalidad del bloque al que pertenece.

• La secuencia de procesamiento de los pasos depende del resultado del paso precedente.

10


• Un paso indica una actividad especifica dentro de la definición del workflow, es decir que es un “paso” del proceso.

Definición en el constructor

Paso

Actividad de negocioActividad (referencia de tarea)

Decisión de usuario

Documento desde plantilla

Control de procesos internos

Condición múltiple

Espera de evento

Condición

Creador de evento

Contenedor de operación

Loop (UNTIL)

Loop (WHILE)

Bucle

Visualización del pasoPasos en proceso paralelo

Monitoreo del plazo de los pasos

Asignar y nombrar sucesores para cada paso

Operaciones en modo de bloqueo

11


Permite ejecutar dos o mas workitems en paralelo. El workflow continuará cuando se cumplan ciertas condiciones.

Procesamiento Paralelo

Permite crear un evento. El contenedor del evento se llena con datos del contenedor del workflow

Creador de Evento

Permite crear un documento local a partir de una plantilla y variables definidas en el contenedor del workflow

Documento con Modelo

Este paso se utiliza para modificar los valores de una variable en el contenedor del workflow.

Operación en el Contenedor

Basado en una variable del contenedor del workflow se pueden generar diversos caminos a seguir.

Condición Múltiple

Dependiendo del resultado de una condición (verdadero o falso) un camino u otro es seguido por el workflow.

Condición

Ejecución de una tarea en un workflow.Actividad

DescripciónSímboloTipo de Paso

12


Este paso se utiliza durante el desarrollo para dejar espacios a completar.

Indeterminado

Permite enviar elementos del contenedor del workflow a través de mensajes XML o SOAP (pe. contra XI o BC)

Actividad WEB

El workflow se detendrá en este paso hasta que no se lance el evento especificado.

Esperar Evento

Se indica un destinatario y un texto para el envío de un correo electrónico.

Enviar Correo

Se repiten una serie de pasos mientras se cumpla una determinada condición (puede no llegar a ejecutarse )

Loop (Mientras)

Se repiten una serie de pasos hasta que se cumpla una determinada condición (al menos 1 vez se ejecutan)

Loop (Hasta)

Se le envía un workitem al usuario con una serie de preguntas para responder. Cada respuesta genera una nueva línea de procesamiento en el workflow.

Decisión de Usuario

DescripciónSímboloTipo de Paso

13


• Creando un paso– Ingresar al Workflow Builder (SWDD)

– Abrir el workflow con el que se quiere trabajar (o crear uno nuevo)

– Hacer doble – click sobre un paso indeterminado (en la posicion del workflow que corresponda.

14


• Creando un paso– Seleccionar el tipo de paso (en el ejemplo seleccionamos una actividad)

15


• Creando un paso– Aparecerá la pantalla para definir la actividad

– Una actividad hace referencia a una tarea, la cual hace referencia a un método de un Business Object. Por lo tanto todas las características del método del Business Object pasaran a la tarea y luego al paso.

16


• Creando un paso– En el caso de las actividades deberemos ingresar el código de la tarea

– Automáticamente el sistema generará o propondrá los bindings entre el container del workflow y el container de la tarea (no obstante siempre conviene revisar lo que el sistema propone)

Propone la creación de nuevasvariables en el container del workflow

Propone el paso de datos entre el contenedor del workflow al de la tarea

Propone el paso de datos entre el contenedor de la tarea al del workflow

17


• Creando un paso– Una vez asignada la tarea y el binding, los atributos de la tarea pasan al

paso (características de la tarea y características del paso)

– El atributo “paso no en log workflow” hará que cuando se ejecute el workflow los datos de el paso no pasen al log (pero si quedará en el log técnico).

– El campo “tratamiento rechazable” permitirá al responsable rechazar la tarea. Si no esta marcado el responsable debera tratarla obligatoriamente.

– El atributo “avanzar con dialogo” permitirá crear una cadena de diálogos que se cortará cuando cambie el responsable. Es decir que si un usuario es el mismo responsable de tres tareas consecutivas, estas irán apareciéndole al usuario automáticamente a medida que las va ejecutando.

18


• Creando un paso– Luego configuraremos las salidas del paso.

– En el caso que el método que ejecutemos genere distintos resultados estos aparecerán en el cuadro de salidas y podremos colocar un texto para que queden documentados en el workflow.

– Cuantas mas salidas tenga el paso mas líneas de workflow se abrirán.

19


• Creando un paso– También el paso puede configurarse para que cuando se termine de ejecutar

el paso envíe una notificación a alguien en forma de correo electrónico. Esto se configura en el área “notificación”

20


• Creando un paso– Luego y en el caso que corresponda podremos configurar los tiempos del

paso. Es decir que al crearse un workitem los tiempos de ejecución de ese workitem podrán controlarse y tomar determinadas acciones.

– Primero podremos configurar un plazo. Es decir que si se cumple un plazo determinado desde que el usuario responsable recibe el workitem y no toma ninguna acción, se podrá tomar una decisión automáticamente.

• El plazo se configura teniendo en cuenta: la fecha de creación del workflow, la fecha de creación del workitem o una fecha que se agregue como una variable en el contenedor del workflow.

• Luego se coloca el tiempo a alcanzar (el plazo)• Y Finalmente se define que acción tomar. O bien se envía un correo electrónico a

alguien (por ejemplo un superior del responsable) o bien se puede “modelar” un subworkflow para actuar en caso de llegar al plazo.

21


• Creando un paso

22


• Creando un paso– Luego se podrá configurar una fecha de inicio mas tardío y una fecha de fin

deseado.

– La configuración de estas fechas se realiza de la misma manera que con el plazo.

23


• Creando un paso– En la parte de métodos podremos configurarle al paso una determinada

cantidad de programas que se ejecutaran antes o después de ejecutarse el paso (complementariamente a los programas que se ejecuten con el método asociado a la tarea)

24


• Creando un paso– Finalmente podremos dar alguno retoques finales indicando otras

características como ser:• La prioridad del paso (este valor hará que se envíen notificaciones visuales al

usuario al recibir el workitem).• Características de ejecución de tareas de fondo

25


• Creando un paso– RESULTADO!!!

26


• Creando otros pasos– Como hemos visto estos son los pasos para crear un paso de tipo

“activididad”. Luego cada paso tendrá sus propias caracteristicas y formas propias de configuración.

27

Contenidos




• Grupo de Tareas

• Contenedores


– Traducciones


28

Definición de Tareas

• Las tareas son el elemento central en el sistema de workflow, y son utilizadas para describir un proceso de negocio

• Las tareas son designadas como módulos reusables e independientes.• Las plantillas de workflows (Workflow templates - WS) y las tareas

estándard (Standard tasks - TS) son independientes del cliente y no disponen de período de validación

• Es posible encontrar en un sistema tareas de workflow (WF) y tareas de Cliente (T), que son específicas del cliente y disponen de período de validación

• Desde la versión 4.5A, solo deberían crearse tareas standard (TS) y plantillas de workflow (WS)

29


• Tipos de Tareas– De un solo paso (single-step)

– Plantilla Workflow (multi-step)

• Ejemplos de un solo paso– Emitir una factura

– Liberar una solicitud de pedido

• Las plantillas workflow se utilizan principalmente para modularizar un workflow mayor, facilitando su mantenimiento.

• Para cada tarea de un solo paso deberemos asegurarnos 3 cosas:– ¿Qué trabajo debe realizarse?

– ¿Quién llevará a cabo el trabajo?

– ¿Qué notificaciones deben realizarse?

30


• Los pasos para crear una tarea son

– Asignar un nombre y descripción a la tarea

– Asociar un método de un business object a la tarea

– Asociar los agentes posibles de la tarea• Puede asociarse uno o mas elementos de la estructura organizativa• Puede definirse como tarea general (todos pueden ejecutarla)

– Definir el texto de la tarea para comunicaciones• Puede crearse el texto en varios idiomas• Pueden utilizarse variables contenidas en el contenedor de la tarea

– Marcar el atributo de “confirmar fin de procesamiento” para las tareas de dialogo, lo que permitira al usuario agregar información a la tarea una vez que se haya realizado el trabajo.

31


• Tareas de Diálogo– El texto de la tarea servirá para informar de las actividades al usuario

– Debe estar asociada a un método marcado como de “dialogo”

– Si o si debe tener asignados los posibles agentes• Marcada como tarea general (todos los usuarios son posibles agentes)• Seleccionando elementos de la estructura organizativa

32


• Atributos de la tarea– Método con dialogo

– Método sincrónico

– Ejecución en fondo

– Confirmar fin procesamiento

– Ejecución como formulario

• Se puede definir la tarea para trabajar con Formularios, Internet y SAPPhone

– Por ejemplo una tarea que se iniciara cuando un cliente llame a una central telefónica y el sistema telefónico solicite el numero al cliente se iniciara un workflow de conversación.

33


• Textos en los Workitems– Se debe definir el título del workitem (el subject del correo)

– Se debe definir el cuerpo de workitem

– Se pueden utilizar variables contenidas en el contenedor de la tarea

– También se pueden colocar gráficos e íconos

34


• Eventos Terminadores– Las tareas basadas en métodos sincrónicos pueden ser definidas con un evento

terminador (o mas).

– Las tareas basadas en métodos asincrónicos deben tener al menos un evento terminador

– Los eventos se toman de los business objects definidos en el sistema (generalmente el mismo business object que provee el método de la tarea)

35


• Para definir un evento terminador se indica– El Business Object que contiene el evento

– El Evento

– El elemento del contenedor de la tarea que contiene la referencia al businessobject que se tiene que utilizar. El objeto solo puede conocerse en tiempo de ejecución.

36


• La comunicación entre las tareas y los métodos es– Bidireccional

– Se pasan parámetros

– Resultados

– Excepciones

37


• Ejemplo de una tarea sincrónica (proyecto PPP)

38


• Ejemplo de una tarea asincrónica (proyecto PPP)

39


• Insertar una tarea en el Workflow– Un paso en un workflow puede hacer

referencia a una actividad– Una actividad apunta a una tarea, si

se trata de un triángulo simple– Una actividad apunta a un workflow,

si tiene tres triángulos (el workflow referenciado se llama subworkflow)

– El binding definirá el flujo de datosentre los distintos contenedores en un workflow.

– Las responsabilidades determinaránlos recipientes para este paso. Esosrecipientes recibirán el ítem de trabajoen su área de trabajo.

– El agente de notificación recibirá un mensaje de correo de SAP una vezque el paso esté finalizado.

40


• ¿Qué atributos de las tareas y los pasos afectan la ejecución de un WorkItem?– Ejecución en proceso de fondo

• Esta opción se marca cuando se desea que el sistema de workflow ejecute elsistema sin intermediación de ningún usuario (lo ejecutará el usuario de workflow WF-BATCH)

– Confirmar fin de procesamiento• Esta opción se marca cuando se desea que el usuario confirme cuando el

workitem estará completo. Mientras que no sea confirmado el workitem permanecerá activo en el inbox del agente responsable.

– Tratamiento rechazable• Al marcar esta opción se le da al usuario la posibilidad de rechazar el workitem.

Cuando se marca la opción aparece una nueva salida (un nuevo camino a seguir) en el workflow

– Paso no en log workflow• Al marcar esta opción el workitem no aparecerá en los logs del workflow (si

aparecerá en el log técnico.

41


• ¿Qué atributos de las tareas y los pasos afectan la ejecución de un WorkItem?– Avanzar con dialogo

• Esta propiedad permitirá al agente responsable del workitem ir ejecutando workitems del workflow uno detrás de otro (en cadena) siempre y cuando el mismo agente sea responsable de todos los pasos que estén encadenados.

42

Contenidos




• Grupo de Tareas

• Contenedores


– Traducciones


43

Grupo de Tareas

44

Grupo de Tareas

• Los grupos de tareas son definidos para ligar lógicamente tareasconectadas.

• Es posible, por ejemplo:– Disponer juntos en un mismo grupo de tareas, plantillas de workflows

que sólo se comunican entre sí a traves de eventos, para lograr unamejor visión global.

– Reunir tareas (plantillas de workflow y tareas estándar) quepertenecen a un área de trabajo, para incrementar la reusabilidad.

• Los grupos de tareas son útiles también en la definición del rangode búsqueda del Business Workflow Explorer. El Business Workflow Explorer puede entonces visualizar las tareas de esosgrupos de tareas.

• Solo pueden asignarse a grupos de tareas los tipos de tareas WS y TS (plantillas workflow y tarea standard)

45

Grupo de Tareas

• Herencia– Se podrá asignar un grupo de tareas a otro grupo de tareas generando una herencia.

– Las tareas hijas heredarán las asignaciones de responsables de las tareas padre

– Tener cuidado en las jerarquías amplias dado que pueden darse asignaciones de responsables no deseadas.

46

Contenidos




• Grupo de Tareas

• Contenedores


– Traducciones


47

Contenedores

• Los contenedores son grupos de variables que se utilizan como interfases para llevar los datos de un lado a otro del workflow.

• Un elemento del contenedor tiene estructura de datos de tablasutilizada por los componentes definidos en el workflow. A su vezpuede ser definido con una estructura de Business Object.

48

Contenedores

• Los contenedores son– El contenedor de eventos: Contiene un elemento que puede obtener una

referencia al objeto(s) a ser procesados en el workflow. Siempre contieneun elemento que pueda obtener el nombre de usuario “iniciador” del workflow actual (_WF_Initiator)

– El contenedor de workflow: Puede tomar al iniciador del workflow desdeel contenedor de eventos (_WF_Initiator).

– El contenedor de tareas: Siempre contiene un elemento que puedeobtener la referencia al objeto a ser procesado en la tarea de un solo pasorespectiva (_WI_Object_ID). También puede contener un elemento quepueda obtener el resultado de un método de un objeto subyacente(_WI_Result).

– El contenedor de métodos– El contenedor de roles (papeles)

49

Contenedores

50

Contenedores

• Ejemplo

51

Contenedores

• Ejemplo– 1. El usuario “USUARIO1” cambia la descripcion del material 1000 de “my_part” a

“new_part”– 2. El cambio provoca la ejecución de un documento de cambio (change document) el

cual generará un evento (material-modificado).– 3. El evento instancia el business object ZBUS001 (Material) con el material 1000 y

sus datos cambiados y además recopila el nombre del usuario que cambio el material “USUARIO1”.

– 4. El evento esta relacionado a un workflow el cual necesita del usuario y el objeto material para realizar sus tareas, estos datos se pasan del contenedor del evento al contenedor del workflow.

– 5. Luego el workflow ejecutara una tarea que tiene asociado un método que necesita el material para poder ejecutarse, entonces el workflow pasa de su contenedor al contenedor de la tarea el objeto respectivo.

– 6. Para determinar el usuario destinatario de la tarea se ejecutará un rol que necesita el nombre del usuario que inicio el workflow para poder determinar destinatarios, por ello se pasara del contenedor del workflow al contenedor del rol el iniciador del workflow.

52

Contenedores

• El contenedor de eventos siempre contiene un elemento quepuede obtener la referencia al objeto cuyo cambio de estatus esanunciado a traves del evento ‘_EVT_Object'. Siempre contiene un elemento que conoce el nombre del usuario responsable del cambio de estado del objeto‘_EVT_Creator'.

• El contenedor de workflow siempre contiene un elemento quepueda almacenar el nombre de usuario del “iniciador” del workflow actual ‘_WF_Initiator'. Para mas workflows usted debecrear nuevos elementos en el contenedor de workflow. Para haceresto usted puede, o bien seguir las propuestas de SAP o crear lassuyas propias.

53

Contenedores

• El contenedor de tareas siempre contiene un elemento que puedacontener la referencia al objeto a ser procesado en la tarea de un solo paso respectiva ‘_WI_Object_ID'. Además contiene el elemento ‘_WI_Actual_Agent‘. Para tareas sincrónicas con un parámetro de resultado definido, existe el elemento ‘_WI_Result' element, que puede almacenar el resultado de los métodos de objetos subyacentes.

• El contenedor de roles contiene los elementos requeridos comoentrada en la conexión con la resolución de rol a ejecutar.

• El contenedor de métodos contiene elementos que son parámetros importados y exportados en la conexión con la ejecución del método.

54

Contenedores

• La estructura de datos utilizada en loscontenedores puede ser tablas de la base de datos y referencias a objetos.

• Para definir un elemento de un contenedor se debe introducir:

– Descripción del elemento a ser almacenados en el contenedorutilizandonombre de elemento, descripción (corta y larga)

– Referencia al tipo de dato o tipo de objeto

– Características del elemento (de importación, de exportación, múltiple o simple y si es obligatorio).

55

Contenedores

• Definición del contenedores (Eventos)– El contenedor de eventos se define en el momento de crear el evento en el

Business Object utilizando el Business Object Builder (SWO1)

56

Contenedores

• Definición del contenedores (Workflow)– El contenedor de workflow se define al crear el workflow utilizando el

Workflow Builder (SWDD)

57

Contenedores

• Definición del contenedores (Tareas)– El contenedor de la tarea se define al crear o modificar la tarea con la

transacción PFTC_CHG.

58

Contenedores

• Definición del contenedores (Papeles)– El contenedor de los papeles se define al crear o modificar el papel con la

transacción PFAC_CHG.

59

Contenedores

• Posibilidades de intercambio de datos entre contenedores (Bindings)

60

Contenedores

• Ejemplos de Bindings (Evento-WF)– Entrar en el Workflow Builder (SWDD)

y visualizar el workflow WS90000001

– Verificar que el contenedor del workflow tiene una variable obligatoria llamada “PurchasingDoc”

– Ir a la cabecera del workflow y verificar el binding entre el contenedor de eventos y el contenedor del workflow

– Observar como pasan los datos de un contenedor a otro

61

Contenedores

• Ejemplos de Bindings (WF-Tarea)– Hacer doble click sobre la tarea

“Tomar cabecera del documento de compras”

– Presionar el botón para ver los bindings entre el contenedor del workflow y el contenedor de la tarea

– Observar como pasan los datos de un contenedor a otro

62

Contenedores

• Ejemplos de Bindings (Tarea-Metodo)– De la misma manera que hemos visto

el paso de datos entre el evento y el workflow y entre el workflow y la tarea podremos ver como se pasa entre la tarea y el evento.

– Para ello pasamos a la definición de la tarea dando doble-click sobre el nro. de la tarea que estamos visualizando (TS90000003).

– Presionamos el botón para ver los bindings con el método que se este ejecutando en la tarea

– Podremos ver los bindings definidos

63

Contenedores

• Ejemplos de Bindings (WF-Papeles)– Si una tarea en el workflow requiere

de la ejecución de un papel para determinar el responsable final de la tarea y este papel requiere de variables de entrada para ejecutarse, entonces estas variables deben pasarse desde el contenedor del workflow al del papel (rol).

– Para ello dentro de la tarea pasamos a “Event. Defecto” y veremos todos los papeles necesarios para determinar responsales.

– Marcamos el papel que deseemos y presionamos el botón de bindings para ver los bindings.

– Para ver un ejemplo con datos ver la tarea TS20000159.

64

Contenedores

• Contenedor del Workflow– El contenedor de workflow es el punto central para todos los datos dentro del

workflow. Si los datos no están en el contenedor, entonces el workflow no losconoce.

• Existen distintos caminos para obtener datos en el contenedor de workflow– Desde los elementos del contenedor de un evento disparador.

– Desde un paso de operación de contenedor.

– Desde los parámetros exportados o resultados de una tarea.

65

Contenidos




• Grupo de Tareas

• Contenedores


– Traducciones


66

Transacciones de Inicio

• Los workflows generalmente se inician a partir de un evento (generado por otro programa, un change document, a través del sistema de status, etc.), también es común que un workflow inicie a otro workflow.

• No obstante en algunas ocasiones es necesario iniciar un workflow manualmente.

• ¿Quiénes necesitan una transacción de Inicio?– Usuarios que inician workflows directamente a través del menú

“Office�Iniciar Workflow”

– Los usuarios que inician workflows a traves de shortcuts en su escritorio

– Los programadores que desean hacer pruebas mientras desarrollan

67


• Para desarrolladores– Durante el desarrollo puede probar el workflow desde el Workflow Builder

presionando el icono

– Luego puede utilizarse la transacción SWUS para iniciar cualquier workflow con datos de pruebas.

68


• Para el resto de los usuarios necesitaremos crear una transacción de inicio de workflow– Primero se debe crear un área de nombres para las transacciones de WF

mediante el customizing de Workflows (SWUT)

– Luego en el Workflow Builder se creará una transacción de inicio a nivel de los datos de cabecera del workflow

• Seleccionar el área de nombres• Seleccionar un numero de pantalla (por ejemplo 100)• Presionar el botón crear para generar la transacción de inicio

– Finalmente se podrá personalizar la transacción de inicio para cubrir las necesidades de los usuarios.

69

Traducciones

• Todos los elementos de un workflow podrán traducirse a diferentes lenguajes.

• En el Workflow Builder mediante la opción de menú “Detalles � Traducción �Traducción” podremos generar los textos que deseemos en diferentes idiomas.

• A su vez los textos de las tareas podrán también traducirse modificando las tareas (entrando al sistema en el lenguaje que se desee traducir).

70

Contenidos




• Grupo de Tareas

• Contenedores


– Traducciones


71

Ejemplo de Definición de un Workflow

• Detalle de Escenario– En el sistema trabajamos con notificaciones de mantenimiento las cuales

generan documentos de medición.

– Estos documentos de medición a su vez generaran ordenes de mantenimiento preventivo.

– Cuando una orden de mantenimiento preventivo se libera deberemos enviar una notificación al responsable.

– Pre-requisitos: evaluar el Business Object de orden de mantenimiento y modificarlo en el caso que sea necesario para adaptarlo al escenario.

November 25, 2008

SAP Business WorkflowAgentes y Estructura

Organizativa

2

Objetivos del Curso


� Enviar los work items a los agentes correspondientes es la mitad de la historia. Tener una estrategia para mantener la asignación trabajando mas alla de los cambios organizacionales y las fluctuaciones de personal es la otra mitad.

� En esta parte del curso nos enfocaremos a lograr que ambas partes se logren con éxito.

3

Contenidos

• Conociendo la asignación de agentes– Agentes Posibles– Agentes Responsables– Agentes Excluidos– Receptores– Agente “actual”– Agentes para notificaciones y plazos

• Estructura Organizativa en la asignación de agentes– El plan organizacional básico– Mantenimiento del plan– Asignación y reasignación de usuarios– Transporte del plan

• Trabajando sin la Estructura Organizativa

4

Conociendo la Asignación de Agentes

• Introducción– Cada work item (entendiendo por work item a la instancia en tiempo de

ejecución de un paso del workflow) puede ser procesado por:• El sistema de workflows, utilizando el usuario WF-BATCH• Un agente

– Un agente es la persona que ejecuta el trabajo a realizar en el workflow.

– Los agentes son los encargados de ejecutar tareas que no puedenejecutarse automáticamente.

– Una de las tareas más interesantes y regularmente una de las que mas tiempo insume en el momento de definir un workflow es como el sistema determinara a los agentes correctos para cada work item. Desde la perspectiva de negocio esto no es “trivial”, particularmente cuando es un nuevo proceso que no ha sido llevado a cabo por nadie anteriormente.

5


• Introducción– Antes de empezar debemos saber:

• Como un agente recibe, visualiza y completa un work item.• Las diferentes maneras en que el workflow asigna agentes a un work item.• Como los agentes son identificados en el sistema (a traves de su user ID y objetos

organizacionales).• Las diferentes técnicas que pueden ser usadas para determinar el agente correcto

para un work item.

6


• Asignación de Agentes– El sistema de workflows deberá trabajar con grupos de agentes para poder

determinar los responsables finales de la ejecución de un work item.

– Cuando estamos diseñando, implementando y manteniendo un workflow, debemos entender como el sistema de workflow ve estos grupos de agentes.

– Los grupos de agentes son:• Agentes Posibles

– Son quienes estan permitidos para ejecutar el trabajo

• Agentes Responsables– Son quienes deben realizar el trabajo en un caso determinado

• Agentes Excluidos– Son quienes no deben realizar el trabajo en un caso determinado

– Estos tres grupos pueden solaparse e intersecarse para poder determinar el agente responsable final.

7

Agentes Responsables


• Asignación de Agentes

Agentes Posibles

Agente ExcluidoReceptor

Receptor

8


• Agentes Posibles– Los agentes posibles son aquellos

que tienen permitido ejecutar una determinada tarea.

– Los agentes posibles siempre se asignan en la tarea según la cual se basaran muchos work itemspero no un work item especifico en si mismo.

– Si una persona no esta en el grupo de agentes posiblesentonces nunca podrá ejecutar la tarea.

– Adicionalmente se puede marcar una tarea como general. En este caso todos los usuarios serán posibles agentes de la tarea.

9


• Agentes Responsables– Los agentes responsables son

aquellos que queremos para que ejecuten un work item “en particular”.

– Los agentes responsables son comúnmente asignados al crear un paso en el workflow builder.

– También pueden ser asignados a través de “reglas o papeles” a nivel de la tarea.

– Con las reglas los agentes responsables se asignan dinámicamente en tiempo de ejecución.

– Siempre son agentes posibles

10


• Agentes Excluidos– Los agentes excluidos son

aquellos que NO queremos que ejecuten un work item “en particular”.

– Los agentes excluidos siempre se definen en el workflow builderal crear un paso para una tarea.

11


• Receptores– Los receptores son aquellos que automáticamente reciben un work item en

su inbox cuando el workflow crea el workitem. También son conocidos como agentes “seleccionados”.

– Los receptores son:• Los posibles agentes para una tarea• Restringidos a las lista de agentes responsables para un workitem• No son miembros de la lista de agentes excluidos

– Dado esto podemos notar• Que si no hay agentes posibles NADIE recibirá el workitem• Si no se define un agente responsable en el paso, el sistema buscara la regla por

defecto de la tarea, si no hay regla todos los posibles agentes recibirán el workitem (excluyendo a los agentes excluidos).

12


• Receptores– Un receptor podrá hacer un re-envío de un work item a otro usuario. En este

caso existen varias posibilidades• General Task: los work items podrán ser re enviados a cualquier usuario.• General Forwarding: los work items podrán ser re-enviados a cualquier usuario

(pero existe una lista de agentes posibles)• No General Forwarding: los work items solo podrán ser re-enviados a los agentes

posibles

13


• Agente Actual– Mientras que un work item se este procesando el agente actual es aquel que

este procesando el work item (lo tiene tomado)

– Una vez completado el work item, el agente actual será el que haya procesado el work item en último lugar.

• Asignación múltiple– Puede darse el caso (y es muy común) que se envíe un mismo work item a

varios receptores.

– Cuando uno de los agentes tome el work item este desaparecerá del inbox del resto y en caso que lo vuelva a dejar sin tomar volverá a aparecerle a todos los usuarios nuevamente

14


• Agentes de Notificación y Plazos– Cuando se esta diseñando el

workflow podremos tener en cuenta dos tipos de agentes muy utiles: los agentes de notificaciony los agentes para plazos.

– Agentes para Plazos• Son aquellos que recibirán un work

item que haya vencido, es decir que se le fijo un plazo y el plazo se alcanzó.

– Agentes de Notificación• Son aquellos que recibirán un

correo electrónico informándoles que determinado work item ha sido ejecutado satisfactoriamente.

15

Contenidos




16

Estructura Organizativa en la Asignación de Agentes

• Introducción– Cada agente en el sistema de workflow debe tener un user ID de SAP.

– Cada vez que se este asignando un agente posible, responsable o excluido estaremos asignando de manera implícita un usuario SAP.

– Desafortunadamente mantener usuario por usuario todos los agentes es una tarea excesivamente tediosa. Dado que pueden existir múltiples workflows, múltiples usuarios, etc. A su vez no debemos olvidar que los usuarios son personas y como tal van cambiando de puesto, se van de la empresa, entran nuevos, etc.

– Por este motivo SAP ha diseñado una manera mucho mejor de mantener la asignación de usuarios al workflow y esta manera es a través de un plan organizacional.

17


• El Plan Organizacional Básico– El plan organizacional básico consiste en una serie de relaciones,

representadas como una estructura organizativa jerárquica entre diferentes elementos organizacionales tales como:

• Unidades Organizativas– Cada unidad organizativa representa un grupo de personas como un equipo, un

departamento, una sección, un área de trabajo, un laboratorio, etc.

• Trabajos– Un trabajo describe una rol funcional dentro de la organización.

• Posiciones– Cada posición representa un lugar a ocupar por una persona, es un escritorio físico o una

vacante.

• Usuarios– Es el usuario SAP que se asigna a la posición.

18


• El Plan Organizacional Básico– La mayoría de los objetos organizativos tienen un código, una descripción y

un periodo de validez. Por defecto el periodo de validez se asigna con la fecha del día de la creación del objeto y como fecha de vencimiento será 31 de Diciembre de 9999. No obstante el periodo se puede cambiar.

– Los objetos organizativos y sus relaciones se mantienen a través de las transacciones de gestión organizativa (PPOM o PPOMW – para workflows)

19


• El Plan Organizacional Básico

Búsqueda

SelecciónEstructura

Detalles

20


• Mantenimiento del Plan: Crear una unidad organizacional

1. Presionar el botón crear

2. Seleccionar “Unidad Organizativa

3. Indicar un “codigo” una “descripción” y el periodo de validez

21


• Mantenimiento del Plan: Crear una función

1. Desde el menú seleccionar “Tratar��Crear Funciones”

2. Colocamos un código y una descripción

22


• Mantenimiento del Plan: Crear una posición

1. Pararse sobre una unidad organizativa y presionar el botón crear

2. Marcamos la opción “posicion” y presionamos intro

3. Colocamos el código, la descripción, una función y si la posición es o no el máximo responsable de la unidad org. También podemos colocar validez.

23


• Mantenimiento del Plan: Asignar un usuario

1. Nos paramos sobre la posición y presionamos el botón asignar.

2.Seleccionamos “titular” y elegimos un usuario

24


• Resultado Final

25


• Reasignación de usuarios– Haciendo DRAG-AND-DROP podremos reasignar usuarios entre distintas

posiciones.

– Presionando el botón para borrar, se podrán borrar tanto las asignaciones como los objetos.

– Tener sumo cuidado que el borrar la asignación DEJARA el objeto creado y no asignado a ninguna posición!

26


• Transporte de la estructura organizativa– Es potencialmente problemático transportar la estructura organizativa,

sobre todo si la estructura ha sido creada en el entorno de desarrollo y ha sido utilizada por los desarrolladores para sus pruebas.

– Además no siempre la base de usuarios es la misma en desarrollo que en productivo, por lo que al transportar los cambios si se transportan también las asignaciones con los usuarios el transporte fallará siempre y habrá que reasignar los usuarios en productivo, lo cual es una tarea tediosa y lenta.

– Para transportar la versión activa del plan tendremos que tener en cuenta entonces que es lo que queremos pasar, es decir que parte de la estructura se desea pasar, una vez que tengamos claro esto podremos proceder al transporte.

– RECOMENDACIÓN: de ser posible y si la estructura de sistemas de la empresa lo permite tener un sistema copia de productivo y mantener la estructura organizativa en ese sistema y no en desarrollo.

27


• Transporte de la estructura organizativa– Cuando se cree por primera vez la estructura organizativa, el sistema

pedirá una orden de transporte.

– Cuando se modifique la estructura (cambiando objetos existentes o creando nuevos) también pedirá ordenes de transporte.

– No obstante podremos pasar toda la estructura organizativa o partes de ella utilizando una herramienta que posee el sistema para tal fin.

28


• Transporte de la estructura organizativa

1. Seleccionar objetosde la estructura.

2. Selección por periodode validez.

3. Marcar las opciones del transporte.

29


• Transporte de la estructura organizativa

1. Seleccionamos los objetos y presionamos el botón para crear el transporte

2. Luego creamos el transporte, liberamos y transportamos

30

Contenidos




31

Trabajando sin la Estructura Organizativa

• Mantener el plan organizativo puede ser tedioso, sobre todo si no hay un departamento de Recursos Humanos u otro dedicado a este tema.

• Es por ello que muchos se preguntan: ¿Es necesario el plan organizativo para el sistema de workflow?– La respuesta es NO.– Existen alternativas al plan organizativo

• Estas alternativas incluyen:– Utilizando listas de distribución de usuarios– Utilizando reglas asignadas directamente a los usuarios (papeles)– Utilizando tablas propias y módulos de funciones desarrollados

internamente.

• Para estas alternativas debemos:– O bien marcar las tareas como generales– O bien usar roles de seguridad del sistema como posibles agentes.

November 25, 2008

SAP Business WorkflowDeterminación de Agentes

(routing)

2

Objetivos del Curso


� Definición de agentes� Definir los posibles agentes de una tarea� Restringir los posibles agentes de una tarea� Definir los agentes responsables de la tarea

� Definición de papeles � Creación de papeles � Creación de bindings entre tareas y papeles.

3

Contenidos

• Determinación de Responsables

• Definición de Agentes Posibles

• Asignación de Agentes en las Tareas

• Definición de Roles (Papeles)

• Determinación de Agentes por Módulos de Función

4

Determinación de Responsables

• En tiempo de ejecución el sistema de resolución de papeles determinaráel/los agente/s responsable/s para un workitem.

• Todos los agentes responsables, los cuales son posibles agentes de la tarea, se volverán destinatarios del workitem.

• El sistema de workflow pondrá este workitem en el worklist del usuario.

• Todos los destinatarios tendrán una vista del workitem refrescando su worklist.

5

Determinación de Responsables

• La determinación de responsables se realiza a través de papeles.

• Los papeles pueden ser de los siguientes tipos:– Responsabilidades

• A través de datos definidos en el contenedor del workflow se pasa el responsable directamente a la tarea (una variable con el nombre del usuario)

• No hay que desarrollar programas ABAP, todo se realiza directamente en el Workflow Builder a través de configuraciones.

– Información organizativa• Se asigna como responsable un elemento de la estructura organizativa

directamente a la tarea• Tampoco hay que desarrollar ABAP, se realiza a través de configuraciones

– A través de módulos de función• La determinación de los agentes responsables se realiza por programas ABAP

(módulos de funciones). Con este medio es posible realizar cualquier tipo de determinación de agentes.

– A través de Roles

6

Contenidos






7

Restringiendo Posibles Agentes

• Una tarea de dialogo tiene pre-definidos los posibles agentes.

• Solo los posibles agentes están permitidos para ejecutar el correspondiente workitem a tiempo.

• Los roles son usados para obtener los usuarios responsables utilizando datos que solo pueden saberse en tiempo de ejecución del workflow.

• Todos los agentes responsables, los cuales son también posibles agentes, reciben un workitem y son llamados receptores.

8


• La asignación de posibles agentes o la restricción de los mismos se hace a través de la actualización de tareas

• Modificando la tarea (o creándola) se puede acceder a la gestión de responsables a través del menú

9


• La tarea puede marcarse como “general” de esta manera “todos” los usuarios quedarán como posibles agentes.

• En el caso que se configure la tarea de manera que no sea general, entonces deberán asignarse los posibles agentes directamente desde la estructura organizativa creada.

10


• Con los íconos de asignar y desasignar se pueden ir agregando elementos de la estructura organizativa (unidades organizativas, puestos, tareas, etc.).

• Si el elemento organizativo tiene asignado usuarios en la lista de responsables asignados nos aparecerán bajo los elementos org. asignados (ver en la imagen los usuarios en verde)

11

Contenidos






12

Asignando Responsables en las Tareas

• En el momento de definir las tareas ya se han asignado los posibles agentes

• Luego al crear el workflow se deben configurar los agentes responsables de recibir los workitems

• La asignación se hace configurando el usuario responsable directamente en la tarea (recordar que la tarea debe ser de dialogo, caso contrario el usuario responsable será el usuario definido en el customizing de workflow para ejecutar tareas de fondo)

• Para la configuración de responsables pueden usarse:– Elementos de la estructura organizativa

– Elementos del contenedor del workflow

– El iniciador del workflow

– El rol – papel “es superior de…”

13


14


• Los elementos del contenedor se asignan como “expresiones”. Las variables del contenedor que se aplican como responsables deben ser del tipo WFSYST-INITIATOR (char de 14 caracteres)

• Si las variables del contenedor son “calculadas” recordar que siempre debe anteponerse el prefijo “US” y luego el usuario SAP. Por ejemplo si el usuario responsable es JPEREZ entonces en la variable se debe guardar el valor “USJPEREZ”.

15


• El iniciador del workflow es el usuario que activo la ejecución del workflow. Esta variable se completa automáticamente al generarse el evento y el evento es quien se encarga de pasarla al contenedor del workflow.

16


• El papel “Superior...” puede ser usado por ejemplo para guiar una petición de vacaciones al line manager en cargo.

• En este caso Adams quiere ir de vacaciones y solo David Boss recibiría este work item.

• Todos los demás posibles agentes no estarían preocupados con esta petición.

17

Contenidos






18

Utilización de Roles

• Los roles son papeles que permiten determinar responsables de una tarea en tiempo de ejecución

• Los roles se sirven de la información que el sistema provee en tiempo de ejecución para evaluarla y determinar a partir de dicha información quien es o quienes son los responsables para la tarea.

• Un rol queda definido por:– Un código y una descripción

– Un contenedor de datos para la evaluación de responsables

– Una serie de parámetros que se incluirán en el container y que determinarán que tipo de información del sistema requerirán en tiempo de ejecución

– El tipo de rol

– Configuraciones específicas dependiendo del tipo de rol

19


• Pasos para crear un rol: (1) Acceder por el menú a la transacción de creación

20


• Pasos para crear un rol: (2) Presionar el botón para crear un nuevo elemento

En el customizing de WF se definió el rango de números interno

Posteriormente aparecerá la pantalla para definir el rol

21


• Pasos para crear un rol: (3) Seleccionar un tipo de rol– Al crear un rol el sistema nos pedirá que indiquemos el tipo de rol entre los cuales

encontraremos• Por competencias (en Readymix utilizamos este TIPO y este ejemplo se basa en

competencias)• Por módulos de funciones• Por atributos organizacionales (evaluation paths)• Por datos de organización

22


• Pasos para crear un rol: (4) Completar los datos identificativos del rol– Colocamos un código y una descripción (sigla y denominación)

23


• Pasos para crear un rol: (5) Completamos los parámetros del tipo de rol. – Dependiendo del tipo de rol deberemos completar algunos parámetros.

– Por ser una competencia debemos indicar si la competencia tiene en cuenta prioridades y si el rol da un error al no encontrar nada (cancela). El atributo Papel Personal se utiliza para que la regla solo devuelva como resulta usuarios de SAP (no devolverá elementos de la estructura org.)

24


• Pasos para crear un rol: (5) Completamos los parámetros del tipo de rol. – Dependiendo del tipo de rol deberemos completar algunos parámetros.

– Por ser una competencia debemos indicar si la competencia tiene en cuenta prioridades y si el rol da un error al no encontrar nada (cancela). El atributo Papel Personal se utiliza para que la regla solo devuelva como resulta usuarios de SAP (no devolverá elementos de la estructura org.)

25


• Pasos para crear un rol: (6) Indicamos una descripción mas larga acerca de cómo trabaja el rol

26


• Pasos para crear un rol: (7) Se configura el container del rol– El container del rol representa un conjunto de variables que el rol necesitará en tiempo

de ejecución para poder evaluar las competencias asignadas. Es decir que dependiendo del valor de las variables que se coloquen se adjudicará una competencia determinada la cual tendrá asignada los usuarios responsables.

27


• Pasos para crear un rol: (8) Finalmente se definen las competencias– Las competencias deben tener en cuenta “TODAS” las posibilidades de asignacion de

datos en las variables del container.

– Una competencias se define con una clave, una descripción, la valorización de las variables del container y una jerarquía.

– Cuanto mayor sea la jerarquía mayor prioridad tiene la competencia en el caso de que dos o mas competencias al ser evaluadas sean válidas.

– Si un campo admite múltiples valores puede utilizarse como valor comodín el “*”.

28


• Pasos para crear un rol: (8-1) Creando una competencia…– Presionamos el botón crear

– Completamos el código y la descripción de la competencia

29


• Pasos para crear un rol: (8-2) Creando una competencia…– Valoramos las variables del container de manera que cuando se cumpla ese valor la

competencia sea válida

– También marcamos el nivel jerárquico de la competencia

30


• Pasos para crear un rol: (8-3) Creando una competencia…– Finalmente agregamos los objetos organizativos dentro de la competencia.

31


• Una vez creada la competencia podríamos desear probarla.– SAP NO ofrece la posibilidad de probar competencias.

– No obstante podremos desarrollar un pequeño programa para poder probarla.

– El programa deberá basarse en el modulo de función RH_GET_ACTORS para poder evaluar el rol.

– Este modulo de función recibe el nombre del rol y su container como entrada y devuelve una tabla con los agentes seleccionados.

CALL FUNCTION 'RH_GET_ACTORS'EXPORTING

ACT_OBJECT = 'AC90000001'TABLES

ACTOR_CONTAINER = ac_containerACTOR_TAB = ac_agents

EXCEPTIONSNO_ACTIVE_PLVAR = 1NO_ACTOR_FOUND = 2EXCEPTION_OF_ROLE_RAISED = 3NO_VALID_AGENT_DETERMINED = 4OTHERS = 5.

El nombre del rol se compone como “AC” + el código generado por SAP

32


• Ejemplo de un programa para probar roles

REPORT ZTESTRULE .

INCLUDE <CNTN01>.

PARAMETERS: p_ekorg TYPE EKKO-EKORG.

DATA: ev_holders TYPE STANDARD TABLE OF SWHACTOR,actor_tab TYPE STANDARD TABLE OF SWHACTOR,ac_agents TYPE STANDARD TABLE OF SWHACTOR,wa_ac_agents TYPE SWHACTOR,wa_ev_holders TYPE SWHACTOR,num_lines TYPE I.

swc_container ac_container.swc_clear_container ac_container.

swc_set_element ac_container 'PurchOrganization' p_ekorg.

CALL FUNCTION 'RH_GET_ACTORS'EXPORTING

ACT_OBJECT = 'AC90000001'TABLES

ACTOR_CONTAINER = ac_containerACTOR_TAB = ac_agents.

33



LOOP AT ac_agents INTO wa_ac_agents.

IF wa_ac_agents-otype = 'US'.APPEND wa_ac_agents TO actor_tab.

ELSE.clear ev_holders[].swc_clear_container ac_container.swc_set_element ac_container 'OTYPE' wa_ac_agents-otype.swc_set_element ac_container 'OBJID' wa_ac_agents-objid.

CALL FUNCTION 'RH_GET_STRUCTURE'EXPORTING

ACT_WEGID = 'WF_ORGUS'TABLES

ACTOR_TAB = ev_holdersAC_CONTAINER = ac_container

EXCEPTIONSNOBODY_FOUND = 1NO_ACTIVE_PLVAR = 2OTHERS = 3.

IF SY-SUBRC = 0.LOOP AT ev_holders INTO wa_ev_holders.APPEND wa_ev_holders TO actor_tab.

ENDLOOP.ENDIF.

ENDIF.ENDLOOP.

34



DELETE actor_tab WHERE otype ne 'US'.

DESCRIBE TABLE actor_tab LINES num_lines.IF num_lines IS INITIAL.

WRITE: 'No agents found.'.ENDIF.

WRITE: / 'The following agents where found:'.

LOOP AT actor_tab INTO wa_ac_agents.WRITE: / wa_ac_agents-otype, wa_ac_agents-objid.

ENDLOOP.

35


• Además de competencias otros tipos de roles que podrían llegar a utilizarse son:– Estructura Organizativa

• Utiliza “evaluation paths” para la selección de componentes y sus usuarios relacionados

• Prácticamente todos los componentes de SAP poseen evaluation paths para trabajar con el plan organizacional.

• Adicionalmente se pueden crear sus propios evaluation paths.– Atributos Organizativos

• Esta técnica permite vincular determinadas configuraciones de customizing (tablas) con elementos de la estructura organizativa (por ejemplo un laboratorio, un controller de MRP, un grupo de compras, etc).

• Se deberá crear un Business Object representando la tabla de customizing, luego se vincula el business object a un elemento de la estructura organizativa con la transacción PFOM.

• Cuando se instancia la tarea, se debera crear un binding entre el contenedor del workflow y el de la regla para poder instanciar el business object.

• Para mas información recomiendo ver la documentación de SAP en htto://help.sap.com– Módulos de Función

• El uso de módulos de función nos dará la máxima flexibilidad pero la mínima visibilidad.• Se pueden usar datos del sistema y de otros sistemas para determinar agentes• Se pueden combinar varias reglas (papeles) en una sola regla• Es importantísimo que la regla quede muy bien documentada.

36

Contenidos






37

Determinación de Agentes por Módulos de Función

• Este tipo de determinación es un subtipo de la determinación por roles.

• Cuando se define el rol se indica el tipo de rol como “Funcion a Ejecutar” y se coloca el nombre del modulo de funciones.

38


• El módulo de funciones debe ser creado por el cliente

• El papel debe tener un container definido con los datos necesarios que necesite el modulo de funciones para poder ejecutarse.

• El container del rol se debe completar con datos del container del workflow a través de un binding (en tiempo de diseño)

• Finalmente el módulo de funciones debe tener la siguiente interface:

39


• La estructura lógica debe ser:– Leer los parámetros del rol (el

contenedor del rol)

– Evaluar los parámetros de acuerdo a las necesidades internas

– Devolver los agentes encontrados o mostrar la excepción nobody_found.

November 25, 2008

SAP Business WorkflowEventos

2

Objetivos del Curso


� Eventos� Entender que es un evento y como crear eventos� Comprender los distintos tipos de eventos� Saber como definir condiciones de inicio de eventos

� Desarrollo� Saber desarrollar: programas que llaman eventos, check function modules y receiver function modules.

3

Contenidos

• Definición de Eventos

• Lanzando eventos desde las aplicaciones SAP– Lanzando eventos con “change documents”– Lanzando eventos con mensajes– Lanzando eventos con cambios de status– Otros tipos de lanzamiento de eventos

• Relacionar un evento a un workflow– Definición en el Workflow Builder– Event Linkage– Condiciones de Inicio

• Desarrollos en Eventos– Llamar un evento de un programa– Desarrollo de módulos de funciones para eventos

4

Definición de Eventos

• Dado que los workflows son procesos de negocio, es vital para una aplicación de negocio poder comunicarse con los workflows.

• Por ejemplo una aplicación de negocio necesita informar:– Cuando comienza un proceso de negocio– Cuando termina un proceso de negocio o una actividad dentro del proceso– Cuando una actividad o proceso que ha comenzado ya no se necesita– Cuando dada una circunstancia ha cambiado el ambiente en el cual el

proceso se ejecuta.

• Para poder comunicarse la aplicación de negocio utiliza EVENTOS.

• Simplemente dicho un evento es el cambio de estado de una instancia de un objeto de negocio (Business Object).

• Por ejemplo cuando un usuario cambia el maestro de materiales para el material XXXY entonces el Business Object XXXY lanzara el evento “Changed”.

5


6


• Para usar un evento como interfase entre la aplicación y un workflow se necesita lo siguiente:

– Definición del Evento• Es el nombre técnico del evento definido en un tipo de objeto. Se definen como un verbo en

pasado (creado, modificado, liberado, etc.).• Además el evento esta definido por sus parámetros. Los parámetros por defecto de un evento

son: su nombre, el tipo de objeto, la instancia del objeto y el creador del evento. No obstante se pueden definir parámetros adicionales que deben acompañar el evento.

– Creador del Evento• Es el programa, workflow, persona que ha creado el evento.

– Receptor del Evento• Es el termino genérico que se usa para denominar a todo aquello que reaccionará ante el

evento. Normalmente son workflows o tareas de espera.

– Linkage del Evento• El linkage especifica la relación entre el evento y su receptor. Se pueden a su vez especificar

las reglas que gobiernan esta relación. Las reglas determinan cuando y como el receptor recibirá el evento.

7


• Creando un evento– Los eventos se crean en el Business

Object Repository

– Debemos especificar el tipo de objeto para el cual queremos crear el evento

– Al definir eventos nunca deberemos codificar nada.

– Los datos que deben ingresarse son• El nombre del evento• Los parámetros del evento

– Podemos ver en el business objectBUS2105 (solicitud de pedido) el evento “released” y veremos si definicion y un parametro que posee asociado que es el codigo de liberación.

8

Contenidos





9

Lanzando Eventos desde Aplicaciones SAP

• Antes de que un evento sea lanzado por una aplicación, la creación del evento debe programarse en el programa de la aplicación.

• Afortunadamente en muchos de los programas standard de SAP están ya definidos los programas que lanzan los eventos y solo es necesario realizar el event linkage y determinadas configuraciones de customizing (ver la documentación de cada modulo para saber como lanzar eventos – http://help.sap.com).

• No obstante puede que para un proceso de negocio particular tengamos que crear un evento nuevo. En este caso deberemos definir como se lanzara el evento a partir de la aplicación.

• En el caso que el evento deba lanzarse desde un programa propio (de cliente) podremos programar el lanzamiento del evento muy fácilmente utilizando las APIs que SAP provee para tal caso.

10


• En el caso que debamos lanzar un nuevo evento desde un programa standard de SAP tenemos las siguientes posibilidades:– A través de documentos de cambio (change documents)

– A través del sistema de gestión de status

– A través de control de mensajes

– Utilizando el sistema de información logística (LIS)

– A través de los datos maestros de HR

– A través de Business Transaction Events (Solo para Finanzas)

– A través de customizing especifico de cada aplicación.

• Solo los tres primeros casos son los mas usados, el resto son específicos para determinados módulos (HR – FI) y para casos aislados (por ejemplo la liberacion de un pedido de compras).

11


• Lanzando Eventos: Change Documents– Muchas aplicaciones de negocio en SAP utilizan documentos de cambio

para dejar registro de las modificaciones hechas (generalmente transacciones de mantenimiento de datos maestros).

– Los documentos de cambio definen la operación que provoca el cambio (modificación, creación o borrado) y registran los datos del objeto de negocio que ha cambiado en forma de tablas con el valor antiguo y el nuevo.

– Los documentos de cambio SOLO se escriben cuando un campo designado como “relevante para change document” cambia.

– Antes de definir un evento basado en un documento de cambio deberemos controlar que el cambio sera escrito como un documento de cambio, controlando el customizing de los campos o bien haciendo pruebas.

12


• Lanzando Eventos: Change Documents– Para crear un evento de este tipo vamos por la siguiente opción de menú

13


• Lanzando Eventos: – Debemos indicar,

• El código de documento de cambio• El business object• El evento• Bajo que actividad se lanzará

– Creación– Modificación– Borrado

• Luego podremos restringir aun mas bajo que circunstancias queremos que se lance el evento, especificando campos de la tabla de campos relevantes, su valor antiguo y su valor actual.

Change Documents

14


• Lanzando Eventos: Cambios de Status– Si una aplicación de negocio utiliza el sistema de gestión de status,

podremos configurar el lanzamiento de eventos a partir de un cambio de estatus del sistema.

– Las aplicaciones de negocio SAP que generalmente usan este sistema son las logísticas, principalmente PP, PM, PS, QM, etc.

– El sistema estándar viene por defecto con status predefinidos llamados “status de sistema”, no obstante y por customizing pueden definirse nuevos status (de cliente).

– Los status de sistema siempre son fijados por el sistema automáticamente, mientras que los de cliente tienen que ser fijados por el usuario.

15


• Lanzando Eventos: Cambios de Status– Para crear un evento de este tipo vamos por la siguiente opción de menú

16


• Lanzando Eventos: Cambios de Status– Primero debemos seleccionar con que tipo de status trabajar, de sistema o

de usuario.

17


• Lanzando Eventos: Cambios de Status– Luego deberemos seleccionar el tipo de objeto y su evento .

– Finalmente activarlo.

18


• Lanzando Eventos: Control de Mensajes– Si una aplicación de negocios usa control de mensajes para intercambiar

información entre los distintos involucrados en el proceso de negocio podemos configurar un mensaje para lanzar eventos.

– Cuando el sistema de control de mensajes se ejecute, cualquier mensaje configurado será lanzado.

– Por ejemplo al crear una orden de ventas o un pedido de compras se utilizan mensajes para imprimir la orden. También podremos usar el mismo sistema para lanzar eventos.

– El tipo de mensaje que se utilice debe tener como medio de transmisión “9 – Eventos de Workflow”.

– La configuración de mensajes se hace a través de la transacción NACE.

19


• Lanzando Eventos: Control de Mensajes– Para configurar el mensaje primero entramos en la transacción NACE

20


• Lanzando Eventos: Control de Mensajes– Luego seleccionamos el objeto de negocio con el que deseamos trabajar y

presionamos el botón “Clases de Mensaje”

– NOTA: previamente deben estar configuradas las secuencias de acceso y los esquemas de mensaje (consultar la documentación de SAP)

21


• Lanzando Eventos: Control de Mensajes– Creamos una nueva clase presionando el botón “Entradas Nuevas”

– Creamos el mensaje con un nombre “EVEN”

– Colocamos sus atributos

22


• Lanzando Eventos: Control de Mensajes– Colocamos los textos y los interlocutores

– Finalmente ingresamos la rutina de proceso• Rutina RVNSWE01• Form CREATE_EVENT

23


• Lanzando Eventos: Control de Mensajes– Una vez definido la clase de mensaje configuramos los registros de

condición seleccionando la clase de mensaje creada (EVEN)

24


• Lanzando Eventos: Control de Mensajes– Seleccionamos la combinación de claves deseada

25


• Lanzando Eventos: Control de Mensajes– Creamos los registros con:

• Clave de Selección (en el ejemplo es el tipo de documento)• Función de interlocutor• Tipo de mensaje (9 – Eventos Workflow)• Tipo de salida (4 – Inmediatamente al grabar el documento)

26


• Lanzando Eventos: Control de Mensajes– Presionamos el botón “Comunicación”

– Aquí indicamos el tipo de objeto y el evento que deseamos que el mensaje lance.

– En el ejemplo vemos que lanza el evento “Created” del objeto “Pedido”

27


• Lanzando Eventos: Otros formas de lanzar eventos– Además de las formas explicadas (las mas importantes) podremos definir

otras maneras de lanzar eventos no tan habituales como ser:

• Utilizando el LIS (sistema de información logística) podremos definir reportes que lancen excepciones. Al lanzar la excepción podremos configurar el sistema para que adicionalmente llame un evento (transacción AWUW).

• A través de cambios en los datos maestros del módulo HR. Para este caso debemos relacionar un infotipo de HR al correspondiente tipo de objeto y activar el evento.

• Utilizando Business Transaction Events. Los business transaction events se utilizan para lanzar eventos relacionados a las aplicaciones financieras de SAP como contabilidad de mayores, cuentas a pagar y a cobrar, etc.

• Utilizando las APIs de Workflow en programas ABAP. Este punto lo veremos en detalle mas adelante durante la presentación.

28

Contenidos





29

Relacionar un Evento a un Workflow

• ¿Quiénes reaccionan a los eventos?– Un Workflow

– Un paso de tipo “esperar por evento”

– Una Tarea

• Cuando se lanza un evento, este puede tener uno o mas receptores.

• Se pueden usar eventos para:– Lanzar un workflow o una tarea

– Parar un workflow, una tarea o un paso de tipo “esperar por evento”.

– Forzar al workflow a cambiar algo sobre si mismo.

• A su vez un workflow puede en si mismo lanzar eventos utilizando el paso de tipo “creador de evento”.

30


• Unir el Evento al Workflow– Para establecer el inicio automático de un workflow a partir de un evento

debemos indicárselo en la configuración del workflow en el Workflow Builder (SWDD).

– Una vez posicionados el en workflow que deseamos iniciar con un evento, debemos pasar a la cabecera del workflow.

31


• Unir el Evento al Workflow– En la cabecera indicaremos que tipo de objeto y evento lanzaran el workflow

– Al crear la relación automáticamente aparecerá un binding ( ) que pasarádatos desde el contenedor del evento al del workflow.

– Podremos modificar el binding para agregar los parámetros que deseemos.

Los parametos _WF_Initiator y _EVT_Objectse generan automáticamente

32


• Unir el Evento al Workflow– Finalmente deberemos “activar” el binding entre el workflow y el evento. Esta

activacion en la jerga de workflow se denomina “event linkage”

– Tener en cuenta que esta actividad genera una orden de transporte de customizing.

Presionar aquí…

33


• Event Linkage– Otra forma de activar el linkage entre el evento y el workflow es a través del

siguiente menú

34


• Event Linkage– En esta transacción nos aparecerá una lista con todas las posibles

relaciones entre un workflow y un evento, a su vez podremos ver si el linkage que los vincula esta o no activado.

– Haciendo doble-click sobre un linkage pasaremos a ver sus detalles

35


• Event Linkage– En esta pantalla principalmente podremos activar o desactivar el linkage,

presionando sobre la opción “Acopl. Tipos activado”.

– Luego podremos configurar opciones acerca de cómo el sistema reaccionará ante un error, pudiendo optar entre:

• Desactivar el evento• Marcar el acoplamiento (linkage) como erróneo• No modificar el acoplamiento

36


• Event Linkage– También deberemos indicarle cual es el programa receptor del evento. Por

defecto para los workflows el programa es: • SWW_WI_CREATE_VIA_EVENT

– Podremos indicar una función de verificación la cual se utiliza para validar el linkage (si falla la función no se inicia el workflow)

– Por último podremos facilitar una función para determinación de receptores, es decir que en tiempo de ejecución (observando parámetros del contenedor del evento) podremos determinar el workflow receptor dinámicamente.

37


• Condiciones de Inicio– Anteriormente vimos como puede condicionarse el inicio de un workflow

utilizando una función de verificación en el linkage (luego veremos como programarla),

– Sin embargo esto puede ser un poco tedioso, sobre todo por que hay que desarrollar ABAP para lograrlo (aunque es la manera mas flexible de lograrlo).

– SAP provee una manera mucho mas fácil (no tan flexible pero bastante completa) de limitar el inicio de un workflow al dispararse un evento y esto es a través de las condiciones de inicio.

38


• Condiciones de Inicio– Para configurar condiciones de inicio seguir la siguiente opción de menú

39


• Condiciones de Inicio– Para crear la condición seleccionamos el tipo de objeto (en el ejemplo es la

solicitud de pedido)

– Aparecerán todos los eventos acoplados con workflow y seleccionamos uno.

40


• Condiciones de Inicio– Utilizando las variables del contenedor del evento, creamos las condiciones

lógicas que deseemos para que se cumpla o no el lanzamiento del workflow.

41


• Finalizado la configuración del linkage de eventos y workflow, y la correspondiente condición de inicio, podremos verificar el evento.

• Para verificar los eventos podremos usar la transacción para simular eventos (SWU0) o para crearlos (SWUE).

42

Contenidos





43

Desarrollos en Eventos

• Arquitectura del Sistema Eventos en SAP

44


• Desarrollo de un programa que lance un evento

– El programa que desee disparar un evento deberá utilizar el modulo de funciones SWE_EVENT_CREATE que forma parte de la amplia API de funciones para workflow.

– La estructura lógica del programa debería ser la siguiente:

• Llenar el contenedor de eventos con los parámetros necesarios

• Componer la clave del objeto que debe instanciarse para llamar al evento

• Llamar la función SWE_EVENT_CREATE

• Controlar las excepciones• Disparar el evento con COMMIT_WORK

explicito

45


• Tener en cuenta los objetos delegados al ejecutar el evento

46


• Desarrollo del modulo de función para verificar el evento– El modulo de función debe tener

la siguiente estructura

– La lógica del modulo de funciones debe ser la siguiente• Leer los parámetros del

contendor de eventos• Verificar lo que se desee

verificar• En caso de errores lanzar

cualquier excepción

47


• Desarrollo del modulo de función para determinar receptores– El modulo de función debe tener

la siguiente estructura

– La lógica del modulo de funciones debe ser la siguiente• Leer los parámetros del

contendor de eventos• Determinar el workflow que

debe llamarse utilizando los datos obtenidos

• En caso de errores lanzar cualquier excepción, sino terminar la función.

November 25, 2008

SAP Business WorkflowAdministración

2

Objetivos del Curso


� Explicar las distintas herramientas utilizadas para extraer información sobre el sistema de workflows.� Dar un resumen de herramientas que se utilizan para encontrar y resolver problemas del sistema de workflow� Indicar los problemas mas comunes que pueden suceder y como resolverlos.

3

Contenidos

• Reportes en Workflow

• Workflow Logs

• Herramientas para el Análisis de Problemas

• Otros Reportes y Herramientas Importantes

• Problemas Comunes

4

Reportes en Workflow

• Toda la información sobre procesos de workflow esta disponible en la base de datos de R/3, y puede ser evaluada usando informes entandar o informes específicos de cliente.

• Informes de tiempo de ejecución (runtime) tiene dos enfoques:– Soporte en los análisis de pruebas y análisis de errores– Mejora en el proceso lógico de negocio basado en la experiencia

• La información de los informes puede ayudarle a valorar la actuación de los procesos, si hay problemas con tiempos de espera, el desarrollo de los tiempos totales de proceso, cuan satisfactorios los acuerdos de servicio son cumplidos y si algo debería ser cambiado.

• Es incluso posible copiar información desde las tablas runtime a las tablas del sistema de información del workflow. De esta manera la información queda disponible para evaluaciones incluso después de que los datos hayan sido archivados.

• Los informes de workflow pueden ser visualizados desde el menú SAP EASY ACCESS dentro de la opción “Informes”.

5


• Existen diferentes informes para informar sobre el sistema de Workflow.

• Si tiene problemas con un workflow específico, entonces usa el diagnóstico de workflow.

6


• Análisis de Carga (workload analysis)– El análisis de carga de trabajo le da una visión de que trabajo ha sido hecho o esta

todavía en proceso, por parte de que usuario, trabajos, posiciones, o unidades organizacionales.

– Para el análisis de carga de trabajo ir la siguiente ruta:SAP EASY ACCESS -> Herramientas -> Business Workflow -> Desarrollo -> Informes -> Análisis carga de trabajo (SWI5)

7


• Evaluando Workitems (Workitem Analysis)– El análisis de Workitem le proporciona información de con que frecuencia

comienza un workflow y cuanto tiempo tarda en procesarse.

– Puede escoger el análisis de periodo. Puede incluso restringir el análisis de para workflows particulares, o tareas o grupos de tareas.

– La parametrización estándar es para poder obtener los workitems de la tareas. Si quiere ver los workitems de los workflows, debe marcar el indicador ‘(Sub)-Workflow’.

– El análisis de Workitem también proporciona información de aquellos workflows que no han sido procesados a tiempo.

– Ir a la siguiente ruta para el análisis de los workitems:Herramientas -> Business Workflow -> Desarrollo -> Informes -> Análisis

de Workitems.• Puedes entonces visualizar los workitems por tareas o por duración de proceso.

Puedes incluso mirar los workitems por tiempos limites fallados.

8


• Análisis de Workitems

9


• Identificando Workitems (Workitem Selection)– La selección del workitem es probablemente el camino más rápido para un

diseñador de workflow alcanzar el log de workflow de cualquier workflow.

– Puedes utilizar criterios de selecciones especiales para optimización de informes en tiempo de ejecución.

– El informe podría visualizar una lista de workitems personalizada, dependiendo de su criterio de selección.

– Puede visualizar estos workitems para obtener información detallada.

– Solo si es un posible agente de estos workitems, entonces estará habilitado para ejecutarlos o cambiarlos.

10


• Para la selección de los workitems es importante conocer su estado– W: dialog workitem

• Es la representación en tiempo de ejecución de una tarea con un diálogo directo con el usuario.

– D: missed deadline workitem• Es un workitem que está vencido, es decir, que el usuario responsable no lo ha

ejecutado y dejo pasar el tiempo de ejecución válido para la tarea.

– F: workflow workitem• Es la representación en tiempo de ejecución de un workflow.

– B: background workitem• Es la representación en tiempo de ejecución de una tarea que es ejecutada

directamente por el sistema (no es asignada a ningún usuario)

– E: wait step workitem• Es la representación en tiempo de ejecución de un paso de espera en la

definición del workflow.

11

Contenidos


• Workflow Logs




12

Workflow Logs

• El sistema de workflow registra en un log todo lo que sucede.

• Algunos pasos pueden filtrarse para que no aparezcan en el log– Pasos sin definir

– Operaciones en contenedor (container operations)

– Workflow control step (terminate step)

– 'Wait for event' steps

– Creación de eventos

– Pasos marcados con el indicador 'no en el log de workflow' en la definición de workflow

• Si la vista técnica está establecida como vista para el log de workflow en el perfil personal de workflow, no hay filtros.

13

Workflow Logs

• El log de workflow proporciona diferentes modos para diferentes requerimientos de información, cada uno de los cuales son apuntados a preguntas particulares y usuarios.

• Los siguientes modos están disponibles: – Modos para agentes procesados, los cuales no contienen ninguna

información técnica.

– Modos con detalle técnicos, requeridos, por ejemplo, por el administrador de workflow.

• La presentación es dependiente del modo que haya escogido el perfil de usuario de workflow.

14

Workflow Logs

• Vista Crónica– La pestaña de Workflow chronicle del log de workflow (ActiveX) muestra

en vista jerárquica todos los pasos del workflow, cuales ya han sido procesados o deberse para ser procesado. Si el workflow tiene una estructura de subworkflows, estos están visualizados también.

– Las funciones detalladas lista lo siguiente de un paso en la parte de abajo de la pantalla:

– Quien lleva a cabo que acción detallada con que resultado en estos workitems.

– Cuando esta acción fue ejecutada. – Que objetos fueron involucrados.

• Las funciones de los agentes muestran:– Agentes seleccionados– Posibles agentes– Agentes excluidos para un paso

15

Workflow Logs

• Vista Crónica

16

Workflow Logs

• Vista Crónica (vista de agentes)– La pestaña de los agentes del log de workflow permite visualizar los empleados

involucrados en el workflow. Lo siguiente esta listado por cada empleado:• Que acción fué llevada a cabo en que paso. • Cuando fue esta acción ejecutada. • Que objetos estuvieron involucrados.

– Esta vista expone primeramente que rol tiene un empleado en la ejecución del workflow

17

Workflow Logs

• Vista Crónica (vista de objetos)– La pestaña de los objetos de workflow lista los objetos que están conectados con el

workflow o que han sido direccionados en la ejecución de workflow.

– Estos objetos son: • El objeto "leading" del workflow.• Accesorios y objetos, que pueden haber sido adjuntados en los pasos o individuales del

workflow.

18

Workflow Logs

• Vista Técnica– El log técnico es siempre el punto de partida para el análisis de problemas del

proceso de workflows.

– Proporciona información detallada sobre resultados, agentes, workitems, y estatus de los workflows activos o completados.

– Haciendo un click en el mensaje nos da información detallada sobre errores o advertencias (warnings).

19

Workflow Logs

• Vista Técnica– Acceder al log técnico desde la

visualización detallada del workitem presionando el botón ‘Workflow log’ o en el menu de la barra superior ‘Ir a -> ‘Listar con detalles técnicos’.

– Puede acceder a la visualización del work item via analisis del work item, por ejemplo. Otra opción es visualizando directamente en el Business Workplace, selección de work item selection o desde analisis de carga de trabajo.

20

Workflow Logs

• Vista Gráfica– El log gráfico del workflow suplementa la información textual. Los pasos de

workflow ya procesados son marcados en una vista gráfica de la definición de workflow. Puede decir a primera vista que “ruta” de workflow cogió y que actividades son procesadas en paralelo de tus propias actividades dentro del proceso de negocio. A diferencia del log de workflow en formato texto, el log gráfico de workflow incluso enseña el futuro estado del workflow: Puede ver como un proceso continuará despues de su actividad.

– Las bases técnicas del log gráfico de workflow es el editor gráfico de workflow. Para visualizar el log gráfico del workflow, la definición relevante del workflow es leída y combinada con la información en tiempo de ejecución.

21

Workflow Logs

• Vista Gráfica

22

Contenidos


• Workflow Logs




23

Herramientas para el Análisis de Problemas

• Las siguientes herramientas están disponibles para los desarrolladores y administradores

24

Herramientas para el análisis de problemas

• Antes de hacer ningún trabajo en el sistema de desarrollo del workflow, debe ver todas las luces verdes en la pantalla de ‘Parametriza el sistema entero de workflow.'

– Utilice la función de chequeo cada vez que tu pienses que hay un error en el sistema workflow.

• El diagnostico del workflow te dará la mejor perspectiva para chequear cada aspecto de tu workflow.

• La simulación de eventos es un juego tipo ‘que pasa si….’– El sistema le informará sobre el impacto de un evento, sin desencadenarlo.– Esta función es excelente para determinar el vínculo del evento con la tarea.

• En el sistema de desarrollo, el trace de eventos puede “encenderse”. – Periódicamente el administrador de workflow debería quitar este fichero físico.– En productivo el trace de eventos debería “apagarse” por razones de rendimiento.

• El log del RFC nos dará una visión de los problemas de RFC.

• Manualmente puedes empezar una tarea o un workflow para hacer pruebas.

25

Herramientas para Análisis de Problemas

• Verificación del Customizing (SWU3)– Esta herramienta permite hacer un chequeo del customizing de workflow

para poder determinar posibles problemas de configuración

26


• Selección de Workitems (SWI1)– Esta herramienta permite visualizar en una lista un conjunto de workitems

con un estatus dado y poder analizar luego uno a uno sus logs.

27


• Rastreo de Eventos (event trace - SWELS)– Puede usar el rastreo de eventos para establecer si un evento esperado actualmente

fue desencadenado en el sistema.

– El rastreo de eventos siempre debe ser desactivado en el sistema de productivo. Es solo para entornos de pruebas!

28


• Iniciar Eventos Manualmente (SWU0 - SWUE)– Pueden simularse o crearse eventos. La simulación solo generará el evento y

mostrará los posibles receptores del mismo. La creación del evento además provocará la ejecución de los receptores asociados, por ello debe además informarse todos los parámetros del contenedor del evento.

29


• Rastreo de Workflows (workflow trace – SWU8)– Tal como existe un rastreo de eventos, también existe el rastreo de workflows. Este

nos indicará muchísima información técnica de lo que va sucediendo en el sistema de workflow. En tiempo de desarrollo puede llegar a ser una herramienta muy útil para poder depurar errores “finos”.

– El rastreo de workflows siempre debe ser desactivado en el sistema de productivo. Es solo para entornos de pruebas!

30


• Herramienta de Diagnóstico (SWUD)– Si tiene una tarea que esta generando problemas puede empezar viendo que sucede

con la herramienta de diagnostico.

– Esta herramienta se utiliza para encontrar distintos tipos de problemas (customizing, tareas que nunca se lanzan, workflows suspendidos, etc).

31

Contenidos


• Workflow Logs




32

Otros Reportes y Herramientas Importantes

• Otros reportes que el sistema ofrece para analizar son:– SWI2_ADM1: Workitems sin responsables– SWI2_DEAD: Workitems con fechas vencidas– SWI2_DIAG: Análisis de workitems– SWU2: Monitor RFC de Workflow

• A su vez podemos usar las siguientes herramientas:– SWI30: Desbloqueo de workflows– SWIA: Ejecutar workitems sin responsables– SWPR: Reanudar workitems tras errores– SWPC: Reanudar workflows tras errores– SWW_SARA: Archivar workitems– SWWL: Borrar workitems

33

Contenidos


• Workflow Logs




34

Problemas Comunes

• Resolviendo Errores en Workitems– Un buen diseño del workflow y su posterior sesión de pruebas en un

entorno de integración debería prevenir la mayoría de los errores en los workitems, sin embargo es posible que en el entorno productivo del sistema se den errores.

– Este tipo de errores se dividen en 2 categorías:

• Workitems con status “erroneo”: estos son los más fáciles de encontrar y los mensajes que se encuentran en el log del workitem casi siempre bastan para poder encontrar el problema.

• Workitems que no se comportan de acuerdo a lo esperado: estos son más difíciles de detectar y determinar la causa del problema, especialmente si el workitem se completa sin dejar rastros del problema (ya que no se puede volver a ejecutar un workitem completado).

35

Problemas Comunes

• Los problemas típicos que un workitem puede tener son:

– Un workitem con status “erroneo” y el mensaje “el Objeto no existe”. • Este problema puede ser resultado de un error de bindings mal diseñados,

errores en la secuencia del workflow (ejemplo, el objeto no existía al crearse o ejecutarse el workitem), o un diseño inadecuado del workflow (por ejemplo, el workflow no tiene en cuanta que un documento pueda borrarse manualmente).

– Un workitem con status “erroneo” y el mensaje “el correo no pudo enviarse”

• Este problema puede darse por un problema de binding en el caso de los datos que necesita la tarea para enviar correos no este recibiendo alguna variable obligatoria. En el caso de que todos los workitem asociados a envíos de correo fallen seguramente se deba a algún problema en la configuración del SAPConnector o el Exchange Connector (o el SAP WAS en el caso de que se este trabajando con esta plataforma).

36

Problemas Comunes

• Otros problemas típicos que un workitem puede tener …:– Un workitem con status “erroneo” y el mensaje “El metodo del objeto

asociado ha fallado”. • Este problema no es un problema del workflow en si mismo, sino del método que

este ejecutando la tarea asociada al workitem. En este caso el problema puede ser un cambio en el customizing, un cambio en los datos maestros utilizados, transacciones que se ejecutan mal, cambios por user-exits o BADIs, etc.

– Un workitem de diálogo que nunca se completa por que el evento “terminador” nunca ocurre.

• Este problema puede darse por un problema de bindings aunque mas posiblemente sea que el responsable de ejecutar el workitem no lo haya echo correctamente.

– Un workitem de background que empieza pero nunca termina.• Esto puede ser un problema de relaciones entre eventos (iniciador – terminador) o

bien puede ser debido a un short dump en el proceso de fondo. En este caso se debera arreglar el problema y volver a ejecutar el workitem.

November 25, 2008

SAP Business WorkflowBusiness Workplace

2

Contenidos

• Definición de Business Workplace

• Detalles de la Worklist

• Detalles de un Workitem

• Logs

• Detalles Adicionales en el marco del proyecto PPP

3

Definición

• El Business Workplace es una parte del entorno de ejecución del “SAP Business Workflow. Los empleados responsables, reciben los documentos y los work items para su tratamiento en el Business Workplace.

• Una vez que una tarea (=un work item) ha sido ejecutado y completado, se puede continuar con el proceso.

• Usando la estructura de las unidades organizativas, las cuales definen roles “funciones” y responsabilidades en la estructura de la empresa, el trabajo requerido para un proceso determinado, es dirigido a la persona apropiada.

4

Definición

• La “worklist”contiene todos los “work items” (todas las actividades que han de ser procesadas) asignadas a su usuario. El Business Workplace es por consiguiente, la interfase más importante para un empleado en su trabajo diario.

• Como extensión a la worklist (lista de work items), los documentos electrónico entrantes (e-mail, Internet mail y fax), se muestra también en el Business Workplace (en el inbox). Esto simplifica el acceso de un empleado a la información que es importante para el.

5

Elementos del Business Workplace

Previsualización de Work items

Worklist

Work itemsespeciales

Árbol de previsualización

Descripción de la tarea Objetos

relacionados

Consejos y trucos

Texto del Work item

6


• El Business Workplace tiene tres zonas diferenciadas, las cuales se detallan a continuación:

– Árbol de previsualización: En la parte izquierda del Business Workplace, se encuentra el árbol de previsualización. Aquí se puede elegir work items para ser ejecutados, workflows que hayas empezado, o documentos.

– Worklist: La Worklist se mostrará en la esquina superior derecha de la pantalla del Business Workplace en el momento en que se seleccione la carpeta “Workflow”. El sistema agrupa las entradas automáticamente en esta carpeta. Existen carpetas especiales donde se pueden encontrar workitems, los cuales están vencidos o están a punto de vencer. Si se selecciona el “inbox” a traves del árbol, se verán todos los work items y documentos en esta parte de la pantalla.

7


• Continuando la tercera zona…

– Previsualización de work items: Se encuentra en la esquina inferior derecha de la pantalla del Business Workplace, el wok item seleccionadoen la worklist es mostrado de forma previa. No todas las funciones de los work items mostradas o registros del workflow están disponibles. es posible ejecutar una decisión de un usuario desde la “previsualización de work item”. También se puede utilizar una “user exit” para ajustar la previsualización del work item a las necesidades del usuario final.

8

Contenidos




• Logs


9

Detalles de la Worklist (lista de Workitems)

Ejecutar Aceptar

Apartar

Visualizar Anexos

Crear Anexos

Los usuarios que reciben los work items pueden mostrar los documentos anexos de dichos work items y añadir nuevos. Se pueden adjuntar muchos tipos de documentos a un work item, incluyendo documentos SAPscript, Microsoft Office o páginas de internet.

Visualizar Transmitir y Reenviar

10

Detalles de la Worklist

• Los Workitems pueden ser ejecutados directamente desde la Worklist. Las aplicaciones se lanzan con los datos requeridos en el momento en que se hace doble-clic.

• El sistema workflow determina los usuarios receptores del Workitem. Todos esos usuarios receptores seleccionados pueden ver y (potencialmente) ejecutar el Workitem en su Business Workplace, pero solamente un usuario puede ejecutar el Workitem. Por consiguiente, una vez que un usuario realizar la ejecución, el resto de los usuarios no podrán ejecutar dicho Workitem posteriormente.

• Un usuario puede aceptar un Workitem. Un Workitem solamente puede ser ejecutado por el usuario que lo aceptó. Si se elige “Rechazar”, se modifica el status de dicho work item de “Reservado” y se vuelve a poner disponible parta todos los usuarios “receptores” seleccionados. En ese momento, el status del work item vuelve a ser “Listo”.

11


• Se puede especificar, que la finalización de un paso en un procedimiento de workflow sea confirmada explícitamente. Posteriormente a que un work item sea ejecutado, se puede hacer que aparezca un cuadro de diálogo en el cual se pueda terminar la ejecución del work item. Si se elige “Cancelar” en este punto, el work item permanece en la worklist y se establece como “ejecutado”. Dentro de la worklist se puede seleccionar “hecho” para work item con el status “ejecutado”. Hasta que se realize esto, el work item puede ser ejecutado o reenviado en reiteradas ocasiones.

• El contenido de la worklist es compilado basándose en datos específicos del usuario, por lo que dicha worklist mostrada, siempre corresponderá a un usuario determinado, el cual puede cambiar de acuerdo a las asignación organizativa del empleado. Por consiguiente, la worklist no es compilada hasta que el usuario llama al Business Workplace.

12


• R/3 almacena temporalmente en memoria los datos relativos a las funciones organizativas asociadas a un usuario la primera vez que este se “loga” en el sistema, y compila la worklist de acuerdo con estos datos, cada vez que esta es llamada.

• Sí una nueva tarea es asignada al usuario después de logarse, dicho usuario podrá ver el work item en el sistema, pero no pueden ejecutarlo. Los usuarios reciben el mensaje “Usuario no puede apartar “aceptar” el work item.” Si esto ocurree,actualize el entorno organizativo en el Business Workplace a trevés del menu superior: Opciones-> Opciones Workflow->Refrescar entorno organizativo.

• Se puede transmitir un work item a otro usuario para ejecutarlo. Las propiedades de una tarea determinan si puedes transmitir un work item a todos los usuarios o solo a alguno de ellos. También puedes hacer que un work itemsea accesible para usuarios que no estaban configurados como “receptores”de dicho work item en un principio.

• Tu puedes volver a reenviar un work item a un servidor para almacenarlo y si se quiere ejecutarlo en un momento especifico del tiempo en el futuro.

13

Worklist: Otras funciones

Otras funciones para el procesamiento de Work items:

� Posibilidad de marcar el work item como “terminado”.� Cambiar fecha limite para la ejecución de dichos work items� Modificar las prioridades.

Configuración individual de las columnas

Se puede configurar la worklist individualmente seleccionando los campos que van a ser mostrados. Para ello posiciónese con el puntero en el icono señalado “Seleccionar disposicion”. Cambie dicho diseño seleccionando los campos que van a aparecer usando el puntero, grabe y seleccionelo.

Se puede configurar la worklist individualmente seleccionando los campos que van a ser mostrados. Para ello posiciónese con el puntero en el icono señalado “Seleccionar disposicion”. Cambie dicho diseño seleccionando los campos que van a aparecer usando el puntero, grabe y seleccionelo.

14

Contenidos




• Logs


15

Detalles de un Workitem

• La visualización estándar del Workitem esconde la información técnica no requerida para las tareas normales del día a día.

• El hecho de que aparezcan los anexos y puedan ser “llamados”inmediatamente se traduce en una ayuda para el usuario. La descripción del work item se encuentra también intregrada, haciendo posible el formato SAPscript.

• La prioridad puede ser cambiada.

• Toda la información adicional (como usuarios o anexos), pueden ser llamados pulsando en un link.

• La pantalla estándar del work item contiene las vistas “Datos basicos” y “Objetos disponibles”.

• Dicha pantalla puede ser ampliada incluyendo “pestañas” definidas por el usuario.

16

Vista Técnica de un Workitem

• La pantalla de visualización técnica del work item contiene entre otros tipos la siguiente información:– Identificación “ID” del work item.

– Mensajes.

– Contenedores.

17

Vista Técnica de un Workitem

• Los Anexos no aparecen de una manera inmediata y tienen que ser llamados a través del menú.

• El Workitem puede ser cambiado (esto se utiliza mucho para poder hacer un debug del Workitem en caso que tenga errores).

• Esta pantalla puede ser usada para diagnosis. Se ve el ID del Workitem, las fechas limites, y puede acceder a toda la información técnica.

• Para acceder a la pantalla de la información técnica seleccione del menú: Opciones->Opciones workflow personales->Vista técnica.

• También se puede acceder a la información técnica a través de: Pasar a->Pantalla técnica de Workitem.

18

Business Workplace: Resumen de funciones.

Otra información:• Fechas limites de ejecución• Reenvió de work items• Prioridades•Status•Anexos

Lista de objetos:Otros Objetos:•Añadir.•Mostrar.•Borrar de la lista

Funciones Ad hoc:•Reenviar.•Cambiar las prioridades.• Remitir a un servidor para un uso posterior•Envío de mail

Descripción de Work item Otras funciones:•Usuarios.•Mostrar historial•Log de pasos•Contenedores de información.•Datos técnicos

Funciones de work item:• Ejecutar•Reservar/Apartar•Marcar como realizado•Fechas limites de ejecución•Anexos•Rechazar

Se recoge toda la información y las actividades del entorno de un work

item.

19

Contenidos




• Logs


20

Business Workplace: Workflow Log

Vista cronológica del proceso

Detalle de cada paso

Muestra todos los receptores, a usuarios tanto posibles como excluidos

La línea verde muestra el progreso del

proceso

Detalles de sección

Gráfico del log de Workflow

Workflow Log

21

Detalles del Log de Workflow

• El “Workflow Log” contiene toda la información sobre un proceso de negocio.

• Dependiendo de los roles “funciones” hay diferentes vistas:

– Vista estándar: Esta vista esta disponible en diferentes formatos.

– Cronología: ¿Por quien y cuando fue realizada una acción?

– Usuarios: Que usuario realizó una determinada actividad y cuando se hizo?

– Objetos: ¿Donde, por quien y de que forma fueron procesados los posibles objetos?

– Vista técnica.

– Gráfico del Worflow Log.

22

Detalles del Log de Workflow

• El Workflow Log responde a las siguientes preguntas:

– ¿Cual es el status?

– ¿Quien completo una tarea determinada?

– ¿Que tipo de información es dirigida a un decisión específica?

• El Log te da acceso a una información mas detallada, en relación a los Workitems o contenidos de los documentos anexos.

• A través de cualquier vista, tu puedes requerir información técnica o adicional, tal como información de un error, condiciones para en enrutamiento de tareas o incluso cualquier contenedor de elementos.

23

Business Workplace: Bandeja de salida para seguimiento de status

Work items ejecutados por ti

Work items transmitidos por ti

Work items lanzados por ti

Objetos relacionados

Usuarios responsables actuales

Status de cada paso del proceso

Workflows procesados

Esta pantalla aporta:

•Una visión general rápida y sencilla de procesos acometidos

• Status de las tareas a primera vista.

•Desarrolla oportunidades de responder a las necesidades de los clientes.

24

Contenidos




• Logs


25

Detalles Adicionales para el proyecto PPP

• En el proyecto PPP se han generado 5 workflows los cuales generan correos electrónicos (al servidor exchange de Readymix).

• De estos workflows 1 en particular genera workitems (para la toma de decisiones en la liberación de pedidos).

• Estos workitems no son enviados como correos electrónicos y deben ser tratados en SAP.

• Para que los usuarios responsables de recibir y tratar estos workitemsse enteren de que tienen datos pendientes para su tratamiento, existe un programa estándar de SAP que debe ser planificado con un JOB y que recorre todos los workitems cuyos “responsables” hayan decidido recibir la notificación de elementos nuevos.

• El programa se llama RSWUWFML y debe parametrizarse mediantevariantes.

26


• El programa contiene la siguiente pantalla de selección que deberáconfigurarse:

– El sufijo del Job

– Como mail colectivo

– Sin anexos ejecutables

– El texto que se desee para informar

27


• Luego cada usuario deberá configurarse la transmisión automática a un correo electrónico que desee para recibir la notificación del programa.

• Esta configuración se hace desde el Business Workplace por el menú

• También se puede acceder directamente a través de la transacción SO13

28


• En la transacción vamos a “transmision automática” y creamos un nuevo destinatario presionando el botón “Dirección de Internet”.

• Colocamos el e-mail y guardamos los datos.

29

Datos Adicionales para el proyecto PPP

• Por ultimo para que las tareas de envío de correo funcione enviando los correos al servidor Exchange deberán configurarse las direcciones de correo electrónico de cada uno de los usuarios implicados en el sistema de workflow.

• Para ello se modifica el usuario con la transacción SU02.

• En el área de “comunicación” se coloca el correo del usuario y se guardan los datos.

Curso Workflow

Documents

Transcript of Curso Workflow