Skip to main content
Lorsqu’un gestionnaire CloudScript est lancé à partir d’une action PlayStream, ce gestionnaire a accès à davantage de données sur la raison de son exécution (le contexte), que vous pouvez utiliser pour piloter votre logique côté serveur. Ce didacticiel vous présente tout ce qui est disponible dans le contexte et comment l’utiliser dans vos gestionnaires CloudScript.

Notions de base de CloudScript

Pour tirer le meilleur parti de CloudScript, il est essentiel de savoir comment utiliser les entrées dont vous disposez, à savoir les arguments (args) et le contexte de votre gestionnaire. Par exemple, voici l’exemple helloWorld du CloudScript de démarrage, chargé en tant que révision 1 dans tous les titres nouvellement créés (également disponible sur notre GitHub, illustré ci-dessous).
Cet exemple illustre le cas d’utilisation courant de l’appel de CloudScript depuis un client, via ExecuteCloudScript. Il recherche un argument transmis avec la clé inputValue et utilise la valeur de cette clé dans le texte renvoyé dans les informations du journal de débogage de l’exécution.

Le paramètre d’entrée context

Cependant, il est également possible d’appeler un CloudScript à la suite d’un événement dans PlayStream, via une règle (Automation->Rules), une action d’entrée/sortie de segment (Players->Segments) ou le service de tâches (Automation->Tasks). Dans ce cas, le contexte transmis à la fonction fournit toutes les informations dont vous aurez besoin pour effectuer l’action appropriée. Pour découvrir les bases du fonctionnement des événements PlayStream, consultez notre article de blog Introducing PlayStream, et pour obtenir la liste des types d’événements PlayStream et de leurs propriétés, consultez notre référence de l’API PlayFab. Pour voir cette action, examinez le gestionnaire handlePlayStreamEventAndProfile du même exemple de CloudScript.
Dans le cas d’un appel CloudScript déclenché par PlayStream, le contexte contient 3 éléments qui peuvent être utilisés pour piloter la logique de votre gestionnaire faisant autorité côté serveur.
  1. Il y a d’abord playStreamEvent, que vous pouvez voir dans l’exemple de code ci-dessus. playStreamEvent contient l’événement complet qui a déclenché le gestionnaire sous forme d’objet JSON, avec tous les paramètres décrits dans la documentation des événements PlayStream. Ainsi, par exemple, si vous configurez dans votre titre une règle qui appelle handlePlayStreamEventAndProfile sur tout player_logged_in event, playStreamEvent.EventName vaudra player_logged_in, etc. (voici l’ensemble complet des paramètres de cet événement).
  2. Ensuite, il y a playerProfile, également illustré dans l’exemple précédent. Il contient des informations sur le joueur qui a déclenché l’événement. Vous trouverez ici tous les détails des paramètres du profil, mais il contient notamment l’ensemble complet des statistiques du joueur dans votre titre, ainsi que toutes les balises personnalisées que vous avez attribuées au joueur, afin que vous puissiez utiliser ces données pour une prise de décision avancée.
  3. Le dernier élément du contexte est triggeredByTask. Contrairement aux deux premiers, qui sont définis lors de l’utilisation des règles et des déclencheurs d’entrée/sortie de segment, triggeredByTask ne s’applique que lorsque le gestionnaire s’exécute à la suite d’une tâche, qu’elle soit manuelle ou planifiée. Il ne contient que deux paramètres :
  • Name : nom unique que vous avez donné à votre tâche lors de sa création.
  • ID : identificateur unique généré automatiquement par PlayFab pour votre tâche.
Pour une tâche exécutée sur un segment d’utilisateurs, vous disposerez également de playerProfile, mais pas de playStreamEvent. Et pour une tâche simplement exécutée sur votre jeu, mais sans segment, il n’y aura pas de playerProfile, car l’objectif est d’exécuter quelque chose de plus général, comme définir des données de titre pour un événement. C’est donc l’élément name que vous utiliserez dans le flux de code de votre gestionnaire pour déterminer l’action appropriée à effectuer.

PlayStream et CloudScript

À bien des égards, les gestionnaires CloudScript déclenchés par des actions PlayStream offrent encore plus de possibilités que ceux déclenchés directement par des appels à ExecuteCloudScript, car un riche ensemble de données est mis à disposition via le contexte. Cela vous permet de mettre à jour vos gestionnaires après le lancement avec davantage de logique exploitant des éléments de l’événement ou du profil du joueur que vous n’aviez pas prévus à l’origine, sans avoir besoin de mettre à jour votre code client de quelque manière que ce soit. En outre, nous continuerons à enrichir le profil du joueur dans les futures mises à jour du service PlayFab, ce qui offrira encore plus d’options pour la logique côté serveur.
Last modified on October 6, 2026