Entlang der in Abbildung angegebenen Varianten der Erbringung von BTA s wird im folgenden untersucht, wie die Zuordnung der Subtransaktion en im Falle mehrerer beteiligter Kontrollflüsse erfolgen kann.
Findet der Start des neuen Kontrollflusses nicht innerhalb eines Bausteins, sondern in der Anwendungslogik statt, so ist zu untersuchen, inwiefern die oben beschriebene Technik ausreicht, um die Korrelation der Kontrollflüsse zu gewährleisten: Die Anwendungslogik wird zunächst sicher im Kontrollfluß des aufrufenden Bausteins ausgeführt, unabhängig davon, ob es sich z.B. tatsächlich um einen asynchronen Aufruf eines Bausteines oder einen Event-basierten Aufrufmechanismus handelt. Der Start des neuen Kontrollflusses findet somit ebenfalls sicher im Kontrollfluß des aufrufenden Bausteins statt; die oben beschriebene Instrumentierung der Bibliothek für die Erstellung neuer Kontrollflüsse ist somit auch in diesem Falle geeignet, um die Zuordnung herzustellen.
Ebenso wie der Start eines Kontrollflusses kann auch dessen Ende durch Erweiterung des entsprechenden Mechanismus ermittelt und an das Managementsystem übermittelt werden. Start und Stop von Kontrollflüssen sind gleichzeitig als Start und Stop einer Subtransaktion zu betrachten.
Neben dem Start neuer Kontrollflüsse ist der Aufruf aktiver Bausteine die zweite Variante, wie weitere Kontrollflüsse an der Erbringung einer BTA beteiligt werden können. Ein aktiv er Baustein ist hierbei ein Baustein, der über einen eigenen Kontrollfluß verfügt und der z.B. in regelmäßigen Abständen überprüft, ob ein Auftrag zur Bearbeitung vorliegt. Das Erteilen eines Auftrages erfolgt durch den Aufruf einer entsprechenden Methode des aktiv en Bausteins, die beispielsweise die zu bearbeitenden Daten in eine Warteschlange einreiht. Andere Formen der Kommunikation, z.B. über gemeinsamen Speicher sind aufgrund der getroffenen Voraussetzungen über die Kommunikation zwischen Bausteinen nicht möglich.
Abbildung veranschaulicht die Abläufe beim Aufruf eines aktiv en Bausteins. Aus darstellungstechnischen Gründen wurde eine explizite Warteschlange für die Aufträge eingeführt; diese kann aber ebenso Teil des aktiv en Bausteins sein. Um einen Auftrag an einen aktiv en Baustein zu erteilen, ruft ein Client-Baustein eine entsprechende Methode der Warteschlange auf, die somit im Kontrollfluß des Clients ausgeführt wird. Zu beliebigen, nicht vorherbestimmbaren Zeitpunkten überprüft der aktiv e Baustein, ob Aufträge in der Warteschlange vorliegen. Ist dies der Fall, so beginnt er mit der Bearbeitung des jeweiligen Auftrags.
Die Problematik, die sich hierbei ergibt, ist die vollständige Entkoppelung der beteiligten Kontrollflüsse. Zum Zeitpunkt der Auftragsbearbeitung durch den aktiv en Baustein ist es nicht mehr ohne Instrumentierung des Bausteins möglich zu entscheiden, welcher BTA die Subtransaktion zuzuordnen ist, da sich in der Warteschlange Daten unterschiedlicher BTA s zur Bearbeitung befinden können (Eine Lösung für diese Problematik wird in Abschnitt angegeben).