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.