BizTalk 2006 BAM EventBus Service Error Event

Fehlermeldung im BizTalk Application Event Log:

Event Type: Error
Event Source: BAM EventBus Service
Event Category: None
Event ID: 25
Date: 3/1/2010
Time: 6:44:58 PM
User: N/A
Computer: BES086.comlineag.cl.local
Description:
Either another TDDS is processing the same data or there is an orphaned session in SQL server holding TDDS lock.Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. SQLServer: BES082, Database: BizTalkDTADb.


Das Problem mit Lösungsvorschlägen ist beschrieben unter
http://support.microsoft.com/kb/841334 (Error Description dazu beachten)

In meinem Fall war die Lösung zu verwaisten Sessions angebracht:
http://msdn.microsoft.com/en-us/library/aa275788(SQL.80).aspx

Die Kurzfassung zur Lösung:

mit der Management Konsole sich auf die BizTalk SQL DB verbinden und exec sp_who als Query ausführen. Das listet die gegenwärtig Session mit ihrem jeweiligen Status und der jeweiligen spid auf. Die 'sa' Sessions interessieren nicht, alle anderen Sessions (bis auf die eigene) kann man dann gegebenenfalls mit dem kill Befehl abschießen (kill <spid>)

Dabei sollte natürlich sichergestellt sein, das der BizTalk in der Zeit nicht auf das System zugreift, bzw. ein anderer User Remote auf dem System arbeitet ;)

BizTalk 2009 Issues unter VS2008

Seit wir mit BizTalk 2009 unter Visual Studio 2008 entwickeln, haben wir immer wieder heftige Probleme mit referenzierten Projekten. Und zwar vornehmlich dann, wenn sich diese innerhalb der gleichen Solution befinden. Nach unseren letzten Problemen hab ich mich auf die Suche gemacht und Blogeinträge mit den gleichen Erfahrungen gefunden:

http://dotnet.org.za/ryancrawcour/archive/2009/07/17/biztalk-2009-amp-visual-studio-2008-annoyance-2.aspx http://blog.eliasen.dk/2009/07/21/IssuesWithBizTalk2009OnVSNET2008.aspx

Und nun die gute Nachricht: Es gibt seit Dezember doch tatsächlich einen Hotfix dafür :)
http://support.microsoft.com/kb/977428/en-us

BizTalk dynamischer Sendport - uninitialized dynamic port

Beim kompilieren eines BizTalk Projektes unter VS2008 mit einem dynamischen Send Port, bekam ich die Fehlermeldung "uninitialized dynamic port"

Eine google Recherche ergab, dass dies auf das nicht gesetztes Property des Send Ports Microsoft.XLANGs.BaseTypes.Address hinweist. Das dumme nur war es ist gesetzt gewesen, aber in der falschen (!) Reihenfolge.

Zuerst hatte ich nämlich das Property Microsoft.XLANGs.BaseTypes.TransportType gesetzt und dann Microsoft.XLANGs.BaseTypes.Address.

Also:
myDynamicSendPort(Microsoft.XLANGs.BaseTypes.TransportType) = "My Type" myDynamicSendPort(Microsoft.XLANGs.BaseTypes.Address) = "My UNC"

-> build failed: uninitialized dynamic port

Aber:

myDynamicSendPort(Microsoft.XLANGs.BaseTypes.Address) = "My UNC" myDynamicSendPort(Microsoft.XLANGs.BaseTypes.TransportType) = "My Type"

-> build succeded


...its not a bug, its a feature :P

BizTalk SAP Adapter 2.0 - IDOC Unknown Segment

Beim abrufen eines IDOCs unter BizTalk 2006 mit dem BizTalk Adapter 2.0 erhielt ich die Fehlermeldung:

The schema generation encountered the following error(s):

1. Error occured while generating schema for: xxxx

Error returned: SEGMENT_UNKNOWN

Die Problemursache war, dass nicht alle Segmente in SAP released waren.

http://www.tech-archive.net/Archive/BizTalk/microsoft.public.biztalk.general/2005-02/0693.html

Error: 0x80040204 - Invalid user auth.

