Manual Workflow

ÍNDICE

1 INTRODUCCIÓN ... 3

2 CONCEPTOS BÁSICOS ... 4

3 MENÚ WORKFLOW ... 6

4 ESTRUCTURA ORGANIZATIVA ... 8

4.1 DEFINICIÓN DE UNA ESTRUCTURA ORGANIZATIVA ... 8

4.2 VISIÓN GENERAL ... 12

5 BUSINESS OBJECT REPOSITORY ... 13

5.1 PROPIEDADES DEL OBJETO ... 14

5.2 NUEVO TIPO DE OBJETO ... 19

5.3 ATRIBUTOS NUEVOS ... 21

5.4 EVENTOS NUEVOS ... 27

5.5 MÉTODOS NUEVOS ... 32

5.6 MACROS Y ATRIBUTOS ... 46

5.6.1 Definición atributos ... 46

5.6.2 Obtener valores de atributos de la base de datos ... 47

5.6.3 Obtener valores de atributos de tipo objeto ... 48

5.6.4 Recuperación atributos clave ... 50

5.6.5 Recuperación parámetros de los métodos ... 50

5.6.6 Asignación parámetros salida método ... 51

5.7 STATUS TIPO DE OBJETO ... 52

5.8 INSTANCIACIÓN DE UN OBJETO ... 53

6 DEFINICIÓN GENERAL DE WF ... 56

7 CONTAINERS ... 58

8 TAREAS ... 61

8.1 CREACIÓN DE TAREA SIMPLE ... 61

8.2 CREACIÓN WORKFLOW ... 79

8.2.1 Pasos de varias líneas ... 100

9 ROLES ... 109 9.1 CREACIÓN DE PAPELES ... 110 9.1.1 Función a ejecutar ... 113 9.1.2 Competencias ... 117 10 SUPERVISIÓN DE FECHAS ... 126 11 EVENTOS ... 127

11.1 PARAMETRIZACIÓN DE GENERACIÓN DE EVENTOS ... 128

11.2 MODIFICACIÓN DE DATOS MAESTROS DE PERSONAL ... 129

11.3 DOCUMENTOS DE MODIFICACIÓN ... 133

11.4 GESTIÓN DE STATUS ... 137

11.6 ACOPLAMIENTO DE EVENTOS ... 143 11.7 CONDICIONES DE INICIO ... 144 12 ASISTENTES ... 150 13 CUSTOMIZING ... 151 13.1 PARAMETRIZACIÓN AUTOMÁTICA ... 151 13.2 PREFIJOS ... 152 14 MONITORIZACIÓN Y ANÁLISIS ... 154

14.1 WORKFLOWS PARA OBJETOS ( SWI6 / SWI14 ) ... 154

14.2 ANÁLISIS DE WORKITEMS ... 157

14.2.1 Work items por tarea ( SWI2_FREQ )... 158

14.2.2 Análisis workload ... 159

14.3 TRACE EVENTOS ... 160

14.4 GESTIÓN ... 164

15 SISTEMAS DE INFORMACIÓN (WIS) ... 166

15.1 CONFIGURAR EL WIS ... 167 15.2 RELLENAR EL WIS ... 167 15.3 CONSULTAR EL WIS ... 167 16 BUSINESS WOKPLACE ... 168 16.1 ANEXOS ... 170 16.2 TRANSMISIÓN DE WORKITEMS ... 172 16.3 SUPLENCIAS... 174

1 Introducción

SAP Business Workflow es una herramienta de SAP para automatizar y coordinar procesos funcionales entre aplicaciones, que ocurren frecuentemente de una forma similar o idéntica, con la participación de varias personas o departamentos y que requieren un alto nivel de participación.

Un sistema de Gestión Workflow facilita el procesamiento de procesos estructurales, y la automatización de tareas.

El Workflow en SAP se caracteriza por:

 Estar basado en los Business Objects de SAP y en la programación orientada a

objetos.

 Integrar las herramientas de PD y HR con la ejecución de circuitos de negocio.

 Estar incorporado en un nivel de integración sobre el nivel de transacciones.

 No cambiar ni restringir la funcionalidad y operabilidad de las transacciones existentes. Ni añadir funcionalidad ( a nivel de módulos ) no existente en SAP.

 Realizar a través del Office de entrada (Inbox) de SAP las tareas de cada usuario y no necesitar trabajar desde el menú Standard.

 Permitir ejecutar las tareas desde aplicaciones externas a SAP.

Las ventajas que proporciona un sistema workflow son las siguientes:

 Reduce la complejidad de los procesos empresariales.

 Incrementa la responsabilidad individual de los empleados.

 Agiliza la actividad interna y externa de la empresa.

 Reduce el papeleo.

 Mejora la calidad del trabajo.

 Es aplicable a la práctica totalidad de los procesos empresariales.

 Perfectamente integrado en la funcionalidad estándar SAP.

 Proporciona información muy detallada sobre los procesos internos realizados en el sistema a través del WIS (Workflow Information System).

2 Conceptos básicos

 Tipos de objeto: Los tipos de objetos son definidos con sus métodos, atributos y eventos en el Repositorio de Objetos (BOR: Business Object Repository).. Es la Unidad básica de un proceso de workflow. Identifica la entidad a procesar por el flujo de trabajo. Por ejemplo: Material, proveedor, pedido,….

 Evento: son señales que desencadenan acciones: por ejemplo el inicio del workflow.

 Workitem: Mensaje que le aparece a un usuario en el Inbox del Workflow, correspondiente a un paso de workflow cuya ejecución es de su competencia. Cuando el usuario hace doble click en el workitem, puede ejecutar el paso de workflow.

 Carpeta entrada del workflow (Inbox): Es donde van a aparecer los mensajes workflow (workitems) cuando éstos se produzcan. A través del Inbox ejecutaremos los diferentes pasos del workflow.

 Tarea: es la ejecución de un método sobre un objeto ( Ej.: visualizar pedido). Es el componente esencial del flujo de proceso.

 Modelo de Workflow: Definición y flujo de proceso de un conjunto de tareas.

 Estructura organizativa: Define el plan organizativo de la empresa. Esto nos permitirá asignar usuarios SAP a cada paso del workflow.

Nomenclatura utilizada en función del tiempo de ejecución / definición:

DEFINICIÓN EJECUCIÓN

Tipo de Objeto = Entidad a procesar.

Ej. EMPLOYEET (Empleado)

Objeto = Instanciación del Tipo de

Objeto.

Ej. Empleado ‘0000184’

Tarea = Acción a realizar con un objeto.

Ej. TS 20000153 Encontrar empleado

Workitem = cualquier Tarea que esté

instanciada.

Ej. Encontrar empleado ‘0000184’

Definición de un Workflow = Conjunto de

tareas relacionadas.

