Namenskonvention für SSIS-Tasks — damit das Ausführungsprotokoll endlich lesbar ist

Ein SSIS-Paket schlägt fehl, der Blick ins Ausführungsprotokoll soll die Ursache liefern — und trifft auf eine Baumstruktur, in der die Tasks nicht in der Reihenfolge ihrer Ausführung stehen, sondern alphabetisch nach Namen. Bei komplexen Paketen wird dieses Protokoll schlicht unlesbar. Die gute Nachricht: Eine durchdachte Namenskonvention macht das Protokoll wieder lesbar — allein über die Benennung.

Das Wichtigste vorab:

• Das Problem: SSIS protokolliert Tasks alphabetisch nach Task-Namen je Container, nicht in Ausführungsreihenfolge — belegt per Screenshots in Visual Studio 2017, im Reiter Progress wie auch in den Integration-Services-Catalog-Reports (Versions-Hinweis siehe unten).
• Nummerierung als Präfix macht die beabsichtigte Ausführungsreihenfolge im Protokoll sichtbar.
• Typ-Präfix (DFT, SQL, SCR, …) macht den Task-Typ im rein textuellen Protokoll erkennbar.
• Sprechender Name + die Gesamt-Syntax XXXX [YYYY] ZZZ Name machen jeden Task-Namen eindeutig und selbsterklärend.
• SSIS heute läuft über die VS-2022/2026-Extension — die Konvention bleibt gültig, und ihr Prinzip überträgt sich auf moderne ETL-Tools (Azure Data Factory, Fabric, dbt, Airflow).

Voraussetzung: ein SSIS-Projekt in Visual Studio (mit der SQL Server Integration Services Projects-Extension). Die Screenshots stammen aus Visual Studio 2017. Die Konvention selbst ist nicht an eine bestimmte SSIS-Version gebunden; die Aussagen zum Protokoll-Verhalten beziehen sich auf diesen getesteten Stand (siehe Versions-Hinweis).

Inhalt

• Warum SSIS-Tasks eine Namenskonvention brauchen
• Nummerierung aller Tasks entsprechend der Ausführungsreihenfolge
• Präfix für jeden Typ einer Task
• Task-Name
• Namenskonvention
• SSIS heute: Tooling-Update und Einordnung
• Fazit
• FAQ

Warum SSIS-Tasks eine Namenskonvention brauchen

Namenskonventionen sind nur dann sinnvoll, wenn sie im Alltag einen konkreten Vorteil bringen. Meist stehen Lesbarkeit und Wartbarkeit von Code im Vordergrund. Im Falle von SQL Server Integration Services (SSIS) kommt jedoch noch ein weiterer Aspekt hinzu: die Protokollierung der Ausführung eines Paketes im Reiter Execution Results bzw. Progress in der Entwicklungsumgebung Visual Studio. Die Ausführung wird in einer Baumstruktur protokolliert. Bei komplexen Paketen mit Unterpaketen, For Each Loop Containern, Sequence Containern etc. wird die Baumstruktur schnell lang und tief. Es ist schwer, die Ausführungsreihenfolge der Tasks in der Baumstruktur nachzuvollziehen und im Fehlerfall die Fehlerursache schnell zu identifizieren.

Ursächlich hierfür ist aber nicht die Komplexität eines Paketes oder die Schachtelungstiefe. SSIS zeigt die ausgeführten Tasks in der hier getesteten Umgebung (Visual Studio 2017) nicht in der Reihenfolge der Ausführung an. Die Anordnung von ausgeführten Tasks in der Baumstruktur erfolgt in alphabetischer Reihenfolge der Task-Namen je Container. (Einordnung gegenüber der aktuellen Microsoft-Dokumentation: siehe Versions-Hinweis in der Sektion „SSIS heute“.)

Der nachfolgende Screenshot zeigt einen vermeintlich übersichtlichen Control Flow nach einer Ausführung in Visual Studio 2017:

Zu beachten sind hier:

• Die Namen der Sequence Container sind so gewählt, dass der Container mit dem Suffix 2 vor dem Container mit dem Suffix 1 ausgeführt wird.
• Innerhalb der Sequence Container sind die enthaltenen Control Flow Tasks so benannt, dass die Tasks mit dem Präfix 2 vor den Tasks mit dem Präfix 1 ausgeführt werden.
• Zwischen den beiden Sequence Containern werden 3 Skript Tasks ausgeführt, die durch die Präfixe C, B und A entgegen der Ausführungsreihenfolge benannt sind.

