First we have to identify which entities have to be named in SSIS:

• Projects
• Packages (filename and identification name)
• Configurations
• Loggers
• Connections
• Variables
• Control Flow and Data Flow items

Secondly it is not important which naming convention you use. It is important that you use a naming convention. There is a good article about naming conventions on Wikipedia you could use for inspiration. The CamelCase naming convention is often used in programming, so I decided to use it for the following examples.

Thirdly we need a clear and intuitive naming definition on how to describe the listed entities above. A naming definition of an entity assumes that we know how to describe important properties of the entity. So what are the important properties of the listed entities?

The Project Name

The name of the SSIS-Project gives a developer an hint which technical task or problem is solved inside. This name is the key entry point to a technical solution, a name for a jigsaw piece. Is is not best practise to bunch all technical things together. Sketch out the system boundaries and name them. Imagine it is a piece of a jigsaw. What picture (the name) have to be on the piece so you can assign it to the right place in the whole.

The Package Name

The package name is related to the given project name. A package is a small piece of the entire project. Without it the entire project can’t exist.

A package can do many things. It could be a control package, which starts other packages. It could be a package which start dimension or cube processing or it loads data from external or operative data sources into a local database for further processing. We can see that there are at least three different things a package can do: Control, Load and execute functional things like sending emails or starting dimension processing. So it suggests itself to use this information for the package naming definition. For example you could use the following prefixes in the package name:

• Ctrl for packages which controls the execution of other packages
• Load for packages which loads data
• Func for packages which do some functional things like sending mails etc. pp.

Based on this we can go further. For Ctrl and Func packages it is obvious how to name them further. The simple questions are: What is the package to be controlled? What functional thing the package will do? Some examples:

• CtrlMaster - A master control package for the whole project
• CtrlCubeProcessing - A package which calls other packages to process dimensions and cubes in a non default manner
• FuncSendSuccMail - Send a success mail to some people after processing cubes
• FuncValidateMailAdresses - A package which validates a table with mail addresses. It marks which are correct and which not.

A load package is somewhat specific. Mostly there is at least one source and one target. So load packages can operate on different databases, tables, schemas etc. pp. The package name should reflect that fact. Here at ORAYLIS we have a process model on how to load data for Datawarehousing. We arrange the whole loading process into three layers: Extraction-Layer, Working-Layer and Frontroom. The Extraction-Layer hold the raw data from external and operative data sources. You could think of it as a one-to-one copy in a relational database or the interface to the outside world. In the Working-Layer we put data together (joining tables, calculating new columns, renaming, data cleansing etc.). The Frontroom-Layer is the actual Datawarehouse. So we have three important layers for loading a Datawarehouse. This could lead us to the following naming definition for Load-Packages.

• LoadExtract - A package which loads data from an operative or external data source
• LoadWork - A package which modifies the loaded data from the Extraction-Layer
• LoadFront - A package which fills the Datawarehouse with data from the Work or Extraction-Layer

It is possible to have more than one Extraction-, Work- or Frontroom-Layer. Simply add the name of the layer (or other important information) at the end of the package name. For example LoadFrontSalesDimCustomer if the package fills the Customer Dimension for the Sales Datawarehouse which is stored in the Frontroom-Layer. The final naming definition for Load-Packages could be

“Load” {Logical Layer} {Database Name or abbreviation} {Tablename/Dimension/Fact}

Connections

Based on the naming conventions above for packages it is best practice to name a connection based on a logical name rather a database name or a server name. A database name can be volatile or meaningless like EGH275. So calling a connection DWH123.EGH275 is either wrong after the Go-live because the server name changed or could be meaningless like EGH275. A logical server name could be DWH and a logical database could be Frontroom which leads to DWHFrontoom or DWHWork.

{Logical Server Name} {Layer}

Variables

Variables in SSIS can be described with a name, a name space and a context. The context is the world were the variable exists in, typically an SSIS container. So variables are context specific or global. The default name space for a variable is called User.

I use the name space to describe the main purpose for using the variable. Is it a variable to override connection strings? Is it a counter in an For-Each-Loop-Container? I found at least three name spaces:

