Archiv für den Monat: November 2008

Business Objects, Projekte

Nettes Projekt: Im InfoView von BO XI R2 die Prompts anpassen

Schreibe einen Kommentar

MultiBase hat einen Kunden, der schon seit langem mit Business Objects arbeitet. Da es ein weltweit tätiges Unternehmen ist, wollte der Kunde die Namen der Berichte, Kategorien und Prompts in mehreren Sprachen anzeigen. Außerdem sollten die Prompts schöner + benutzerfreundlicher gestaltet werden unter Verwendung von Listen, Komboboxen, Checkboxen, abhängigen Prompts (ausgewähltes Land bestimmt den Inhalt der Bundesland-Kombobox) und allem, was das Herz begehrt.

In einem früheren Projekt hatten wir bereits diese Anforderung in BO 6.5 umgesetzt. Dazu hatten wir die ASP-WebI-Version verwendet und die ASP-Seiten modifiziert.

Jetzt beim Umstieg auf XI R2 sollten dieselben Anforderungen auch dort umgesetzt werden. Deswegen verwendeten wir dort das .NET InfoView. Da dazu alle Sourcen mitgeliefert werden, war es möglich, sich an einer Stelle in den bestehenden Code zu hängen und über eine Art Weiche (wenn in unserer Meta-Datenbank zu diesem Bericht Einstellungen gesetzt waren) auf eigenen aspx-Code umzuleiten. Dort erstellen wir in HTML die Prompts wie in einer Meta-Datenbank definiert. Letzlich definiert „unsere“ Seite dann die gleichen hidden fields, die auch die Originalseite definiert und somit können wir dann wieder in den Standard-Code zurückkehren.

Dieses Projekt ist nicht typisch für meine Projekte (es hat ja auch gar nichts mit Microsoft zu tun), aber es war trotzdem recht nett, weil es gelang, (trotz sehr schlechter Dokumentation) eine sehr schöne Erweiterung für InfoView zu erstellen.

Dabei musste man eine ausgewogene Lösung finden, die folgenden Anforderungen genügt:

  • Umsetzung der fachlichen Anforderung (Mehrsprachigkeit, Prompts)
  • Geringe Kosten: Kein eigenes Frontend bauen, sondern nur an wenigen Stellen das vorhandene verbessern
  • Nur minimale Veränderungen an dem bestehenden BO-Code, da jede Veränderung Probleme nach sich zieht (Beim Einspielen von Service Packs etc.).

Jetzt sind wir richtig stolz, was wir aus BO XI gezaubert haben.

Ich war in diesem Projekt für die technische Konzeption und für die Erarbeitung der grundsätzlichen Logik, wie wir uns an welchen Stellen in InfoView einhängen können.

MS SQL Server

SQL Server: Versteckte Einstellung für Copy & Paste mit Spaltenüberschriften

Schreibe einen Kommentar

Es kommt ziemlich oft vor, dass man das Ergebnis einer SQL-Abfrage (aus dem SQL Server Management Studio) in Excel weiterbearbeiten will (z.B. Filtern, Sortieren etc.). Dabei ist extrem störend, dass die Spaltenüberschriften nicht mit kopiert werden. Glücklicherweise kann man das unter Tools > Options einstellen:

Einstellungen, um die Spaltenüberschriften bei Copy&Paste mitzunehmen

PS: Danke, Stefan, für den Tip.

MS Integration Services

Konfigurationsdateien im SSIS – Nutzen und Fallen

Schreibe einen Kommentar

In SSIS-Paketen können alle möglichen Einstellungen in Konfigurationsdateien ausgelagert werden. Insbesondere können damit

  • die Eigenschaften von Verbindungen wie ConnectionString, User, Passwort
  • oder Variablen wie Name des zu durchsuchenden Datei-Ordners oder ähnliches