Die im Titel stehende Meldung erhielt ich letztens beim lauf einer meiner Schnittstellen, die sich sequentiell durch Datensätze (in meinem Fall Accounts) eines CRM Systems per Webservice itteriert und darin automatisiert Änderungen durchführt.

Kleiner Fehler ganz groß. Als erstes wurde von allen (ausser mir ;) ) vermutet das sich der am CRM anmeldende User etwas erlaubt was ihm so nicht gestattet ist. Da ich diesen User aber bei allen Zugriffen benutze und alle anderen ja einwandfrei funktionierten, konnte ich das gleich ausschließen.

Meine Vermutung ging in Richtung des im Datensatz selbst zugewiesenen Systemuser (Owner) der bei jeder Änderung mit überegben wird. Dieser User ist ein auf der CRM Seite vorhandener Domänenuser und wird vom CRM System noch einmal extra als Entität "Systemuser" gehalten.

Meine Recherchen ergaben das man den Domänenuser aus der Domäne GELÖSCHT hatte, aber der User natürlich immer noch im CRM als Entität "Systemuser" vorhanden und bei vielen Datensätzen als Owner eingetragen war.

Durch die Löschung jedoch aus der Domäne hat der User praktisch alle rechte verloren und darf somit seine ihm zugeteilten Datensätze auch nicht mehr ändern.

Im vorliegenden Fall, hat die Firma in deren CRM das vorgekommen ist, in allen Datensätze mit einer Referenz zu dem rechtelosen User diesen durch einen in der Domäne noch aktiven User ausgetauscht. Damit hat dann wieder alles funktioniert.

CU TerA 

throw ex vs throw

Es ist eigentlich ein alter Hut, der Unterschied zwischen throw ex und throw sollte jedem bekannt sein. Throw ex schneidet den alten Stack Trace ab und verpackt sozusagen den Fehler neu, Throw hingegen nicht.

Aber dennoch halten sich irgendwie hartnäckig gegenteilige Meinungen, vermutlich aus den Gegenbenheiten aus Java resultierend, aber ich habe auch schon einige ellenlange Threads gelesen in denen das vollkommen Falsche dargelegt wurde, bis hin zu Projektleitern die von einem Verlangen ein ganzes Projekt umzuprogrammieren, weil sie der Meinung wären es wäre genau anders herum. 

Den Beweis zu führen ist recht simpel, entweder man schaut sich den MSIL Code an und erkennt das throw zu einem rethrow compiliert, während throw ex, ein throw ex bleibt. Oder aber man testet es einfach mit einem Programm folgender Art selber aus, um auch den letzten Kritiker hoffentlich verstummen zu lassen...

   1:  class ThrowVsThrowEx

   2:  {

   3:     static void Main(string[] args)

   4:     {

   5:        try

   6:        {

   7:           ReThrow();

   8:        }

   9:        catch(Exception ex)

  10:        {

  11:           Console.WriteLine("ReThrow sent: " + ex.ToString());

  12:        }

  13:   

  14:        Console.Write(System.Environment.NewLine);

  15:   

  16:        try

  17:        {

  18:           ThrowNew();

  19:        }

  20:        catch (Exception ex)

  21:        {

  22:           Console.WriteLine("ThrowNew sent: " + ex.ToString());

  23:        }

  24:   

  25:        Console.ReadLine();

  26:     }

  27:   

  28:     static void ReThrow()

  29:     {

  30:        try

  31:        {

  32:           DontCallMe();

  33:        }

  34:        catch

  35:        {

  36:           throw;

  37:        }

  38:     }

  39:   

  40:     static void ThrowNew()

  41:     {

  42:        try

  43:        {

  44:           DontCallMe();

  45:        }

  46:        catch(Exception ex)

  47:        {

  48:           throw ex;

  49:        }

  50:     }

  51:   

  52:     static void DontCallMe()

  53:     {

  54:        throw new ApplicationException("I said don't call me!!");

  55:     }

  56:  }

Ergebnis von throw:

ReThrow sent: System.ApplicationException: I said don't call me!! at DemoExceptions.ThrowVsThrowEx.DontCallMe() in C:\Projects\DemoExceptions\D emoExceptions\ThrowVsThrowEx.cs:line 54 at DemoExceptions.ThrowVsThrowEx.ReThrow() in C:\Projects\DemoExceptions\Demo Exceptions\ThrowVsThrowEx.cs:line 36 at DemoExceptions.ThrowVsThrowEx.Main(String[] args) in C:\Projects\DemoExcep tions\DemoExceptions\ThrowVsThrowEx.cs:line 7


und das Ergebnis von throw ex:

ThrowNew sent: System.ApplicationException: I said don't call me!! at DemoExceptions.ThrowVsThrowEx.ThrowNew() in C:\Projects\DemoExceptions\Dem oExceptions\ThrowVsThrowEx.cs:line 48 at DemoExceptions.ThrowVsThrowEx.Main(String[] args) in C:\Projects\DemoExcep tions\DemoExceptions\ThrowVsThrowEx.cs:line 18


Wunderbar zu erkennen wie throw ex den Ursprung abgeschnitten hat und stattdessen bei sich "selbst" anfängt... keine Worte :)

BizTalk 2006 Error BEC2004: Validate Instance failed for schema

warning BEC2004: Data at the root level is invalid. Line 1, position 1

Da erstelle ich doch glatt ein XSD Schema mit dem Flatfile Schema Wizard von BizTalk2006/R2 für meinen Kollegen, schick es ihm rüber und es funktioniert nicht...

Noch einmal getestet bei mir, geht immer noch, bei ihm... nicht...

Also hingesetzt bei ihm, Schema nachkreiert -> Funktioniert...

Zu mir rübergeschickt -> geht nicht...

WinDiff -> Kein Unterschied...

Unterschied Kollege hat 64Bit Betriebssystem ich 32Bit, also Files in einer anderen Text Codierung neu abgespeichert auf meinem 32Bitter.... Gleiches Verhalten...!

Copy und Paste vom Inhalt des 64Bit Schemas in eine neue Datei... Gleiches Verhalten...!!!

Nun bin ich etwas ratlos. Deutet vielleicht auf ein Problem mit Escape Zeichen hin... aber der Austausch von Escape Sequencen für Tab und CR/LF brachte auch keine Lösung.

Äußerst kurios, zumal ich schon vorher mehrfach mit anderen Windows 2003 64Bit Systemen das gleiche tat und XSD Schemas aus einer 32Bit Entwicklungsumgebung migrierte in das dortige Projekt.

Irgendjemand eine Idee?

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 :( 

BizTalk Deployment OOM Probleme

Out of Memory ist so eine Totschlag Fehlermeldung beim BizTalk 2006 Deployment, die ziemlich viele Ursachen haben kann, wie diverse Googlesuchsessions bei mir ergaben. Eine kurze Checkliste woran es liegen kann und ich gegenveriferziert habe bei mir selbst: 1. Hat der Host zu wenig (Arbeits-)Speicher: Visual Studio (wenn auf dem Hostsystem) schließen und neu starten (kann schon reichen) und/oder "Services" öffnen (Run Box Command: services.msc) und ein Restart von "SQL Server (MSSQLSERVER)" mit allen daran hängenden anderen Services (geschieht automatisch). Zusammen sollte das jedenfalls den Speicher dramatisch leeren 2. Hat der Host genug (Arbeits-)Speicher, bzw. der Erste Tipp funktioniert nicht: ...dann hilft ein überprüfen der SQL Jobs. Es ist enorm wichtig das der "MessageBox_Message_Cleanup_BizTalkMsgBoxDb"-Job läuft(!!) Jede Message die mehr als EINEN Subscriber hat wird nämlich nicht sofort aus der Message Box intern gelöscht, das macht erst später dieser Job. Zu finden ist dies im "Microsoft SQL Server Management Studio", rechts unter SQL Server Agent->Jobs Langwieriges Deployment... Tipp 2 ist übrigens auch zu prüfen wenn das Deployment sehr lange dauert, bzw. es immer langsamer wird. Hier ist auch gegenfalls zu überprüfen, wenn Visual Studio sich auf dem selben System befindet, ob im Projekt unter Deployment -> BizTalk Group -> Server "(LOCAL)" eingetragen ist und nicht(!) die (lokale) IP Adresse. Warum auch immer, auch dies hat einen "bremsenden" Effekt.

Inconsistent duplicate module attribute

Ein 'Microsoft.XLANGs.BaseTypes.BPELExportable': inconsistent duplicate module attribute Error hat mich ziemlich lange geärgert in Biztalk2006 R2 beim kompilieren. Des Rätsels Lösung war das sowohl in den Projekteneigenschaften unter Build - Code Generation: BPEL Compliance True als auch in einer Orchestration unter Eigenschaften: Module Exportable auf True gesetzt war. Leider natürlich an einer völlig anderen Stelle als im Error Output angegeben. Ein setzen innerhalb der Orchestration auf False behob das Problem... Offenbar ist "doppeltgemoppelt" nicht immer gut ;)

