none
CustomPipeline Component

    Frage

  • Hallo alle zusammen.

    Heute habe ich versucht, eine Custom Pipeline Component (e) zu erstellen, die einen Ordnernamen an die weitere Verarbeitung in der Orchestrierung übergibt. Der Ordnername wird in der Konfiguration der Komonente über die BizTalk-Verwaltungskonsole eingetragen.

    Dazu habe ich ein public static string erstellt, welches ich anschließend in der Orchestrierung aufrufe.

    Leider bekomme ich in der Orchestrierung ein leeres String zurück, obwohl die Ausgabe in der Pipeline-Komponente die richtigen Werte ausgibt.

    Woran liegt das???

    Mittwoch, 16. Februar 2011 10:56

Antworten

  • Hallo zusammen,

    @Alex

    Wenn ich das Posting richtig lese, ist der String Ordnerpfad nicht Bestandteil der Nachricht, somit sind deine Überlegungen zwar richtig, greifen hier aber nicht.

    @Igor

    Zwei Dinge;

    Eine Orchestrierung wird durch eine Message ausgelöst. Wenn die Message aber an den BizTalk Server übergeben wurde, hat sich der Ablauf in der Pipeline längst erledigt. Du musst deinen String, also mit der Message übergeben (z.B. als Custom SOAPHeader).

    Eine Pipeline gibt nur Messages zurück und keine sonstigen Daten. Ich kann aber innerhalb der Pipeline beinflussen, wo der gewünschte Ausgang ist.

    Überdenke mal dein Solutiondesign, dann sollte es auch klappen.

    Schöne Grüße

    Oliver

    Mittwoch, 16. Februar 2011 16:05