extern konfiguriert werden – ganz analog zur web.config in ASP.NET oder app.config in Windows-Programmen. Theoretisch ist es möglich, viel mehr Attribute als oben genannte in der Konfigurationsdatei zu pflegen – aus Übersichtlichkeitsgründen ist das aber nicht empfohlen.

Dies hat den Sinn, dass das Paket in der Entwicklungs-, Test- und Produktionsumgebung immer gleich ist und nur die Konfigurationsdateien bei einer Installation angepasst werden. Dadurch wird sichergestellt, dass wirklich das getestete Paket in Produktion geht und nicht aus Versehen beim Öffnen im Visual Studio irgendwelche Einstellungen angepasst wurden. Dies ist in meinen Augen – neben vielen anderen Features – ein wesentlicher Vorteil von SSIS gegenüber seinem Vorgänger DTS.

Konfigurationsdateien werden erstellt über SSIS > Package Configurations… :

Erstellen von Konfigurationsdateien

In der Regel werden XML-Konfigurationsdateien verwendet. Dort kann man den Ort der Konfigurationsdatei und die enthaltenen Attribute angeben. Dadurch erzeugt das Visual Studio die entsprechende Konfigurationsdatei. In dieser Konfigurationsdatei sind alle Werte der Attribute gespeichert, so wie sie derzeit (im Verbindungsmanager, Variablenfenster, etc.) definiert sind. Einzige Ausnahme: Falls im Verbindungsmanager ein Passwort verwendet wird, wird in der Konfigurationsdatei zwar dieses Attribut angelegt, aber nicht der Wert übernommen. (erste kleine Falle)

Nun ist die Idee, bei der Installation in der Produktiv-Umgebung das dtsx-Paket unverändert zu lassen und nur die Konfigurationsdatei anzupassen. Beim Starten des Pakets kann man dann die zu verwendende Konfigurationsdatei angeben (z.B. im SQL Server Agent oder beim direkten Aufruf von DTExec) und diese wird beim Ausführen des Pakets verwendet.

Beispiel für die Verwendung einer Konfigurationsdatei im SQL Server Agent

Allerdings gibt es ein paar Fallen, die man umschiffen sollte:

Falle 1: Änderungen an Variablen während der Entwicklung gehen beim Starten des Pakets im Visual Studio verloren:

Wenn man im Visual Studio Eigenschaften ändert, die bereits in die Konfigurationsdatei exportiert wurden, ist diese Änderung wirkungslos. Beim Start des Pakets wird ja die Konfigurationsdatei geladen und dessen Wert verwendet. Eine automatische Aktualisierung der Konfigurationsdatei bei Änderungen im Visual Studio findet (glücklicherweise) nicht statt.

Falle 2: Das Paket versucht beim Start die im Paket definierte Konfigurationsdatei zu laden

Im produktiven Umfeld liegt die Konfigurationsdatei wahrscheinlich nicht am selben Ort (im Dateisystem) wie in der Entwicklungsumgebung. Wenn man nun das Paket (wie unter Idee beschrieben) in der Produktion unter Angabe der Produktions-Konfigurationsdatei startet, so versucht das Paket zunächst die Datei zu laden, deren Pfad im Paket (s. obiger Screenshot) definiert ist. Diese Datei wird in der Regel nicht gefunden werden. Dies wird als Fehler protokolliert – das Paket bricht aber nicht ab. Danach wird die beim Aufruf mitgegebene Konfigurationsdatei geladen. Somit läuft das Paket sauber durch – allerdings ist ein Fehler protokolliert, der Verwirrung stiften kann. Deswegen ist es am sinnvollsten, den Haken bei „Enable package configurations“ (s. Screenshot) wieder zu entfernen. Durch diesen Haken hat man sich somit nur auf einfache Art und Weise eine Konfigurationsdatei erstellen lassen (anstelle sie komplett selbst manuell zu erstellen).