OPC: DataChange-Event

Ein OPC-Client hat die Möglichkeit, vom Server Nachrichten über Aktualisierungen von Werten zu empfangen. Das ist natürlich sehr nützlich, wenn man gerne eine bestimmte Aktion ausführen möchte, wenn ein definierter Wert erreicht wird. Kommt ja auch nicht gerade selten vor, diese Anforderung, also hat die OPC Foundation da schon ganz schön schlau definiert.

Nicht ganz so schlau ist jedoch die Umsetzung innerhalb der OpcDAAuto.dll gelungen. Ich habe heute etwa einen halben Tag gekämpft, bis ich tatsächlich in der Lage war, den DataChange-Event, der vom Server bei Veränderungen von zuvor dafür angemeldeten Werten gesendet wird, zu empfangen. Ich habe Tutorials gewälzt, das Internet durchforstet und experimentiert - alles ohne Erfolg. Alle Voraussetzungen, die ich finden konnte, schienen mir erfüllt. Nach ewigem Herumprobieren gab es nur noch einen einzigen Unterschied zwischen den Tutorials - die, heruntergeladen und kompiliert im Übrigen einwandfrei funktionierten - und meiner Applikation. Dieser fand sich beim Anlegen von OPC-Items, also jenen Werten, die ich überwachen wollte. Mein Code - im Übrigen eigentlich absolut korrekt - sah folgendermaßen aus:

   1:  OPCGroupClass opcGroupTriggerItems;

   2:   

   3:  // Gruppe anlegen

   4:  opcGroupTriggerItems = ( OPCGroupClass ) opcServer.OPCGroups.Add( "TriggerItems" );

   5:   

   6:  // Items hinzufügen

   7:  opcGroupTriggerItems.OPCItems.AddItem( connection + "/" + alias + "/TriggerItem1", 0 ) );

   8:  opcGroupTriggerItems.OPCItems.AddItem( connection + "/" + alias + "/TriggerItem2", 1 ) );

   9:  opcGroupTriggerItems.OPCItems.AddItem( connection + "/" + alias + "/TriggerItem3", 2 ) );

  10:  opcGroupTriggerItems.OPCItems.AddItem( connection + "/" + alias + "/TriggerItem4", 3 ) );

  11:   

  12:  // Event Handler Methode registrieren

  13:  // WICHTIG: Die Event Handler Methode wird erst nach dem hinzufügen der Items zur Gruppe registriert,

  14:  //          da sonst beim Hinzufügen für jedes Item ein Event ausgelöst wird.

  15:  opcGroupTriggerItems.DataChange += new DIOPCGroupEvent_DataChangeEventHandler( opcGroupTriggerItems_DataChange );

Hier wird zuerst eine Gruppe auf dem OPC-Server angelegt, zu der dann anschließend die Items hinzugefügt werden, die die Werte darstellen, die überwacht werden sollen. Um zu vermeiden, dass für alle Items ein initialer Event ausgelöst wird, der über die Änderung von "nicht vorhanden" nach "vorhanden" und die damit verbundene Wertänderung benachrichtigt, wird die Event-Handler-Methode erst nach dem Anlegen der nötigen Items registriert. So wurden die Items korrekt angelegt, sie konnten ausgelesen werden, aber die Benachrichtigung über Wertänderungen funktionierte, wie bereits erwähnt, überhaupt nicht.