• User – holds mostly context specific variables
• Config – holds variables which overloads package or task properties and is more global
• Result – holds variables with information for further processing inside or outside the package. These variables are mostly global.

The variable name is highly specific. So the only advice I can give is to use lowerCamelCase.

Control and Data Flow Items

The name of a task or container is comparable with the name of a function or procedure. For example the function name Math.Add imply that it can add two numbers. A Task name should do also.

I often use the WhoN’How-Where-What-Pattern for Data Flow Items. For example a data source (Who?) which loads accounting periods (What?) from the Work-Layer (Where?) in the ABCD-Table (Where?) is called:

Using CamelCase here would lead us to SrcWorkAbcdAccountingPeriod but this is too illegible. See here another example. A Lookup-Component. Proof it … what is done here?

This name gives us the following information: A full cache lookup onto the ShippingAddress table in the Extract-Layer with the IDShipAddr key column which returns the StrName column named as Street. It is very long eeh? Of course it is, but having a meaningful name is better than having a non-meaningful name. Every time I see packages without naming conventions the first thing I do is to rename the items inside to get the big picture.

Conclusion

In this article I covered naming conventions for control and data flow items as well as for packages, connections and variables. Feel free to make comments and suggestions on how to name things and please keep in mind: It is not important which naming convention you use. It is important that you use a naming convention.

]]> http://blog.oraylis.de/2012/03/ssis-pattern-naming-convention-part-i/feed/ 0 http://blog.oraylis.de/2012/03/templating-mechanismus-fr-integration-service-pakete/ http://blog.oraylis.de/2012/03/templating-mechanismus-fr-integration-service-pakete/#comments Fri, 16 Mar 2012 09:00:31 +0000 Daniel Esser http://blog.oraylis.de/?p=865 Update für SQL Server 2012 (16.03.2012)

Die RTM Version des SQL Server 2012 ist gerade draußen und einige Fragen sich bereits ob das generieren von Pakten unter der Version 2012 immer noch funktioniert, schließlich hat sich das Paketformat drastisch verändert.

Die Antwort lautet ja. Allerdings sind die Integration Service Assemblies auf die CLR Version 4 angehoben worden. Solltet Ihr nun versuchen das ManagedDTS Assembly zu laden bekommt ihr folgende Fehlermeldung.

This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. (Exception from HRESULT: 0x8013101B)

Dies liegt daran, dass die Powershell 2.0 keine CLR 4 Assemblies laden kann (nur bis CLR 3.5). Glücklicherweise gibt es schon die PowerShell 3.0 CTP 2 oder richtiger das Windows Management Framework 3.0 CTP 2 welches PowerShell 3.0 beinhaltet. Mit PowerShell 3.0 ist es nun wieder möglich die entsprechenden Assemblies zu laden. Die Assemblies findet Ihr wie gewohnt unter:

C:\Program Files (x86)\Microsoft SQL Server\110\SDK\Assemblies

Einführung

Es gibt vielerlei Gründe dafür ein SSIS-Template-Paket zu erstellen. In der Regel möchte man die Konfiguration über die Vielzahl der Paket in einem Projekt homogen halten. Heterogenität in der Paketkonfiguration erhöht die Fehleranfälligkeit während der Bereitstellungsphase insgesamt. Zwar gibt es die Möglichkeit der Vererbung der Konfiguration für Unterpakete, allerdings führt das für den IS-Entwickler dazu, dass Pakete nicht mehr einzeln zu starten sind, da diesen Paketen die vererbte Konfiguration des Elternpakts fehlt. Diese Einschränkung ist für die Entwicklung nicht hinnehmbar.

Um diese Einschränkung zu umgehen, muss jedes Paket einzeln Konfiguriert werden. Diese Arbeit manuell zu machen erhöht wieder die Fehleeanfälligkeit für die Bereitstellungsphase. So liegt der logische Schluss der Automatisierung recht nahe.

