Way back at the start of Autumn 2011, I wrote two blogs covering the install of a standalone SAP Data Services 4.0 environment. The first blog covered the deployment of the standalone Information Platform Services (IPS) required to manage authentication and security of the Data Services environment whilst the second looked at installing Data Services 4.0 itself. Keen readers of those two blogs will have noticed that each made reference to a forthcoming third entry which would look at integrating that Data Services environment with an existing SAP BusinessObjects BI 4.0 environment. It's taken me a while but here it is!

So in my last blog I wrote about the pretty straightforward process for installing the Information Platform Services (IPS) foundation necessary for a standalone deployment of the new SAP Data Services 4,0 environment. In this blog I'm going to walk through the install process for the actual Data Services 4.0 servers and software. All done through the one install job I'm happy to report but there were a few curios in there which makes the process a little bit less than smooth. Principally there was a bit of acrobatics required to install the repository on the same SQL Server Express Instance that was installed with the IPS. If I was to do it again I think I'd probably recommend using your own supported database but note that it does seem to have to be installed on the same server as the Data Services install.

Like many people working in the financial service industry, I've become increasingly involved in SOX Compliancy; what the regulations require, who must adhere to it, and the consequences of not following the rules. This blog aims to provide an introduction to SOX and explain how it impacts BI and ETL development.

This blog entry is really a case study, offering an overview to the problem and subsequent solution carried out on the Data Quality Improvements (DQI) project at one of Maxima's Retail Bank clients. The business requirements capture, detailed analysis and detailed design of the solution were carried out by Maxima before the build of the solution - developed in Business Objects Data Integrator, SAS, UNIX and Oracle – was carried out by Accenture, Maxima consultants worked very closely with the Accenture developers, acting in an end-to-end design consultancy role, overseeing delivery from build through to functional, integration and technical assurance testing. The team were also involved in creating the implementation plan and overseeing deployment of the solution into the production environment.

In previous posts I have reviewed the common ETL process of Change Data Capture (CDC) and shown how I have delivered this using SQL Server Integration Server 2005 (SSIS).  In this post I will outline how the same outcomes were achieved using SAP Business Objects Data Integrator (BODI) AKA SAP Data Services.

In my earlier post I outlined the aims of an ETL CDC process.  In this post I will review how I have delivered this using Microsoft SQL Server Integration Services 2005 (SSIS).

I’ve used a number of ETL product sets in my career to date and am interested in how they take different approaches to perform regularly required tasks. A good example is the  comparison between SAP Business Data Integrator 11.7 (BODI) and SQL Server Integration Services (SSIS) 2005.  It is not particularly useful to compare these two products on terms such as speed, performance or efficiency.  The tools are functionally very different. In SSIS, data is loaded into memory and the work is carried out within the engine so an increase in physical memory means better performance, whereas BODI allows some less complex operations to be pushed down to the database at run time while processing the complex transformations in memory.

Not every client has a full EIM toolset available to them and, even though it’s not the best practice approach, we’re challenged to deliver similar results with what is available. At a recent client I had to service a lot of Information Requests, generating datasets to support a variety of integration projects (migrating accounts from one system to another, consolidating large quantities of information across different systems). The vast majority of the time these datasets are output by request to either csv or xls files. Not a major problem for Oracle where we’d use import/export or, even better, Datapump. Unfortunately, this client did not have access to those utilities.