No sé si conocéis arcplan pero tal vez os resulte muy curioso el título de este artículo.
¿arcplan? ¿Qué es arcplan?
arcplan es una herramienta de frontend especializada en cuadros de mando y con conectividad a prácticamente cualquier sistema de base de datos que se os pueda pasar por la cabeza, lo que le da una versatilidad en los accesos a información que no tiene ninguna otra.
Aparte de esto, es una herramienta WYSIWYG que permite generar documentos (pantallas) con interactividad simplemente arrastrando y colocando objetos (tablas, gráficos, desplegables) relacionados entre ellos y los datos de la base de datos, con capacidad de personalización de imagen a gusto del consumidor y posibilidad de publicación web estándar y en movilidad.
Personalmente os recomiendo que le podáis echar un vistazo a algunas de las demos reales que podéis encontrar en la web del fabricante. Como dato adicional, comentaros que arcplan tiene una gran base instalada en España y en el mundo, siendo además especialista en conexión a nativa a SAP BW.
El caso es que como especialista en BI muchas veces nos encontramos con necesidades específicas en proyectos que son puramente de BI (informes, cuadros de mando, etc) y otras que son más de aplicaciones a medida porque las aplicaciones clásicas de BI no permiten ciertas cosas que a veces son necesarias como por ejemplo:
- Quiero que me aparezca un menú personalizado con estas imágenes y enlaces a este, este y este documento.
- Quiero conservar la navegación aquí y aquí pero en este documento no.
- Quiero poder grabar una determinada información en la base de datos (configuración, datos de presupuestación, comentarios, etc)
- Quiero poder lanzar procesos en la base de datos (PLSQLs o Stored Procedures, por no hablar de cálculos de Essbase)
- Y quiero hacerlo todo con la misma herramienta, claro.
Como podéis ver, pensando en un BO o en un Microstrategy, estas opciones no son factibles fácilmente y normalmente se resuelven con opciones de rodeo como páginas web de configuración, aplicaciones PHP/.Net/Java que hacen determinadas acciones y otros cambalaches con los SDKs para integrar diferentes tecnologías en el mismo entorno.
Si además pasa que no tenemos BO o Microstrategy y somos pro Microsoft (por ejemplo), la solución pasa por desarrollar aplicaciones .Net que tienen la flexibilidad total pero que carecen en muchos casos de:
- Un mantenimiento ágil y sencillo del código de la aplicación
- Un entorno visual
- Un enlace nativo con la base de datos tipo arrastrar y colocar
- Un sistema sencillo de interacción entre objetos
- Sistemas visuales avanzados (ya desde el punto de análisis de BI).
En estos casos en que tenemos necesidades de BI, de gestión de procesos, de control de los mismos, de ejecuciones en otros entornos, de aplicaciones y configuración de las mismas, arcplan se presenta como una alternativa sólida para cubrir todos los entornos (web / transaccional / control de procesos / BI / Budgeting), consiguiendo una integración máxima entre ellos y con una única herramienta para todo.
Lo que conseguimos con esto es una reducción drástica en el tiempo de desarrollo y de mantenimiento (por su naturaleza wysiwig y su facilidad de uso) comparado con un desarrollo a medida con .Net o Java. Si además tenemos en cuenta de que usuarios de negocio pueden aprender fácilmente su utilización para desarrollos (que no así con otras opciones), se convierte en una alternativa totalmente válida para un alto porcentaje de las necesidades de información de las compañías.
Alternativas de Gestión de Bucles en Informatica PowerCenter
Todos los que hemos utilizado la herramienta, Informatica
PowerCenter, nos hemos encontrado con la problemática de realizar procesos
iterativos basados en datos.
La solución que se suele implementar es utilizar dos
WorkFlows, lo que obliga a realizar algunos cambios en los dos WorkFlows en
algunas ocasiones, y si existe una dependencia de otro WorkFlow, relacionada
con la finalización del bucle, la cosa se complica. En muchas ocasiones nos
encontramos con las limitaciones, en muchos casos infundadas, de los clientes
que no permiten la utilización de ficheros de control, para los EventWait.
Aquí intentaremos dar soluciones alternativas, que permiten
realizar seguimiento y poder controlar las ejecuciones desde el WorkFlow
Monitor. Origen
Se quieren eliminar los controles de finalización (EventWait)
basados en ficheros. A partir de ahí hay que analizar un procedimiento que nos
permita controlar la ejecución, y finalización correcta, de los bucles y, al
mismo tiempo nos, nos facilite la posibilidad de indicar una finalización
correcta o incorrecta, al Workflow General, para que continúe, aún que no haya
finalizado un bucle o no se haya ejecutado, o forzar una parada controlada.
Problemática
La utilización de EventWait se basa en dos posibilidades:
a) Fichero de sistema
b) Event Raise
El primer caso es el que queremos utilizar, aunque si se fuerza el borrado del fichero al comienzo y se sincronizan correctamente las ejecuciones, en el Workflow General, debería ser igual de fiable.
El segundo caso es el que hemos analizado, para evaluar las alternativas que nos ofrece la herramienta, intentando minimizar la complejidad, maximizando el control y revisando opciones de reducir el desarrollo y la gestión.
Todas las alternativas han de permitir las opciones de controlar la finalización de cada bucle de forma independiente, ejecución asíncrona, o analizar la finalización de todos ellos como bloque, finalización síncrona.
Análisis de soluciones
Tras analizar las posibilidades, de la herramienta, desechamos algunas de las alternativas, al no ser factibles.
1) Ejecutar un EventRaise, desde fuera del Workflow, para activar el EventWait.
a) Definir el Evento en el WorkFlow o WorkLet