Der Code, der mir von den Tutorials aufgezeigt wurde und der jetzt, nachdem ich ihn so auch in meiner Applikation habe, zu dem gewünschten Ergebnis führt, sieht so aus:

   1:  OPCGroupClass opcGroupTriggerItems;

   2:  string[] itemIds = new string[5];

   3:  int[] clientHandles = new int[5];

   4:  int[] serverHandles;

   5:  int[] errors;

   6:   

   7:  // Gruppe anlegen

   8:  opcGroupTriggerItems = ( OPCGroupClass ) opcServer.OPCGroups.Add( "TriggerItems" );

   9:   

  10:  // Items erstellen

  11:  itemIds.SetValue( connection + "/" + alias + "/TriggerItem1", 1 );

  12:  itemIds.SetValue( connection + "/" + alias + "/TriggerItem2", 2 );

  13:  itemIds.SetValue( connection + "/" + alias + "/TriggerItem3", 3 );

  14:  itemIds.SetValue( connection + "/" + alias + "/TriggerItem4", 4 );

  15:   

  16:  // ClientHandles erstellen

  17:  clientHandles.SetValue( 1, 1 );

  18:  clientHandles.SetValue( 2, 2 );

  19:  clientHandles.SetValue( 3, 3 );

  20:  clientHandles.SetValue( 4, 4 );

  21:   

  22:  // Items der Gruppe hinzufügen

  23:  opcGroupTriggerItems.OPCItems.AddItems( 4, ref itemIds, ref clientHandles, out serverHandles, out errors, null, null );

  24:   

  25:  // Event Handler Methode registrieren

  26:  // WICHTIG: Die Event Handler Methode wird erst nach dem hinzufügen der Items zur Gruppe registriert,

  27:  //          da sonst beim Hinzufügen für jedes Item ein Event ausgelöst wird.

  28:  opcGroupTriggerItems.DataChange += new DIOPCGroupEvent_DataChangeEventHandler( opcGroupTriggerItems_DataChange );

Auch hier wird zunächst eine Gruppe angelegt. Es werden hier jedoch die Items nicht, wie zuvor, einzeln der Gruppe hinzugefügt. Statt dessen werden ein String-Array mit den Werten und ein Integer-Array mit den Client-Handles, unter denen die Items eindeutig zu identifizieren sind, angelegt. Hier ist die Besonderheit zu beachten, dass der erste Wert des Arrays jeweils nicht beachtet wird, das Array wird immer nur von 1 bis max durchlaufen. Das hängt, so weit ich informiert bin, damit zusammen, dass die von mir verwendete OpcDAAuto.dll in VB geschrieben ist. Jedenfalls werden anschließend die Items und ihre Client-Handles gesamt an eine Methode übergeben, die sie der Gruppe hinzufügen. Anschließend wieder die Event-Handler-Methode registriert. Test anwerfen - funzt.  Sehr erstaunlich und für mich nicht wirklich nachvollziehbar, aber im Endeffekt ist es jetzt auch egal, es läuft ja nun :)

Biztalk SAP Adapter Error 8007007e

Vielleicht "schon wieder" ein 64Bit Enviroment Issue... (?) der Auslöser ist mir nicht ganz klar, aber bei meinem aktuellen Projekt tritt nach der Konfiguration im Biztalk Server 2006 von SAP Ports alle paar Minuten im Eventlog den folgenden Fehler:

Nach etwas Rumforschen und Abgleichen der SAP Adapter Installationsverzeichnisse ergab sich das sowohl die ATL71.dll als auch die MSVCR71.dll fehlten. Offensichtlich hat der Adapter Installer Probleme diese Komponenten unter Windows 2003R2/x64 zu installieren. Ich musste diese von Hand nachträglich reinkopieren nach "C:\Program Files (x86)\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite" Der Fehler stoppte sofort, ohne irgendetwas neu zustarten, von alleine.

Seltsames Verhalten im Event Log