Ej. WS 01200003 Encontrar y bloquear

empleado

Instanciación de un Workflow

Ejecución concreta

Ej. Encontrar y bloquear empleado

‘0000184’ Agentes Posibles = son todas las personas

que pueden ejecutar una Tarea Ej. Tarea ejecutable por cualquier

posición con función de jefe de área.

Agentes Seleccionados = son las

personas que se seleccionan para realizar una tarea en tiempo de ejecución

Ej. Tarea se ejecuta sólo para jefe de

área del área de empleado del workflow

Esquema de funcionamiento

3 Menú workflow

Toda la funcionalidad de workflow la podemos encontrar en:

Si no deseamos trabajar desde el menú principal, a través de SWLD accedemos a un menú específico para workflow:

4 Estructura organizativa

La estructura organizativa es necesaria para asignar responsabilidades sobre cada una de las tareas del Workflow.

Podemos definir a través de las herramientas de Workflow una estructura organizativa

específica sin necesidad de crear una en el módulo de PD, aunque es aconsejable

utilizar la misma para evitar doble mantenimiento.

Una estructura organizativa puede utilizarse, y es lo más conveniente, en varios workflows.

Tal y como hemos mencionado anteriormente, la estructura organizativa servirá para definir las responsabilidades de cada paso del proceso, que podrán ser uno o más

usuarios. El usuario que primero ‘atrape’ el workitem será el que ejecute la tarea.

Para la implantación de estructuras organizativas no es necesario tener el módulo de RRHH. Podemos representar la estructura de la organización o de la empresa mediante la herramienta proporcionada por el WF. De esta forma podremos asignar responsables a las tareas de forma dinámica a través de un puesto de trabajo, función, unidad

organizativa, usuario, etc. Para ello tendremos que definir:

 UNIDAD ORGANIZATIVA (O): Jerarquías empresariales

Ej. Departamento de Administración de Personal

 FUNCIÓN (C): Tareas generales asociadas en la empresa una determinada posición

Ej. Director de Área, Jefe de Dpto., Secretaria...

 POSICIÓN (S): Lugar ocupado por una persona para desempeñar una función

Ej. Jefe Dpto. Compras, Secretaria Dpto. RRHH...  USUARIO (US): Usuario SAP destinatario de la tarea

Ej. Usuario número E00000184

 PERSONA (P): Personas de la estructura organizativa

Ej. N° de personal 00000184

4.1 Definición de una estructura organizativa

A partir de la transacción PPOSE definiremos la estructura organizativa procediendo de la siguiente manera:

1. Crear las unidades organizativas (O) y situarlas por ordenación jerárquica.

2. Crear las posiciones y funciones. Colgar las posiciones (S) de cada unidad organizativa, y asignar a funciones a cada posición. Las funciones no tienen relevancia a la hora de encontrar el responsable de la tarea.

3. Luego se realiza la asignación de usuarios (US) y/o personas (P) a las posiciones.

4. Es posible designar una de las posiciones de cada unidad organizativa como su

responsable.

Las tareas podrán ser direccionadas dinámicamente al responsable de la unidad organizativa del usuario que ejecutó el último paso.

Existen funciones en SAP que a partir de una posición o usuario o persona, calcula su responsable de unidad

5 Business Object Repository

La arquitectura del Workflow está basada en el Tipo de Objeto. Un tipo de objeto cumple las propiedades necesarias e imprescindibles de la programación orientada a objetos: encapsulamiento, herencia y polimorfismo.

La herramienta que proporciona SAP para crear, modificar o visualizar objetos es el

En la pantalla siguiente escribiremos el nombre del objeto:

5.1 Propiedades del objeto

Un tipo de objeto contiene los siguientes elementos:

 DATOS BÁSICOS: Relaciones con supertipos, status. Atributos y métodos por defecto.

Obtendremos los datos básicos haciendo doble-click sobre el código del objeto.

 INTERFACES: Atributos, métodos y eventos predefinidos.

 ATRIBUTOS: Son las propiedades de un objeto. Pueden hacer referencia a otro objeto.

Pueden servir para controlar el flujo de proceso de un Workflow (condiciones), también pueden hacer referencia a un campo de la BD ( código autogenerado) o pueden ser virtuales (código ABAP de cliente) y pueden ser multilínea (infotipos 0008 vigentes en un año).

 MÉTODOS: Son las acciones permitidas sobre un objeto.

Encapsulan la funcionalidad de la aplicación SAP y el código es transparente para el usuario.

Hacen referencia a transacciones, módulos de función, etc. Pueden ser síncronos o asíncronos.

Métodos síncronos: el método es llamado, asume el control del proceso y

confirma el resultado del proceso. Permiten parámetros import y export, resultado y excepciones. (Ej.: visualizar material).

Métodos asíncronos: el método es llamado y corre sin conexión al emisor. Sólo

 EVENTOS: Describen el cambio en el status de un objeto.

Sólo son definidos en el tipo de objeto, pero son disparados fuera del tipo de objeto, en la aplicación. No poseen código implementado.

La definición de este tipo de objeto quedará implementada en un programa ABAP. Dicho programa podrá ser editado siempre que queramos, para realizar las

modificaciones oportunas. Todo tipo de objeto va a tener un programa ABAP

asociado.

Si no existe el tipo de objeto que necesitamos para el workflow podemos crearlo a partir del Business Object Builder.

Observación:

Todos los elementos que aparecen con el símbolo quieren decir que están obsoletos y no se recomienda su utilización.

5.2 Nuevo tipo de objeto

Si un Tipo de Objeto no cumple todas las funcionalidades necesarias para nuestro Workflow podemos crear un Subtipo para ese Tipo de Objeto que heredará todo su código, propiedades y funcionalidad (ej. ZBUS1001) y añadirle nuevos atributos, métodos y/o eventos.

Para ello procederemos de la siguiente manera: desde la transacción SWO1 escribiremos el tipo de objeto principal y con el botón crearemos el subtipo deseado.

Nos aparece la siguiente pantalla donde indicamos:

 Tipo Objeto: Nombre interno del nuevo objeto

 Objeto: Nombre descriptivo del objeto

 Denominación: Denominación del objeto, con un valor que permita su búsqueda con facilidad

 Descripción breve

 Programa: Nombre del programa en el que quedarán implementados los atributos y métodos del objeto

Una vez cumplimentados los campos tenemos el objeto creado.

A este objeto podemos añadir:

 Interfaces

 Atributos

 Métodos

 Eventos

5.3 Atributos nuevos

y con el botón de crear nos aparece la siguiente pantalla:

El atributo a añadir puede ser un campo del diccionario ABAP, diremos si o no según proceda

Si es un campo del diccionario ABAP, nos aparecerá una pantalla en la cual indicaremos la tabla a la que pertenece el campo. Al hacer ‘Enter’ obtendremos la lista de campos de esta tabla, con los ya asignados marcados.