Alle Antworten

  • Hallo,

     

    kannst Du nachprüfen, ob der Nachricht, welches aus Pipeline rauskommt der richtige Wert beinhaltet?

     Am einfachsten erstelle einen Sende Port mit dem Filter auf MessageType und dem File-Adapter.

     

    Grüß,

     

    Alex.

    Mittwoch, 16. Februar 2011 14:51
  • Guten Tag Herr Polonskiy.

    Die Message wird richtig abgelegt. Der Gedanke ist jedoch den Pfad nicht in die Message einzutragen, sondern in die static-Variable abzulegen, damit ich diese zu einem späteren Zeitpunkt in der Orchestrierung verwenden kann, ohne die Maschine nicht unnötig auszulasten.

    Oder habe ich Sie missverstanden?

    P.S.: Meine Vermutung ist folgende: Die PipeLine-DLL wird nur dann eingebunden, wenn die Nachricht empfangen wird. Bei der anschließenden übergabe in die Orchestrierung, wird das Pipeline-Objekt zersört, was dazu führt, dass die geänderte (static-)Variable aus dem Speicher entfernt wird.

    Wenn dies der Fall ist, dann muss ich mir eine andere Methode überlegen. Diese jedoch wäre eine schönere.

    Mittwoch, 16. Februar 2011 15:10
  • Hallo,

     

    Wenn die Nachricht der richtige Wert beinhaltet, dann funktioniert CPC auch richtig J

     

    Probiere  das Element in das Schema als Distinguished Field gekennzeichnen. (Promote Properties). Danach kann man in der Orchestration in Message Assignment Shape auf das Feld zuzugreifen.

     

    Grüß,

    Alex.

    Mittwoch, 16. Februar 2011 15:27
  • Hallo zusammen,

    @Alex

    Wenn ich das Posting richtig lese, ist der String Ordnerpfad nicht Bestandteil der Nachricht, somit sind deine Überlegungen zwar richtig, greifen hier aber nicht.

    @Igor

    Zwei Dinge;

    Eine Orchestrierung wird durch eine Message ausgelöst. Wenn die Message aber an den BizTalk Server übergeben wurde, hat sich der Ablauf in der Pipeline längst erledigt. Du musst deinen String, also mit der Message übergeben (z.B. als Custom SOAPHeader).

    Eine Pipeline gibt nur Messages zurück und keine sonstigen Daten. Ich kann aber innerhalb der Pipeline beinflussen, wo der gewünschte Ausgang ist.

    Überdenke mal dein Solutiondesign, dann sollte es auch klappen.

    Schöne Grüße

    Oliver

    Mittwoch, 16. Februar 2011 16:05
  • Vielen Dank für die Beiträge.

    Ich werde die Lösung jetzt so aufbauen, dass ich den Pfad für den Ordner in die Registry ablege.

    Herr Polonskiy hat mich (durch eine andere Kommunikationsquelle) auf einen interessanten Punkt hingewiesen, den ich übersehen habe und welcher auch zeigt, dass das Vorhaben nicht klappen kann:

     - Würde das ReceivePort über eine andere HostInstanz als die Orchestrierung laufen, würden wir uns in einem anderen Thread befinden und dadurch NICHT mehr auf die Variable zugreifen können.

    Mittwoch, 16. Februar 2011 17:06
  • Hallo Igor,

     

    also zunächst ist deine Lösung ein wenig komisch. Üblich wäre ein Property Schema zu erstellen (für den Pfad) und dann in der Pipeline den Wert zu ermitteln und dann zu promoten. Je nach Kenntnisstand im BizTalk Server ist das aber mal "nicht so eben" erledigt.

    Der Trick mit der Static Variable müsste eigentlich klappen, aber nur wenn der Receiveport und die Orchestration auf der gleichen Hostinstanz laufen. Dann teilen sich diese im .NET Sinne eine AppDomain und müssten auch die statischen Variablen teilen. Denn BizTalk Host Instanz = Windows Dienst = AppDomain. Kann es sein, dass du hier zwei unterschiedliche Hostinstanzen nutzt?

     

    Ich habe ähnliches schonmal mit einem Singleton ausprobiert. Eine Orchestration füllte diesen Singleton mit Konfigurationswerten, die sich täglich änderten und eine zweite Orchestration nutzte diese für diverse Ablauflogik. Solange alles auf einer Host Instanz läuft, kein Thema.

    Aber wie gesagt, Singleton und statische Variable sollten sich gleich verhalten.

     

    Bedenke nur: Wenn die Nachricht in der Messagebox liegt und der Server abstürzt oder die Host Instanz neu gestartet werden muss, bevor die Orchestrierung durch ist, geht die die Information aus der statischen Variable verloren. Da können leicht Fehler auftreten.

    Zudem wäre es ungeschickt, wenn zweimal die Nachricht einlaufen würde, da du dann keine Zuordnung mehr treffen kannst. Was aber bei einem (wahrscheinlich gleichlautenden) Verzeichnisnamen nicht relevant sein sollte.


    If you like my post or consider it as a valid answer, please use the buttons to show me - Oliver

    http://pi.hauth.me

    Mittwoch, 16. Februar 2011 18:58
  • Hallo zusammen,
     
    Davon würde ich abraten. Folgender Hintergrund:
     
    1. Wenn die Pipeline Komponente schreibend auf den Pfad zugreift, kann es bei Parallelverarbeitung aus mehrere Quellen durcheinander geben.
    2. In einem grossen BizTalk Deployment ist nicht nur nicht garantiert, dass die Verarbeitung Adapter / ReceivePipeline und Orchestration im gleichen Prozess stattfinden – es kann sogar sein, dass es auf unterschiedlichen Maschinen läuft (Scale out bei Enterprise Edition).
     
    Daher unbedingt:
     
    1. Wenn Informationen aus der Pipeline an nachgelagerte Verarbeitungen weiterzureichen sind, sollte man hierfür auf jeden Fall den Context der Nachricht bzw. des Parts nutzen.
    2. Wenn die Pipeline Komponente konfiguriert werden soll, ist dies im Pipeline Designer vorgesehen. Darüber hinaus kann ich im Einzelfall noch eine Per-Instance Config der Pipeline auf der Receive Location durchführen, um ggf. noch leicht abweichende Configurationen zu hinterlegen.
    3. Für Globale Configurationsdaten – zu dem Thema sind schon Bücher gefüllt worden – gibt es einen einfachen Weg, der von MS Seite bereitgestellt wurde: SSO Config (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14524).
     
    Genug Aufzählungen, Viele Grüße
     
    Jörg Fischer
     
     
    "TCP_Igor Pfeifer" schrieb im Newsbeitrag news:850bc624-711c-401d-833e-bcfc879916d7...

    Vielen Dank für die Beiträge.

    Ich werde die Lösung jetzt so aufbauen, dass ich den Pfad für den Ordner in die Registry ablege.

    Herr Polonskiy hat mich (durch eine andere Kommunikationsquelle) auf einen interessanten Punkt hingewiesen, den ich übersehen habe und welcher auch zeigt, dass das Vorhaben nicht klappen kann:

    - Würde das ReceivePort über eine andere HostInstanz als die Orchestrierung laufen, würden wir uns in einem anderen Thread befinden und dadurch NICHT mehr auf die Variable zugreifen können.


    Jörg Fischer
    Mittwoch, 27. Juli 2011 09:19
    Moderator