✒️ABAP Los Agentes y la Estructura Organizativa
ABAP Los Agentes y la Estructura Organizativa
1 | ¿Qué es un Agente?
Agente
Es la persona que ejecuta el trabajo a realizar en el Workflow.
Cada workitem (entendiendo por workitem a la instancia en tiempo de ejecución de un paso del workflow) puede ser procesado por:
El sistema de Workflow, utilizando el usuario WF-BATCH.
Un agente.
Los agentes son los encargados de ejecutar tareas que no pueden ejecutarse automáticamente.
Una de las tareas más interesantes y normalmente, una de las que más tiempo consume en el momento de definir un Workflow
es cómo el sistema ha de seleccionar a los agentes correctos para la ejecución de cada workitem.
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.
2 | La 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 workitem.
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:
Imagen 2.1 - Los grupos de agentes
Agentes Posibles: son quienes están permitidos para ejecutar el trabajo.
Siempre se asignan en la tarea según la cual se basarán muchos workitems pero no un workitem especifico en sí 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.
Imagen 2.2 - Los agentes posibles
Agentes Responsables: son aquellos que queremos que ejecuten un workitem “en particular”.
Son comúnmente asignados al crear un paso en el Workflow builder.
También pueden ser asignados a través de “roles o papeles” a nivel de la tarea.
Con los roles los agentes responsables se asignan dinámicamente en tiempo de ejecución. Siempre son agentes posibles.
Imagen 2.3 - Los agentes responsables
Agentes Excluidos: son aquellos que NO queremos que ejecuten un workitem “en particular”.
Siempre se definen en el Workflow builder al crear un paso para una tarea.
Imagen 2.4 - Los agentes excluidos
Estos tres grupos pueden solaparse e “interseccionarse” para poder determinar el agente responsable final.
3 | Los receptores
Receptores
Son aquellos que automáticamente reciben un workitem 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.
Debemos tener en cuenta que:
Si no hay agentes posibles NADIE recibirá el workitem.
Si no se define un agente responsable en el paso, el sistema buscará la regla por defecto de la tarea,
si no hay regla todos los posibles agentes recibirán el workitem (excluyendo a los agentes excluidos).
Un receptor podrá hacer un re-envío de un workitem a otro usuario. En este caso existen varias posibilidades:
Tarea general (General Task):
los workitems podrán ser re-enviados a cualquier usuario.
Transmisión general permitida (General Forwarding):
los workitems podrán ser re-enviados a cualquier usuario (pero existe una lista de agentes posibles).
Transmisión general no permitida (No General Forwarding): los workitems solo podrán ser re-enviados a los agentes posibles.
Prohibido transmitir: no esta permitido reenviar workitems.
Las posibilidades de re-envío las definimos dentro de la tarea, cuando determinamos los agentes posibles.
Imagen 3.1 - Reenvío de workitem
4 | Otros Agentes
Agente Actual: mientras que un workitem se este procesando el agente actual
es aquel que este procesando el workitem (lo tiene tomado).
Una vez completado el workitem, el agente actual será el que haya procesado el workitem en último lugar.
Asignación múltiple: puede darse el caso (y es muy común) que se envíe un mismo workitem a varios receptores.
Cuando uno de los agentes tome el workitem este desaparecerá del Inbox del resto
y en caso que lo vuelva a dejar sin tomar volverá a aparecer a todos los usuarios nuevamente.
Agentes para Plazos: son aquellos que recibirán un workitem que haya vencido,
es decir que se le fijo un plazo y el plazo se alcanzó.
Imagen 4.1 - Los agentes para plazos
Agentes de Notificación: son aquellos que recibirán un correo electrónico informándoles
que determinado workitem ha sido ejecutado satisfactoriamente.
Imagen 4.2 - Los agentes de notificación
5 | La estructura organizativa en la asignación de agentes
Cada agente en el sistema de Workflow debe tener un user ID de SAP.
Cada vez que se asigne un agente posible, responsable o excluido estaremos asignando de manera implícita un usuario SAP.
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.
Siempre que sea posible debemos mantener la asignación de usuarios a workflow
a través de un plan organizacional o estructura organizativa.
6 | 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.
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 período se puede cambiar.
Transacciones PPOM, PPOMW y PPOCW (Gestión Organizativa)
Los objetos organizativos y sus relaciones se mantienen a través de las transacciones de gestión organizativa PPOM, PPOMW y PPOCW.
Imagen 6.1 - La transacción de gestión organizativa
7 | El mantenimiento del Plan Organizacional Básico
Para crear un Plan organizacional o Estructura organizativa ingresamos a la transacción PPOCW y seleccionamos una fecha de validez.
Imagen 7.1 - Selección de la fecha de validez
Luego realizaremos los siguientes pasos:
Creación de la unidad organizativa: para ello presionamos el botón crear,
seleccionamos la unidad organizativa e indicamos un código, una descripción y un período de validez.
Imagen 7.2 - Creamos la unidad organizativa
Creación de la función: desde el menú seleccionamos Tratar / Crear Funciones tal como vemos a continuación:
Imagen 7.3 - Creamos la función
Y ingresamos un código y una descripción.
Imagen 7.4 - Introducimos un código y una denominación
Creación de una posición: 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 organizativa. También podemos colocar validez.
Imagen 7.5 - Creamos una posición
Asignar un usuario: nos ubicamos sobre la posición y presionamos el botón Asignar.
Imagen 7.6 - Asignamos un usuario
Luego seleccionamos titular y elegimos un usuario, por ejemplo el nuestro.
Imagen 7.7 - Seleccionamos un usuario
Finalmente cambiamos la descripción de la posición.
Imagen 7.8 - Modificamos la descripción de la posición
 
 
 
Sobre el autor
Publicación académica de Alex Francisco Lemos Collazos, en su ámbito de estudios para la Carrera Consultor ABAP.
Alex Francisco Lemos Collazos
Profesión: Ingeniero en Sistemas - Colombia - Legajo: QS36A
✒️Autor de: 174 Publicaciones Académicas
🎓Cursando Actualmente: Master S/4HANA Material Management
🎓Egresado de los módulos:
- Máster Material Management en SAP S/4HANA LOGISTIC
- Carrera Consultor ABAP Nivel Avanzado
- Carrera Consultor ABAP Nivel Inicial
- Carrera Consultor en SAP SD Nivel Inicial