Nun gibt es unzählige Möglichkeiten IS-Pakete automatisiert anzupassen. Eine Möglichkeit wäre die Pakete durch einen XSLT-Prozessor zu jagen, die für die richtig Konfiguration sorgt. Das hätte den Charm, dass man für verschiedene Bereitstelllungszenarien verschiedene XSLT-Stylesheets schreiben könnte, die die jeweilige Konfiguration für das entsprechende Endsystem berücksichtigt. Der Nachteil dieser Variante ist, dass das KnowHow für XSLT vorhanden sein muss. Außerdem geht XSLT nicht leicht von der Hand.

Ein andere Variante wäre ein .NET-Applikation zu entwerfen, welche mitteln des IS-Objektmodell die entsprechenden Pakte anpasst oder generiert. Der Nachteil hierbei wäre die fehlende Flexibilität während der Entwicklung. Schnelle Änderungen setzen eine Ressource mit C#-Kenntnissen und Visual Studio voraus.

Eine ähnlicher aber flexiblerer Ansatz wäre eine Skript-Sprache zu verwenden mit Zugang zur .NET-Welt. Die Möglichkeiten sind auch hier wieder vielfältig. Hier wären zu nennen: Visual Basic, PowerShell und Iron Python. Welche Skript-Sprache man verwendet ist eher eine Geschmackssache. Da ich das Erweitern von IS-Paketen um eine einheitliche Paketkonfiguration eher in der Bereitstellung verorten würde, würde ich PowerShell (wegen der Nähe zur Administration) den Vorzug geben.

Grundgerüst

Die erste Hürde, die es zu meisten gilt ist von recht langweiliger Natur. Standardmäßig können PowerShell-Skripte nicht direkt ausgeführt werden. Wenn man sich die Mächtigkeit der PoweShell bewusst macht, ist das verständlich.

Es gibt zwei Wege dieses Hürde zu nehmen. Zum einen können wir die Sicherheitsmaßnahmen für PowerShell-Skripte herunterfahren. Für eine Produktionsumgebung ist das nicht zu empfehlen, zu Entwicklungszwecken aber legitim. Mit folgendem Kommando wird die Sicherheitseinstellung ausgeschaltet.

Set-ExecutionPolicy Unrestricted

Für eine Produktionsumgebung müsste das Skript signiert werden und eine Vertrauensstellung dem Eigentümer gegenüber eingerichtet werden. Weitere Informationen hierzu finden sich hier:

• http://www.scriptinganswers.com/essentials/index.php/2008/02/21/how-do-i-sign-a-windows-powershell-script/

Der nächste Schritt wäre PowerShell mit SSIS zu verheiraten. Dazu müssen Assemblies des SQL Servers geladen werden. Im Fall des SQL Server 2008 befinden sich diese Dateien im Verzeichnis C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies.

[Reflection.Assembly]::LoadFile(“…\Microsoft.SqlServer.DTSPipelineWrap.dll”)[Reflection.Assembly]::LoadFile(“…\Microsoft.SQLServer.ManagedDTS.dll”)

Nach diesem Schritt stehen einem alle Objekte des SSIS-Objektsmodells zur Verfügung. Der nächste Schritt ist nun sich eine SSIS-Applikationskontext zu besorgen, ein Paket zu erstellen bzw. zu öffnen, Änderungen vorzunehmen und diese wieder abzuspeichern. Hier ein Beispiel für ein Grundgerüst:

# SSIS-Kontext erstellen
$context = new-object Microsoft.SqlServer.Dts.Runtime.Application

# Neues Paket erstellen
$package = new-object Microsoft.SqlServer.Dts.Runtime.Package

# Paket nach eigenen Wünschen anpassen

# Aufräumen
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($package)[System.Runtime.Interopservices.Marshal]::ReleaseComObject($context)

Remove-Variable context
Remove-Variable package

Soll ein bereits vorhandenes Paket geöffnet werden müsste das Grundgerüst entsprechend angepasst werden:

$context.LoadPackage(“C:\TestPackage.dtsx”, $null, $false)

Variablen erstellen und/oder anpassen