b) Definir un EventWait que espere ese evento

c) Definir un EventRaise desconectado, que active el evento

d) Definir un command, en otro WorkFlow que ejecute ese EventRaise

pmcmd starttask -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -w wf_MGM_Prueba_WF_Control -wait er_FinalBucle
e) Resultado: Al ejecutar el command nos devuelve un código de retorno que corresponde a que no se ha podido ejecutar la tarea, al estar en ejecución el WorkFlow.

2) Ir finalizando las tareas en el WorkFlow General
a) Realizar las tareas a y b de la opción 1, para preparar el entorno
b) Definir un command, en otro WorkFlow, que finalice el Event Wait
i. Abort

pmcmd aborttask -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -w wf_MGM_Prueba_WF_Control ew_FinalBucle
ii. Stop

pmcmd stoptask -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -w wf_MGM_Prueba_WF_Control ew_FinalBucle
c) Resultado: Al ir finalizando los EventWait el estado del WorkFlow cambia y el Workflow no continúa con la siguiente tarea.
i. Si todas las tareas acaban como stopped el WorkFlow acaba como stopped
ii. Si alguna de las tareas, o todas, finalizan como aborted, independientemente de si el resto finalizan como stopped, el WorkFlow finaliza como aborted.
Soluciones Propuestas
Existen varias alternativas basadas en el concepto de controlar las ejecuciones en base a un Workflow de Control. En ese Workflow de control podemos tener tantas tareas como bucles, o procesos independientes, que queramos relacionar.
En caso de generar tareas, independientes para cada proceso, tendremos la opción de finalizarlas manualmente, como Stopped o Aborted, e indicar al WorkFlow General si debe parar o continuar, dependiendo de la definición de controla aplicada.
Esta solución nos permite esperar la finalización de todas las tareas y preguntar por el estado final del WorkFlow o preguntar independientemente por cada tarea, y continuar el flujo según esté definido, aunque exista un único WorkFlow de Control.
La solución tiene una aplicación sencilla, y como hemos visto, con varias alternativas de uso y control. A continuación se explicarán la sencilla y la más completa, aunque existen variedades de las mismas.
Vamos a trabajar con:
1) Un WorkFlow, de Inicio de Bucle, que emula la ejecución de 3 bucles y su finalización asíncrona, como stopped, con un minuto de diferencia por cada uno de ellos.

pmcmd stoptask -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -w wf_MGM_Prueba_WF_Control ew_FinalBucle
pmcmd stoptask -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -w wf_MGM_Prueba_WF_Control ew_FinalBucle1
pmcmd stoptask -sv %INFA_DEFAULT_IS% -u
<Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta>
-w wf_MGM_Prueba_WF_Control ew_FinalBucle2
En caso de necesidad se podría forzar una
finalización con Abort, ejecutando el pmcmd aborttask, utilizando los mismo
parámetros.
2) Un WonkFlow, de Control, con 3 eventos separados, uno por cada bucle, el EventRaise no tiene utilidad como hemos visto en el análisis de soluciones.

Con estos WorkFlows como base, vamos a emular los procesos indicados (General y Detallado) para explicar algunas de las posibilidades.
1) Solución General basada en el control de un único WorkFlow
a) Creamos un WorFlow General

Todos los command tienen activado el control de errores.


i. La ejecución del WorkFlow InicioBucle

pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_InicioBucle
ii. La ejecución del WorkFlow de Control, con parámetro –nowait y controlando la finalización errónea, ya que el pmcmd, siempre finalizaría erroneo al cancelar las sesiones si lo ejecutamos con la opción -wait, y de esta forma fallará únicamente en caso de no poder ejecutarlo, al no haber finalizado una ejecución previa o tener algún problema de conexión o configuración.

pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_Control
iii. La verificación del estado de la última ejecución del WorkFlow de Control. Se ejecuta un primer comando WaitWorkFlow, forzando una finalización correcta al asignarle un exit 0, y un segundo para verificar el estado de finalización, que finalizará correctamente si el WorkFlow de control finalizó como stopped. Se puede incluir en el command anterior, se ha hecho así para facilitar la comprensión de los pasos.

pmcmd waitworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> wf_MGM_Prueba_WF_Control | exit 0
2) Un WonkFlow, de Control, con 3 eventos separados, uno por cada bucle, el EventRaise no tiene utilidad como hemos visto en el análisis de soluciones.

Con estos WorkFlows como base, vamos a emular los procesos indicados (General y Detallado) para explicar algunas de las posibilidades.
1) Solución General basada en el control de un único WorkFlow
a) Creamos un WorFlow General

Todos los command tienen activado el control de errores.


i. La ejecución del WorkFlow InicioBucle

pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_InicioBucle
ii. La ejecución del WorkFlow de Control, con parámetro –nowait y controlando la finalización errónea, ya que el pmcmd, siempre finalizaría erroneo al cancelar las sesiones si lo ejecutamos con la opción -wait, y de esta forma fallará únicamente en caso de no poder ejecutarlo, al no haber finalizado una ejecución previa o tener algún problema de conexión o configuración.

pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_Control
iii. La verificación del estado de la última ejecución del WorkFlow de Control. Se ejecuta un primer comando WaitWorkFlow, forzando una finalización correcta al asignarle un exit 0, y un segundo para verificar el estado de finalización, que finalizará correctamente si el WorkFlow de control finalizó como stopped. Se puede incluir en el command anterior, se ha hecho así para facilitar la comprensión de los pasos.

pmcmd waitworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> wf_MGM_Prueba_WF_Control | exit 0
pmcmd
getworkflowdetails -sv %INFA_DEFAULT_IS% -u <Usuario> -p
<Contraseña> -usd <Directorio de Usuarios>-f <Carpeta>
wf_MGM_Prueba_WF_Control | findstr /C:"Workflow run status:
[Stopped]" > nul 2>&1 && (exit 0) || (exit 99)
iv. Para que sirva de ejemplo, se ha incluido la ejecución, del propio WorkFlow General, en caso de finalización correcta, de los bucles.

start cmd /C "ping -n 3 localhost && pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_GeneralDeCarga"
2) Solución Detallada basada en el control independiente de cada Bucle
a) Creamos un WorFlow Detallado

Todos los command tienen activado el control de errores.


i. La ejecución del WorkFlow InicioBucle

pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_InicioBucle
ii. La ejecución del WorkFlow de Control, con parámetro –nowait y controlando la finalización errónea, ya que el pmcmd, siempre finalizaría erroneo al cancelar las sesiones si lo ejecutamos con la opción -wait, y de esta forma fallará únicamente en caso de no poder ejecutarlo, al no haber finalizado una ejecución previa o tener algún problema de conexión o configuración.

pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_Control
iii. La verificación del estado de la última ejecución de cada uno de los bucles. Para cada uno de los command, se ejecuta un primer comando WaitTask, forzando una finalización correcta al asignarle un exit 0, y un segundo para verificar el estado de finalización, que finalizará correctamente si la Task del WorkFlow de control finalizó como stopped. En este caso, no tiene sentido incluir estas verificaciones en el command anterior, ya que sería lo mismo que controlar que todo el Workflow de Control finalizara como stopped

pmcmd waittask -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -w wf_MGM_Prueba_WF_Control ew_FinalBucle | exit 0
iv. Para que sirva de ejemplo, se ha incluido la ejecución, del propio WorkFlow General, en caso de finalización correcta, de los bucles.

start cmd /C "ping -n 3 localhost && pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_GeneralDeCarga"
2) Solución Detallada basada en el control independiente de cada Bucle
a) Creamos un WorFlow Detallado

Todos los command tienen activado el control de errores.


i. La ejecución del WorkFlow InicioBucle

pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_InicioBucle
ii. La ejecución del WorkFlow de Control, con parámetro –nowait y controlando la finalización errónea, ya que el pmcmd, siempre finalizaría erroneo al cancelar las sesiones si lo ejecutamos con la opción -wait, y de esta forma fallará únicamente en caso de no poder ejecutarlo, al no haber finalizado una ejecución previa o tener algún problema de conexión o configuración.

pmcmd startworkflow -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -nowait wf_MGM_Prueba_WF_Control
iii. La verificación del estado de la última ejecución de cada uno de los bucles. Para cada uno de los command, se ejecuta un primer comando WaitTask, forzando una finalización correcta al asignarle un exit 0, y un segundo para verificar el estado de finalización, que finalizará correctamente si la Task del WorkFlow de control finalizó como stopped. En este caso, no tiene sentido incluir estas verificaciones en el command anterior, ya que sería lo mismo que controlar que todo el Workflow de Control finalizara como stopped

