Seule Session traitements

A partir de Composer 8.1.300.78, Composer prend en charge les traitements d'un seul session ORS orientées GVP. Lorsque vous utilisez les blocs exécuter l'Application, lire sons (musique et gestion des ressources audio Types) quitter et déconnecter, applications vocales maintenant peuvent vous pouvez également utiliser une seule session VXML sur {{{term}}}[[Category:G_{{{term}}}]] pour lire/exécuter les traitements multiples au lieu d'utiliser une session par le traitement. Ceci permet de DTMF tampon entre les traitements multiples MSML.

Une nouvelle Page statique de VXML principal est utilisée pour la lecture des traitements dans une session GVP : (e.g., ComposerPlayTreatments.vxml). URL de traitement pour émettre peut être fichier vxml a généré un schéma de Composer, MCP élaboré dans les traitements ou tiers secondaire URL de la boîte de dialogue. Le ORSSessionID seront fournis comme initiales paramètres lecture de l'Application d'entrée ; successifs HTTP demande pouvant s'écouler des paramètres d'entrée de traitement. Résultats de l'exécution de traitement, ainsi que les résultats retour seront passés en remontant jusqu'à la session ORS. La boîte de dialogue Options d'Orchestration est utilisée pour cette fonctionnalité.

Modifications de bloc de flux de travail

• Flux de travail principale -> quitter le bloc de déconnexion : Génère du code pour mettre fin à la session GVP si active fonction KeepGVPSessionAlive et isGVPSessionActive indicateurs.
• Exécuter l'Application / lecture sons (musique) -> changement dans le code pour simuler des traitements.

IPD diagramme modifications

• Nouveaux gestionnaires de d'événement ont été ajoutés au traitement de communication entre la page sur les principal GVP et l'application SCXML.

1. composer.Dialog.Play -demande bloc exécuter l'Application au schéma IPD pour la demande de traitement une fois la page principale VXMl action.
2. composer.Dialog.Start.Done -Maste vxml demande de la page à la session ORS pour traitement terminé.
3. Error.composer.Dialog.Start -demande de page principale vxml à la session ORS pour erreur de traitement.
4. composer.Dialog.Exit -demande de bloc de sortie/déconnexion au schéma IPD pour quitter la session GVP.
5. composer.Workflow.proceed -schéma IPD à événement bloc exécuter l'Application continuer ultérieur (Comparez dialog.start.done ou dialog.start.requestid).
6. composer.Workflow.Exit -événement IPD schéma de réponse composer.dialog.exit demande de l'événement de bloc de sortie ou déconnecter continuer quitter (session après GVP existe réponse "cet événement" est lancée).

Exécuter l'Application passage de paramètre

Dans le modèle de traitements ORS traditionnel, paramètre de traitement d'application lire transmission se produit par le biais de données de l'utilisateur. qui a été envoyé avec la requête de traitement à GVP. Dans le modèle de session GVP unique, la disponibilité des données utilisateur sera qu'une limitation en tant que les requêtes de traitement successifs se produit par le biais d'événements. Toutefois, il n'y a aucune modification aux paramètres d'entrée/sortie définition mécanisme dans le bloc d'exécuter l'Application. Cela signifie que les paramètres de l'entrée/sortie d'Application lire blocs sont transmises à la VXML principal par le biais d'événements et puis propagées à chaque subdialog dans system_treatment_params json objet.

Pour recevoir des paramètres d'entrée :

• Dans secondaire-callflows, au lieu d'utiliser des blocs InteractionData d'accéder aux données util., utilisez les propriétés de l'objet system_treatment_params. Première <form> dans le rubriques de callflow doit porter les lignes suivantes afin de recevoir les paramètres d'entrée et la langue de traitement :

Remarque : Même si le bloc d'exécuter l'Application n'est pas envoyer ou recevoir des paramètres, ce qui précède <var> balises doivent être ajoutés à la Callflows de rubriques, car le VXML principal envoie toujours ces paramètres.