Bei der Homogenisierung der Paketkonfiguration werden Variablen benötigt. Zum Beispiel können Variablen dazu verwendet werden bestimmte Connections über Expressions zu Parametrisieren. Hier ein einfaches Beispiel um dem Paket Variablen mit zu geben. Diese Variablen werden später mittels Expressions an eine Connection weitergegeben. Über diese Connection werden dann alle benötigten weiteren Connections und Variablen geladen.

$var = $package.Variables.Add(“AdminDBCatalog”, $false, “Config”, “AdminDB”)
$var = $package.Variables.Add(“AdminDBHostename”, $false, “Config”, “HOSTNAME”)

Paketkonfiguration einschalten

Wie die Connections und die Variablen ist auch die Paketkonfiguration über das Objekt-Modell zu erreichen. Der Einfachheit halber verzichte ich an dieser Stelle darauf zu überprüfen ob die Konfiguration bereits existiert. Auf das grundlegende Prinzip dabei gehe ich bei der Erstellung der Connections im nächsten Abschnitt ein.

Im folgenden erstelle ich eine Paketkonfiguration welche einen Katalog- und Hostnamen aus einer Environmentvariable läd. Später wird eine Connection dann mit den Inhalten der Variablen parametrisiert.

#Sicherstellen, dass die Paket-Konfiguration eingeschaltet ist
$package.EnableConfigurations = $true

# Katalog aus Envrironment-Variable laden
$config = $package.Configurations.Add()
$config.Name = “AdminDBCatalog”
$config.ConfigurationType = 2
$config.ConfigurationString = “AdminDBCatalog”
$config.PackagePath = “\Package.Variables[Config::AdminDBHostname].Properties[Value]”

# Katalog aus Envrironment-Variable laden
$config = $package.Configurations.Add()
$config.Name = “AdminDBHostname”
$config.ConfigurationType = 2
$config.ConfigurationString = “AdminDBHostname”
$config.PackagePath = “\Package.Variables[Config::AdminDBCatalog].Properties[Value]“

Connections erstellen oder anpassen

Wesentlicher Bestandteil einer Connection ist der Connection-String und der Connection-Type. Folgendes Beispiel zeigt die Erstellung einer einfachen OLEDB-Connection:

$conMgr = $package.Connections.Add(“OLEDB”)
$conMgr.Name = “AdminDB Connection”
$conMgr.ConnectionString = “Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=AdminDB;Data Source=HOSTNAME;Auto Translate=False;”

Den Connection String bekommt man entweder über der Database Explorer des VS, mit dem SSIS-Designer oder von http://www.connectionstrings.com/. Den Connection Type könnt ihr mit folgendem Befehl ermitteln:

$context.ConnectionInfos | select ConnectionType

ConnectionType
————–
ODBC
FLATFILE
OLEDB
MULTIFILE
MSOLAP100
HTTP
FILE
ADO.NET
FTP
ADO
MULTIFLATFILE
EXCEL
SQLMOBILE
CACHE
MSMQ
SMTP
WMI
SMOServer

In der Regel wäre es für unser Vorhaben aber besser wenn auf das Vorhandensein der Connection geprüft und diese ggf. angepasst würde. Prüfen kann man diese wie folgt:

$ErrorActionPreference = “SilentlyContinue”
$connectionName = “AdminDB Connection”
$conMgr = $package.Connections.Item($connectionName)

# Im Fehlerfall Connection neu anlegen
if (!$?) {
$conMgr = $package.Connections.Add(“OLEDB”)
$conMgr.Name = $connectionName
}

# Connections String setzen
$conMgr.ConnectionString = “Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=AdminDB;Data Source=ANDERESOURCE;Auto Translate=False;”

Diese Technik stellt sicher, dass die Connection angelegt wird oder wenn bereits vorhanden, angepasst wird. Im zweiten Schritt wird die Connection so mit Expressions parametrisiert, dass die Connection dynamisch von den beiden Enronmentvariablen AdminDBCatalog und AdminDBHost abhängt.

# Connection an die Paketkonfiguration koppeln
$conMgr.SetExpression(“InitialCatalog”, “@[Config::AdminDBCatalog]“)
$conMgr.SetExpression(“ServerName”, “@[Config::AdminDBHostname]“)

