CONNECTED Conference 2023 - Aufzeichnungen jetzt hier verfügbar +++                     

Suche

über alle News und Events

 

Alle News

 

Für Entwickler, Architekten, Projektleiter und...

Read more

In der Welt der Softwareentwicklung ist die...

Read more

QUIBIQ spendet für den guten Zweck – und für...

Read more

Eine bestimmte Antwort auf einen HTTP Request zu...

Read more

In einer Welt, die von stetigem Wandel geprägt...

Read more

In einem unserer Kundenprojekte, war das Ziel eine...

Read more

QUIBIQ Hamburg wird mit dem Hamburger...

Read more

Zwei Tage lang wurde vom 14.-15.11 wieder das...

Read more

Was ist ein Excel-Plugin – und wann ist es...

Read more

Wir expandieren, bringen Kunden und Talente besser...

Read more

How-to: Early Exit mit Erfolg in einer Orchestration

Normalerweise kennt eine BizTalk Orchestration nur ein erfolgreiches Ende. Wenn man typischerweise von nur einem Startpunkt einer Orchestration ausgeht, entspricht das dem "Single-Entry – Single-Exit“ Programmier-Paradigma. Ursprünglich sollte dieses Paradigma einen klaren Programmablauf bedingen. Praktisch führt das strikte Befolgen aber eher zu Spaghetti-Code und wird von den meisten Programmierern daher, ähm, nicht so gemocht… wir haben da eine Lösung für euch.

Nun kann man ja eine BizTalk Orchestration schon vorzeitig verlassen, mit Hilfe des Suspend-Shapes (https://msdn.microsoft.com/en-us/library/aa560868.aspx), oder der Terminate-Shapes (https://msdn.microsoft.com/en-us/library/ee294389.aspx). Allerdings sind beide Shapes nur für Fehlersituationen vorgesehen. Was also tun, wenn in einer größeren Orchestration z.B. bei unterschiedlichen Bedingungen der Ablauf an verschiedenen Stellen vorzeitig (und erfolgreich) beendet werden sollte?
Zur Not kann man natürlich die Terminate-Shapes missbrauchen. Dann sind jedoch „erfolgreich“ terminierte von wirklich fehlerhaften Orchestration-Instanzen beim Orchestration-Tracking schwer zu unterscheiden. Oder man kann mit Dutzenden Decide-Shapes den schwer zu überblickenden Programmablauf bis zum bitteren erfolgreichen Ende führen. Nicht wirklich schön. Als Lösung (oder wenn man will, Workaround, bis es ein Return-Shape gibt ;-) haben wir folgenden Ansatz erfolgreich verwendet.

Exception Typ

In einem kleinen C# Helper-Projekt basteln wir eine minimale Exception. Diese repräsentiert kein Problem, sondern ein erfolgreiches Ende.

[Serializable]

public class ExitWithSuccessException : Exception

{

    public ExitWithSuccessException() {}

    public ExitWithSuccessException(SerializationInfo info, StreamingContext context)

        : base(info, context) {}

}

Zu bemerken sind die beiden Konstruktoren: Mit dem parameterlosen Konstruktor kann eine Exception-Instanz von der Orchestration direkt instanziiert werden. Der Konstruktor mit den Serialisierungs-Parametern wird im Falle von Dehydration/Rehydration benötigt, damit BizTalk beim Aufwachen der Orchestration-Instanz die Exception deserialisieren kann.

Exception Variable

Wir erzeugen in der Orchestration eine Variable vom Typ dieser Exception, z.B. SuccessException genannt.

Global Scope mit Exception Handler

 

Wir legen die komplette Orchestration in einen Scope mit einem Exception Handler, in dem nur Exceptions vom Typ der ExitWithSuccessException gefangen werden.

Throw to Exit

 

An jeder Stelle, an der ein Early Exit benötigt wird, werfen wir mit Hilfe eines Throw Shapes die SuccessException. Dieses Throw Shape repräsentiert dann das erfolgreiche Return.

 

Demo

 

Voila,das war’s schon! Eine komplette einfache Demo eines beispielhaften Ablaufs passt auf eine Seite.

 

Details können nun selbstverständlich ausgeschmückt werden. Z.B. können verschiedene Exception Typen sinnvoll sein (für Erfolg, für Warning oder doch für Fehler – dann mit anderer Behandlung…) oder es kann zum Erzeugen der Exceptions ein kleiner C# Helper verwendet werden, um z.B. interessante Infos in die Exception zu stecken oder diese Infos auszugeben. Statt des Throw-Shapes wird dieser Helper dann in einem Expression-Shape aufgerufen.

 

Viel Spaß beim Umsetzen. Wir freuen uns darauf, von Euren Erfahrungen und Ideen zu hören!

Nun kann man ja eine BizTalk Orchestration schon vorzeitig verlassen, mit Hilfe des Suspend-Shapes (https://msdn.microsoft.com/en-us/library/aa560868.aspx), oder der Terminate-Shapes (https://msdn.microsoft.com/en-us/library/ee294389.aspx). Allerdings sind beide Shapes nur für Fehlersituationen vorgesehen. Was also tun, wenn in einer größeren Orchestration z.B. bei unterschiedlichen Bedingungen der Ablauf an verschiedenen Stellen vorzeitig (und erfolgreich) beendet werden sollte?
Zur Not kann man natürlich die Terminate-Shapes missbrauchen. Dann sind jedoch „erfolgreich“ terminierte von wirklich fehlerhaften Orchestration-Instanzen beim Orchestration-Tracking schwer zu unterscheiden. Oder man kann mit Dutzenden Decide-Shapes den schwer zu überblickenden Programmablauf bis zum bitteren erfolgreichen Ende führen. Nicht wirklich schön. Als Lösung (oder wenn man will, Workaround, bis es ein Return-Shape gibt ;-) haben wir folgenden Ansatz erfolgreich verwendet.

Exception Typ

In einem kleinen C# Helper-Projekt basteln wir eine minimale Exception. Diese repräsentiert kein Problem, sondern ein erfolgreiches Ende.

[Serializable]

public class ExitWithSuccessException : Exception

{

    public ExitWithSuccessException() {}

    public ExitWithSuccessException(SerializationInfo info, StreamingContext context)

        : base(info, context) {}

}

Zu bemerken sind die beiden Konstruktoren: Mit dem parameterlosen Konstruktor kann eine Exception-Instanz von der Orchestration direkt instanziiert werden. Der Konstruktor mit den Serialisierungs-Parametern wird im Falle von Dehydration/Rehydration benötigt, damit BizTalk beim Aufwachen der Orchestration-Instanz die Exception deserialisieren kann.

Exception Variable

Wir erzeugen in der Orchestration eine Variable vom Typ dieser Exception, z.B. SuccessException genannt.

Global Scope mit Exception Handler

 

Wir legen die komplette Orchestration in einen Scope mit einem Exception Handler, in dem nur Exceptions vom Typ der ExitWithSuccessException gefangen werden.

Throw to Exit

 

An jeder Stelle, an der ein Early Exit benötigt wird, werfen wir mit Hilfe eines Throw Shapes die SuccessException. Dieses Throw Shape repräsentiert dann das erfolgreiche Return.

 

Demo

 

Voila,das war’s schon! Eine komplette einfache Demo eines beispielhaften Ablaufs passt auf eine Seite.

 

Details können nun selbstverständlich ausgeschmückt werden. Z.B. können verschiedene Exception Typen sinnvoll sein (für Erfolg, für Warning oder doch für Fehler – dann mit anderer Behandlung…) oder es kann zum Erzeugen der Exceptions ein kleiner C# Helper verwendet werden, um z.B. interessante Infos in die Exception zu stecken oder diese Infos auszugeben. Statt des Throw-Shapes wird dieser Helper dann in einem Expression-Shape aufgerufen.

 

Viel Spaß beim Umsetzen. Wir freuen uns darauf, von Euren Erfahrungen und Ideen zu hören!

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz