Namenskonvention für SSIS Tasks

Die Festlegung von Programmierrichtlinien und Namenskonventionen macht nur dann Sinn, wenn sie Gewinn bringend eingesetzt werden können. Voraussetzung hierfür ist, dass die Vorteile klar identifiziert und benannt werden können. Die Lesbarkeit und Wartbarkeit von Code steht im Allgemeinen im Vordergrund. Im Falle von SQL Server Integration Services (SSIS) kommt jedoch noch ein weiterer Aspekt hinzu: die Protokollierung der Ausführung eines Paketes in dem 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. Wer ist nicht schon an dieser vermeintlich einfachen Aufgabe verzweifelt?!

Ursächlich hierfür ist aber nicht die Komplexität eines Paketes oder die Schachtelungstiefe. SSIS zeigt die ausgeführten Tasks 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.

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 wird in dem 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 ist dieses Ausführungsprotokoll schlicht unlesbar. Warum Microsoft dieses Systematik gewählt hat, ist nicht nachvollziehbar. Nun sind die gezeigten Screenshots bzw. die gewonnenen Erkenntnisse eher für die Entwicklung von SSIS Paketen relevant. Wie sieht es im Betrieb von SSIS Solutions aus, wenn diese in dem Integration Services Catalogs bereitgestellt und ausgeführt werden? Das Ausführungsprotokoll eines im Integration Services Catalogs bereitgestellten Paketes kann über die Standard-Berichte

Rechter Mausklick auf Projekt/Paket > Reports| Standard Reports | All Executions

aufgerufen werden. Und tatsächlich wird auch hier die Ausführung von Tasks nicht entsprechend der tatsächlichen Ausführungsreihenfolge protokolliert:

Aus den gewonnenen Erkenntnissen ergibt sich die Forderung nach einer Benennung von Tasks, die eine korrekte – der Reihenfolge der Ausführung von Tasks entsprechende – Protokollierung von Tasks sicherstellt. Es gibt zwei weitere weit verbreitete Namenskonventionen, die die Lesbarkeit von Paketen sowohl zur Entwurfszeit aber auch die Lesbarkeit des Protokolls zur Laufzeit erhöhen.

  • 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 von Tasks ist zwischen der Nummerierung von 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 in aufsteigender Reihenfolge der Ausführungsreihenfolge entspricht. Die Nummerierung sollte einen vierstelligen Nummernkreis unterstützen (also Nummern bis mindestens 9999) und bei kleineren Zahlen führende Nullen aufweisen. Die Nummerierung sollte keineswegs geschlossen sein, also noch Lücken aufweisen, damit die Reihenfolge der Ausführung durch Änderung der Nummerierung einfach geändert werden kann. Natürlich ist die Nummerierung von Tasks mit Aufwand verbunden. Aus der Erfahrung aus Mehrentwicklerprojekten kann ich aber berichten, dass diese Namenskonvention weithin akzeptiert und auch gewinnbringend angewandt wurde.

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

In dem normalen Ausführungsplan sind Data Flow Tasks nicht enthalten. Trotzdem ist es ratsam die oben beschriebene Systematik der Benennung von Tasks auch in Data Flows beizubehalten bzw. 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 in dem 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 wir 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 in dem 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 ist daher allgemein anerkannt, den Task Namen in Abhängigkeit von dem Task Typ ein Präfix bzw. eine Abkürzung voranzustellen:

  • DFT für Data Flow Task
  • SCT für Script Task
  • SQL für SQL Execute Task

Im Internet findet man einige Vorschläge für diese Präfixe. In den folgenden beiden Listen habe ich die von mir verwendeten Task Präfixen zusammengetragen:

Präfixe für Control Flow Tasks

Task Präfix Typ
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… Natürlich sollte der eigentliche Task Name kurz und knapp das beschreiben, was die Task macht. Zum Beispiel Import Customer, Check Data Types, usw.

Namenskonvention

Innerhalb eines SSIS Paketes sollten alle Tasknamen, unabhängig davon ob es sich um einen Control Flow Task oder einen Data Flow Task handelt, eindeutig sein. Die folgende Namenskonvention stellt dieses sicher und folgt der folgenden 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, um eine nachträgliche Änderung der Reihenfolge durch Veränderung der Precedence Constraints zu vereinfachen.

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, um eine nachträgliche Änderung der Reihenfolge durch Veränderung der Precedence Constraints zu vereinfachen.

ZZZ

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

Name

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