Users frequently find their explorer spaces and exploration views displaying outdated information. Indeed this can happen if the source data is not ready when the indexing process is scheduled to start at a fixed time, so a manual re-run is needed when the data is available to ensure data freshness. Unfortunately scheduling explorer spaces is not possible in the current 3.x or 4.x versions of SAP BusinessObjects BI, but a workaround has been recently applied in one of our customers which we detail in this article.
Gestión de dependencias ETL con SAP BusinessObjects Data Services (Parte 4)
Are you satisfied with the way you currently manage the dependencies in your ETL? In the part 1 of this article, I talked about the features I’m expecting from a dependency management system, and what are the main possibilities offered (directly or indirectly) by Data Services. In part 2, I proposed an architecture (structure and expected behavior) for a dependency management system inside Data Services. In part 3, I explained the complete implementation details. In this final part, I'm going to give you a feedback on how it went “in real life” as well as possible improvements. So, the most important question is of course "Does it work?". I'm happy to confirm that yes, it does! And it makes quite a difference in the life of the customer's Data Services administrator. Of course it doesn't change anything if the ETL is running fine, but when there are problems, this dependency management system can be a huge time-saver!
Informatica PowerCenter - Automated loop execution with exchange of input parameters
One often required functionality that's not inherent to any Informatica PowerCenter entity is to automate loop execution of arbitrary logic with exchange of input parameters. In this article I will give you the implementation steps so you can achieve this. Most common implementation occurs with execution of arbitrary Data Integration process for a time period that's comprised of multiple temporal scopes of a single process run. For example, reloading a full month of transactions after the cutoff date when retroactive bookings for previous month become impossible, by means of daily transaction increment.
Not missing a hit in SAP BusinessObjects using HTTP traffic logs
Monitoring the number of views of an important corporate document is a key need for any company who is aiming for better resource management and company-wide alignment. This is especially important in a migration project in order to define what content to migrate or in a document maintenance process to prioritize assignments. SAP BusinessObjects Auditing is able to register when documents are viewed or retrieved but it has certain limitations, so most of the users activity is lost. This article explains an alternative method to collect the number of views of any SAP BusinessObjects file type or web page that sits on our web server so they can complement our current auditing reports.
Gestión de dependencias ETL con SAP BusinessObjects Data Services (Parte 3)
Are you satisfied with the way you currently manage the dependencies in your ETL? In Part 1 of this series, I talked about the features I expect from a dependency management system, and what are the main possibilities offered (directly or indirectly) by Data Services. In Part 2, I proposed an architecture (structure and expected behavior) for a dependency management system inside Data Services. Now I will give you the implementation details, while a feedback on how it went “in real life” as well as possible improvements will come in part 4. So how do we implement this theoretical solution in Data Services?
Common SAP Dashboards (Xcelsius) bugs and how to solve them
This post is about SAP BusinessObjects Dashboards (formerly known as Xcelsius) and its intricate form of work. If you are an assiduous dashboard developer or just beginning to work with the tool, you will notice some bugs that interfere with your developing and slows you down. My main goal is to talk about the bugs or "misfortunes" that I have commonly faced in SAP BO Dashboards (Xcelsius) and the workarounds that I have found to save you some time when working with this tool. My second objective is to open a discussion where you can comment on other SAP Dashboards issues and solutions you found.
Integración de tablero en SAP Crystal Reports
In this blog article I would like to share with you how to embed a dashboard in a Crystal Report using flash variables. First of all let’s give a scenario that leads us to do that. In this case we wanted to create a dashboard for a SAP GRC module. The problem was that we could not connect to the system directly with SAP BusinessObjects Dashboards (Xcelsius for the most nostalgic ones). Apart from that, there is a good thing about having a dashboard embedded in Crystal, you will have a dashboard that can be refreshed from Crystal Reports without needing a previous authentication. You will also be able to save the “report” (you can show the dashboard) in PDF with saved data and the dashboard will be completely clickable and navigable.
Cómo cargar y leer Web Services Data Store en Data Integrator
En este artículo, le enseñaré en 12 pasos cómo cargar y leer la información recuperada por un servicio web basado en una aplicación Java como fuente de información. Esto tiene una característica muy importante si, por ejemplo, está creando aplicaciones Java Social Media que leen información de Internet o si ha creado una aplicación Java que recupera información en Json Structure XML. Le mostraré cómo Data Services realiza solicitudes e interpreta las respuestas de un origen de datos de servicio web.
If you need background information on the first steps of my process, I have done a first post on how to use Data Services SDK libraries to construct an AWTableMetadata in a Java application, followed by the post where I explained how to access a JAVA application as a source of information using the WebService DataStore in SAP Data Services.
Si ya lees mis blogs anteriores, vamos a saltar en cómo cargar y leer Web Services Data Store en Data Integrator.
Paso 1:
Open Data Services Designer. Go to the Data Store perspective and right click with the mouse and select New.
Paso 2:
Set the name of the extractor and the URL where your web service WSDL is located (see my previous blog for reference).
Paso 3:
Right Click on the “f(x)” symbol and select Import. Choose the functions from the webservice that you are going to use. In this example we select “getTableTweeetsEN” and “getTableTweeetsES”.
Nota especial:
Para acceder a estas funciones dentro de una transformación tenemos que usar el esquema de llamada de función proporcionado por Data Services. En este caso, la función getTableTweets_EN recibe una entrada y devuelve una tabla (tabla AWTableMetadata). Este tipo de retorno viene en un formulario anidado de nuestro Servicio Web. Tendremos que resolver este esquema anidado haciendo un par de transformaciones a continuación.
Paso 4:
Seleccione el parámetro de entrada para las funciones; En este caso es un campo de una tabla llamada "WS_Parameter". Seleccionamos esa tabla como una tabla de origen y nuestro primer elemento en nuestro flujo de datos.
Paso 5:
Inserte una transformación en el flujo de datos como su segundo elemento. En esta primera consulta (Query1_EN). Creamos un SCHEMA llamado Schema 1, y asignamos el campo proveniente de la base de datos "Parameter" como un atributo de este Schema.
Paso 6:
Cree una segunda transformación (Query2_EN). Esta consulta se encargará de llamar al servicio web con el parámetro de entrada mediante el procedimiento de llamada de función. Haga clic con el botón derecho del ratón en la tabla de esquemas llamada Consulta2 y seleccione Nueva llamada de función.
Paso 7:
Seleccione el WS_ClaribaSMT dataSotre en el panel izquierdo, el panel derecho muestra las funciones que importamos al Data Store. Seleccionamos el primer getJsonTweet (para el idioma inglés) y clicamos en Siguiente.
Paso 8:
We have to map the new function call Schema with the new Schema1. This is the structure used to call a Web Service in Data Services. In this case we are calling the function getJsonTweets_EN with a parameter nombre. Structure that matches our SHEMA1. Then click Finish.
El resultado final contendrá la llamada a la función. También puede agregar un atributo debajo de la llamada de función. En este caso agregamos "load_date" que contiene el sysdate que representa la fecha de los datos de carga.
Paso 9:
La tercera consulta se encargará del reconocimiento de los datos devueltos por el servicio Web. En este caso, el Esquema se encuentra en el panel izquierdo. Para capturar esto en el integrador de datos necesitamos desacoplar este esquema hasta llegar al "objeto de retorno" que contiene los datos.
Hacemos clic en el panel izquierdo encima de getJsonTweetResponse y lo arrastramos hacia el panel derecho. Luego hacemos clic derecho sobre el getJsonTweetResponse desde el panel derecho y seleccionamos la opción "Unnest". Esto causará la división entre los esquemas. Procedemos a capturarlo en la próxima consulta anidada.
Paso 10:
Hacemos el mismo procedimiento en la consulta 4, arrastramos el getJsonTweetResponse a la derecha y lo desentrañamos.
Paso 11:
Query 5_EN contains the final result which be two variables that contains the header of the table plus the Load Date.
Paso 12:
El último paso depende de la implementación y las reglas de negocio. La tabla devuelta tendrá este formato.
Columna 1
Valor 1
Columna 2
Valor 2
Columna N ...
Valor N ...
Conclusión
Este método se aplica especialmente si está utilizando esquema de llamada de función y una matriz como tipo de devolución para su servicio web. Si su fuente es otra cosa diferente a una aplicación, la resolución del servicio web puede variar. El método para asignar la tabla final depende de usted y de sus necesidades empresariales. Una solución fácil podría ser agregar un ID a cada fila.
Si desea tener más información, lea mis blogs anteriores o deje un comentario a continuación.
Ahorrando el tablero de instrumentos con un clic en movimiento
Looking forward to add a little more to your visualizations? Spice them up with a clickable moving ticker! For those who are not familiar with Dashboard Design (formerly known as Xcelsius), a moving ticker is a banner which has a similar look to a stock market ticker displaying customized moving labels from right to left. The one described here is also clickable, which means that when you click on any label it can execute many actions such as opening URL’s.
We always try to build dashboards that people really use, and for that we need to find a balance between functionality and design. The design might not seem as important as the functionality, but trust me, in order to get the attention of users you need to build something that really catches their eyes, such as this ticker feature which is easily noticeable to do it´s constant movement.
Step by step process
In order to help you make your Dashboards eye-catching, I am going to show you how to build a clickable ticker to open URL’s with the following steps.
Let’s start by organizing our spreadsheet (find example below – Fig.1) with the following information:
- Labels: Information that will be displayed on the ticker
- URLs: Links that will be opened when clicking on the labels
- Auxiliary info: cells containing Index, destination, status, key, URL to open, which will be explained later on
When your spreadsheet is ready follow these steps:
1) Drag and Drop the ticker object to your canvas.
The ticker object can be found under the category “Selector”.
2) Configure the Ticker object’s properties.
In the General tab, assign the labels you would like to show on the dashboard.
Insertion type: Position
Destination: This cell is key as it will give the position number of the clicked label on the ticker.
e.g: If you click the third label of the ticker this cell will be a “3”, it it will change when you click another label.
3) Drag and Drop a URL object to your Canvas.
The URL object can be found under the category “Web Conectivity”
4) Configure the URL object’s properties and behavior.
URL: In this cell you need to build a “vlookup” formula as it is shown in fig.1.
In the behavior tab under the Trigger Behavior properties you find:
Trigger cell: This is going to be the same as the destination cell of the Ticker (Sheet1!D$4 in this case – Fig 2.).
Check the “When Value Changes” option.
Hide this button by selecting different values for the status and key cells as below:
The outcome and conclusions
After completing these steps you should have built a clickable moving ticker which will spice up your visualization.
This solution will allow you to:
- Open Intranet/Internet URL’s from moving labels.
- Change visibility dynamically for graphs and images from you Dashboard Design visualization.
- Enhance the design and gain visibility of your visualizations
I hope this feature is useful to you and it brings positive feedback from your end users. Please feel free to leave a comment or question below.
Gestión de dependencias ETL con SAP BusinessObjects Data Services (Parte 2)
Are you satisfied with the way you currently manage the dependencies in your ETL? In part 1 of this article, I talked about the features I’m expecting from a dependency management system, and what are the main possibilities offered (directly or indirectly) by SAP Data Services. Now (part 2 of the article), I’m going to propose an architecture (structure and expected behavior) for a dependency management system inside Data Services. The implementation details will come in part 3, while a feedback on how it went “in real life” as well as possible improvements will come in part 4.
La arquitectura propuesta
What I’m going to develop now is the following: an improvement of the “One job with all processes inside” architecture.
Las principales características de esta arquitectura son:
- Gestión de múltiples dependencias (un flujo puede depender de múltiples procesos)
- Un gracioso reinicio es posible. El reinicio ETL completo también es una opción.
Primero debemos crear dos tablas, FLOW_DEPENDENCIES y FLOW_STATUS.
- La tabla FLOW_DEPENDENCIES tiene dos columnas FLOW_NAME y PREREQUISITE. Tiene una línea para cada prerrequisito.
Para el ejemplo siguiente (dependencias de flujo lógico en un trabajo) ...
... relataremos la tabla FLOW_DEPENDENCIES de la siguiente manera:
Por supuesto, no puede implementar directamente estas dependencias lógicas en los Servicios de datos, por lo que es necesario encadenarlos uno tras otro.
La tabla se actualiza manualmente cada vez que hay un nuevo requisito previo. Un flujo sin requisito previo no necesita ninguna fila en esta tabla (ver flujo A por ejemplo).
La tabla FLOW_STATUS realiza un seguimiento de los diferentes estados de flujo (ya se ejecutan, Sucesos, Fallas, Requisitos previos faltantes) para cada ejecución del trabajo principal. Las columnas 3 son JOB_KEY (que contiene una clave sustituta para cada nueva ejecución del trabajo), FLOW_NAME y STATUS.
Para dejar las cosas claras, imaginemos que ejecutaremos el trabajo por primera vez (JOB_KEY = 1).
- El flujo A no tiene ningún requisito previo, por lo que se permite ejecutar. Tiene éxito. Se inserta una fila con STATUS = Success en la tabla FLOW_STATUS.
- El flujo B tiene un requisito previo de acuerdo con la tabla FLOW_DEPENDENCIES (el flujo A), por lo que comprueba el estado del flujo A en la misma ejecución. Resulta que el flujo A fue exitoso, por lo que se permite que el flujo B se ejecute. Desafortunadamente, falla por una razón desconocida. Se inserta una fila con STATUS = Failure en la tabla FLOW_STATUS.
- Se permite que el flujo C se ejecute de acuerdo con la misma lógica que para el flujo B. Se ejecuta con éxito. Se inserta una fila con STATUS = Success en la tabla FLOW_STATUS.
- El flujo D tiene dos pre-requisitos de acuerdo con la tabla FLOW_DEPENDENCIES (flujos B y C). Comprueba el estado de ambos. A medida que el flujo B falla, el flujo D no se deja correr. Se inserta una fila con STATUS = Requisito faltante en la tabla FLOW_STATUS.
- Se permite que el flujo E se ejecute de acuerdo con el mismo flujo lógico B. Se ejecuta correctamente. Se inserta una fila con STATUS = Success en la tabla FLOW_STATUS.
- El flujo F tiene un requisito previo (flujo D). Pero como el estado del flujo D es "Requisito faltante", el flujo F también no se permite correr. Se inserta un estado similar en la tabla de estado de flujo.
A continuación se muestran las filas insertadas en la tabla FLOW_STATUS durante esta ejecución del trabajo.
Una vez corregida la causa del error en el flujo B, podemos volver a ejecutar el trabajo. JOB_KEY será igual a 2, e indicaremos al trabajo que debe comprobar los estados del trabajo anterior (en el que JOB_KEY = 1).
- El trabajo comienza comprobando el estado del flujo A en la tabla FLOW_STATUS con JOB_KEY = 1. Como el estado es igual a Éxito, el flujo A no necesita ejecutarse en este trabajo. Se inserta una fila con STATUS = "Already run" en la tabla FLOW_STATUS.
- El estado del flujo B con JOB_KEY = 1 es "Fallo". Por lo tanto, el flujo B debe ejecutarse durante este trabajo. A continuación, el trabajo comprueba el estado del requisito previo (el flujo A) para JOB_KEY = 2. Resulta que el flujo A ya estaba ejecutado, por lo que se permite que el flujo B se ejecute. Se ejecuta con éxito. Se inserta una fila con STATUS = Success en la tabla FLOW_STATUS.
- Los flujos restantes siguen una lógica similar.
A continuación se muestran las filas insertadas en la tabla FLOW_STATUS durante esta ejecución del trabajo.
Como puede ver, esta solución gestiona las dependencias de ETL, mantiene el rastro del historial de carga y permite fácilmente una re-ejecución parcial del ETL si una parte de éste falla. En la siguiente parte os daré los detalles de la implementación de Data Services: qué scripts / flows / functions / etc. Debemos usar ¿Cómo hacemos este sistema fácil de implementar y mantener? Hasta entonces, espero su opinión sobre esta arquitectura propuesta. ¿Se ve bien? ¿Cómo lo mejorarías? Háganme saber con un comentario a continuación.