Marcaremos el campo que deseamos introducir, por ejemplo BSTME, y haremos enter otra vez.

Si el atributo no corresponde a un campo del diccionario ABAP nos aparecerá la siguiente pantalla:

En ella indicaremos las características del atributo, por ejemplo, lista de los centros en los que está dado de alta el material.

Una vez dado de alta el material debemos implementarlo. Para ello nos situamos sobre el atributo creado

y con el botón nos aparecerá la siguiente pantalla:

Diremos que si y obtendremos el código de programa donde indicaremos de donde se obtiene dicha información.

5.4 Eventos nuevos

Nos situamos sobre la carpeta eventos

y con el botón de crear nos aparece la siguiente pantalla, en la que indicaremos el identificador del evento, la denominación y la descripción:

Una vez creado el evento podemos asignarle parámetros. A través de los parámetros pasaremos la información al workflow.

Nos situamos sobre el evento y a través del botón nos aparece la siguiente pantalla:

Con el botón nos aparece, al igual que los atributos, la posibilidad de crear los parámetros a partir del diccionario ABAP.

Indicamos la tabla del diccionario y seleccionamos los campos correspondientes a los parámetros

Para cada campo indicamos el identificador, la denominación y el significado y con el botón crearemos el parámetro

Así tendremos los parámetros creados:

5.5 Métodos nuevos

Nos aparecerá la opción de crear el método como modelo de un módulo de funciones.

Si creamos el método como módulo de funciones deberemos indicar el módulo de función a utilizar como modelo, el nombre del método, la denominación y la descripción breve, y los atributos:

Pasamos a la siguiente pantalla donde nos aparecerán los parámetros del método, que se crearán automáticamente a partir de los imports, exports, y tablas de la interfaz del módulo de funciones:

con el botón vemos el código del método generado, donde podremos realizar las modificaciones que consideremos oportunas:

Si no creamos el método como modelo de un módulo de funcione nos aparecerá la siguiente pantalla:

En ella indicamos el nombre del método, la denominación, la descripción breve y los atributos.

En la pestaña ABAP identificamos a el método con el objeto a ejecutar: transacción, report,...

Una vez creado el método creamos los parámetros de la misma manera que lo hemos hecho para los eventos

Indicamos la tabla de base de datos y marcamos los campos que definirán los parámetros:

y así tenemos creados los parámetros:

Ahora debemos implementar el método, para ello nos situaremos sobre el nombre del método y con el botón nos aparece la siguiente pantalla:

Observamos que al haber definido los parámetros antes de la implementación, ya nos aparece en el método la definición de variables correspondientes a los parámetros. Igualmente se recuperan los valores de los parámetros, y son enviados a memoria según los campos de entrada en la transacción.

Aquí revisamos el código y realizamos las modificaciones que consideremos pertinentes.

5.6 Macros y Atributos

Las macros indicadas a continuación, nos permitirán en la instanciación de atributos y métodos, recuperar y asignar valores a las propiedades del objeto y a los parámetros de los métodos.

Los atributos creados aparecerán declarados de la siguiente manera en el programa asociado al objeto

Para los atributos que corresponden a objetos se declararán tipo SWC_OBJECT y los que corresponden a algún campo de una tabla de la Base de Datos, se define una variable _NombreTabla con estructura la tabla de la base de datos

5.6.2 Obtener valores de atributos de la base de datos

Definimos una variable con la estructura la tabla de la base de datos

Ejemplo: I_MARA like mara.

Realizamos la selección a la tabla según los criterios establecidos asignándolos a la variable definida.

Ejemplo: Select single * into I_MARA from MARA client specified

Where mandt = sy-mandt and Matnr = object-key-material.

Asignamos el valor de nuestra variable al atributo del objeto.

5.6.3 Obtener valores de atributos de tipo objeto

Ejemplo: Vamos a obtener los pedidos a los que pertenece un material

Definimos una variable de tipo objeto.

Ejemplo: DATA PORDER TYPE SWC_OBJECT.

Obtenemos los pedidos del material. Para cada pedido ( EBELN ) creamos su objeto con la macro SWC_CREATE_OBJECT &1 &2 &3 donde:

&1: Variable de tipo objeto &2: Nombre del objeto

Ejemplo: SWC_CREATE_OBJECT PORDER 'BUS2012’ EBELN.

Una vez creado el objeto, lo añadimos al atributo del objeto.

Ejemplo: APPEND PORDER TO OBJECT-PURCHASEORDER.

Una vez añadidos todos los pedidos, asignamos el valor al atributo con la macro

SWC_SET_TABLE CONTAINER &1 &2 &3 donde: &1: CONTAINER

&2: Nombre del atributo &3: Valores a asignar

Ejemplo: SWC_SET_TABLE CONTAINER 'PurchaseOrder'

OBJECT-PURCHASEORDER.

Observación:

Utilizaremos la macro SWC_SET_TABLE porque el atributo consta de varias líneas, si no utilizaríamos SWC_SET_ELEMENT

5.6.4 Recuperación atributos clave

Obtendremos los valores de los campos claves con la siguiente instrucción:

OBJECT-KEY-XXXXXXX donde XXXXXXX es el identificador del campo

clave.

Ejemplo: OBJECT-KEY-MATERIAL. 5.6.5 Recuperación parámetros de los métodos

Obtendremos el valor del parámetro de entrada con la siguiente macro

SWC_GET_ELEMENT &1 &2 &3 donde: &1: CONTAINER

&3: Variable a la que asignaremos el valor

Ejemplo: Método Edit con parámetro de entrada SKIP_1ST_SCREEN Observación:

Si el parámetro fuera de varias líneas utilizaríamos la macro SWC_GET_TABLE

5.6.6 Asignación parámetros salida método

Asignaremos valor al parámetro de salida con la siguiente macro

SWC_SET_ELEMENT &1 &2 &3 donde: &1: CONTAINER

&2: Identificador del parámetro de entrada &3: Valor a asignar

Observación:

Si el parámetro fuera de varias líneas utilizaríamos la macro SWC_SET_TABLE

5.7 Status tipo de objeto

Cada tipo de objeto y sus componentes puede tener uno de los siguientes Status:

 Modelado: no está todavía programado

 Implementado: el programa está implementado, pero la funcionalidad no está permitida

 Liberado: puede ser ejecutado.

 Obsoleto: el objeto no es vigente.

Modificaremos el status del objeto o del cualquier componente del objeto a partir del menú:

5.8 Instanciación de un objeto

Con el botón de crear instancia nos aparece una pantalla con los atributos clave del objeto

Una vez introducida los campos claves, nos aparece una pantalla con los atributos calculados y la opción de poder testear los métodos del objeto.