Die beiden Data Flows enthalten identische Data Flow Tasks. Die Tasks sind so benannt, dass sie entgegen der alphabetischen Sortierung nach dem Task-Namen ausgeführt werden. Zuerst wird die Task OLE-DB Source ausgeführt und danach erst die Task Count.

Die Ausführung der Control und Data Flow Tasks wurde im Reiter Progress des ausgeführten Paketes nicht in der Reihenfolge der tatsächlichen Ausführung, sondern in der Reihenfolge der alphabetischen Sortierung der Task-Namen je Container protokolliert:

Bei umfangreichen und komplexen Transformationsprozessen wird die Zuordnung zwischen Protokoll-Eintrag und tatsächlicher Ausführungsabfolge damit unnötig schwierig. Die gezeigten Screenshots betreffen zunächst die Entwicklung von SSIS-Paketen. Wie sieht es im Betrieb von SSIS-Solutions aus, wenn diese im Integration Services Catalogs bereitgestellt und ausgeführt werden? Das Ausführungsprotokoll eines im Integration Services Catalogs bereitgestellten Paketes kann über die Standard-Berichte

Rechtsklick auf Projekt/Paket > Reports | Standard Reports | All Executions

aufgerufen werden. Und tatsächlich zeigte auch dieser Standardbericht im selben getesteten Stand die Ausführung von Tasks nicht entsprechend der tatsächlichen Ausführungsreihenfolge (Screenshot als Beleg). Die zugrunde liegende SSISDB speichert dabei durchaus Start- und Endzeiten je ausgeführtem Element — per eigener Abfrage ließe sich die tatsächliche Reihenfolge rekonstruieren, die Standard-Darstellung machte sie nur nicht unmittelbar ablesbar:

Daraus ergibt sich die Forderung nach einer Task-Benennung, die eine Protokollierung in der Reihenfolge der Ausführung sicherstellt. Drei weit verbreitete Konventions-Bausteine erhöhen die Lesbarkeit von Paketen zur Entwurfszeit wie auch die Lesbarkeit des Protokolls zur Laufzeit:

• Nummerierung aller Tasks entsprechend der Ausführungsreihenfolge
• Präfix für jeden Task-Typ
• Task-Name beschreibt das, was die Task macht

Nummerierung aller Tasks entsprechend der Ausführungsreihenfolge

Bei der Nummerierung ist zwischen Control Flow Tasks und Data Flow Tasks zu unterscheiden.

Control Flow Tasks

Alle Tasks sollten über eine aufsteigende Nummerierung als Präfix verfügen, die der Ausführungsreihenfolge entspricht — bei parallelen Zweigen gibt es keine einzige lineare Reihenfolge, die Nummerierung bildet dann die modellierte Abfolge ab. Bewährt hat sich ein vierstelliger Nummernkreis (Nummern bis 9999) mit führenden Nullen bei kleineren Zahlen. Die Nummerierung sollte Lücken aufweisen, damit sich bei einer geänderten Reihenfolge neue Nummern einfügen lassen, ohne alle nachfolgenden Tasks umbenennen zu müssen. Die Nummerierung von Tasks ist mit Aufwand verbunden. Die Erfahrung aus Mehrentwickler-Projekten zeigt aber, dass diese Namenskonvention weithin akzeptiert und gewinnbringend angewandt wird.

Das folgende Ausführungsprotokoll listet die Tasks in der Reihenfolge ihrer Ausführung auf und ist damit ungleich lesbarer als die erste Version:

Data Flow Tasks

Im hier betrachteten Progress-/Catalog-Kontext wird der Data Flow selbst als Task protokolliert — seine einzelnen Komponenten erscheinen dort nicht als eigene Task-Einträge. Bei ihrer Benennung geht es deshalb weniger um die Sortierung als um die eindeutige Identifikation im Fehlerfall. Deshalb ist es ratsam, die oben beschriebene Systematik der Benennung auch in Data Flows beizubehalten und sogar noch zu erweitern:

Die erste ausgeführte Data Flow Task hat als Präfix die Nummer 0110. Dieses Präfix ist für alle Data Flow Tasks zu verwenden, gefolgt von einer weiteren Nummer, um die Tasks im Data Flow eindeutig identifizieren zu können. Damit werden jedem Data Flow Task-Namen zwei Nummern vorangestellt.

• Control Flow Nummer
• Data Flow Nummer

Im Fehlerfall wird schließlich auch der Task-Name der Data Flow Task protokolliert, die einen Fehler verursacht hat. Die Vergabe eindeutiger Nummern ermöglicht eine zweifelsfreie und vor allem schnelle Identifikation der Fehler verursachenden Task:

Präfix für jeden Typ einer Task

Jeder Task-Typ verfügt in Visual Studio über ein eigenes Piktogramm. Der stilisierten Darstellung von Task-Typen sind aber aufgrund der verfügbaren Größe der Piktogramme Grenzen gesetzt. Zudem handelt es sich hier um eine visuelle Darstellung, die in dem Ausführungsprotokoll nicht zur Verfügung steht. Die Unterscheidung der Tasks im Reiter Execution Results bzw. Progress erfordert daher eine Kennzeichnung über ein Präfix, das den Typ der Task identifiziert.

Um die Lesbarkeit zu erhöhen, hat es sich bewährt, den Task-Namen in Abhängigkeit vom Task-Typ ein Präfix bzw. eine Abkürzung voranzustellen:

• DFT für Data Flow Task
• SCR für Script Task
• SQL für Execute SQL Task
• …

Im Internet finden sich einige Vorschläge für diese Präfixe. Die folgenden beiden Listen zeigen die in eigenen Projekten bewährte Präfix-Konvention — eine Beispiel-Konvention, kein aktueller Referenz-Katalog. Sie spiegeln den Komponenten-Stand ihrer Entstehungszeit: Die Azure-Komponenten setzen das Azure Feature Pack voraus, die SQL Server Compact Destination wird in aktuellen Visual-Studio-Versionen nicht mehr unterstützt, und die KingswaySoft-Einträge sind Dritt-Anbieter-Komponenten (siehe Spalte „Anbieter“).iden Listen habe ich die von mir verwendeten Task-Präfixe zusammengetragen:

Präfixe für Control Flow Tasks

Task	Präfix
Back Up Database Task	BACKUP
CDC Control Task	CDC
Check Database Integrity Task	CHECKDB
Data Profiling Task	DPT
Execute SQL Server Agent Job Task	AGENT
Execute T-SQL Statement Task	TSQL
History Cleanup Task	HISTCT
Maintenance Cleanup Task	MAINCT
Notify Operator Task	NOT
Rebuild Index Task	REBIT
Reorganize Index Task	REOIT
Shrink Database Task	SHRINKDB
Update Statistics Task	STAT
For Loop Container	FLC
Foreach Loop Container	FELC
Sequence Container	SEQC
ActiveX Script	AXS
Analysis Services Execute DDL Task	ASE
Analysis Services Processing Task	ASP
Bulk Insert Task	BLK
Data Flow Task	DFT
Data Mining Query Task	DMQ
Execute Package Task	EPT
Execute Process Task	EPR
Execute SQL Task	SQL
Expression Task	EXPR
File System Task	FSYS
FTP Task	FTP
Message Queue Task	MSMQ
Script Task	SCR
Send Mail Task	SMT
Transfer Database Task	TDB
Transfer Error Messages Task	TEM
Transfer Jobs Task	TJT
Transfer Logins Task	TLT
Transfer Master Stored Procedures Task	TSP
Transfer SQL Server Objects Task	TSO
Web Service Task	WST
WMI Data Reader Task	WMID
WMI Event Watcher Task	WMIE
XML Task	XML

Präfixe für Data Flow Tasks

Task	Präfix	Type	Supplier
ADO NET Source	ADO_SRC	Source
Azure Blob Source	AB_SRC	Source
CDC Source	CDC_SRC	Source
DataReader Source	DR_SRC	Source
Excel Source	EX_SRC	Source
Flat File Source	FF_SRC	Source
HDFS File Source	HDFS_SRC	Source
OData Source	ODATA_SRC	Source
ODBC Source	ODBC_SRC	Source
OLE DB Source	OLE_SRC	Source
Raw File Source	RF_SRC	Source
SharePoint List Source	SPL_SRC	Source
XML Source	XML_SRC	Source
Aggregate	AGG	Transformation
Audit	AUD	Transformation
Balanced Data Distributor	BDD	Transformation
Cache Transform	CCH	Transformation
CDC Splitter	CDCS	Transformation
Character Map	CHM	Transformation
Conditional Split	CSPL	Transformation
Copy Column	CPYC	Transformation
Data Conversion	DCNV	Transformation
Data Mining Query	DMQ	Transformation
Derived Column	DER	Transformation
DQS Cleansing	DQSC	Transformation
Export Column	EXPC	Transformation
Fuzzy Grouping	FZG	Transformation
Fuzzy Lookup	FZL	Transformation
Import Column	IMPC	Transformation
Lookup	LKP	Transformation
Merge	MRG	Transformation
Merge Join	MRGJ	Transformation
Multicast	MLT	Transformation
OLE DB Command	CMD	Transformation
Percentage Sampling	PSMP	Transformation
Pivot	PVT	Transformation
Row Count	CNT	Transformation
Row Sampling	RSMP	Transformation
Script Component	SCR	Transformation
Slowly Changing Dimension	SCD	Transformation
Sort	SRT	Transformation
Term Extraction	TEX	Transformation
Term Lookup	TEL	Transformation
Union All	ALL	Transformation
Unpivot	UPVT	Transformation
ADO NET Destination	ADO_DST	Destination
Azure Blob Destination	AB_DST	Destination
Data Mining Model Training	DMMT_DST	Destination
Data Streaming Destination	DS_DST	Destination
DataReaderDest	DR_DST	Destination
Dimension Processing	DP_DST	Destination
Excel Destination	EX_DST	Destination
Flat File Destination	FF_DST	Destination
HDFS File Destination	HDFS_DST	Destination
ODBC Destination	ODBC_DST	Destination
OLE DB Destination	OLE_DST	Destination
Partition Processing	PP_DST	Destination
Raw File Destination	RF_DST	Destination
Recordset Destination	RS_DST	Destination
SharePoint List Destination	SPL_DST	Destination
SQL Server Compact Destination	SSC_DST	Destination
SQL Server Destination	SS_DST	Destination
Microsoft Dynamics 365 CE/CRM Source	CRM_SRC	Source	KingswaySoft Software
Microsoft Dynamics 365 CE/CRM Destination	CRM_DST	Destination	KingswaySoft Software
Oracle Eloqua Source	ELO_SRC	Source	KingswaySoft Software
Oracle Eloqua Destination	ELO_DST	Destination	KingswaySoft Software

Task-Name

Zu guter Letzt: Der eigentliche Task-Name sollte kurz und knapp beschreiben, was die Task macht — zum Beispiel Import Customer oder Check Data Types.

Namenskonvention

Für die Fehlersuche sollten innerhalb eines SSIS-Paketes alle Task-Namen — unabhängig davon, ob es sich um einen Control Flow Task oder einen Data Flow Task handelt — eindeutig sein. Die folgende Namenskonvention stellt das sicher und folgt dieser Syntax:

XXXX [YYYY] ZZZ Name

mit

XXXX

• Nummerierung der Control Flow Tasks.
• Die Nummerierung von Control Flow Tasks sollte 4-stellig sein.
• Bei kleinen Nummern sind führende Nullen voranzustellen.
• Die Nummerierung sollte Lücken aufweisen, damit bei Änderungen der Control-Flow-Reihenfolge (Precedence Constraints) neue Nummern eingefügt werden können, ohne alle nachfolgenden Tasks umbenennen zu müssen.

YYYY

• Nummerierung der Data Flow Tasks
• Die Nummerierung von Data Flow Tasks enthält als Präfix immer die Nummer der Control Flow Task vom Typ Data Flow (XXXX).
• Die Nummerierung von Data Flow Tasks sollte 4-stellig sein.
• Bei kleinen Nummern sind führende Nullen voranzustellen.
• Die Nummerierung sollte Lücken aufweisen, damit bei Änderungen der Control-Flow-Reihenfolge (Precedence Constraints) neue Nummern eingefügt werden können, ohne alle nachfolgenden Tasks umbenennen zu müssen.

