CFD-Projektablauf

[CleCle]

Hallo zusammen,

folgende Ausgangssituation ich habe grade 4 CFS im Einsatz.

Grobe Funktion Skript 1 übergibt an Warteschlange 1, bei nicht Annahme geht der Call zu Skript2 was dann wieder an eine andere Warteschlange mittels Transfer abgibt.

Die Frage ist macht es sinn die Skripte in ein Projekt als Komponenten zu packen und die Skripte dann über den Mainflow anzusprechen? Aus Administrativer Sicht macht es meiner Meinung nach Sinn.
Macht die Anlage das auch mit bei einer Belastung mit 100 Lines in der Spitze?
Der Disconnect Tab wird der bei jedem Verlassen des Skriptes ausgelöst oder erst wenn der Call wirklich beendet wird? Ich befürchte zwar bei jedem Verlassen des Skriptes.

Vielen Dank für eure Mithilfe.
Viele Grüße

Clemens

 

[fxbastler]

Hallo zusammen,

folgende Ausgangssituation ich habe grade 4 CFS im Einsatz.

Grobe Funktion Skript 1 übergibt an Warteschlange 1, bei nicht Annahme geht der Call zu Skript2 was dann wieder an eine andere Warteschlange mittels Transfer abgibt.

Du meinst 4 mit dem CFD gebaute Programme / Apps, sogenannte CFD Apps oder CFA? Ich zähle nur 2, aber egal.

Die Frage ist macht es sinn die Skripte in ein Projekt als Komponenten zu packen und die Skripte dann über den Mainflow anzusprechen?

Das verstehe ich nicht. Willst du diese beiden CFA aus deinem Beispiel von oben zu einer CFA zusammenfassen?

Macht die Anlage das auch mit bei einer Belastung mit 100 Lines in der Spitze?

Die 3CX selber schafft 'alles'. Es gibt doch so einige Anlagen die parallel > 1000 Anrufe verarbeiten, vorausgesetzt die Hardware hat die entspr. Auslegung - je nachdem was gefordert ist: CPU Leistung (mehr single Core Leistung ist immer besser an Stelle vieler langsamer Cores), RAM Größe (das ist sehr relativ, i.d.R. wird weniger gebraucht als man denkt, das kann man ja beobachten wie der voll läuft in der Spitze), Disk IO (wesentlicher Faktor für sehr vieles einer 3CX, wird von vielen sträflich vernachlässigt).
https://www.3cx.com/docs/recommended-hardware-specifications-for-3cx/

Der Disconnect Tab wird der bei jedem Verlassen des Skriptes ausgelöst oder erst wenn der Call wirklich beendet wird? Ich befürchte zwar bei jedem Verlassen des Skriptes.

Der Disconnect Handler Flow wird nur dann abgearbeitet:

1. wenn der Anruf während der Abarbeitung der CFA vom Anrufer beendet wurde
2. kein Fehler im Skript aufgetreten ist (dann wird der Error Handler Flow abgearbeitet)
3. wenn der Anruf an eine andere 3CX Entität regulär übergeben wurde
4. wenn der Main Flow abgearbeitet ist
5. wenn der Baustein Exit Callflow im Programmablauf nicht benutzt wird, siehe
   https://www.3cx.com/docs/manual/cfd-conditions-variables/#h.bhcv2k7t5t3d

 

[CleCle]

Du meinst 4 mit dem CFD gebaute Programme / Apps, sogenannte CFD Apps oder CFA? Ich zähle nur 2, aber egal.

Ich dachte das CFA ist das Ergebnis aus dem, was man mit dem CFD baut. Ich meine auf jeden Fall ein Projekt im CFD.
Ja das ist richtig die anderen beiden Skripte steuern AB Funktionalitäten. Aber vom Prinzip machen die alle was ähnliches.
Wenn ich das Richtig verstanden habe, definiere ich im Main Skript die Variablen auf Projektebene. Und dann kann ich beliebig zwischen den Komponenten teilen hin und herspringen und kann überall auf die Variablen zugreifen.
Wenn der Call z.B. vom Skript per Transfer an eine Warteschleife abgeworfen wird und der Call geht dann zurück weil keiner abgenommen hat oder die Wartezeit zu lange Startet das Skript wieder im Main Tab?

Das verstehe ich nicht. Willst du diese beiden CFA aus deinem Beispiel von oben zu einer CFA zusammenfassen?

Die 3CX selber schafft 'alles'. Es gibt doch so einige Anlagen die parallel > 1000 Anrufe verarbeiten, vorausgesetzt die Hardware hat die entspr. Auslegung - je nachdem was gefordert ist: CPU Leistung (mehr single Core Leistung ist immer besser an Stelle vieler langsamer Cores), RAM Größe (das ist sehr relativ, i.d.R. wird weniger gebraucht als man denkt, das kann man ja beobachten wie der voll läuft in der Spitze), Disk IO (wesentlicher Faktor für sehr vieles einer 3CX, wird von vielen sträflich vernachlässigt).
https://www.3cx.com/docs/recommended-hardware-specifications-for-3cx/

Das geht ja alles noch.

Der Disconnect Handler Flow wird nur dann abgearbeitet:

1. wenn der Anruf während der Abarbeitung der CFA vom Anrufer beendet wurde
2. kein Fehler im Skript aufgetreten ist (dann wird der Error Handler Flow abgearbeitet)
3. wenn der Anruf an eine andere 3CX Entität regulär übergeben wurde
4. wenn der Main Flow abgearbeitet ist
5. wenn der Baustein Exit Callflow im Programmablauf nicht benutzt wird, siehe
   https://www.3cx.com/docs/manual/cfd-conditions-variables/#h.bhcv2k7t5t3d

Beim Disconnect wird da der Disconnect Tab aus der Komponenten oder aus dem Main Skript ausgeführt?

 

[fxbastler]

Ich dachte das CFA ist das Ergebnis aus dem, was man mit dem CFD baut.

Genau das habe ich doch beschrieben

Wenn ich das Richtig verstanden habe, definiere ich im Main Skript die Variablen auf Projektebene. Und dann kann ich beliebig zwischen den Komponenten teilen hin und herspringen und kann überall auf die Variablen zugreifen.

richtig

Wenn der Call z.B. vom Skript per Transfer an eine Warteschleife abgeworfen wird und der Call geht dann zurück weil keiner abgenommen hat oder die Wartezeit zu lange Startet das Skript wieder im Main Tab?

nein
Die WS nimmt den Anruf an, daher beendet sich die CFA.
Wenn der Anruf später nach der WS als Überlauf wieder auf dieselbe CFA kommt, dann startet die von vorn.

Beim Disconnect wird da der Disconnect Tab aus der Komponenten oder aus dem Main Skript ausgeführt?

Eine einfache Frage, keine einfache Antwort.

Siehe oben: der Disconnect Handler Flow des Main Flow wird immer ausgeführt, außer es gab einen Fehler oder die CFA wurde mit Exit Callflow beendet.

Der Disconnect Handler Flow einer UDC (User Defined Component) wird nur dann ausgeführt, wenn diese UDC Audio handhabt und dann der Anruf während des Ablaufes der UDC beendet wird oder das Gespräch in der UDC übergeben wird (Transfer oder erfolgr. MakeCall) oder die UDC den Programmablauf beendet ohne Zuhilfenahme des CFD Bausteins Exit Callflow und ohne selber einen Fehler zu haben. Aber eben: nur wenn Audio an den Anruf in der UDC kommt.

Wenn die UDC nur rechnet oder etwas ändert oder sonstwas, dann wird i.d.R. die gesamte UDC ausgeführt auch wenn der Anruf vom Anrufer schon beendet wurde. Es wird auch kein Disconnect Handler Flow der UDC ausgeführt sondern nach dem Ende der UDC gibt es den Rücksprung zum aufrufenden CFA Kontext (Main Flow oder eine andere UDC). Wenn auch dort kein Audio verarbeitet wird (beim aufrufenden CFA Kontext), dann wird auch dieser Flow nach dem Rücksprung komplett ausgeführt auch wenn der Anruf schon beendet ist.

Ein Beispiel:
Wenn die CFA einen Main Flow und zehn UDC hat und im gesamten Ablauf kein Audio angefasst wird, dann ist es völlig egal wann der Anrufer auflegt: der Main Flow und alle UDC werden komplett abgearbeitet und ganz am Ende gibt es nur den Disconnect Handler Flow des Main Flow (außer es gab einen Fehler oder die CFA wurde mit Exit Callflow beendet).

Das ist der Stand jetzt mit der 3CX v20 und das war bei der v18 auch schon so. Ich kann mich nicht mehr erinnern wie das bei der v16 war, da gab es irgendwann Änderungen diesbezüglich. Ich weiß auch nicht, ob diese Art der Abarbeitung so bleibt. Außerdem: es gibt noch keinen finalen CFD v20. Es kann auch sein, dass dieser noch etwas daran ändert weil das Verhalten leicht eigenartig ist.

Nachtrag:
Das akt. Verhalten mit und ohne Audio was wie läuft, wie lange läuft und was nicht müsste ich sonst mal als Tabelle hier einstellen. Das erklärt es vielleich besser. Ich hatte da früher auch Probleme beim Verständnis.