6 Definición general de WF

Un workflow está formado por diferentes pasos de procesos. Entre los pasos podemos distinguir de dos tipos básicos:

 Pasos que se refieren a actividades de negocio y/o diálogo: actividades y decisiones de usuario.

 Pasos para control interno del proceso workflow: condición, loop, operación de container.

La secuencia de proceso de los pasos dependerá del resultado de los pasos precedentes.

Workflow Builder es la herramienta para definir y modificar workflows. Crearemos

Los pasos puede ser uno de los siguientes tipos:

Así, en un workflow podemos definir procesos en paralelos, bifurcaciones, loops, etc…

En el Workflow Builder encontramos las siguientes opciones:

 Navegación

 Modularización en bloques

 Copiar, cortar, pegar y borrar

 Impresión (Detalle/Esquema)

 Verificación y activación

 Referencia al diccionario

Un workflow permite programación de Deadlines, pasos que tienen una fecha máxima de inicio, de finalización,...

Pasos de Implementación

1. Identificar los eventos estándar que lanzan en el proceso a modelizar con el Trace de Eventos.

2. Identificar los objetos estándar de dichos eventos y su estructura (atributos y métodos).

3. Identificar los modelos workflow que están ligados a dichos objetos y eventos. Partir de una copia de dichos modelos en caso de aproximarse a nuestra

funcionalidad.

4. Analizar en el proceso las diferentes tareas, qué se realiza en cada una de ellas y cómo reproducirlas mediante métodos o funciones estándar.

5. Identificar cuando y bajo que condicionantes se ejecutan las diferentes tareas. 6. Identificar cómo determinar quien es el responsable de cada paso.

7 Containers

Para que un workflow opere de forma consistente es necesario que los datos requeridos por el workflow, los eventos, las tareas, los roles y los métodos pasen de una entidad a otra.

Así, el container de un elemento (p.e.: de una tarea) es la interfase que sirve para pasar datos de una entidad a otra. Es similar a la interfase de un módulo de funciones. Así todos los elementos están encapsulados, aunque no todos los datos son visibles entre ellos.

Los containers son requeridos para almacenar la información en una estructura estándar.

Los containers los podemos encontrar en:

Container de la tarea: siempre contiene dos elementos principales:  _WI_Object_Id: almacena el objeto a procesar en la tarea.

 _WI_Actual_Agent: pasa el agente seleccionado y ejecutor al resto del Workflow

Container del workflow: siempre contiene un elemento principal:

 _WF_Initiator: almacena el nombre del usuario que inició el Workflow.

El resto de containers funcionan igual y en todos los casos es posible, si es necesario, añadir más elementos al container.

Flujo de datos Proceso:

Contenido:

Hay varias maneras de informar o modificar los datos del Container de un Workflow:

 Desde los elementos del container del evento Desencadenante.

 Con un paso de Operación Container

 Desde los resultados de una tarea

8 Tareas

Tenemos 4 tipos de tareas diferentes, englobadas en tareas simples y múltiples:

 Tareas Standard (TS)

Tareas simples ya existentes proporcionadas por SAP, independientes de mandante.

 Tareas Cliente (T)

Tareas simples dependientes de mandante

 Tareas Workflow (WF)

Tarea múltiple que engloba a varis tareas simples dependientes de mandante, definidas por el cliente en anteriores versiones.

 Modelos Workflow (WS)

Tarea múltiple que engloba a varis tareas simples independientes de mandante.

Observación:

A partir de la 4.6 sólo se permite crear Tareas Standard y Modelos Workflows. Las tareas simples son los elementos centrales del sistema workflow. Se utilizan en pasos de un Workflow de tipo Actividad. También pueden ejecutarse sin estar incluidas dentro de un Workflow.

Para definir una tarea es necesario haber definido previamente:

 Quien ejecutará la tarea

 Que trabajo debe realizar

 Que mensaje debe enviar

Podemos crear una tarea desde el menú SWLD, en la carpeta Herramientas de definición, en Tareas/Grupos de Tareas

Ejemplo: Crearemos una tarea simple que visualice la lista de material de un

material.

Introducimos el tipo de tarea que deseamos crear y con el botón pasaremos a definir las propiedades de la tarea.

En esta pantalla introducimos el nombre de la tarea (sigla), y su descripción

(denominación) y se le asigna un objeto y un método de ese mismo objeto que será la acción a realizar por esta tarea.

Ejemplo:

Del objeto creado ZBUS1001 asignamos el método ListaMat.

Una vez asignado el método el sistema nos pide adaptar automáticamente los elementos del método.

De esta manera SAP detecta automáticamente los parámetros definidos en el método y crea las definiciones necesarias en los parámetros de la tarea (container).

De esta manera podremos pasar los datos de la tarea al método.

Definir texto Tarea

En el campo Texto de WorkItem introducimos una breve descripción de la tarea. Dicha descripción es la que le aparecerá al usuario en el inbox, como pasos pendientes de ejecutar.

En esta descripción podemos añadir variables del sistema, información de la tarea. Lo haremos de la siguiente forma:

Nos situamos dentro del campo Texto WorkItem en la posición en la que deseamos que aparezca el dato nuevo y pulsamos el botón . Nos aparecerá la siguiente pantalla:

Seleccionamos el dato a introducir, por ejemplo: el código del material correspondiente al objeto ZBUS1001 que definía el método a ejecutar. Y el dato nos aparece en el texto WorkItem.

Pasar valores

El método asignado a la tarea puede tener creados parámetros de import y export necesarios para ejecutar la acción especificada en el código del método. Estos parámetros serán informados a través de los datos del container de la tarea. Pasaremos dichos datos de la siguiente manera:

En esta pantalla definimos el traspaso de información de la tarea al método previa a la ejecución de la acción y del método a la tarea una vez se haya finalizado la acción.

Ejemplo: Paso de parámetros de la tarea al método ListaMat

Sobre los campos situados en los datos de la tarea, con la ayuda podemos obtener la información que es posible traspasar. Seleccionamos el código de material

Realizamos la misma acción pero en los datos correspondientes al método, y seleccionamos también el material.

También podemos realizar esta acción situándonos sobre el elemento a asignar y arrastrando el ratón hasta el lugar de asignación.

Realizamos la misma acción para el resto de parámetros del método: centro y utilización de la lista y el resultado es el siguiente:

Descripción de la Tarea

El usuario una vez recibe el workitem en su inbox, si acepta el workitem le puede aparecer información más detallada sobre la tarea a realizar. Esta información la indicaremos en la descripción de la tarea.

Para incluir información del container de la tarea, nos situamos en la posición en la que deseamos incluir la información y por el menú:

Nos aparece una pantalla con toda la información posible que podemos añadir:

Eventos desencadenantes