Zur Zeit schreibe ich, wenn es die Zeit und die Laune zulassen, an einem kleinen Tool zum Auslesen des Windows Event Log. Dabei habe ich eine recht interessante Feststellung gemacht.
Zum Auslesen der Einträge einer bestimmten Quelle, die im Event Log registriert ist, habe ich folgendes getan:

   1:  public static EventLogEntryCollection GetEntriesForSource( string logSource )

   2:  {

   3:      EventLog log;

   4:      EventLogEntryCollection entries;

   5:   

   6:      source = logSource;

   7:   

   8:      // EventLog vorbereiten

   9:      log = new EventLog();

  10:      log.Source = logSource;

  11:              

  12:      // EventLog-Einträge auslesen

  13:      entries = log.Entries;

  14:   

  15:      return entries;

  16:  }

Hier tue ich nichts anders, als ein EventLog-Objekt zu erstellen, das, wer hätte es gedacht, den Zugriff auf das Windows Event Log erlaubt.
Anschließend wird die Quelle (Source) gesetzt, deren Einträge ausgelesen werden sollen. Damit ist die Vorbereitung auch schon abgeschlossen und die Einträge innerhalb der Source können in eine EventLogEntryCollection eingelesen werden.

Damit ist das Auslesen aus der gewünschten Quelle auch schon abgeschlossen - dachte ich. Seltsamerweise werden trotz des Setzens der zu lesenden Quelle alle Einträge des Logs, in dem sich die Quelle befindet, in die EventLogEntryCollection geschrieben.

Ich möchte jetzt nicht so weit gehen zu sagen, dass es sich hierbei um einen Fehler im Konzept des Event Log-Handlings handelt, aber für mich ist es nicht logisch, alle Einträge in meine Collection geschrieben werden, obwohl ich - für meine Begriffe - eine Eingrenzung auf eine ganz bestimmte Source vorgenommen habe.

Das Schlimme daran ist nicht die Tatsache an sich, sondern viel eher, dass man sie nicht direkt wahrnimmt. Ich habe beispielsweise in eigenen Tests nie zwei mal hintereinander Quellen aus dem gleichen Log verwendet, so dass mir nie aufgefallen ist, dass alle Quellen des Logs exakt gleich viele (und vor allem die selben) Einträge hat. Das hat erst ein Betatester festgestellt (vielen Dank dafür an tropensturm!).

Die Beseitigung des Problems gestaltet sich glücklicherweise denkbar einfach, so dass in meiner Anzeige jetzt tatsächlich nur noch die erwarteten Einträge zu finden sind. Hierfür wird einfach nachträglich nochmals die Source eingegrenzt.

   1:  if( !entry.Source.Equals( source ) )

#error "Errors exist for one or more children."

Ich hatte gerade ein seltsames Problem mit einer Orchestration innerhalb eines VisualStudio BizTalk.Projektes. Ich konnte einfach partout nicht mehr kompilieren, obwohl im Orchestration-Designer alles bestens aussah (der Fehler war in meinem Fall '#error "Errors exist for one or more children."').

Nachdem ich alles was mir eingefallen ist ausprobiert hatte, öffnete ich die Orchestration im XML-Editor (eine Orchestration ist ja nichts weiter als ein XML). Der "normale" Aufbau einer Orchestration folgt folgendem Muster:

   1:  #if __DESIGNER_DATA

   2:   #error Do not define __DESIGNER_DATA.

   3:   <?xml version="1.0" encoding="utf-8" standalone="yes"?>

   4:   <om:MetaModel [...viele Attribute...]>

   5:    [...viel mehr XML...]

   6:   </om:MetaModel>

   7:  #endif // __DESIGNER_DATA

Manchmal findet man jedoch darunter noch Code im folgendem Stil:

   1:  [Microsoft.XLANGs.BaseTypes.BPELExportable(false)]

   2:  module xyz.IndustryTemplate.MSCRMToSAP

   3:  {

   4:   [...viel mehr Code]

   5:  }

In meinem Fall hat es nun geholfen den untenstehenden Code komplett zu löschen und die Orchestration zu speichern. Der erneuter Kompilierungsversucht ist danach fehlerfrei durchgelaufen.

BizTalk: "Variable Längen" handeln in Flatfile Schemas

Ziemlich viel Zeit hat mich folgendes Problem mit BizTalk gekostet, als ich die Lösung hatte hab ich dazu auch endlich was in Google gefunden... ärgerlich.

