A performance gain of 3 hours down to 30 seconds is impressive and what’s even more remarkable is that it was only one minor change to an existing dataflow that was responsible for the gain.
This article provides a summary of the high level steps involved with building a SAP BI 4 Demo System and provides guidance on hardware and software requirements and links to where software can be downloaded from. The Demo System will host SAP Business Objects 4.0 and SAP Data Services 4.0
The previous article provided an introduction to unit testing in general covering the purpose and benefits of unit testing. This article now looks at a method of unit testing that can be utilised in a SAP DataServices project. First we’ll discuss what objects are candidates for unit testing and then look at how we implement the unit testing of these objects.
One of the key drivers of this article is that although there are many articles on unit testing in general on internet there are hardly any on unit testing with SAP DataServices. Unit testing has been accepted as a key part of the software development lifecycle for projects building applications in languages such as Java or C++ however I have rarely come across a SAP DataServices project where unit testing is treated as a fundamental part of the software development life cycle. As a result projects without rigorous unit testing spend longer than planned in system testing, identifying trivial defects, and as a result suffer from delays and cost overruns.
This article first explains what is unit testing and what benefits it brings to a project and then looks at how to implementing automated unit testing in a SAP DataServices project.
In software programming it is widely held that using global variables or other constructs to maintain global state is a poor programming practice and many of those reasons can also be applied to development of jobs in SAP Data Services.
The following is my list of 10 reasons for why you should never use global variables,
- Tight coupling between separate parts of a Data Services job
- Hidden dependencies between separate parts of a job
- Lack of isolation for unit testing components of a job
- No access control – everything in a job has full access to a global variable
- Global variable values can be set at runtime
- Lazy reuse of global variables
- Global variables depend on the context in which they are being used
- Local variables can have same name as global variables
- Global variables discourage code reuse
- Global variables restrict configuration management
These are further explained below and since I’m a never-say-never type I’ve also included one situation where you can use a global variable.