Bekannte Probleme für Microsoft BizTalk Accelerator for RosettaNet (BTARN)
Dieser Abschnitt enthält nützliche Informationen, die Ihnen helfen können, Fehler mit Microsoft® BizTalk Accelerator for RosettaNet (BTARN) zu vermeiden. Die bekannten Probleme sind in die folgenden Bereiche unterteilt:
0A1 Fehlerbenachrichtigung
Geschäftsaktivitätsüberwachung (BAM)
Installation und Konfiguration
Verschiedenes
0A1 Fehlerbenachrichtigung
BTARN führt keine feldübergreifende Validierung für die CIDX-Prozesskonfigurationseigenschaft und die 0A1-Vereinbarungseigenschaft durch.
BTARN hindert Sie nicht daran, die Eigenschaft "Standard" für ein Prozesskonfigurationsprofil auf "CIDX" festzulegen, nachdem Sie die Eigenschaft "0A1 agreement" für eine Vereinbarung, die dieses Profil verwendet, auf "0A1" festgelegt haben, obwohl ein CIDX keine 0A1-Vereinbarungen unterstützt.
Geschäftsaktivitätsüberwachung (Business Activity Monitoring, BAM)
Doppelte Spaltendaten werden in den Berichten zur Überwachung der Geschäftsaktivität angezeigt.
Die Spalten ActivityID und PIPInstanceID in den Webberichten für BAM-Aktivitäten enthalten denselben Inhalt. Diese Daten geben den Partner Interface Process (PIP) instance Bezeichners genau wider. Die ActivityID verwendet diesen Wert für die interne Korrelation. Diese Meldung können Sie ignorieren.
Leere Datenspalten in den Webberichten zur Überwachung der Geschäftsaktivität
Die BAM-Webberichte (Business Activity Monitoring) enthalten keine Daten für 0A1-Nachrichtenprozesse. Die 0A1-Nachrichtenspalten in den Webberichten sind mit "Initiated 0A1" hartcodiert.
Installation und Konfiguration
Gruppen und Benutzer in der Gruppe BizTalk-Anwendungsbenutzer und der Gruppe BizTalk Server-Administratoren müssen sich in derselben Domäne befinden.
BTARN unterstützt das Hinzufügen einer Gruppe zur Gruppe BizTalk-Anwendungsbenutzer oder BizTalk Server Administratoren. Einzelne Benutzerkonten und Gruppen, die entweder zur Gruppe BizTalk-Anwendungsbenutzer oder der Gruppe BizTalk Server-Administratoren gehören, müssen jedoch Teil derselben Domäne sein.
Die Deinstallation von BTARN schlägt fehl, wenn BizTalk Server zuerst entfernt wird
Wenn Sie vor dem Entfernen von BTARN BizTalk Server entfernen, schlägt der BTARN-Entfernungsprozess ohne Fehler fehl. Um dieses Problem zu beheben, installieren Und konfigurieren Sie BizTalk Server neu, und entfernen Sie dann BTARN.
Für die verteilte Bereitstellung ist ein Domänencontroller erforderlich.
Die Bereitstellung von BTARN in einer Umgebung mit mehreren Servern erfordert einen Domänencontroller, z. B. wenn Sie BTARN auf einem Server installiert haben und die SQL Server Datenbanken, die für die Konfiguration auf einem anderen Server verwendet werden.
Benutzerdefinierte PIP-Konfigurationen werden nicht unterstützt.
Die aktuelle Version von BTARN unterstützt nicht die Konfiguration von PIPs mit benutzerdefinierten Elementen oder anderen Nicht-RosettaNet-Standardinformationen.
BTARN startet automatisch den Single Sign-On-Dienst
BTARN startet das einmalige Sign-On (Single Sign-On, SSO) automatisch in einem Fall, wenn BTARN es erfordert und der SSO-Dienst nicht ausgeführt wird.
Das Konfigurationsprogramm entfernt keine virtuellen BTARN-Verzeichnisse aus der Liste ausgeschlossener Pfade, wenn WebApps nicht für die Standardwebsite konfiguriert ist.
Wenn Sie eine BTARN-Installation aufheben, in der der virtuelle Ordner der Webanwendung als SharePoint Server und nicht als Standardwebsite konfiguriert wurde, müssen Sie nach der Dekonfiguration die virtuellen Verzeichnisse btarnapp und btarnhttpreceive manuell aus der Liste Ausgeschlossene Pfade auf der Website der SharePoint-Zentraladministration entfernen. Dies tritt auf, da Sie beim Konfigurieren des virtuellen Webanwendungsordners sharePoint Server der Liste Ausgeschlossene Pfade manuell btarnapp und btarnhttpreceive hinzufügen müssen. Das Konfigurationsprogramm kann sie nicht automatisch aus der Liste ausgeschlossener Pfade entfernen.
Verschiedenes
BTARN empfängt Nachrichten, die in beiden Verschlüsselungsalgorithmus verschlüsselt sind
Die BTARN-Empfangspipeline empfängt und entschlüsselt eine Nachricht, auch wenn das Protokoll, das zum Verschlüsseln der Nachricht verwendet wird, und die Einstellung Codierung in diesem Feld nicht übereinstimmen. Daher empfängt BTARN Nachrichten, die entweder in RC2-40 oder 3DES verschlüsselt sind.
BTARN erfordert ein Signal in einem synchronen Szenario mit einzeler Aktion
In einem synchronen Einzelaktionsszenario erwartet und generiert BTARN immer Signale. Dieses Verhalten unterscheidet sich von der RosettaNet-Spezifikation, da in einem synchronen Szenario mit einzeler Aktion möglicherweise ein Signal erforderlich ist oder nicht. Wenn BTARN ein Responder ist, generiert es immer ein Signal als Reaktion auf eine Nachricht des Initiators. Wenn BTARN ein Initiator ist, erwartet es immer ein Signal zurück vom Antwortgeber. Wenn BTARN kein Signal empfängt, tritt ein Timeout nach dem in der Eigenschaft in den Time To Perform Prozesskonfigurationseinstellungen angegebenen Intervall auf, und es wird eine 0A1-Nachricht generiert.
BTARN unterstützt UTF-16 in empfangenen Nachrichten
BTARN empfängt und verarbeitet Nachrichten mit einem Zeichensatz von UTF-16. BTARN sendet Nachrichten mit einem Zeichensatz von UTF-8.
Namespaces müssen aus Antwortnachrichten entfernt werden, die aus Anforderungsnachrichten zugeordnet sind
Wenn Sie BizTalk Mapper im privaten Prozess eines Szenarios mit doppelter Aktion verwenden, fügt BizTalk Mapper einigen Elementtags in Antwortmeldungsinstanzen Namespaces hinzu, die aus Anforderungsmeldungen zugeordnet sind. Diese Namespaces verursachen einen Fehler in der Sendepipeline. Sie müssen diese Namespaces entfernen. Verwenden Sie dazu das HeaderHelper-Beispiel. Weitere Informationen finden Sie unter Double Action PIPAutomation Orchestration [RN3] und Schritt 4: Erstellen des HeaderHelper-Projekts [RN3].
Das Ändern von URI-Einstellungen erfordert IISRESET
Beim Ausführen des Setupprogramms legen Sie die URI-Einstellungen fest, die die ASPX-Seiten empfangen und senden verwenden, sowie die URI-Einstellungen der Empfangs- und Sendeadapter. Sie müssen diese Einstellungen ändern, wenn Sie den Namen des Computers ändern, auf dem die ASPX-Seiten oder die Adapter installiert sind. Sie können diese Einstellungen ändern, indem Sie den Konfigurationsvorgang erneut ausführen. Hierzu müssen jedoch alle Konfigurationseinstellungen zurückgesetzt werden. Sie können die URI-Einstellungen allein ändern, indem Sie die zugeordneten Registrierungsschlüssel (AsyncReceivePortURI, , RNIFSenderURIund SyncReceivePortURI) ändern. Nachdem Sie eine dieser Registrierungseinstellungen geändert haben, müssen Sie IISRESET ausführen, damit die Änderungen wirksam werden. Dies liegt daran, dass BTARN die Einstellungen für die Verwendung zwischenspeichert. Nachdem Sie IISRESET ausgeführt haben, müssen Sie auch BizTalk-Dienste neu starten.
BTARN erzwingt keine Einschränkungen für RNIF v1.1-Enumerationen
Die RnIF-Spezifikation (RosettaNet Implementation Framework) v1.1 legt Einschränkungen für einige RNIF-Schemaaufzählungen fest. BTARN erzwingt diese Einschränkungen nicht und überprüft nicht anhand dieser Einschränkungen. Die Einschränkungen gelten nicht für RNIF v2.01.
Dies gilt für die folgenden Dienstheaderelemente:
GlobalBusinessActionCodeGlobalPartnerClassificationCodeGlobalBusinessServiceCodeGlobalProcessCodeGlobalProcessIndicatorCodeVersionIdentifier
PerformanceControlRequest-Parameter überschreiben die Standardprozesskonfigurationseinstellungen nicht.
Eingehende Nachrichten können Parameter im Dienstheader enthalten PerformanceControlRequest . Diese Parameter enthalten Werte für die Zeitverzögerungsparameter von Time to Acknowledge (Receipt) und Time to Perform, die in den Prozesskonfigurationseinstellungen in der BTARN-Verwaltungskonsole festgelegt sind. BTARN legt die Zeitverzögerungen nicht dynamisch basierend auf den PerformanceControlRequest Parametern in der eingehenden Nachricht fest. BTARN nimmt immer die Zeitverzögerungen von den pip-Standardwerten ab, die in den Prozesskonfigurationseinstellungen festgelegt sind. Dies entspricht der RnIF-Spezifikation (RosettaNet Implementation Framework) v1.1.
Bei PIP-Name und PIP-Version von Double-Action-Nachrichten wird die Groß-/Kleinschreibung beachtet.
Wenn der PIP-Name und die PIP-Version einer Antwortnachricht eine andere Groß- und Kleinschreibung aufweisen als die entsprechenden Werte der ursprünglichen Double-Action-Anforderungsnachricht, lehnt der Initiator BTARN die Antwortnachricht als ungültig ab und gibt eine Ausnahme an den Antwortgeber zurück.
BTARN unterstützt keine Änderung der Vereinbarungseinstellungen, während aktive Prozesse vorhanden sind.
Änderungen an den Vereinbarungseigenschaften gelten, sobald Sie auf Anwenden oder OK klicken, um sie zu akzeptieren. Nachdem Sie eine Vereinbarung geändert haben, verwenden alle neuen Aktivitäten in einem bereits ausgeführten Prozess oder jeder neue Prozess, der diese Vereinbarung umfasst, die geänderten Vertragseigenschaften. Wenn beim Ändern der Vereinbarung ein Prozess ausgeführt wurde, hat dieser möglicherweise bereits die vorherigen Vertragseigenschaften für eine Nachricht verwendet. Die neuen Nachrichten für diesen Prozess verwenden die neuen Vereinbarungseinstellungen, die zu unvorhersehbaren Ergebnissen führen können. Es wird empfohlen, die Vereinbarungseinstellungen zu ändern, wenn keine Prozesse ausgeführt werden.
BTARN führt nach Änderungen an einem Prozesskonfigurationsprofil keine feldübergreifende Überprüfung durch.
Wenn Sie ein Prozesskonfigurationsprofil erstellen und dann eine Vereinbarung erstellen, führt BTARN eine feldübergreifende Überprüfung durch, um sicherzustellen, dass die Eigenschaften der Vereinbarung und des Profils kompatibel sind. Beispielsweise wird überprüft, ob für ein Profil, für das die Standard-Eigenschaft auf "CIDX" festgelegt ist, die 0A1-Vereinbarungseigenschaft der Vereinbarung auf "No 0A1" festgelegt ist. Wenn Sie jedoch ein Prozesskonfigurationsprofil ändern, nachdem Sie eine Vereinbarung erstellt haben, führt BTARN keine feldübergreifende Überprüfung durch. Wenn Sie die Standard-Eigenschaft von "RosettaNet" in "CIDX" ändern, überprüft BTARN nicht, ob die 0A1-Vertragseigenschaft der Vereinbarung auf "No 0A1" festgelegt ist.
Fehler treten auf, wenn nicht alle Orchestrierungen gestartet werden.
Das BTARN-Setupprogramm installiert neun Orchestrierungen. Damit BTARN Nachrichten erfolgreich verarbeiten kann, müssen Sie alle neun Orchestrierungen binden, auflisten und starten, bevor Sie die Verarbeitung initiieren. Weitere Informationen finden Sie in den Themen "Orchestrierungsverwaltung in BizTalk Explorer" oder "Verwalten von Orchestrierungen" in BizTalk Server Hilfe.
RNIFReceive.aspx entfernt die MIME-Untergrenze nicht aus einer Nachricht.
Wenn die RNIFReceive.aspx-Seite eine Nachricht von einer RNIFSend.aspx-Seite eines Partners empfängt, enthält die Nachricht einen MIME-Header und eine MIME-Ober- und Untergrenze, eine Basis-64-Zahl. RNIFSend.aspx fügt der Nachricht den Header und die Begrenzungen für die RNIF-Übertragung hinzu. RNIFReceive.aspx sollte den MIME-Header und die Begrenzungen aus der Nachricht entfernen, bevor die Nachricht an den öffentlichen Prozess gesendet wird. RNIFReceive.aspx entfernt den MIME-Header und die obere Grenze, aber nicht die untere Grenze. Das Vorhandensein der unteren Grenze wirkt sich nicht auf die Verarbeitung der Nachricht im öffentlichen Prozess aus.
BTARN unterstützt keine Konfiguration von SQL Server Datenbanken, bei der die Groß-/Kleinschreibung beachtet wird.
Wenn Sie bei BTARNSQL Server-Datenbanken und Datenbankobjekten die Groß-/Kleinschreibung beachten, kann die BTARN-Verwaltungskonsole Datenbankressourcen nicht finden und löst eine Ausnahme aus. Bei den BTARNSQL Server-Datenbanken und -Datenbankobjekten muss die Groß-/Kleinschreibung nicht beachtet werden.
Alle Abfragen in Datenbankwartungsskripts sollten für UTC-Zeit geschrieben werden.
BTARN SQL Server Datenbanken die UTC-Zeit (Universal Time Coordinate) verwenden, sodass jede Abfrage, die Sie zum Verwalten einer dieser Datenbanken erstellen, für UTC-Zeit geschrieben werden muss. Wenn Ihr Wartungsskript beispielsweise den GetDate() Befehl verwenden würde, sollten Sie ihn in GetUTCDate()ändern.
Eine PublicResponder-Orchestrierung lehnt eine doppelte Anforderungsaktionsnachricht ab.
Wenn eine PublicResponder Orchestrierung (PublicResponderV11.odx) eine doppelte Anforderungsaktionsmeldung empfängt, protokolliert sie eine Warnung im Ereignisprotokoll und lehnt dann die Nachricht ab. Wenn nach Abschluss der Responder-Orchestrierung eine doppelte Nachricht empfangen wird, beendet BizTalk Server die Nachricht, da keine Abonnements vorhanden sind.
Übertragungsfehler werden in BAM nicht angezeigt, wenn der öffentliche Prozess beendet wurde
Wenn ein Übertragungsfehler auftritt, wenn eine Öffentliche Prozessorchestrierung die endgültige Nachricht verarbeitet, zeigen das Ereignisprotokoll und hat den Fehler an, bam hingegen nicht. BAM kann die Meldung nicht anzeigen, weil die Orchestrierung beendet wurde.
Das pipeline.exe-Tool kann nicht zum Debuggen einer BTARN-Empfangspipeline verwendet werden.
Wenn Sie eine Empfangspipeline debuggen möchten, müssen Sie einen Port erstellen, der die Pipeline hosten soll. Sie können sie nicht mit dem pipeline.exe-Tool debuggen, das BizTalk Server bereitstellt.
Möglicherweise wird ein Fehler für eine Wiederholungsmeldung generiert, die nach Abschluss der Orchestrierung erfolgreich verarbeitet wird.
BTARN verwendet Orchestrierungen, um den Prozessfluss darzustellen. In einigen Fällen, in denen mehrere wiederholte Nachrichten wiederholt werden, kann die Orchestrierung erfolgreich abgeschlossen werden, bevor eine wiederholungsbasierte Nachricht im BizTalk MessageBox-Objekt eingeht. Wenn dieses Verhalten auftritt, generiert BizTalk Server eine entsprechende Fehlermeldung "abgeschlossen, aber verworfen". Sie sollten sich Ihre Branchenanwendung ansehen, um zu ermitteln, ob der Prozess abgeschlossen wurde oder nicht. Wenn die BRANCHENanwendung einen erfolgreichen Abschluss angibt, können Sie die Meldung "Abgeschlossen, aber verworfen" ignorieren.
Eine aus tracking.xls exportierte XML-Datei enthält möglicherweise falsche Felder.
Wenn Sie neue Überwachungsansichten in einer XLS-Nachverfolgungsdatei definieren und eine XML-Datei aus der XLS-Nachverfolgungsdatei exportieren, werden einige der Feldnamen geringfügig geändert. Um dies zu korrigieren, überprüfen Sie die Felder in Ihrer angepassten XML-Nachverfolgungsdatei mit dem standard-tracking.xml Feld, das vom BTARN-Setup installiert wird.
DAS RNIF 1.1-Dienstheaderschema für Signale und Antworten muss möglicherweise geändert werden.
BTARN liefert alle RosettaNet-Headerschemas standardmäßig. Einige Implementierungen verwenden die Knoten Signalsteuerung und Aktionssteuerung anders als andere, wie unten beschrieben.
BTARN enthält das Signal Control-Element wie folgt. Beachten Sie, dass dies auch für das Action Control-Element der Fall sein kann.
<!ELEMENT SignalControl (
InstanceIdentifier,
PartnerRoute,
SignalIdentity,
inResponseTo)>
Wenn Ihre Lösung diese Sequenz erfordert, müssen Sie nichts tun.
Einige andere Implementierungen verwenden dagegen den folgenden Code:
<!ELEMENT SignalControl (
inResponseTo,
InstanceIdentifier,
PartnerRoute,
SignalIdentity)>
Wenn Ihre Lösung diese Sequenz erfordert, lesen Sie kb-889523. Dieses Softwareupdate ändert das entsprechende XML-Schema. Beachten Sie, dass sich dieses Update nur auf RNIF 1.1-Prozesse auswirkt.
Gespeicherte PipAutomationGetAction SQL-Prozedur muss aktualisiert werden
Sie müssen die gespeicherte SQL-Prozedur PipAutomationGetAction aktualisieren, um einzelne Datensätze zu sperren. Löschen Sie die folgenden Zeilen:
IF @@ERROR <> 0
UPDATE MessagesToLOB SET Delivered = -1 WHERE MessageID = @tempGUID
Die richtige gespeicherte PipAutomationGetAction-Prozedur lautet wie folgt:
CREATE PROCEDURE PipAutomationGetAction
AS
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRANSACTION
DECLARE @tempGUID nvarchar(36)
SELECT TOP 1 @tempGUID = MessageID FROM MessagesToLOB WITH (READPAST,UPDLOCK,ROWLOCK)
WHERE Delivered = 0 AND MessageCategory = 10
ORDER BY TimeCreated
SELECT PIPInstanceID,DestinationPartyName,SourcePartyName,PIPCode,PIPVersion, ServiceContent FROM MessagesToLOB
WHERE MessageID = @tempGUID
For xml auto
UPDATE MessagesToLOB SET Delivered = 1 WHERE MessageID = @tempGUID
COMMIT TRANSACTION
GO
Sie können aspx-Code anpassen, um die Fehlerbeschreibung zurückzugeben.
Wenn Sie eine Fehlerbeschreibung protokollieren oder senden müssen, können Sie den ASPX-Code so anpassen, dass der tatsächliche Text in der Antwort zurückgegeben wird. Verwenden Sie hierzu HttpResponse.Status (das Antwortobjekt der systeminternen asp-Anforderung) oder HttpWebResponse.StatusDescription (das vom .NET-Aufruf der GetResponse-Methode des HttpWebRequest-Objekts zurückgegeben wird). Um die Rückgabewerte aus einem der anwendbaren Antwortobjekte zurückzugeben, legen Sie den Response.Status-Wert ähnlich wie Response.StatusCode im aspx-Code fest, der mit BTARN enthalten ist.
RNIF 1.1-Nachrichten können nicht als Nur-Text aus Nicht-Ablehnungstabellen gelesen werden, wenn die Codierungsmethode auf Base64 festgelegt ist.
Dies geschieht nur, wenn die Codierungsmethode auf Base64 festgelegt ist. Nachrichten können in Klartext aus Nicht-Ablehnungstabellen gelesen werden, wenn die Codierungsmethode auf Inführungszeichen druckbar oder 8 Bit festgelegt ist. Sie müssen die Nachrichtendatei mit der Erweiterung *.eml speichern und dann mit Outlook Express öffnen, um die Nachricht zu lesen, und Outlook Express decodiert die Nachricht für Sie. Sie können auch den folgenden Code verwenden, um die Base64-codierten Nachrichten aus Nicht-Ablehnungstabellen zu lesen.
byte[] textBytes = Convert.FromBase64String(txtEncodedText.Text);
string plainText = Encoding.UTF8.GetString(textBytes);
txtOutput.Text = plainText;