Speichern des Pakets

Gespeichert werden kann das Paket mit folgendem Kommando:

$context.SaveToXml(“C:\TestPaket.dtsx”, $null)

Fazit und Ausblick

Im weiteren Verlauf wäre es wohl Ratsam weitere Fehler abzufangen. Des weiteren müssten weitere Variablen und Connections hinzugefügt werden, die man über eine Konfigurationsdatenbank konfigurieren will. Zum Schluss müsste noch die Paketkonfiguration angepasst werden, so dass weitere Inhalte aus der Konfigurationsdatenbank in Variablen geladen werden.

Wie jedoch zu sehen ist kann man mit PoweShell-Skripten und relativ wenigen Zeilen einen kleinen IS-Paket-Generator schreiben der auch noch leicht zu verstehen und zu erweitern ist.

Die Arbeit für solch ein Skript hat man genau einmal. Sich bei jeder Änderung der Konfiguration oder der Implementierung neuer Pakete durch die Dialoge der Paketkonfiguration zu klicken ist recht mühsam, Fehleranfällig und zeitverschwenderisch.

This post is about a problem I faced some years ago. The source system was SAP with user defined hierarchies, in this case within the cost center and cost type tables. Parallel hierarchies are well supported in SQL Server BI but in this case, users in SAP could define multiple hierarchies on their own and they wanted these hierarchies to be also available in the OLAP cube. For example, costs associated with the cost center 1000 should be analyzed as shown below:

All costs that are booked on cost center 1000 have to appear in the hierarchy as shown in the sketch. And end-users may also be able to create new hierarchies (for example to analyze a certain project). Of course there may be better ways to model this but in this case we had basically two tables for the cost centers:

• table CC (Cost Center)
• table CCG (Cost Center Group)

Table CC contains all cost centers (for example the above cost center 1000) together with additional information (like name, responsible person etc.) while table CCG contains the hierarchy. in CCG we basically find two columns:

• Node name
• Parent node name

Facts (in this case actual or planned costs) are associated with the cost center number (for example 1000). Usually, parent-child hierarchies may be used in this case where we have a very dynamic structure and we do not know the number of levels. However, parent-child may only be used if each node has at most one parent. But here we find the cost center 1000 having two parents (Internal HR Costs DE and Marketing_DE). The same situation exists with the Marketing_DE node (having parents Marketing and Germany).

The solution I’m presenting here is to create additional nodes until each node only has one parent. This is possible as each node of a parent-child hierarchy in SSAS has a name and a key property. So, the name will be identical, while the key will be different. In order to show the process, let’s add internal keys to each of the hierarchy elements.

What we have to do now is to create additional nodes for every node that has more than one parent. Let’s start with the ‘Marketing_DE’ node:

The additional node gets a new (internal) key, in this example the number 8. But there is still a node with multiple parents: the cost center 1000. Let’s also transform this into separate nodes:

After this step, each node has at most one parent and therefore the structure can be modeled as an SSAS parent-child hierarchy. 

But now, we have to think about the fact rows. Without the hierarchy, facts would have been associated to the cost center by using the internal key (surrogate key), so for example 1000 € that are booked on cost center 1000 would appear in the fact table like

But now, we have to associate this single fact row to three rows in the dimension table (as the cost center 1000 appears three times now). Therefore we have to use a many-to-many approach, so we add another table, a so called bridge table with the following rows:

For technical reasons, our fact table has to be linked to a dimension (of flat cost centers), which is also used by the bridge table. This is shown in the following image:

The most difficult part here is to “normalize” the parent-child structure. One way to do this is to use a stored procedure. Here is the code I used. Within this procedure, the following tables are used:

Here is the code:

CREATE PROCEDURE [dbo].[ExpandCostcenterGroup]
AS
    SET NOCOUNT ON
    truncate table ods.costcenterGroupExpanded
   
    declare @level int
    declare @affectedrows int
    declare @totalrowcount int
       
    set @level=0
   
    insert into ods.costcenterGroupExpanded(costcentergroup,Parentgroup,Description1,Description2,Responsibility,AccountingArea)   
     Select distinct costcenterGroup, Parent,Description1,Description2,Responsibility,AccountingArea from masterdata.costcentergroup
       
    — Initialize all keys   
    update ods.costcenterGroupExpanded
    set ParentKey=(select min(costcenterkey) from ods.costcenterGroupExpanded where costcenterGroup=c.Parentgroup)   
    from ods.costcenterGroupExpanded as c
    where not c.ParentGroup is null       
   
    set @affectedrows=1   
   
    while @affectedrows>0
    begin
   
        Set @level=@level+1
       
        set @totalrowcount=(select Count(*) from ods.costcenterGroupExpanded)
   
        insert into  ods.costcenterGroupExpanded(costcentergroup,Parentgroup,ParentKey,"level",Description1,Description2,Responsibility,AccountingArea)
        select distinct cparent.costcentergroup, cparent.Parentgroup,cparent.costcenterKey,@level,cparent.Description1,cparent.Description2,cparent.Responsibility,cparent.AccountingArea
        from ods.costcenterGroupExpanded as cparent inner join ods.costcenterGroupExpanded as cchild on
        cparent.Parentgroup=cchild.costcenterGroup
        where cparent.ParentKey!=cchild.costcenterKey
        and cchild."Level"=@level-1
       
        set @affectedrows=@@rowcount
       
    end
   
    return

GO

To keep things simple, I truncate the output table CostcenterGroupExpanded here. However, there is a drawback with this approach: The surrogate keys may change after changes of the imported source tables. This will result in a problem for example for the Excel users. If you’re using filters like ‘show this element only’, only the key is stored.

In order to avoid this you will need to store the mapping and the assigned surrogate key separately. Here it is necessary not only to store the combination of cost center/parent cost center/surrogate key but the whole branch up to the root instead. If you look at the example above you will find two entries of ‘Cost Center 1000’ –> ‘Marketing_DE’, so this is not unique. You have to store the full path up to the root for each node (not only for the leaf-nodes) to make it unique:

In order to store the full path up to the root level I recommend using a hash code (MD5 for example) as this is easier to handle as a long list of node names. In this case our additional key store table would look like this

The sample code above does not manage this key store table so the keys may change a lot on each load. But for practical purposes you will have to add this key management to make sure the same node always gets the same key.

Das Servicepack hat die Versionsnummer 10.50.2500.0.

Zu den Neuerungen gehören:

• Dynamic Management Views for increased supportability
• ForceSeek for improved querying performance
• Data-tier Application Component Framework (DAC Fx) for improved database upgrade
• Disk space control for PowerPivot

Weitere Info befinden sich auf der Download Seite von Microsoft.

Some facts about the Office OLEDB provider and SSIS:

Currently the Office OLEDB provider is 32 bit only!

That is wrong! Microsoft provides a 64 bit version since December 2010. You can download it here: Microsoft Access Database Engine 2010 Redistributable

Developing SSIS packages with the 64 bit Version of the provider does not work!

Unfortunately Microsoft provides Visual Studio as 32 bit application only (Why?). Therefore it can’t access/use 64 bit OLEDB providers. As a consequence of that fact you cannot select the Office OLEDB provider. In an development environment you have to use the 32 bit provider.

Excuting SSIS packages in an 64 bit environment with 64 bit OLE DB driver does not work!

Yes and no! Using the original Excel-Source does not work. It seems that Microsoft implemented an hard if-statement which throws an exception (DTS_E_OLEDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64-bit version of SSIS, as no OLE DB provider is available.) if these conditions are met:

• DTS-Engine runs in 64 bit environment
• Connection string is “Microsoft.ACE.OLEDB.12.0″

One solution for that is to use the standard OLEDB Source. Select Microsoft.ACE.OLEDB.12.0 as OLEDB provider and set the extended properties to “Excel 14.0;HDR=YES”. Now you can use the normal OLEDB source to retrieve data from an Excel file. I found no restrictions so far.

Excel has to be installed where the SSIS package is to be executed!