pmcmd waittask -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña> -usd <Directorio de Usuarios>-f <Carpeta> -w wf_MGM_Prueba_WF_Control ew_FinalBucle | exit 0
pmcmd
gettaskdetails -sv %INFA_DEFAULT_IS% -u <Usuario> -p <Contraseña>
-usd <Directorio de Usuarios>-f <Carpeta> -w
wf_MGM_Prueba_WF_Control ew_FinalBucle | findstr /C:"Task run status:
[Stopped]" > nul 2>&1 && (exit 0) || (exit 99)
iv. Para finalizar, el WorkFlow, se ha incluido un Decision, para que aglutine todas las tareas, igual que si hubiéramos preguntado por la finalización del WorfFlow. Y finalmente un Command con Exit 0. Para que se pueda verificar que únicamente se ejecuta si todos los Bucles acaban correctamente.
Ejemplo de Ejecución:

iv. Para finalizar, el WorkFlow, se ha incluido un Decision, para que aglutine todas las tareas, igual que si hubiéramos preguntado por la finalización del WorfFlow. Y finalmente un Command con Exit 0. Para que se pueda verificar que únicamente se ejecuta si todos los Bucles acaban correctamente.
Ejemplo de Ejecución:

(BOBJ) Creación de medidas dinámicas en WebI
Imaginad un caso en que tengamos mas de un tipo de medidas de las cuales solo queramos mostrar una cada vez, una solución no muy profesional sería duplicar el report para tantas medidas como tengamos, esto se puede hacer de una forma mas simple creando una medida dinámica que nos permita ir filtrando la medida seleccionada en cada caso.
Para esta entrada estamos usando:
1. Deberemos crear un nuevo Report en WebI, seleccionamos nuestros objetos de dimensión y medida.
2. Una vez hecho esto, creamos la tabla maestra con la que realizaremos la prueba, deberíamos de seleccionar los objetos de dimensión y medidas que queramos utilizar.
3. Ahora añadimos una variable nueva del tipo Dimensión, la llamaremos “Selecciona Medida”, le pondremos como valor predeterminado “Unidades”.
5. El Control de Entrada lo haremos a partir de la dimensión que hemos creado previamente llamada “Selecciona Medida”.
Para esta entrada estamos usando:
- Business Object 4
- SQL Server 2008 R2
- Windows Server 2008 R2
- El usuario tiene conocimientos de WebI
- Estas familirializado en la creación de Reports con WebI
- Tienes conocimientos SQL
1. Deberemos crear un nuevo Report en WebI, seleccionamos nuestros objetos de dimensión y medida.
2. Una vez hecho esto, creamos la tabla maestra con la que realizaremos la prueba, deberíamos de seleccionar los objetos de dimensión y medidas que queramos utilizar.
3. Ahora añadimos una variable nueva del tipo Dimensión, la llamaremos “Selecciona Medida”, le pondremos como valor predeterminado “Unidades”.
4. Una vez tenemos la medida creada, lo que haremos con ella será irnos al apartado izquierdo y crear un nuevo “Control de Entrada”
6. Hecho esto hacemos click en siguiente y seleccionamos “Pulsadores” como formato para la visualización del Control de Entrada y su filtrado.
7. Ahora haremos click en “Lista de valores”
8. Escribimos en “Escriba un valor:” de la nueva medida que vamos a añadir, en este caso, haremos el ejemplo con “Valores”.
9. Ahora deberías de ser capaz de seleccionar entre ambos, como es lógico todavía no hará ningún tipo de filtrado.
10. Lo que necesitamos hacer para que haga el filtrado será crear una dimensión de medida nueva, la cual nos retorne la medida apropiada basándose en la selección de nuestro Control de Entrada.
11. Hecho esto, podemos comprobar que dependiendo de la medida que seleccionamos en nuestro Control de Entrada el valor en nuestra tabla cambia (Unidades).
12. Otra captura con Valores.
13. Hecho esto hemos completado la creación de nuestra medida dinámica, pero aún podemos ir un poco mas lejos, vamos a formatear nuestra medida dinámica de modo que dependiendo si son unidades o valores aplique formato de moneda o no, para ello utilizaremos las “Reglas”.
14. Aplicamos esta nueva regla a nuestra columna y acabará quedando algo así para el caso de Unidades.
15. Para el caso de Valores.
16. Ahora para cuando creemos nuestro Informe lo único que deberemos hacer será usar esta nueva medida como si fuera una normal.
Suscribirse a:
Entradas (Atom)