Folgendes Problem: ich bekomme eine Datenstruktur mit folgendem Aufbau zugeschickt: nnnXXXXabcd/CR/LF
Dies ist erst einmal relativ simpel mit dem Flatfile Wizard von Biztalk zu lösen (wem das Tutorial aus der MSDN nicht den zündenen Geistesblitz gibt, sollte es mit dem hier versuchen).

Jetzt ist allerdings folgender Fallstrick in meinem Flatfile, eine nachfolgende row im Flatfile kann wie folgt aussehen:
nnnXXXXabcdefgh/CR/LF
urgs, richtig! Variable Längen... in einem positional record, das gibt einem auch prompt beim ausprobieren einen "Unexpected Data found while looking for '/r/n'" Error

Um das in den Griff zu kriegen, mußte ich furchtbar lange rumpobieren da ich nix sinnvolles an Hilfe fand. Ich bin dann mit dem XSD Editor auf folgendes gestoßen:

   1:  <?xml version="1.0" encoding="utf-16" ?>

   2:    <xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003"

   3:        xmlns="http://xyz.de"

   4:        targetNamespace="http://xyz.de"

   5:        xmlns:xs="http://www.w3.org/2001/XMLSchema">

   6:    <xs:annotation>

   7:    <xs:appinfo>

   8:      <schemaEditorExtension:schemaInfo namespaceAlias="b"

   9:        extensionClass="Microsoft.BizTalk.FlatFileExtension.FlatFileExtension"

  10:        standardName="Flat File"

  11:        xmlns:schemaEditorExtension="http://schemas.microsoft.com/BizTalk/2003/SchemaEditorExtensions" />

  12:      <b:schemaInfo standard="Flat File"

  13:        codepage="65001"

  14:        count_positions_by_byte="true"

  15:        default_pad_char="" pad_char_type="char"

  16:        parser_optimization="speed"

  17:        lookahead_depth="3"

  18:        suppress_empty_nodes="false"

  19:        generate_empty_nodes="true"

  20:        allow_early_termination="false" 

  21:        early_terminate_optional_fields="false"

  22:        allow_message_breakup_of_infix_root="false"

  23:        compile_parse_tables="false"

  24:        root_reference="Group" />

  25:      </xs:appinfo>

  26:    </xs:annotation>

  27:   

  28:  ...

Das Attribute "allow_early_termination" auf true gesetzt und dann bei pos_length im entsprechenden Element eine geeignete Größe gewählt (z.B. pos_length="1000") führte zu einem funktionierendem Ergebnis.

Nachteil bleibt der Faktor mit pos_length, sollte es einmal doch "länger" sein, sind wir wirklich aufgeschmissen an diesem Punkt. Da bleibt dann wohl nur noch ein Umweg dies über die BizTalk Pipelines zu fixen, bzw. mit einer geeigneten Applikation, die uns das File vorher aufbereitet.

The underlying connection was closed

System.Net.WebException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request) at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at <my webservice> ....

Das Problem ist meist Serviceseitig zu suchen, durch irgendwelche verkorksten oder properitären, veralteten, etc. Einstellungen. Dummerweise hat man meistens keinen Einflußmöglichkeit auf diesen Service, also muss ein Workaround her.

Als erster Anlaufpunkt kann man versuchen den KeepAlive auf false zu setzen. Denn unter .NET 1.1 war KeepAlive noch defaultmäßig auf false, ab 2.0 auf true. Das steuert ob die WebService Verbindung dauerhaft offen gehalten werden soll, nur dumm wenn der Webserver von alleine irgendwann dicht macht nach einer gewissen Dauer, bzw. idle time.

Funktioniert das nicht, kann man noch versuchen die HttpVersion auf 1.0 runter zu setzen für mehr Kompatibilität.

