No, no nos han abierto el código para que modifiquemos lo que queramos dentro de SuccessFactors, pero si según la Wikipedia un lenguaje de programación es: “la capacidad de escribir (o programar) una serie de instrucciones o secuencias de órdenes en forma de algoritmos con el fin de controlar el comportamiento físico o lógico de un sistema informático, de manera que se puedan obtener diversas clases de datos o ejecutar determinadas tareas”, las reglas de negocio de SuccessFactors nos permiten hacer justo esto.
Las reglas de negocio se van a utilizar para agregar lógica de la programación a los datos. Y a los campos que los contienen.
Vamos a poder ocultar campos, o solo ocultárselos a ciertos colectivos. Vamos a poder hacer fórmulas, concatenaciones, actualizar campos en base a otros, mostrar mensajes, errores, mandar emails, flujos, y como estas cosas, muchas más.
Y no se van a utilizar solo en Empleado Central, sino que es algo que encontramos en la plataforma para usarlas en varios módulos. Por ejemplo, en Compensación se utilizan para la selección de empleados que entran en cada proceso de compensación.
Las reglas de negocio se pueden ver de forma particular en cada una de las partes donde se aplican, pero hay una pantalla principal desde la que se pueden buscar todas (dar un nombre relevante y coherente puede ser muy importante en la búsqueda)
Y el sitio desde donde se pueden crear de forma centralizada (además de poder crearlas individualmente en cada apartado)
Una vez pinchado el botón de crear, “solo” hay que elegir el tipo de regla de negocio que queremos crear
Pero, ¿qué es una regla de negocio?
Pues lo que decía al principio, una serie de instrucciones o secuencias de órdenes en forma de algoritmos con el fin de controlar el comportamiento físico o lógico de un sistema informático, que puede ser así de sencilla para que se ejecute siempre algo en el sistema. Es algo que a un informático no le costará crear, pero que a un no informático no le costará mucho leer ni entender, lo que facilitará mucho el análisis de cambios y errores.
En este caso por ejemplo, es una regla que se ejecutará siempre
Y así de sencillo será iniciar procesos de workflow en base a ciertos datos del sistema y habiendo creado antes el workflow, claro
En resumen, las reglas de negocio se pueden utilizar para poner/quitar/modificar datos, lanzar procesos, workflows, ocultar campos y un largo etc de cosas.
Creación de una regla. Caso práctico
Para crear una regla hay que tener dos cosas claras, la primera es qué queremos hacer, la segunda es dónde la vamos a poner. Tan importante es una como la otra, ya que las reglas se ejecutan en el orden en el que las ponemos en el evento que las active. Por lo que si la regla 1 modifica un campo y la 2 también, solo quedará el último cambio.
En un post anterior añadí un campo en un portlet estándar del sistema, así que vamos añadir una regla a este campo, por ejemplo, para que lo proponga automáticamente con el código interno de empleado. Aunque podría ser un campo calculado, autonumérico, concatenación de varios o sacado de otro campo.
Una vez elegido el tipo, hay que elegir nombre e Id de la regla, la fecha de inicio, y sobre todo el objeto base sobre el que se va a ejecutar la regla, y este último punto será el más importante de todos puesto que de ello dependerán los campos que podamos ver y modificar dentro
Y una vez rellenos los campos…, a crear la regla
Las reglas se dividen en 3 partes.
- Información básica, con los datos rellenados anteriormente. Nombre, ID, tipo de regla y descripción
- Parámetros, con los datos del objeto, el contexto, que son datos que podemos visualizar para apoyarnos y la posibilidad de añadir objetos auxiliares
- Configuración de la regla
Y ahora vamos a la parte del código
Que una vez está acabado nos queda, guardarlo y colocar la regla para su uso (Si, he cogido un caso sencillo, pero para complicarnos tiempo hay en un proyecto)
Para ello elijo el portlet de personalinfo. Para saber que pantalla es esta, aquí os dejo la entrada sobre la configuración empresarial.
Y añado la regla al final, en el evento onSave
De forma que cuando entre al portlet ahí puedo ver el campo que quiero que se rellene, si es que está vacío
Y cuando a modificar algo y grabe
Se rellene el campo solo.
Bueno, parece que aún nos queda un paso previo. Como he dicho antes, las reglas se ejecutan en secuencia, por lo que aunque haya grabado y mi evento sea onSave, hay una regla que lanza un workflow que se ha ejecutado antes.
Para saberlo hay que ir de nuevo a la configuración empresarial y buscar las reglas que hay antes que la mía.
Sin llegar a confirmarlo, creo que es esta (hay 2 y no he mirado exactamente el workflow que lanza y el grupo para el que lo lanza, que como se ve, está compuesto por 2 personas)
Así que volviendo al caso de prueba, primero hay que aprobar el dato para poder verlo reflejado en mi perfil de empleado.
De momento veo que tengo un dato pendiente de aprobación
Que si entro a verlo ya puedo ver que mi dato está ahí, a falta de aprobación.
Así que vamos a hacer proxy para entrar como Tessa Walker, que es una de las aprobadoras
Ahí tiene la tarea pendiente
Así que la apruebo
Y sí, ahora ya por fin veo el dato grabado, puesto automáticamente por una regla de negocio
Una vez visto todo esto, ¿todavía tienes algún campo para automatizar o un control que poner para evitar ese error recurrente? A lo mejor la solución va por aquí y te animas a buscar solución
