BizTalk und SAP Adapter Error

Schon ne ganze Weile habe ich immer wieder neue Probleme mit dem Microsoft SAP Adapter, dieses mal war es (mal wieder) richtig tricky. IDocs aus SAP verschwanden einfach spurlos im wahrsten Sinne des Wortes. Im BizTalk Tool "Health and Activity Tracking" gabs einen spärliche Meldung mit "Loading property information list by namespace failed or property not found in the list. Verify that the Schema is deployed properly." Redeploys brachten aber keine Verbesserung. Nach diversen anderen Versuchen, bin ich schließlich mit dem freien Sysinternal Process Monitor Tool von Microsoft an die Sache. Es ist nicht so einfach sich durch den Datenwust zu kämpfen und das richtige Problem zu identifizieren. Jedenfalls hatte ich danach ein paar Informationen mehr und den Kreis der Verdächtigen stark eingekreist. Die IDOCs kamen im System an und wurden auch erstmal intern verarbeitet, aber als es dann darin ging das IDOC in die Pipeline zu schieben, verschwand einfach alles. Im Registry Monitoring Teil tauchte ein kleiner Warnhinweis auf, das für den SAP Adapter nicht alle Registry Informationen gefunden werden konnten (aus welchen Gründen auch immer die verschwunden waren).

Lange Rede, kurzer Sinn: ein referenzieren der Microsoft.BizTalk.SAPAdapterProperties.dll aus dem (SAP Adapter Installationsverzeichnis) über die BizTalk Ressourcen selbst brachte letztendlich die Lösung. Der Adapter wurde wieder gefunden und das Problem war gefixt, ohne die tatsächliche Ursache zu reparieren. 

Ich vermute eine komplette Neuinstallation des Adapters könnte vielleicht das Problem beheben... bliebe zu testen, doch im Moment bin ich einfach nur froh, dass es nach doch einer recht anstrengenden Fehlerjagd quer durchs ganze System, wieder funktioniert. Bin eben Entwickler und kein SysAdmin ;)

BizTalk error "...has no Transport type specified"

Das hat mich ein bischen Nerven gekostet, zum Glück hat Félix Mondelo in seinem Blog eine simple Lösung parat:

Einfach unter C:\Documents and Settings\[user name]\Application Data\Microsoft\BizTalk Server\Deployment\BindingFiles alle Files im BindingFile Verzeichnis löschen. 