Desweiteren könnte es noch helfen Expect100Continue auf false zu ändern. Dies bewirkt, dass bei einem Request gleich die Daten mit dem Header geschickt werden. Bei true (Default) wird nur der Header geschickt und die Daten erst, wenn ein "100 Continue" Response vom Server erfolgte.

   1:  namespace MyWebServiceNamespace

   2:  {

   3:      partial class MyWebServices_MyMethod

   4:      {

   5:          protected override System.Net.WebRequest GetWebRequest(Uri uri)

   6:          {

   7:              System.Net.HttpWebRequest request =

   8:                  (System.Net.HttpWebRequest)base.GetWebRequest(uri);

   9:   

  10:              // fix "underlying connection was closed.."

  11:              request.KeepAlive = false;

  12:              request.ProtocolVersion = System.Net.HttpVersion.Version10;

  13:              request.ServicePoint.Expect100Continue = false;

  14:              ...

  15:          }

  16:      }

  17:  }

Anmerkung: Durch das partial class (ab .NET 2.0) kann man das wunderbar in eine eigene Datei verlagern, getrennt vom generierten Proxy und somit unabhängig wenn neu generiert werden muss.

Probleme mit SSO (Single Sign On) und Custom BizTalk Adapter

Beim registrieren eines Custom Adapters in BizTalk 20006 hab ich folgenden Fehler bekommen:

Cannot perform encryption or decryption because the secret is not available from the master secret server. See the event log (on computer 'XYZ') for related errors.

Des Rätsels Lösung war schnell gefunden - Ich mußte das SSO Master Secret wiederherstellen, Anleitung siehe hier:
http://msdn2.microsoft.com/en-us/library/aa560589.aspx

Einfach SSO Administration starten, Rechtsklick auf System und dann Restore mitsamt dem Passwort ...wenn hoffentlich noch zur Hand ;)

BizTalk Deployment Probleme

Wer kennts nicht als BizTalk Entwickler? Kaum wird das Projekt mal ein bischen Komplex hakts mit dem Undeployen. Irgendwo in den untiefen des ewigen Internets hab ich dann eine effektive Lösung gefunden.

Some items in the removed assembly are still being used by items not defined in the same assembly, thus removal of the assembly failed. Make sure that items in the assembly you are trying to remove fulfill the following conditions: 1. Pipelines, maps, and schemas are not being used by Send Ports or Receive Locations 2. Roles have no enlisted parties. ... Undeployment failed.

Anstatt ewig zu versuchen, was denn nun blockieren könnte und alles einzeln durchzuprobieren, gibt es einen "Trick"(?) mit der SQL Datenbank, um herauszufinden welche sogenannten Referenzen uns in die Suppe spucken (wobei sich mir durchaus die Frage stellt wieso BizTalk nicht einfach das Ergebnis dieses Selects selber anzeigen kann).

SQL Datenbank... ja aber welche?
Das kann man einfach in der Registry nachsehen unter:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0\Administration\MgmtDbServer

Dann den SQL Query Analyzer öffnen mit der Verbindung auf unsere gefundene Datenbank und folgenden großen SELECT absetzen:

   1:  select

   2:  'RcvPort' PortType,

   3:  r.nvcName Port,

   4:  item.name MapName,

   5:  assem.nvcName Assembly,

   6:  nSequence, indoc_docspec_name, outdoc_docspec_name

   7:  from bts_receiveport_transform rt

   8:  inner join bts_receiveport r

   9:  on rt.nReceivePortID = r.nID

  10:  inner join bt_mapspec ms

  11:  on ms.id = rt.uidTransformGUID

  12:  inner join bts_assembly assem

  13:  on ms.assemblyid = assem.nID

  14:  inner join bts_item item

  15:  on ms.itemid = item.id

  16:  --order by Port, nSequence

  17:   

  18:  union

  19:   

  20:  select

  21:  'SendPort' PortType,

  22:  r.nvcName Port,

  23:  item.name MapName,

  24:  assem.nvcName Assembly,

  25:  nSequence, indoc_docspec_name, outdoc_docspec_name

  26:  from bts_sendport_transform rt

  27:  inner join bts_sendport r

  28:  on rt.nSendPortID = r.nID

  29:  inner join bt_mapspec ms

  30:  on ms.id = rt.uidTransformGUID

  31:  inner join bts_assembly assem

  32:  on ms.assemblyid = assem.nID

  33:  inner join bts_item item

  34:  on ms.itemid = item.id

  35:   

  36:  order by PortType, Port, nSequence

Der Result Set ist eine Liste mit noch referenzierenden Objekten.