En una tarea podemos definir que evento de un objeto puede desencadenar dicha tarea.

De la misma manera que en el método con el botón pasaremos la información del evento a la tarea:

Una vez asignado el evento desencadenante es necesario activarlo. Para ello nos situaremos sobre el rombo gris y haremos doble-click. Una vez activado nos aparecerá un círculo verde.

Responsable de la tarea

Asignaremos los agentes posibles desde Datos adicionales – Asig. Responsables –

Actualizar, es decir especificaremos que usuarios recibirán y podrán ejecutar en

principio la tarea ( workitem ).

 Tarea específica: algunos elementos de la estructura organizativa

 Tarea general: cualquier usuario SAP será posible ejecutor del workitem

Ejecución en fondo:

Que una tarea se ejecute en fondo dependerá de la definición del método.

Confirmación fin de procesamiento:

Si se selecciona esta opción, después del tratamiento de este paso el sistema espera confirmación explícita del fin del tratamiento. Permite añadir un anexo o tratar un objeto con el mismo método en varias ocasiones (Ejemplo: modificar pedido).

8.2 Creación Workflow

Partiendo de la misma opción de menú que la creación de tareas simples, podemos crear circuitos workflow.

Indicaremos en el campo tipo tarea ‘Modelo workflow’.

Indicar, que muchas de las opciones explicadas para las tareas simples, son aplicables a los workflows.

Ejemplo: Vamos a crear un workflow que visualice la lista de material utilizando la

Con el botón obtenemos la pantalla donde indicaremos el identificador de workflow, denominación y texto del workflow.

En ella indicamos el tipo de objeto y el evento, que cuando sea disparado en el sistema, debe provocar que se inicie el workflow.

creamos un elemento que sea de tipo objeto y correspondiente al tipo de objeto del evento que desencadena el workflow:

Cuando explicamos la creación de eventos para un tipo de objeto, vimos que se podían asociarle parámetros. Si deseamos que esta información sea traspasada al workflow, debemos crear en el container del workflow, elementos definidos de la misma manera que en el evento.

Ahora vamos a ver como traspasar la información del container del evento al container del workflow.

Con el botón de flujo de datos , obtenemos la pantalla de siempre para

intercambio de información donde indicaremos los valores a traspasar del container del evento al container del workflow.

Volvemos a la pestaña de datos básicos para acceder a la pantalla de definición del workflow, a partir del Workflow Builder.

Hacemos doble-click sobre el paso indeterminado, y nos aparece una lista de los posibles tipos de pasos a asignar.

Como ejemplo, vamos a crear un paso de tipo actividad para asignar la tarea simple creada en el apartado anterior que nos permitía visualizar la lista de material para un material dado.

Obtendremos la pantalla siguiente donde indicaremos la tarea correspondiente al paso:

Una vez indicada la tarea, el sistema nos propone crear automáticamente el flujo de datos entre el workflow y la tarea:

Una vez comprobado y aceptado el flujo de datos que nos propone el sistema, obtenemos la pantalla de definición de flujos de datos para realizar las

Volvemos a la pantalla de definición y asignación de la tarea para asignar el responsable:

Observamos las diferentes maneras que tenemos de asignar o determinar responsables. Asignamos por ejemplo un usuario de SAP

Grabamos el workflow y realizamos su verificación a través del botón obteniendo en la parte inferior el resultado de la verificación

Igualmente lo activamos con el botón obteniendo el resultado sobre su activación

A continuación activaremos el evento desencadenante para que el workflow sea iniciado en cuanto sea disparado el evento.

8.2.1 Pasos de varias líneas

Habrá pasos que nos interese que se ejecute un número indeterminado de veces, en función de los valores que tenga un elemento del container de varias líneas.

Ejemplo:

En el workflow definido para visualizar lista de materiales de un material y centro, nos podría interesar visualizar todas las listas de material para un material y para todos los centros en los que estuvieran dadas de alta estas listas.

Para ello es necesario tener definido en el container del workflow un elemento de varias líneas correspondiente al tipo de dato que nos va a determinar el número de pasos a ejecutar.

En nuestro ejemplo definimos un elemento Centro correspondiente al campo MAST-WERKS

En el campo Elemento de varias líneas indicamos el elemento del container de varias líneas que nos va a determinar el número de veces que ejecutaremos este paso.

y volvemos al flujo de datos

y al elemento de la tarea le asignamos el elemento del container de varias líneas correspondiente.

En el ejemplo: al elemento del container de la tarea Plant le asignamos el elemento del container de workflow Centros

y observamos que existe un elemento que pone centros() que corresponde al Índice de Centros. Debemos asignar este elemento en el flujo de datos.

Un vez volvemos a la definición del workflow observamos que el paso aparece como varios pasos superpuestos.

9 Roles

Los Roles sirven para asignar la responsabilidad de ejecución de una tarea, a una persona de forma dinámica y restringir el número de agentes posibles de una tarea. Hay veces en que las responsabilidades para procesar una tarea son especificadas en tiempo de ejecución en función de los valores que tengan unos parámetros

determinados, parámetros de rol. Los roles pueden ser:

 de módulo de función de ABAP/4

 de competencia

 de Objetos Organizativos

Al asignar un rol a un paso con tarea, el rol devuelve uno o más usuarios, que de no coincidir con ninguno de los agentes posibles asignados al definir la tarea, provoca el fin del Workflow ( stop ) => no existen agentes seleccionados.

Cada uno de los agentes seleccionados recibirá en su inbox el mismo Workitem de la tarea. El primero que lo procese se quedará con él y desaparece del resto de inboxs automáticamente.

Observación:

Normalmente se definirá la tarea como Tarea General, y la asignación de responsable se realizará en el mismo paso de Workflow en que se ejecuta esta tarea.

Los roles también reciben los siguientes nombres:

 de funciones standard

 de reglas p.asignación de responsables

9.1 Creación de papeles

Observación:

Pondremos como ejemplo la creación de un papel para determinar el responsable de un centro dado.

Desde el menú de workflow, en la carpeta de Herramientas Def.

Con el botón de crear obtenemos una nueva pantalla:

En los datos básicos indicaremos la sigla que nos identificará la regla y una descripción de la regla.

Si desplegamos la ayuda del Tipo de regla obtenemos todos los tipos que podemos definir:

Estudiaremos las siguientes:

 F: Determinación responsable: Función a ejecutar  R: Determinación responsable: Competencias 9.1.1 Función a ejecutar

Una vez se ha asignado el tipo F como regla nos aparece un nuevo campo en el que informaremos de la función que según los valores del container del papel determinará los responsables del paso o de la tarea.

La función deberá tener los siguientes parámetros

donde

 ACTOR_TAB: Aquí indicaremos los responsables calculados según la información obtenida de AC_CONTAINER.