...es ist wirklich unglaublich an wievielen verstreuten Stellen man bei BizTalk suchen und rumschrauben muss :( 

MS-CRM begrenzt Fetch auf 5000 Datensätze

Bei dem Versuch alle Datensätze einer Entität (z.b. „accounts“) mit einem „Fetch“ aus einem MS-CRM System zu holen, kann man schnell eine herbe Enttäuschung erleben. Zumindest wenn mehr Datensätze als 5000 an der Zahl geholt werden müssen. Microsoft begrenzt die Anzahl der höchstmöglichen Datensätze per Default auf 5000 Stück. Hat man mehr, werden nur die ersten 5000 zurückgegeben. Möchte man diesen Defaultwert ändern, hat man nur den Weg über die Registry des Rechners auf dem MS-CRM installiert ist!

Es muss der Eintrag "TurnOffFetchThrottling" als DWORD in der Registery unter „HKEY_LOCAL_MACHINE\Software\Microsoft\MSCRM“ mit dem Wert ‚1’ eingetragen werden. Danach ist die Limitierung auf 5000 Datensätze aufgehoben.

Biztalkbeschleunigung durch Speicherzuweisung.

Bei einem aktuellem Projekt bei dem ca. 7000 Datensätze aus einem MS-CRM durch Biztalk2006 (inkl. Aufbereitung) gelesen werden sollten und danach in eine MS-SQL Tabelle landen sollte, musste ich eklatante Performanceschwächen feststellen. Wenn man nicht alle paar Minuten die Host-Instace manuell restarted hat, begab sich Biztalk für unbestimmte Zeit in Tiefschlaf. Erst nachdem in der „Administration Console“ unter „Platform Settings“->“Hosts“->“BizTalkServerApplication“->”Advanced“->”Throttling Thresholds”->”Process memory usage:” ein Wert von ‘700’ hinterlegt wurde, lief das ganze wie gewünscht. Der vorhergeige Wert ‚25’ wurde als „%“ interpretiert (wie alle Werte zwischen 1 und 100), wobei damit nicht "von Gesamtspeicher" gemeint ist sondern nur "freier Speicher" benutzt wird. Somit ist es Auslastungs- und Glückssache wie viel Speicher dem Biztalk wirklich zur verfügung stehen.

Microsoft Posters (Bezugsquellen und Links)

Wer kennt sie nicht als Software Entwickler, überall hängen diese schön bunten Poster herum die mal mehr oder weniger sinnvoll Features und Frameworks anschaulich demonstrieren können.

Bei Microsoft kann man einge davon herunterladen. Was ich sehr bedauerlich finde ist, dass ich keine Einstiegsseite auf MSDN kenne, die einem alle Poster zusammenfassend präsentiert. Nun gut, man kann immerhin die Suche bemühen, dennoch bleibt bei mir das Gefühl nicht alle zu erfassen. Natürlich kann man die auch für einen verhältnismäßig günstigen Preis erwerben, z.B. bei Amazon.de wie die das Posterpack für das .NET Framework 2.0, oder auch über Technet (da kann man auch z.B. die Jahresarchiv DVDs des MSDN Magazins ordern).

Empfehlenswert finde ich folgende Poster:

• Ein Namespace und Type Überblick für das .NET Framework 3.5.
• Hochinteressant finde ich die PnP (Patterns and Practices) Poster: Smart Client Architektur und der Overview.
• Für Shortcutfetischisten die C# Keybinding Poster für VS2008 und VS2005 (gibt es auch für Basic und C++. J# und der Rest gehen leider leer aus).
• Wer mit InfoPath oder Sharepoint entwickelt wird hier fündig, inkl. einer Developer Roadmap für Office 2007.
• Für BizTalk2006 Entwickler gibts gleich nen ganzen Schwung an Poster, u.a. die Datenbank Struktur inkl. der SQL Jobs und die Runtime Architektur.

Strings verschlüsseln mit C#

Strings mit .NET verschlüsseln ist gar nicht schwer. Durch Zuhilfenahme der TripleDESCryptoServiceProvider-Klasse kann ein String ganz einfach ver- und entschlüsselt werden. Hier ein kleines Beispiel: Das erste was wir brauchen ist ein Initialisierungsvektor und ein Schlüssel.

private readonly byte[] key = new byte[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24 };

private readonly byte[] iv = new byte[] { 65, 110, 68, 26, 69, 178, 200, 219 };

Der Initialisierungsvektor ist der Eingangsparameter mit dem die Startbedingungen für einen kryptografischen Algorithmus gesetzt werden. Der Schlüssel wird für die Verschlüsselung benötigt.Die beiden Werte werden für das Ver- und Entschlüsseln benötigt. Als nächstes der Code zum Verschlüsseln. Die Kommentare erklären eigentlich den Code.

/// <summary>
/// Verschlüsselt einen Eingabestring.
/// </summary>
/// <param name="input">Der zu verschlüsselnde String.</param>
/// <returns>Byte-Array mit dem verschlüsselten String.</returns>
public byte[] StringVerschluesseln(string input)
{
try
{
// MemoryStream Objekt erzeugen
MemoryStream memoryStream = new MemoryStream();

// CryptoStream Objekt erzeugen und den Initialisierungs-Vektor
// sowie den Schlüssel übergeben.
CryptoStream cryptoStream = new CryptoStream(
memoryStream, new TripleDESCryptoServiceProvider().CreateEncryptor(this.key, this.iv), CryptoStreamMode.Write);

// Eingabestring in ein Byte-Array konvertieren
byte[] toEncrypt = new ASCIIEncoding().GetBytes(input);

// Byte-Array in den Stream schreiben und flushen.
cryptoStream.Write(toEncrypt, 0, toEncrypt.Length);
cryptoStream.FlushFinalBlock();

// Ein Byte-Array aus dem Memory-Stream auslesen
byte[] ret = memoryStream.ToArray();

// Stream schließen.
cryptoStream.Close();
memoryStream.Close();

// Rückgabewert.
return ret;
}
catch (CryptographicException e)
{
Console.WriteLine(String.Format(CultureInfo.CurrentCulture, "Fehler beim Verschlüsseln: {0}", e.Message));
return null;
}
}

Bei DES handelt es sich um einen symmetrischen Algorithmus, das heißt zur Ver- und Entschlüsselung wird derselbe Schlüssel verwendet. TripleDES verschlüsselt die Daten dreimal. Um den String wieder herzustellen, dient folgende Funktion:

/// <summary>
/// Entschlüsselt einen String aus einem Byte-Array.
/// </summary>
/// <param name="data">Das verscghlüsselte Byte-Array.</param>
/// <returns>Entschlüsselter String.</returns>
public string StringEntschluesseln(byte[] data)
{
try
{
// Ein MemoryStream Objekt erzeugen und das Byte-Array
// mit den verschlüsselten Daten zuweisen.
MemoryStream memoryStream = new MemoryStream(data);

// Ein CryptoStream Objekt erzeugen und den MemoryStream hinzufügen.
// Den Schlüssel und Initialisierungsvektor zum entschlüsseln verwenden.
CryptoStream cryptoStream = new CryptoStream(
memoryStream,
new TripleDESCryptoServiceProvider().CreateDecryptor(this.key, this.iv), CryptoStreamMode.Read);
// Buffer erstellen um die entschlüsselten Daten zuzuweisen.
byte[] fromEncrypt = new byte[data.Length];

// Read the decrypted data out of the crypto stream
// and place it into the temporary buffer.
// Die entschlüsselten Daten aus dem CryptoStream lesen
// und im temporären Puffer ablegen.
cryptoStream.Read(fromEncrypt, 0, fromEncrypt.Length);

// Den Puffer in einen String konvertieren und zurückgeben.
return new ASCIIEncoding().GetString(fromEncrypt);
}
catch (CryptographicException e)
{
Console.WriteLine(String.Format(CultureInfo.CurrentCulture, "Fehler beim Entschlüsseln: {0}", e.Message));
return null;
}
}

Hashtable und der loadFactor Parameter

Ich bin heute über den "ominösen" float loadFactor Parameter im Hashtable Constructor beim Fremdcode debuggen gestoßen. Wer sich nicht mit theoretischen Verständnis belasten will, nicht das "letzte" bischen Performance braucht und auch noch nie eine "System.InvalidOperationException: Hashtable insert failed. Load factor too high" Exception gesehen hat, dem sei gesagt, laß den loadFactor in Ruhe. Der ist Standardmäßig auf 0.72 eingestellt und völlig ausreichend normalerweise.

Wer jetzt noch dabei ist, der muss sich nun darauf gefasst machen das ich recht weit ausholen muß. Nach etwas Recherche in Wesner Moise's legendärem .NET undocumented blog, ging mir ein Licht auf, was dass denn nun genau ist. 

Theorie

Die Grundidee der Hashtable ist, simpel gesagt, mittels des Keys den man besitzt direkt zum Eintrag in einer Liste springen zu können. Kein suchen und langes vergleichen, man hat den Key, berechnet daraus eine Art "Offset" und hat damit den Speicherplatz lokalisiert wo der zugehörige Value abgelegt ist. Die Berechnung dieses "Offsets" übernimmt die Hashfunktion in unserer Hashtable. 

Z.b. wir haben eine Mitarbeiternummer für 50 Mitarbeiter, um jeden Eindeutig zu identifizieren würde es reichen aus den letzten 2 Nummern der Mitarbeiternummer einen eindeutigen Hashcode zu berechnen, ergo reicht uns ein vorinitialisiertes leeres Array von 100 Einträgen (nennen wir dieses Array Buckets) und je nach Hashcode kann man dann zum berechneten Index springen (egal ob 0 oder 99). Nun kommt aber Mitarbeiter 51, und dessen letzten 2 Ziffern aus der Mitarbeiternummer stimmen ganz zufällig mit der eines anderen überein. Ein insert schlägt fehl (Hashtable insert failed), unsere Hashfunktion ist nicht ausreichend und es gibt das, was man eine Collision in der Hashtable nennt. 

Um diese Collision  zu vermeiden kann man nun z.B. die Hashfunktion neu implementieren, nur haben wir dann das dilema, um so komplizierter und einzigartiger dieser Hashcode berechnet  wird, um so langsamer wird jeder Zugriff auf unsere Hashtable. Ein anderer Ansatz geht vom Load Factor der Hashtable aus. haben wir unsere Buckets aus dem obigen Beispiel mit der Größe 100 und 50 Einträge drin, dann beträgt der Load Factor 50/100 = 0.5. Das heißt unsere Buckets sind zu 50% gefüllt, die Wahrscheinlichkeit das eine Collision stattfindet ist 0.5. Um so niedriger wir diesen Faktor drücken können, um so unwahrscheinlicher ist eine Collision, aber auch um so mehr freien Speicherplatz verpulvern wir sprichwörtlich. 

Aber selbst wenn wir die Wahrscheinlichkeit drücken, sie bleibt bestehen, daher benötigt man eine Technik die im Falle der Collision eine Gegenstrategie fährt. Buckets machen aus unserem 1-dimensionalen Array ein 2-dimensionales Array. Ist der Index belegt, wird einfach in der 2. Dimension am nächsten freien Index unser Kollidierter Hash abgelegt. Praktisch auffüllen wie bei einem Eimer (Bucket). Die Nachteile sind offentsichtlich, das eingangs erwähnte "Vergleichen", dass man vermeiden wollte ist plötzlich wieder da, auch noch eine Collisiondetektions und Handlingsroutine.

Ergo man kann es also auf den Punkt bringen, mehr Speicherplatz für mehr Performance in der Hashtable. Vermeidet man Kollisionen, vermeidet man unnötige Operationszeiten. Sowohl beim schreiben und vor allem auch beim auslesen.

.NET Praxis

Nach dem theoretischen Ausflug zurück zu .NET. Ganz so simpel wie das theoretische Modell ist es nicht ganz in der Praxis.

Buckets sind in der .NET Hashtable ein Array von Arrays, um genau zu sein ein Bucket[], wobei jedes Bucket drei Werte hält: hash_coll (int), key (object) und val (object):

Füge ich in die obige Hashtable den key "a" ein, berechnet die Hashfunktion einen Wert dazu und ordnet diesem Wert einen Index in DIESEM(!) Bucket Array zu (andere Bucket Array Größe, andere Zuordnungsweise). Daher wird in dieser Hashtable (100, 1.0f), der key "a" immer an Position 49 im Bucket Array landen (.NET 3.5). Hätte ich nun einen key zur Hand, dessen Hashcode zufällig identisch wäre, würde eine Collision eintreten und das Collision Handling tritt ein. Dazu wird der Hashkey neu berechnet und als "Offset" zu der Kollision Index Position aufgerechnet. Es wird also nicht wie im klassischen Bucket in die 2. Dimension gegangen, sondern, flapsig gesagt, flach "weitergesprungen" (was uns den Compare aus der Theorie von oben erspart!).

Das wiederrum erklärt warum das Bucket Array hier deutlich größer ist als der vorgegebene Initialwert von 100. Und jetzt kommen wir damit auch endlich zum loadFactor und dessen Auswirkung. Ich habe den Wert von 1.0f übergeben als loadFactor. Dies wird mit dem Initialwert 0.72 multipliziert. D.h. würde ich 0.5f übergeben, wäre der interne loadFactor 0.36:

Die Berechnung der Bucket Anzahl ist jetzt eher nebensächlich, grob gesagt die Initialgröße dividiert durch den loadFactor und dann die nächste Primzahl (aus statistischen Gründen für maximale Effektivität). Wesner Moise läßt sich in seinem Blog detailierter darüber aus, wen es genauer interessiert (siehe Verlinkung oben).

Fazit

D.h. zusammenfassend:

um so kleiner der loadFactor...

-> um so größer das Bucket Array

-> um so mehr Speicherverbrauch

-> um so weniger Collisionen

-> um so weniger Operationen

-> um so höhere Performance in Abhängigkeit von der steigenden Anzahl der keys (was wirklich durchaus in einem signifikanten Rahmen liegt, ...probierts aus)