Pour revenir paramètres de sortie à blocs d'exécuter l'Application : Aucune modification ici ; variables définies dans le bloc de sortie retourner pour le bloc d'exécuter l'Application (si d'attente pour traitement fin est définie sur vrai).

Page de flux VXML principal :

GVP attente et les délais d'attente de Session :

L'application VXML GVP Master peut attendre pour recevoir la requête suivante de traitement de la session ORS. Le délai d'attente GVP avant de demander ORS est désormais contrôlé du côté ORS au lieu du côté GVP en raison de l'invite sans tenir compte des files d'attente. Voici des options disponibles pour contrôler GVP délai d'attente entre les traitements et le délai d'attente de session GVP :

1. gvp_Wait_Treatment_Timeout variable dans le fichier de diagramme IPD sera utilisé pour retard de réponses aux GVP si aucun traitement n'est prêt à être exécuté. La valeur par défaut de cette variable est 1 s et ceci peut être configuré dans l'objet ERS -> section params de l'Application dans Configuration Manager. Si la configuration de la nouvelle valeur prendre effet.
2. Option d'orchestration -> page de propriétés -> nombre d'attente de traitement demande GVP que doit respecter pour terminer la session. Lorsqu'il n'y a pas de traitement pour émettre pendant un certain temps, cette option est utilisée pour contrôler le délai d'attente de session GVP.
3. Total délai d'attente de session GVP = Nombre de requêtes d'attente * gvp_Wait_Treatment_Timeout. Par exemple, 10 demandes d'attente continu avec 3 secondes de retard fournira les 30 secondes de délai d'attente de Session GVP pour une analyse de cas inactive -> 10 * 3 s = 30 secondes.

Questions fréquemment posées

Comment puis-je exécuter des traitements dans une session GVP distincte lors de ne pas déranger la session principal VXML ?
À l'aide de blocs de l'attribution d'indicateur défini _data.keepGVPSessionAlive à faux avant votre bloc de traitement et la réinitialisation à vrai après votre bloc de traitement.

Que se passe-t-il si la logique ORS ne dispose pas des traitements après le premier traitement d'exécuter l'Application ?
La session principal VXML interroge ORS (IPD diagramme SCXML), en fonction du gvp_Wait_Treatment_Timeout valeur jusqu'à ce qu'il tombe sur le délai de Session GVP maximal (configurable par le biais de propriétés de Composer projet) et termine la session de délai d'attente de Session GVP.

Si le flux de travail veut terminer la session principal VXML au milieu d'un appel ?
Vous devrez le flux d'envoyer la demande de traitement de « quitter » à GVP pour terminer la session.

Comment envoyer et recevoir les paramètres de ce modèle GVP seule Session ?
Transmission des paramètres d'entrée de la session GVP continue à travailler à l'aide de la méthode Udata, sans modification. Paramètres de sortie de réception arrivera par le biais de composer.dialog.start.done événement (composer_treatment_result option).

Que se passe-t-il si le "GVP Keepalive" option n'est pas cochée dans la page de propriétés d'Orchestration Options ?
Génération de code est obligatoire, chaque fois que des modifications apportées dans la page sur les propriétés des Options d'Orchestration. Si le "GVP Keepalive" option n'est pas cochée, la génération de code générera du code de traitements de modèle normales ORS MCP.

Comment mettre fin à la session de traitement VXML principal dans un diagramme de flux de travail ?
Bloc d'État SCXML utilisé pour générer une "quitter" demande à la Session GVP principal.

Si l'URL de traitement est incorrect ou n'est pas disponible ?
Le VXML principal tentera d'exécuter l'URL de traitement comme subdialog et revenir sur les résultats de retour. Si l'URL ne peut pas être exécutée, error.composer.dialog.start revient en comme résultat de l'erreur diagramme IPD.

Comment annuler la boîte de dialogue de traitement VXML principal à l'aide de ORS annuler l'appel ?
Boîte de dialogue de la session principal VXML requestID sera disponible dans la _data.gvpMasterTreatmentRequestID variable de l'application. Pour mettre fin à manuellement la session VXML principale GVP utiliser l'extrait suivant du code dans un bloc SCXML État.

<state id="CancelMasterVXML">
<onentry>
            <script>
                        composerRequestID var = _sessionid+'_'+generateComposerTrtRequestID() ;
            </script>
<if cond="_data.keepGVPSessionAlive==true &&_data.isGVPSessionActive==true">
                        <send event="'composer.dialog.exit'">
                                    <param name="treatment_id" expr="'exit'"/>
                                    <param name="treatment_url" expr="''"/>
                                    <param name="treatment_GVPRequestID" expr="composerRequestID"/>
                                    <param name="treatment_waitForEnd" expr="'true'"/>
                        </send>
                        <else/>
                                    <raise event="'proceedNext'"/>
            </if>
            </onentry>
            <événement transition="composer.Workflow.Exit" cond="_Event.Data.RequestId == composerRequestID"  
            cible="$NextBlock$">
<script>
                        _data.isGVPSessionActive =faux ;
                        _data.keepGVPSessionAlive = faux ;       Facultatif - keepGVPSessionActive défini sur faux 
            de complètement terminer la session GVP unique et d'exécuter des traitements ORS ordinaires partir.                                
</script>
            </transition>
            <transition event="proceedNext" target="$NextBlock$">
            </transition>

Que se passe-t-il si la page sur les URL VXML traitement est un callflow de type principale (ne possède pas les <return> marquer mais plutôt le <exit> balise) ?
Si vous utilisez un schéma de callflow type principale, une page de traitement VXML aurez un <exit> balise, qui sera terminer la session GVP et retourner à ORS. En conséquence, les demandes successifs de traitement démarre une nouvelle page VXML principal. Pour cette raison, secondaire callflows requis pour maintenir une session de page VXML principal.

Lorsqu'un diagramme ORS/flux de travail n'a pas d'un traitement pour exécuter, ce qui sera GVP faire et la fréquence il interroge une session ORS ?
GVP exécutera "attendre" (silence) traitements en attendant la requête suivante de traitement de ORS. GVP interroge ORS basé sur le gvp_Wait_Treatment_Timeout valeur jusqu'à ce que le délai d'attente de session GVP est atteint.