Actor_tab tiene la estructura SWHACTOR, así en el campo OTYPE indicaremos el tipo de responsable ( Usuario, Posición, … Ver Unidad Organizativa ), y en el campo OBJID indicaremos el identificador del responsable.

 AC_CONTAINER: De aquí obtendremos la información necesaria para determinar los responsables a informar en ACTOR_TAB.

Ejemplo:

 INCLUDE <CNTAIN>: Include en el que tenemos las macros necesarias para leer y pasar datos del container.

 SWC_GET_ELEMENT AC_CONTAINER ‘Centro’ Centro:

Obtenemos del container la información necesaria para determinar los responsables

 RESULT_TAB-OTYPE = ‘US’: Indicamos que el responsable será un usuario.

 CASE CENTRO… ENDCASE: Según el centro dado asignamos un

usuario.

 APPEND RESULT_TAB TO ACTOR_TAB: Una vez hemos obtenido los responsables los añadimos a la tabla ACTOR_TAB.

Ahora debemos definir en el container los elementos correspondientes a la

información necesaria para determinar los responsables, en nuestro caso en Centro

9.1.2 Competencias

Definimos en el container los elementos correspondientes a la información necesaria para determinar los responsables, en nuestro caso el Centro

Una vez definidos los elementos del container, pasamos a definir las

competencias. Las competencias corresponden a las combinaciones de valores que pueden tener los elementos del container. A cada combinación se le asignará un responsable.

Con el botón nos aparece la siguiente pantalla, en la que identificamos la competencia a crear y asignamos un periodo de validez:

Grabamos y nos deberá aparecer la competencia como completa.

Volvemos a la pantalla principal y creamos tantas competencias como necesitemos para la asignación de responsable.

Observación:

Cuando indiquemos * en el valor de un elemento del container, querremos indicar todos los valores posibles.

Asignación de responsable

Nos posicionamos sobre la competencia a la que vamos a asignar un responsable:

Con el botón nos aparece la siguiente pantalla en la que seleccionamos el tipo de responsable a asignar:

En el ejemplo seleccionamos usuario y nos aparece una pantalla en la indicaremos el usuario:

Pasamos a la siguiente pantalla en la que indicaremos el periodo de validez del responsable

y con el botón tendremos creada la asignación de responsable. Procederemos igual con el resto de las competencias.

10 Supervisión de fechas

El sistema de tiempo de ejecución de workflow permite la supervisión de las siguientes fechas:

 Fecha de inicio deseada (modelo):

En la fecha de inicio deseada, el sistema de tiempo de ejecución cambia el status del workitem de "esperando" a "dispuesto".

 Fecha final deseada:

El tratamiento del workitem debe haber finalizado antes de la fecha final deseada. Esta fecha se alcanza cuando el workitem pasa al status "finalizado".

 Fecha de inicio más tardía (inicio de tratamiento más tardío):

El tratamiento del workitem debe haber comenzado antes de la fecha de inicio más tardía.

Esta fecha se alcanza cuando el workitem pasa por primera vez del status "dispuesto" al status "aceptado" o "en tratamiento".

 Fecha final más tardía (plazo):

El tratamiento del workitem debe haber finalizado antes de la fecha final más tardía.

Esta fecha se alcanza cuando el workitem pasa al status "finalizado".

Clasificamos los pasos de workflow con supervisión de fechas según el tipo de gestión en:

 Simples: si se alcanza alguna de las fechas límite, se envía un mail al agente de Deadline y no se modifica el status del Workitem

 Modelados: si se alcanza alguna de las fechas límite, se procesan acciones alternativas:

o Debe incluirse una rama alternativa de Procesamiento obsoleto. o Después del evento Fecha límite alcanzada, debe incluirse un paso de

Control de Proceso, que se encarga de marcar como obsoleto al Workitem inicial.

Todo esto lo definiremos en la definición de un paso de workflow en las pestañas Fecha

Ejemplo:

El proceso de validación de viaje de un empleado en un workflow no debe exceder de 7 días. Pero una de las tareas no ha sido procesada en 8 días. Podemos finalizar el paso a través de los deadlines.

Control de deadlines

Veremos en el apartado monitorización y análisis como revisar los pasos de workflow con control de fechas.

11 Eventos

Por regla general, se deseará que se inicie un workflow o una tarea cuando una acción concreta es realizada en el sistema. Para ello SAP dispone de señales, llamadas eventos

(desencadenantes), que se pueden parametrizar para que sean enviadas al realizar la

acción realizada.

El evento desencadenante (triggering event) es aquel capaz de disparar una tarea o un Workflow. El evento debe estar definido en el Tipo de Objeto, por tanto se identifica por el nombre y el tipo de objeto.

Un evento se disparará:

 Por código explicito en la aplicación

 Por parametrización explícita

 Por lanzamiento explícito a través de una user-exit.

Encontramos el menú de definición de eventos en:

SAP permite lanzar eventos desde una aplicación cuando se produce la creación, modificación o el cambio de status de un objeto de dicha aplicación. Todo ello se puede realizar sin modificar el estándar.

Ejemplo: Creación de un material. Modificación de un pedido. Creación de un empleado.

Cambio de status en una orden de fabricación. Podremos realizar la generación de eventos en el siguiente menú:

11.2 Modificación de datos maestros de personal

Cuando sobre algún objeto o figura de Recursos Humanos ( p.e.: candidato, empleado, posición,... ) se realiza alguna acción (crear, modificar, borrar, ...), SAP permite lanzar un evento según sea el caso.

Debemos seguir los siguientes pasos:

1. Acoplam. Tipos objeto a infotipos HR

Debemos asociar el objeto de recursos Humanos y el infotipo/subtipo asociado a dicho objeto a un Tipo de Objeto.

Ejemplo:

Objeto HR: AP ( Candidato )

Infotipo: 4000 ( Medidas Candidatos )

Subtipo: Se puede dejar vacío

2. Evento – Operación Infotipo ( SAP )

Sobre los infotipos/subtipos se realizan diferentes operaciones: crear registro, borrar registro,…

En esta pantalla podemos definir para los Objetos/infotipos/subtipos/operación que evento del tipo de objeto asignado en el primer paso deseamos que sea lanzado.

Ejemplo:

Objeto HR: AP ( Candidato )

Infotipo: 4001 (Solicitudes de empleo )

Subtipo: Se puede dejar vacío

Operación: DEL

Tipo Objeto: APPLICATIO ( Candidato )

También se pueden asignar eventos de forma dinámica a través de funciones.

Ejemplo:

Objeto HR: AP ( Candidato )

Infotipo: 4000 ( Medidas candidatos )

Subtipo: Se puede dejar vacío

Operación: DEL

Tipo Objeto: APPLICANT ( Candidato )

Función: HR_EVENT_RULES_PB4000