ZZZ

• Präfix, das den Typ der Control Flow oder Data Flow Task identifiziert.
• Liste mit Präfixen (siehe oben).

Name

• Kurze und bedeutungsvolle Umschreibung dessen, was die Aufgabe der Task ist.

Zwei vollständige Beispiele: 0100 SQL Truncate Staging für eine Execute-SQL-Task im Control Flow und 0110 0200 LKP Lookup Customer für eine Lookup-Komponente im Data Flow der Control-Flow-Task 0110.

SSIS heute: Tooling-Update und Einordnung

Die Screenshots in diesem Artikel stammen aus Visual Studio 2017 — die Konvention selbst ist seither unverändert gültig. Geändert hat sich das Tooling: SSIS-Pakete werden heute mit der separat zu installierenden Extension SQL Server Integration Services Projects 2022+ gebaut, die Visual Studio 2022 und 2026 unterstützt und Zielversionen bis SQL Server 2025 abdeckt (laut SSDT-Dokumentation ab SQL Server 2019, laut den Release-Notes der Extension ab SQL Server 2017). Die grundlegenden Konzepte der Ausführungsüberwachung (Reiter Progress / Execution Results, Catalog-Berichte) bestehen weiter. Darstellung und Sortierung im Detail sollten für die eingesetzte Version geprüft werden.

Versions-Hinweis: Die Screenshots dieses Artikels belegen das Verhalten des Progress-Tabs in Visual Studio 2017: Die protokollierten Tasks erscheinen dort je Container alphabetisch nach Namen, nicht in ihrer tatsächlichen Ausführungsreihenfolge. Microsofts aktuelle Dokumentation beschreibt den Progress-Tab dagegen als Darstellung „in execution order“ — wann oder ob dieses Verhalten geändert wurde, ist aus den Quellen nicht ersichtlich. Für neuere SSIS-Versionen lohnt deshalb ein kurzer eigener Test. Die Namenskonvention ist davon unabhängig sinnvoll, weil sie die Identifikation von Tasks im Entwurf wie im Protokoll erleichtert.

Die Konvention bleibt in jedem Fall nützlich, denn die drei Bausteine wirken unabhängig von der exakten Sortierreihenfolge: Eine Nummerierung macht das Protokoll scanbar, ein Typ-Präfix macht den Task-Typ im reinen Text erkennbar, und ein eindeutiger Name erlaubt im Fehlerfall die zweifelsfreie Zuordnung — egal, wie die Einträge angeordnet sind.

Wohin sich ETL bewegt

SSIS bleibt der etablierte On-Premises-ETL-Motor und wird weiter gepflegt. Für neue Projekte verschiebt sich der Schwerpunkt aber: In der Microsoft-Welt übernehmen Azure Data Factory und Microsoft Fabric die Cloud-Orchestrierung. Im Open-Source- und Postgres-Umfeld haben sich dbt (Transformation) und Apache Airflow (Orchestrierung) etabliert. Die Grundidee dieses Artikels überträgt sich direkt: Auch dort entscheidet eine konsequente Benennung von Schritten und Modellen darüber, ob ein Lauf-Protokoll lesbar bleibt.

Fazit

SSIS protokollierte Tasks im getesteten Stand (Visual Studio 2017) alphabetisch nach Namen je Container, im Reiter Progress wie in den Catalog-Berichten. Eine Namenskonvention aus drei Bausteinen macht das Protokoll unabhängig davon lesbar: Eine vierstellige Nummerierung mit Lücken macht die beabsichtigte Ausführungsreihenfolge sichtbar, ein Typ-Präfix macht den Task-Typ im reinen Text erkennbar, und ein sprechender Name ordnet im Fehlerfall jeden Eintrag zweifelsfrei zu. Zusammen ergibt das die Syntax XXXX [YYYY] ZZZ Name. Die Konvention kostet beim Bauen ein wenig Disziplin und zahlt sich bei jeder Fehlersuche aus — unabhängig von der Visual-Studio-Version, und im Prinzip auch in modernen ETL-Stacks von Azure Data Factory bis Airflow.

FAQ