That is wrong. You only need the Microsoft Access Database Engine 2010 Redistributable

The lesson is clear: Using Office OLEDB in a 64 bit environment with SSIS works (At least at the command line with DTEXEC)!

There are many recurring tasks via ETL development. I will now explain how to write a macro to automate these recurring tasks. For example we want to add a frequently used connection manager. Unfortunately the Visual Studio Macros environment isn’t set up correctly for this.

Go to the Microsoft SQL Server SDK folder: C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies

Copy the following assemblies: Microsoft.SqlServer.DTSPipelineWrap.dll Microsoft.SQLServer.DTSRuntimeWrap.dll

To the Visual Studio Public Assemblies folder: C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies

Now start Visual Studio and open an SSIS project. Select Other Windows and then Macro Explorer (Alt+F8). Right click on Macros in the Macro Explorer and select New Macro Project called MySSISMacros. Create a new module called Samples. Double click Samples to open the Macro Editor.

In the Macro Editor right click at the MySSISMacros project and select Add reference. Add references to the assemblies above and click OK.

Now you are ready to write macros for SSIS development. Here is a very simple example:

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports EnvDTE90a
Imports System.Diagnostics
Imports Microsoft.SqlServer.Dts.Runtime

Public Module Samples

    Public Sub Example01()
        Dim app As New Microsoft.SqlServer.Dts.Runtime.Application()
        Dim filename As String

        filename = DTE.ActiveDocument.FullName()
        Dim p As Package

        '' Save the document before making changes
        DTE.ActiveDocument.Save()

        '' Open the package
        p = app.LoadPackage(filename, Nothing)

        '' Do some changes
        Dim cm As ConnectionManager
        Dim connString, dataSource, catalog, provider, appName As String

        dataSource = "."
        catalog = "AdventureWorksDW2008"
        provider = "SQLNCLI10.1"
        appName = p.Name
        connString = String.Format("Data Source={0};Initial Catalog={1};Provider={2};
             Integrated Security=SSPI;Application Name={3};Auto Translate=False;"
             , dataSource, catalog, provider, appName)

        cm = p.Connections.Add("OLEDB")
        cm.ConnectionString = connString
        cm.Description = "AdventureWorks DW"
        cm.Name = "AdventureWorksDW"

        '' Save the package
        app.SaveToXml(filename, p, Nothing)
    End Sub
End Module

Download: Samples.zip

Now open a package and execute the macro. It will add a connection to the active package.

Today we released the new version of BI.Quality on Codeplex. The new release contains many features from the wishlist (check the release notes for details):

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0fd439d7-4bff-4df7-a52f-9a1be8725591

Der SQL Server 2008 R2 BPA ist ein Diagnosetool, welches den SQL Server anhand von Best Practices analysiert und einen Bericht ausgibt, in dem auf mögliche Konfigurationsfehlern oder Fehlenden Updates hinweist.

Der BPA gibt auch genaue Hinweise wie die möglichen Probleme gelöst werden können.

Diese Beitragsreihe stellt die allgemeinen Anforderungen für den Betrieb von SSIS dar. In Folgebeiträgen gehe ich auf die Stärken und Schwächen des Produktes ein. Ferner gehe ich darauf ein, wie wir diese Anforderungen standardisiert in unseren Projekten lösen.

Was sind die allgemeinen Anforderungen?

Betrieb bedeutet einen Service bereitzustellen, nicht selten 24×7, der zuverlässig funktioniert. Im Falle von SSIS werden periodisch Jobs gestartet, die projektindividuell Daten von A nach B bewegen. Das geschieht in der Regel im verborgenen, d.h. die Prozesse und deren Ergebnisse sind von Hause aus “unsichtbar”. Die nachfolgenden Anforderungen treffen wir in allen Projekten wieder:

1. statusbasierte Ergebnisüberwachung
   • Welche Jobs müssen laufen?
   • Sind diese erfolgreich gelaufen? Gewünscht ist ein einfacher Soll Ist Vergleich, analog zu Performance Management, zum Beispiel anhand von roten oder grünen Ampeln