Las funciones que asignemos en este apartado debe tener la siguiente estructura

FUNCTION HR_EVENT_RULES_PB4000.

*"--- *"*"Lokale Schnittstelle:

*" IMPORTING

*" VALUE(AFTER_IMAGE) LIKE PRELP STRUCTURE PRELP *" VALUE(BEFORE_IMAGE) LIKE PRELP STRUCTURE PRELP *" VALUE(BUSINESSOBJECT) LIKE SWOTBASDAT-OBJTYPE *" VALUE(OPERATION) LIKE T779W-WFOPR

*" EXPORTING

*" VALUE(EVENT) LIKE SWETYPECOU-EVENT *" TABLES

*" EVENTS_PER_OPERATION STRUCTURE EVENTPOPER OPTIONAL *"--- DATA: BEFOREIMAGE LIKE P4000.

BEFOREIMAGE = BEFORE_IMAGE. AFTERIMAGE = AFTER_IMAGE.

* Status changes by 'update' or 'delete' IF NOT BEFOREIMAGE-PERNR IS INITIAL.

* Changed status only when BeforeImage exists IF BEFOREIMAGE-APSTA NE AFTERIMAGE-APSTA. CASE AFTERIMAGE-APSTA.

WHEN '1'. EVENT = 'INPROCESSING'. WHEN '2'. EVENT = 'HIRED'.

WHEN '3'. EVENT = 'ONHOLD'. WHEN '4'. EVENT = 'REJECTED'.

WHEN '5'. EVENT = 'CONTRACTOFFERED'. WHEN '6'. EVENT = 'OFFERREJECTED'. WHEN '7'. EVENT = 'TOBEINVITED'. ENDCASE.

ENDIF."beforeimage-apsta ne afterimage-apsta ELSE."BeforeImage is initial ==> new entry EVENT = 'CREATED'.

ENDIF. ENDFUNCTION.

3. Evento – Operación Infotipo ( clte. )

En este apartado realizaremos las mismas parametrizaciones que en el apartado anterior pero para infotipos propios de cliente.

11.3 Documentos de modificación

Un evento puede ser disparado cuando un objeto es modificado, creando un documento de modificación. Por ejemplo, pedido de ventas.

Para ello debemos seguir los siguientes pasos:

1. Resumen

Una vez identificado el objeto de modificación correspondiente verificaremos que se encuentra en esta relación de objetos de modificación.

2. Acoplamiento

En este apartado asociamos a cada objeto de modificación un tipo de objeto con el evento a disparar, y sobre que acción se debe disparar, si al crear, al modificar o al borrar.

Una vez asignado el evento, podemos restringir el disparo del evento según que campos se han modificado y de los valores que hayan tomado.

11.4 Gestión de Status

Un evento puede lanzarse cuando camina el status de un objeto.

Ejemplo:

Pasar una orden de fabricación a cierre técnico.

En la siguiente pantalla aparecerá dos botones con el mismo texto:

Parametrizaciones de

El primer botón corresponde a status de sistema, propios de SAP. El segundo botón corresponde a Status de usuario, definidos por el cliente. En los dos casos se

Status de sistema

En esta pantalla asociamos el tipo de objeto del status con el tipo de objeto de negocio y el evento a lanzar

Ejemplo:

TOstatus: ORI ( Orden PM/SM )

TOBusiness: BUS2007

Podremos restringir el lanzamiento del evento según el valor del status.

11.5 Otras maneras de lanzar un evento

 Control de mensajes: la determinación de mensajes puede ser usada para lanzar eventos. Ej. Clase de mensaje EVEN

 Mensajes de error: lanzar un evento si se produce cierto error. Ej. Error al grabar un CC-nómina en el infotipo 0008.

 Simulación: a través de la transacción SWU0 podemos instanciar y simular un objeto

 Creación evento: a través de la transacción SWUE podemos lanzar el evento de un objeto instanciado.

11.6 Acoplamiento de eventos

Disparado un evento, para que se inicie el workflow es necesario que el evento esté activado. Esto se puede definir, tal como hemos visto, en la definición del workflow activando el evento desencadenante.

Pero también se puede definir en esta opción. En ella encontramos un listado con los tipos de objeto y eventos, y los workflows o tareas para los cuales estos eventos son sus eventos desencadenantes. En acoplamiento tipos nos indica si el evento está activado o no.

Marcando el registro que nos interesa,

Si visualizamos el detalle obtenemos las características del acoplamiento para poderlas modificar

Observamos que podemos indicar un módulo func. Verif. Esta función nos permitirá según criterios establecidos lanzar o no el workflow.

Esta función deberá tener la siguiente interfaz:

*"--- *"*"Lokale Schnittstelle:

*" IMPORTING

*" VALUE(OBJTYPE) LIKE SWETYPECOU-OBJTYPE *" VALUE(OBJKEY) LIKE SWEINSTCOU-OBJKEY *" VALUE(EVENT) LIKE SWEINSTCOU-EVENT *" VALUE(RECTYPE) LIKE SWETYPECOU-RECTYPE *" TABLES

*" EVENT_CONTAINER STRUCTURE SWCONT *" EXCEPTIONS

*" NO_RECTYPE *" ...

*"---Evitaremos que se lance el workflow a través de las excepciones.

11.7 Condiciones de inicio

Con esta opción también podemos, según criterios establecidos, lanzar o no un workflow.

Obtenemos esta pantalla:

Indicamos el tipo de objeto correspondiente al evento del workflow sobre el que queremos definir condiciones de inicio.

Con el botón nos aparecen los workflows para los cuales este evento esta acoplado y activado.

Hacemos clic en el workflow deseado y aparece pantalla donde definir el criterio según el cual se iniciará el workflow.

12 Asistentes

SAP provee de unos asistentes (Wizards) para facilitar la construcción y definición del Workflow:

 Informando un mínimo de datos en una serie de pantallas definimos un flujo completo.

 Se asegura la consistencia del proceso insertado

 Soporta programación de loops, vencimientos de fechas, procesos paralelos y otros.

 Su ruta es: Desarrollo -> Herramientas Def. -> Asistentes -> Repositorio.

Wizards importantes:

 Incluir ‘Enviar Mail’.

 Incluir ‘Ejecutar Report’.

 Modelización de vencimiento de fechas.

13 Customizing

La parametrización del workflow la encontraremos en la transacción SPRO en:

13.1 Parametrización automática

SAP permite parametrizar de forma automática y sencilla las opciones necesarias para definir y ejecutar workflows.

Ejecutando esta opción nos aparece una lista con las opciones que hace falta parametrizar:

Sobre cada opción y con el botón parametrizaremos cada apartado

13.2 Prefijos

Es necesario definir los prefijos que se utilizará para asignar código a las tareas, workflows y papeles.

14 Monitorización y análisis