Nun könnte man sich wundern, ob dann trotzdem die beim Aufruf mitgegebene Konfigurationsdatei geladen wird. Die Bedeutung des Hakens ist in meinen Augen nämlich etwas verwirrend. Es besagt nämlich nicht „Dieses Paket hat eine Kofnigurationsdatei mit den dort eingestellten Attributen“. Egal ob der Haken gesetzt ist oder nicht, kann eine Konfigurationsdatei beim Start angegeben werden, die beliebige Attribute verändert, also auch Attribute, die nicht im Visual Studio zum Export in die Konfigurationsdatei markiert worden waren. Der Haken besagt somit, dass „Dieses Paket lädt beim Start automatisch die angegebene Konfigurationsdatei – danach werden die beim Start übergebenen Konfigurationsdateien geladen“.

Dieses Verhalten ist in meinen Augen wenig intuitiv – aber so ist es halt. Dadurch kann man sein eigenes Paket also auch nicht schützen, so dass bestimmte Attribute nicht von außen durch Konfigurationsdateien überschrieben werden können.

MS Integration Services, SQL Server Agent

Verschlüsselungs-Fehlermeldung beim Ausführen von SSIS-Paketen

Schreibe einen Kommentar

Ein gängiges Szenario für das produktive Ausführen von SSIS-Paketen ist die Ausführung im SQL Server Agent.

Für Verwirrung sorgt dabei häufig eine Fehlermeldung, dass der Knoten aufgrund eines Verschlüsselungsfehlers nicht geöffnet werden kann. Falls ein Paket nicht ausgeführt werden konnte, führt das leicht auf eine falsche Fährte.

kryptographischer Fehler

Dieser Fehler ist nämlich nicht Ursache dafür, dass das Paket auf einen Fehler gelaufen ist. Dieser Fehler tritt in folgender Situation auf:

  • Das Paket wird durch einen User geöffnet, der das Paket nicht gespeichert hat.
  • Das Paket enthält eine Verbindung, die ein Passwort gesetzt hat – auch wenn diese Verbindung gar nicht verwendet wird (weil die Verbindungsinformationen z.B. durch eine Konfigurationsdatei o.ä. überschrieben werden.)
  • Die Einstellungen des Pakets (ProtectionLevel) stehen auf „encrypt sensitive with user key“

Dann versucht Integration Services nämlich alle sensitiven Daten – das ist vor allem das Password in einer Verbindung – mit dem aktuellen User zu entschlüsseln – und scheitert und protokolliert den Fehler. Integration Services bricht dann aber nicht die Verarbeitung ab, sondern verwendet dann ein leeres Passwort. In meinem Beispiel-Screenshot war der tatsächliche Fehler eine (bewusst herbeigeführte) Division durch Null. Diesen Fehler sieht man ganz am Ende.

Im produktiven Umfeld ist das im Normalfall kein Problem, da normalerweise Integrierte Sicherheit (also Anmeldung mit dem Windows-User) verwendet wird oder die Verbindungsinformationen (Server, Datenbank und eben auch User und Passwort) extern verwaltet werden (also in einem Config-File oder im SQL Server Agent etc.). Letzteres hat den Grund, dass man Pakete auf dem Produktivsystem ohne Veränderung (d.h. ohne Öffnen im Visual Studio) aus dem Testsystem installieren will.

Somit kann man einfach die Einstellung auf „Do not save sensitive“ stellen. Dann tritt der oben beschriebene Fehler nicht auf und die verwirrende Fehlermeldung in der Task History des SQL Server Agent taucht nicht auf. In meinem Beispiel erkennt man die Division durch 0 jetzt viel besser:

Fehlermeldung Division durch 0 viel leichter erkennbar

 

Um allerdings eine gute Grundlage für die Fehlersuche zu haben, reicht auch die Anzeige im SQL Server Agent nicht aus. Man sollte besser Logging aktivieren – (dazu vielleicht später mehr 🙂 )