Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Workflow

No description
by

Silvia Soto

on 15 December 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Workflow

– Asignar un nombre y descripción a la tarea
– Asociar un método de un business object a la tarea
– Si o si debe tener asignados los posibles agentes, marcada como tarea general
– 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.
– El texto de la tarea servirá para informar de las actividades al usuario
– Debe estar asociada a un método marcado como de “dialogo”
– 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)
– La comunicación entre las tareas y los métodos es:
Bidireccional
Se pasan parámetros
Resultados
Excepciones


• 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)
• Acceso al Workflow Builder
– Transacción SWDD
• 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.
• Al finalizar la contrucción del workflow es necesario ejecutar la Trx. SWU_OBUF para refrescar los cambios.
• Trabajando con la Estructura Organizativa

– Cada agente en el sistema de workflow debe tener un user ID de SAP.

– Desafortunadamente mantener usuario por usuario todos los agentes es una tarea excesivamente tediosa, 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.

¿Es necesario el plan organizativo para el sistema de workflow?
– 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.
– Los agentes responsables son aquellos que queremos para que ejecuten un work item “en particular”.
– 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).
– La 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

– Para la configuración de responsables pueden usarse:
Elementos de la estructura organizativa
Elementos del contenedor del workflow
Trx. SWDD
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.
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.
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 “aceptar” el work item.” Si esto ocurree,actualize el entorno organizativo en el Business Workplace.
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 item sea accesible para usuarios que no estaban configurados como “receptores” de dicho work item en un principio.

Detalles del
worklist

Como paso inicial para la instalacion de la herramienta de Workflow, se deben ejecutar los siguientes pasos: (Se realiza por unica vez con la instalación de SAP)

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

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 un usuario batch para las tareas que deben ejecutarse por el sistema
Definir uno o mas usuarios responsables del sistema workflow (adm.)
Crear los jobs para la supervisión de tareas vencidas y erróneas

El sistema de workflow viene con una herramienta muy útil para configurarlo automáticamente que 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 debemos repasar a mano algunas configuraciones e Iniciar el workflow para verificar el correcto funcionamiento.

SAP Workflow
Ventajas del Workflow
Terminología de Workflow
Existen 5 preguntas claves para definir un proceso de negocio

Introducción
Para los usuarios
Tan pronto como una tarea sea asignada a él, se le enviará electrónicamente a su inbox.

El sistema workflow lleva al usuario directamente a la transacción o aplicación para transaccionar.

El usuario recibe la información e instrucciones necesarias para llevar a cabo la tarea.

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 de negocios al automatizarlos

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

¿Qué es Workflow?

Los sistemas de workflow son herramientas que permiten la implementación técnica de procesos de negocio.

El flujo de trabajo es controlado y coordinado activamente por el sistema de workflow.

Permiten dar soporte y agilizar el proceso de negocio ganando tiempo.

Permite a la gente involucrada llevar a cabo procesos de negocio complejos independientemente del tiempo y el lugar.

Se integra completamente con las funciones de negocio 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.
¿Quién?
El quién o quienes pueden o deben realizar la tarea, lo define el Agente

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.

Luego se definen los agentes responsables. El agente responsable es quien recibirá la tarea en su Business Workplace y se determina en tiempo real.

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

¿Cuándo?
¿En qué
orden?
¿Cómo?
¿Qué?


Que es lo que se debe realizar, lo define la "Tarea"

Una tarea puede ser:
Ejecutar una transacción, ejecutar un reporte, tomar alguna decisíon, etc.
Generación y envío de documentos
Control de flujo del proceso.

Las tareas 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.

Cuándo debe realizarse la tarea por parte del agente lo define los eventos.

Los eventos informan al workflow que algo ha sucedido. El workflow a su vez puede reaccionar al evento y de esa forma disparar una o mas tareás dependientes del evento.

Los eventos se "publican" para que puedan ser evaluados por el workflow.

Dentro de la definición del workflow pueden existir pasos que impliquen esperar por un evento y otros pasos que permiten generar eventos
El orden del flujo de proceso lo define el "Workflow"

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 cómo debe realizarse la tarea, lo define los objetos de negocio.

Los componentes de un objeto de negocio 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 sobre los tipos de objetos para iniciar, finalizar o marcar eventos en el workflow.

Arquitectura del Workflow
Customizing
Desarrollo BO
Workflow
Builder

Determinación
de
Agentes

Eventos
Administración
Business
Workplace
y UWL

Customizing de Workflows Standards
Asignar tareas a responsable
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).

Activar acoplamiento de eventos
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.

El acceso al customizing de workflow desde la SPRO se alcanza a través del siguiente paso:
IMG->SAP Netweaver->Servidor de aplicación->Business Management->SAP Business Workflow

La configuración de los workflows estándar de SAP consiste 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 “Ejecutar customizing específico de tareas” y también se puede acceder directamente desde la tx. OOCU
Rango 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 verificar la versión activa del plan (que se configuro mediante la configuración automática)

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

Prefijos para objetos estándar

Al desarrollar workflows nuevos (workflows, tareas, papeles, etc.) el sistema asignara un numero interno al objeto desarrollado el cual debe ser univoco entre todos los sistemas.

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.

Jobs
Existen 2 jobs que deben programarse para monitorear tareas vencidas y erróneas. El primero que configuraremos es el de tareas vencidas (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.

En este punto se debe definir y crear un usuario batch para las tareas que deben ejecutarse por el sistema.

Por lo general este usuario tiene el nombre WF-BATCH y tiene asignado un rol de SAP_ALL

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).


¿Qué NO es Workflow?

Un sistema de gestión de documentos (trabaja con ellos)

Un sistema de e-mail (trabaja con ellos)

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

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á)
Ejemplo:
Proceso de evaluación de empleados.
Proceso de solicitud de cursos.
Ejemplo:
Solicitar aprobación de vacaciones
Aprobar / Rechazar solicitud de vacaciones
Realizar evaluación de un empleado
Realizar autoevaluacion por un empleado
Ejemplo:
Empleado:
Solicitar aprobación de vacaciones
Realizar autoevaluación
Supervisor:
Aprobar / Rechazar solicitud de vacaciones
Realizar evaluación de un empleado
Ejemplo:
Cuando RH crea y asigna las evaluaciones de desepeño a los supervisores, se publica un evento el cual el workflow lo interpreta como un cambio de estado de la evaluación y crea una tarea para que el supervisor (agente responsable) realice la valoracion de los objetivos de la evaluación.
Arquitectura de un workflow para un proceso de negocio
Objetivo
Explicar las distintas herramientas utilizadas para extraer información sobre el sistema de workflow.

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.

Reporte de Workflow
Toda la información sobre procesos de workflow esta disponible en la base de datos de SAP ECC, y puede ser evaluada usando informes entandar o informes específicos de cliente.

Existen diferentes informes para informar sobre el sistema de Workflow.

Análisis de Carga
El análisis de carga de trabajo brinda una visión de seguimiento del trabajo que ha sido realizado 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 -> Reporting -> Análisis carga de trabajo (SWI5)

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.

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.

Workflow Logs
Vista Crónica
La pestaña de Workflow log de workflow (ActiveX) muestra en vista jerárquica todos los pasos del workflow, cuales ya han sido procesados. 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 work items.
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

Vista Gráfica
Los pasos de workflow ya procesados son marcados en una vista gráfica de la definición de workflow.
Permite decir a primera vista que “ruta” tomo el workflow 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.

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).

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.

La presentación es dependiente del modo que haya escogido el perfil de usuario de workflow.
Problemas Comunes
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).

Un problema típico que un workitem puede tener es:
Un workitem con status “erroneo” y el mensaje “el Objeto no existe”.
Este problema puede ser resultado de 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).

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.

Herramientas para el
Análisis de Problemas
Customizing en el
sistema workflow
Rastreo de Eventos ( SWELS - SWEL )
Usuario genérico para la
ejecución del workflow
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!

Iniciar Eventos Manualmente
(SWU0 - SWUE)
Otros Reportes y Herramientas
Importantes
SWI2_ADM1: Workitems sin responsables

SWI2_DEAD: Workitems con fechas vencidas

SWIA: Ejecutar workitems sin responsables

SWPR: Reanudar workitems tras errores

SWPC: Reanudar workflows tras errores

SWWL: Borrar workitems
Definición
El Business Workplace y el Universal Work List (Portal) son parte del entorno de ejecución del “SAP Business Workflow. Los empleados responsables, reciben los documentos y los work items para su tratamiento.
Una vez que una tarea (=un work item) ha sido ejecutado y completado, se puede continuar con el proceso.
La “worklist”contiene todos los “work items” (todas las actividades que han de ser procesadas) asignadas a su usuario, es por consiguiente, es 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) y en el caso del Universal Work List se encuentra en la solapa de Notificaciones. Esto simplifica el acceso de un empleado a la información que es importante para el.


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.

Notificaciones
SAP proporciona la opción de envío y recepción de notificaciones, esto puede ser tratado desde el Business Workplace.
Las notificaciones que se visualizan desde SAP pueden ser visualizadas desde el UWL pero con una configuracion previa.
En el UWL tenemos solo la opción de recibir notificaciones pero no de crear una.

Arquitectura BO
Áreas de la arquitectura donde requeriremos programación:
Atributos
Eventos
Metodos

– 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 genérico WF-BATCH

¿Qué es 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 pueden ejecutarse automáticamente.
– Una de las tareas más interesantes y regularmente una de las que más tiempo insume en el momento de definir un workflow es como el sistema determinara a los agentes correctos para cada work item.
– El sistema de workflow deberá trabajar con grupos de agentes para poder determinar los responsables finales de la ejecución de un work item.
Definición
– 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.
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 items pero no un work item especifico en si mismo.
– Si una persona no está en el grupo de agentes posibles entonces 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.
– Si no se definen los agentes posibles NADIE recibirá el workitem

Agentes Responsables
Agentes excluidos
Definición de Rol (Papel)
– Los agentes excluidos son aquellos que NO queremos que ejecuten un work item “en particular”.
– Los agentes excluidos siempre se definen en el workflow builder al crear un paso para una tarea.