Una vez implementados los procesos workflow deberemos realizar un trabajo de administración. Esto consistirá en lo siguiente:

Control de los distintos status de los WI’s:

 WAITING: WI con fecha de comienzo aún no alcanzada.

 READY: WI aparece en el Inbox de los responsables seleccionados.

 SELECTED: WI reservado por uno de los responsables.

 STARTED: WI en tratamiento.

 COMMITED: WI ejecutado correctamente pero necesita ser completado manualmente.

 ERROR: WI erróneos.

 COMPLETED: WI ejecutado con éxito.

Existen una serie de reports estándares que sirven para monitorizar y/o analizar los flujos del proceso y los datos generados en tiempo de ejecución en el sistema Workflow.

14.1 Workflows para objetos ( SWI6 / SWI14 )

Transacción SWI6

Este listado nos permite obtener los workitems para un objeto y su clave.

Ejemplo:

Vamos a obtener el listado de todos los workflows del objeto ZBUS1001 para el material ( clave de objeto ) 000001

En la siguiente pantalla introducimos el objeto y su clave, así que otros criterios que nos acota la selección:

Observación:

Para versiones de SAP anteriores a la 4.7, para poder ejecutar este listado es muy importante que el tipo de objeto tenga la interfase IFFIND creada.

Transacción SWI14

Tiene la misma funcionalidad que la anterior pero sin indicar la clave del objeto.

14.2 Análisis de Workitems

Estos listados nos muestran los workitems de una tarea y los workitems de un workflow, según unos criterios.

Nos proporciona información sobre: historial, log. Técnico, mensajes de error y procesos en la definición del workflow.

14.2.1 Workitems por tarea ( SWI2_FREQ )

14.2.2 Análisis workload

A partir de esta opción podemos averiguar los workflows ejecutados o pendientes de ejecutar por diferentes responsables

En esta pantalla indicaremos el responsable:

14.3 Trace eventos

Para saber si un evento es disparado por el sistema, podemos averiguarlo a través del Trace de Eventos.

Primero tenemos que activar el trace de eventos en la opción de menú

Podemos restringir el control del trace con el botón y a través de los siguientes criterios:

Con la opción del menú Visualizar trace de eventos obtendremos el listado de los eventos lanzados.

obteniendo el siguiente listado:

14.4 Gestión

Este apartado nos permitirá administrar los workflows del sistema. Lo encontraremos en:

Supervisión de plazos workitem

En este apartado parametrizaremos los jobs que controlarán aquellos pasos de workflow que tengan control de tiempo

Supervisión error workitem

En este apartado parametrizaremos los jobs que controlarán el relanzamiento de workflows que hayan quedado en status erróneo.

Reorganización

En este apartado realizaremos el archivado de los workitems de workflows antiguos.

Obtendremos el listado de workitems con vencimiento de fecha

Ejecutar workitems sin verif.responsable

Obtendremos un listado de los workitems pendientes de ser ejecutados, y tendremos la opción de ejecutarlos aunque no seamos ninguno de los responsables posibles.

Reanudar workflow tras error

Obtendremos un listado con todos los workflows erróneos con la posibilidad de volverlos a ejecutar.

Monitor RFC de workflow

Puede que en raras ocasiones nos encontremos con un problema de RFCs no procesados. En este caso deberemos planificar un job que ejecute el report

RSARFCEX cada 30 minutos. Este report relanza los RFCs no ejecutados.

15 Sistemas de Información (WIS)

El sistema de información de workflow, a partir de ahora WIS, en un reporting basado en datos sumarizados.

El WIS posee sus propias tablas, y sólo se aplica a workitems completados. Sus daos permanecen a pesar de archivar los originales.

15.1 Configurar el WIS

 Extender ‘Estructura de Comunicación’ del diccionario MCWF_TRANS. Transacción MCAM.

 Programar la ‘User Exit’ ( EXIT_SAPLMCWF_001 ) y activarla. Transacción

MCAN.

 Crear un ‘Catálogo de Campos’ que podrán ser Características, Tiempo o Estructuras Clave. Transacciones MC18, MC19, MC20.

 Crear ‘Estructuras Info’. Transacciones MC21, MC22, MC23.

 Definir las ‘Reglas de Actualización’ entre la Estructura de Comunicación y la Estructura info. Transacciones MC24, MC25, MC26.

15.2 Rellenar el WIS

Podemos Transferir ( MCAR ), Corregir ( MCAQ ) y/o Borrar ( MCAP ) datos. La transferencia de datos debe realizarse periódicamente mediante un job cuyas ejecuciones no deben superponerse.

15.3 Consultar el WIS

Mediante el menú MCA1 se puede acceder a todos los reports de consulta. El sistema de información workflow lo encontramos en el menú de workflow en la carpeta Reporting

16 Business Wokplace

Los pasos de diálogo de un workflow, aquellos pasos que deben ser ejecutados por sus responsables, los encontraremos en el Business Workplace de cada usuario responsable de dichos pasos.

El Business Workplace es el sistema de mensajería interno de SAP, que presenta el siguiente aspecto:

Para ejecutar un workitem lo haremos a través del botón

16.1 Anexos

Podremos añadir comentarios a cualquier workitem de la siguiente manera:

En la siguiente pantalla, escribiremos el comentario deseado:

Grabamos y volvemos a la pantalla principal del Workplace. Observamos que al lado del workitem al que hemos anexado el documento, nos aparece el símbolo . Este símbolo nos indica que tiene documentos anexados.

Igualmente en el apartado de objetos y anexos tenemos todos los documentos anexados.

Observación:

Si deseamos anexar un documento ( word, excel, ... ), en la pantalla de cabecera del documento utilizaremos el botón para indicar donde encontraremos dicho documento.

16.2 Transmisión de workitems

Podemos traspasar un workitem a otro usuario, para ello nos situamos sobre el workitem y con el botón o apretamos el botón derecho del ratón y elegimos la opción transmitir:

En la pantalla siguiente indicamos el responsable al cual deseamos enviar el workitem y damos al botón de aceptar:

Así el workitem desaparece de nuestro inbox y aparece en el del nuevo usuario. Para cambiar el tipo de responsable al cual transmitir el workitem, pulsaremos el botón , apareciendo una lista con los posibles tipos de responsables.

16.3 Suplencias

Un usuario responsable de un workitem, si por carga de trabajo o por estar de vacaciones, quiere que sus workitems aparezcan en el inbox de otro usuario puede hacerlo creando y activando una suplencia.

Podemos crear una suplencia a través del siguiente menú:

Nos situamos sobre sustituto personal y con el botón aparece la pantalla en la que indicaremos el usuario que puede asumir la suplencia:

Aceptado el usuario, en la siguiente pantalla indicamos el periodo de validez de la suplencia y si la activamos o no: