Ich habe einen BizTalk WCF-Custom-Empfangsspeicherort, dem ich ein benutzerdefiniertes Verhalten hinzugefügt habe:
%Vor%Parameter-Setup-Code wurde der Kürze wegen weggelassen
Dies ist aus einer Probe, die in Ссылка gefunden wurde - dieser Autor ist in der BizTalk-Community weithin respektiert und Code dieser Art wird seit einigen Jahren verwendet. Alles, was ich tue, ist die Anpassung der Methode, die er verwendet, die nachweislich funktioniert, um einen anderen TokenProvider zu ersetzen.
Ich kann durch das Debugging sehen, dass dieser Code ausgeführt wird und der TransportClientEndpointBehavior mit korrekten Parametern zum Kanal hinzugefügt wird. Wenn die BizTalk-Standortabfrage Service Bus empfängt, sehe ich jedoch im Ereignisprotokoll Folgendes:
Der Adapter "WCF-Custom" hat eine Fehlermeldung angezeigt. Details "System.UnauthorizedAccessException: 40102: Fehlendes Autorisierungstoken, Ressource: sb: // [Namespace] .servicebus.windows.net / [Warteschlange]. TrackingId: 452c2534-d3e6-400f-874f-09be324e9e11_G27, SystemTracker: [Namespace]. servicebus.windows.net:[queue], Timestamp: 01.12.2016 11:38:56 --- & gt; System.ServiceModel.FaultException: 40102: Fehlendes Autorisierungstoken, Ressource: sb: // [Namespace]. servicebus.windows.net/[queue]. TrackingId: 452c2534-d3e6-400f-874f-09be324e9e11_G27, SystemTracker: [namespace] .servicebus.windows.net: [Warteschlange], Timestamp: 01.12.2016 11:38:56 AM
Ich kann keinen Grund dafür finden, dass der Azure Service Bus-Endpunkt diese Fehlermeldung zurückgibt, mit der Ausnahme, dass der Token-Anbieter nicht verwendet wird. Warum sollte der Kanal den TokenProvider ignorieren und was muss ich tun, um das Token korrekt zu übergeben?
Bearbeiten:
Ich habe den rohen WCF-Nachrichtenverkehr für den fraglichen Port sowie den SB-Messaging-Adapter geprüft, der wie erwartet funktioniert. Der Unterschied besteht darin, dass die Nachrichten des SB-Messaging-Adapters einen SOAP-Header wie folgt enthalten:
<Authorization xmlns="http://schemas.microsoft.com/servicebus/2010/08/protocol/">SharedAccessSignature sr=[really long encoded string]</Authorization> und die Nachrichten meines benutzerdefinierten Bindungs-Ports nicht. Es stimmt also, dass das Problem ein fehlender SOAP-Header der Autorisierung ist; aber die Frage bleibt bestehen - warum fügt der Kanal diesen Header nicht hinzu?
Bearbeiten Sie # 2:
Ich habe Microsoft.ServiceBus.dll dekompiliert und ich glaube, ich habe die Klasse gefunden, die tatsächlich die WCF-Nachricht erstellt, Microsoft.ServiceBus.Messaging.Sbmp.SbmpMessageCreator . Es hat diese Methode:
Wenn wir logisch darüber nachdenken, gibt es zwei Gründe, warum der Autorisierungskopf fehlt:
includeToken ist falsch (Warum sollte das so sein?) GetAuthorizationHeader() gibt null (Warum?) Bearbeiten Sie # 3:
Ich habe den Beispielcode kompiliert und ausgeführt und das funktioniert. Der einzige signifikante Unterschied zwischen meinem Code und seinem ist, dass meins eine Zeile enthält, die zu Azure Key Vault aufruft:
%Vor%Dies ist eine asynchrone Methode, die eine Aufgabe zurückgibt. Kann es sein, dass das Blockieren des Ergebnisses dieser Aufgabe irgendwie nicht funktioniert, was in bestimmten Situationen zu erwarten wäre, und das die Konfiguration des WCF-Kanals irgendwie in Unordnung bringt? Wie gesagt, ich bin mir sicher, dass dieser Code läuft und den TokenProvider zuweist. Ich bin jetzt nur nicht sicher wenn es läuft.
D'OH!
Ich hatte versäumt zu erkennen, dass die sehr alte Version von Microsoft.ServiceBus.dll, die wir noch in der Lösung für Interop mit der (ebenso alten) lokalen Version von Service Bus (Service Bus für Windows Server) haben, die referenzierte war bei meinem Projekt. Aus irgendeinem Grund tut diese Version einfach nicht, was sie soll, und gibt keinen Hinweis darauf, dass sie das beabsichtigte Verhalten umgeht. Das Aktualisieren des aktuellen NuGet-Pakets für Service Bus behebt das Problem.
Tags und Links wcf azureservicebus biztalk azure-servicebus-queues