Trabajando con y sin la estructura Organizativa
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.
Trx. PFAC_INS Creación de Rol
Trx. PFAC_CHG Modificación de Rol
Por módulos de funciones
Por competencias
etc..

Al crear un rol el sistema nos pedirá que indiquemos el tipo de rol entre los cuales encontraremos:
Delegación
Estados
Elementos del Tipo
de Objeto
Propiedades
Clave
Atributos
Métodos
Eventos
– 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
– Deben ser campos tipo carácter (CHAR).
– Los campos clave concatenados pueden contener un máximo de 70 caracteres.

– Un atributo de un objeto representa determinada característica que este objeto puede llegar a tener.
– 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),
– Un evento se utiliza principalmente para indicar que algo ha sucedido y 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.).

– 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.

– 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.

– Todos los componentes tiene asignado uno de los cuatro estados posibles:
Modelado: no existe programa para asignado aún.
Implementado: el programa ha iniciado pero no finalizado oficialmente.
Liberado: el programa puede ser ejecutado por todos
Obsoleto: no utilizar más.

Business Object Builder es la herramienta de desarrollo de la clase de Objeto. Trx. SWO1
Utilizamos tecnología orientada a objetos principalmente porque permite simplificar el proceso de modelado del workflow
En la metodología de desarrollo orientada a objetos las clases tienen determinadas propiedades de las cuales enumeramos:
- Encapsulamiento de datos: 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.
- 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”.
Un tipo de objeto (clases) describe un objeto de negocio abstracto, los datos que le pertenecen, métodos, etc, pero no es un objeto, sino que es un molde del mismo.
Para trabajar con un objeto de negocio, debe primero crearse una instancia del objeto a partir del tipo de objeto.
– Los métodos son las actividades que podemos llevar a cabo sobre un objeto
– 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

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”.

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.
En la cabecera indicaremos que tipo de objeto y evento lanzaran el workflow
Otra forma de activar el linkage entre el evento y el workflow es a través de la Trx. SWETYPV

Condición de Inicio
SAP provee una manera de limitar el inicio de un workflow al dispararse un evento y esto es a través de las condiciones de inicio, esto se puede realizar a travez de la Trx. SWDD.
Otra alternativa es realizarlo por la Trx. SWB_COND
Lanzando eventos desde
las aplicaciones SAP
Lanzando eventos con
“change documents”

Lanzando eventos con mensajes

Cambios en los datos maestros
del módulo HR

Otros tipos de lanzamiento
de eventos

- 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.
- 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.

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.
Trx. SWEC
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.
Trx. SWEHR1, SWEHR2, SWEHR3
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.
Los status de sistema siempre son fijados por el sistema automáticamente, mientras que los de cliente tienen que ser fijados por el usuario.
Trx. BSVW
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).
Uilizando control de mensajes. que intercambia información entre los distintos involucrados en el proceso de negocio.
La configuración de mensajes se hace a través de la transacción NACE.
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.

Definición
Definición
Definición de
Pasos
Definición de Tareas
Contenedores
• Al crear un paso, primero se debe especificar el tipo de paso. Estos pueden ser:
– Pasos que hacen referencia a las actividades de negocio: actividad, decisión de usuario, documento desde plantilla.
– Pasos que son usados para el monitoreo y control de procesos internos: condición, condición múltiple, loop, bucle, operación de contenedor, evento creador, espera de evento.
• Un paso indica una actividad especifica dentro de la definición del workflow, es decir que es un “paso” del proceso.

Creación paso de Actividad
– 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.
– Seleccionar el tipo de paso (en el ejemplo seleccionamos una actividad)
– 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.
– 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)
– 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.
– 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.
– 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.



Creación otros pasos
Cada paso tendrá sus propias caracteristicas y formas propias de configuración.
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.
Trx. PFTC_INS, PFTC_CHG
Tarea de proceso de fondo
– Asignar un nombre y descripción a la tarea
– Asociar un método de un business object a la tarea
– El container se completa automáticamente con los parametros del metodo agregado.


Tarea de Dialogo
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 tablas utilizada por los componentes definidos en el workflow. A su vez puede ser definido con una estructura de Business Object.
Existen contenedores en los siguientes lugares:
El contenedor de eventos: Contiene un elemento que puede obtener una referencia al objeto(s) a ser procesados en el workflow. Siempre contiene un elemento que pueda obtener el nombre de usuario “iniciador” del workflow actual (_WF_Initiator)
El contenedor de workflow: Puede tomar al iniciador del workflow desde el contenedor de eventos (_WF_Initiator).
El contenedor de tareas: Siempre contiene un elemento que puede obtener la referencia al objeto a ser procesado en la tarea de un solo paso respectiva (_WI_Object_ID). También puede contener un elemento que pueda obtener el resultado de un método de un objeto subyacente (_WI_Result).
El contenedor de métodos
El contenedor de roles (papeles)

Container de Tarea
Container de Workflow
Container de Regla
Full transcript