2. Laufzeit basierte Überwachung
   • aktuell aktive Jobs (Wie lange laufen sie schon? Wie lange werden sie vermutlich noch laufen?)
   • abgeschlossene Jobs (Wie lange läuft der Job gewöhnlich? Wie hat sich die Laufzeit in der letzten Zeit entwickelt? Wie ist der Trend? Wann wird ein kritisches Limit erreicht?)
3. KPI Überwachung
   • Welche Datenmengen befördert der Job? (aktuell und gewöhnlich)
   • Anzahl von Fehlern, Korrekturen oder sonstigen wichtigen Ereignissen?
4. Fehlererkennung und Lösung
   • Sind Fehler aufgetreten?
   • Wenn ja, wo? Die Praxis zeigt, dass Logging immer falsch ist. Für den Betrieb ist das Logging in der Regel unübersichtlich und überfrachtet. Die wichtigen Informationen müssen wie Rosinen herausgepickt werden. Expertentätigkeit. Für die Fehleranalyse ist es immer zu wenig. Das Optimum ist sehr schwer zu erreichen.
   • Wer ist der geeignete Ansprechpartner?
   • Trennung nach technischen Fehlern: In aller Regel auf Systemressourcenengpässe oder Security zurückzuführen, kann durch das BI Team oder die IT gelöst werden.
   • Und fachliche Fehler: Fehler liegt in aller Regel im Vorsystem (Datenquelle), kann nicht dauerhaft durch das BI Team gelöst werden, sondern fällt in die Zuständigkeit der Quellsysteme. Das ist einer der wesentlichen Beiträge der BI zur Verbesserung der primären Datenqualität! In der Regel wechselt hier die organisatorische Zuständigkeit. Nicht selten wird eine “andere Sprache gesprochen”.
5. Optimierung
   • Die Daten sind wichtig für die Erkennung des Optimierungsbedarfs. Wie so soft machen 20% des Codes 80% der Laufzeit aus. Deshalb ist eine längerfristige Bevorratung wichtig.
6. Performance
   • Trotz langer Bevorratung von Logging Informationen müssen alle Berichte innerhalb von 2 Sekunden zur Verfügung stehen
   • Alle Berichte müssen die Gegenwart zeigen, d.h. Bewirtschaftungszeiten werden nicht akzeptiert 
7. Nachrüstbarkeit
   • Ganz gleich in welcher Phase ein SSIS Projekt ist: Die hier genannten Anforderungen müssen leicht nachrüstbar sein. Besser noch. Bestehende Loggingdaten sollten in die neue Welt migriert werden können.

BI mit BI betreiben!

Nach Durchsicht der Anforderungen ist die Lösung recht naheliegend: Alle Betriebsanforderungen erfordern die Sammlung und Aufbereitung von Daten. Das ist die wesentliche BI Kernkompetenz!

Das ist das zentrale Ziel unserer Projekte: Ein standardisiertes Datenmodell mit standardisierten Berichten und einer standardisierten Vorgabe für die Entwicklung, um die hier darstellten Anforderungen zu erfüllen.

Damit erfüllen sich auch weitere, unausgesprochene Anforderungen:

1. Mit der Standardisierung kann eine BI Plattform kostengünstiger erstellt werden. Die Entwickler können sich zu 100% auf die Business Lösung konzentrieren und müssen sich nicht mit Fehlerhandling auseinandersetzen. Wir werden oft in Projekte gerufen, bei denen dieser Teil der Umsetzung eine signifikante Größe eingenommen hat und den Blick auf das wesentliche eintrübt.
2. Mit der Standardisierung kann eine BI Plattform kostengünstiger betrieben werden. Das Personal benötigt für den 1rst und 2nd Level Support keine tiefen Projektkenntnisse. Es bekommt effizient die Informationen, die es benötigt.
3. Consultants können zwischen den Projekten leichter wechseln

In den nächsten Beiträgen erläutere ich, was die Stärken und Schwächen des Produktes SSIS sind und was zur Erfüllung der Anforderungen erforderlich ist.