- Accueil
- /
- Article
Trouvez toutes les informations importantes dont vous avez besoin concernant l’API Cisco Webex Meetings, telles que les changements de schéma et autres annonces.
Pour plus d’informations sur l’API XML 39 et l’API XML 11, consultez le Présentation des mises à jour de l’API XML de Cisco Webex Meetings (API XML 39 et versions antérieures).
Pour plus d’informations sur l’API 40 XML, consultez le document Présentation des mises à jour de l’API XML Cisco Webex Meetings (API 40 et versions ultérieures).
Pour les mises à jour d’API XML 11 SP9 et des versions antérieures, rendez-vous sur Cisco DevNet.
Mises à jour de l'API 41.12.0
Mises à jour XML API 41.12.0
XMLAPI bloquera la programmation et la modification de Webex Events (classique) en fonction de l’élément de configuration du site de EnableClassicEvent
qui est faux
Modifications des API et du schéma concernées
Dans la page de configuration de l'administration du site, si la case à cocher Activer l'événement classique est fausse, ce site ne prendra plus en charge les réunions Webex Events (classiques).
Si la case à cocher Activer classicEvent est fausse, vous appelez ces API pour faire fonctionner la réunion Webex Events (classique) :
CreateEvent
, SetEvent
, GetEvent
, GetSessionInfo
, LstsummaryEvent
, LstrecordedEvent
, LstsummaryProgram
, UploadEventImage
L'API répondra à une nouvelle exception 010106L'événement classique a été désactivé.
Modifications du schéma
Aucun changement de schéma.
Exemple de requête et de réponse API
Créer un événement Demande et réponse de l’API
Demande de CreateEvent
<bodyContent xsi:type="java:com.webex.service.binding.event.CreateEvent">
<accessControl>
<sessionPassword>XXXXXXXX</sessionPassword>
</accessControl>
<metaData>
<sessionName>Test XMLAPI EC</sessionName>
</metaData>
<schedule>
<startDate>17/07/2021 01:29:15</startDate>
<openTime>15</openTime>
</schedule>
</bodyContent>
Réponse de CreateEvent
<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:header>
<serv:response>
<serv:result>ÉCHEC</serv:result>
<serv:reason>L'événement classique a été désactivé.</serv:reason>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
<serv:exceptionID>010106</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>
CreateEvent3.1.3 Affecter les API :
SetEvent GetEvent
GetSessionInfo
LstsummaryEvent
LstrecordedEvent
LstsummaryProgram
UploadEventImage
XMLAPI LstMeetingType
sera responsable du nouvel élément de subProductCodePrefix
API concernées
Mettre à jour l'API LstMeetingType
élément de réponse de productionCodePrefix
: PRO, AUO et autres qui sont des préfixes de type réunion Webex.
Après cette nouvelle amélioration, l'API répondra à un nouvel élément de subProdctCodePrefix
:PRO1, PRO2, etc. qui peuvent être personnalisés préfixe du type de rencontre.
Changements de schéma sur l’API : LstMeetingType
Il répondra à un nouvel élément : subProdctCodePrefix
Exemple de requête et de réponse API
LstMeetingType
Demande et réponse API
Demande du LstMeetingType
<bodyContent xsi:type="java:com.webex.service.binding.meetingtype.LstMeetingType">
<meetingTypeID>13810</meetingTypeID>
</bodyContent>
Réponse de LstMeetingType
<serv:body>
<serv:bodyContent xsi:type="mtgtype:lstMeetingTypeResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<mtgtype:matchingRecords>
<serv:total>1</serv:total>
<serv:returned>1</serv:returned>
<serv:startFrom>1</serv:startFrom>
</mtgtype:matchingRecords>
<mtgtype:meetingType>
<mtgtype:productCodePrefix>PRO</mtgtype:productCodePrefix>
<mtgtype:subProductCodePrefix>PRO3</mtgtype:subProductCodePrefix> //Nouvel élément pour le type de réunion personnalisé
<mtgtype:active>ACTIVÉ</mtgtype:active>
<mtgtype:name>Cus_Chat_Fermé</mtgtype:name>
<mtgtype:displayName>Cus_Chat_Fermé</mtgtype:displayName>
Mises à jour de l'API 41.11.0
Mises à jour de l'API XML 41.11.0
L’API XML prend en charge la compatibilité de transfert dans l’API de gestion des utilisateurs pour les sites gérés par Control Hub
Modifications des API et du schéma concernées
Si votre application d'intégration utilise actuellement les API de gestion des utilisateurs Webex XMLAPI : CreateUser
, SetUser
, DelUser
et GetUser
pour provisionner ou gérer les utilisateurs, après que votre site Webex classique ait été converti en site géré par Control Hub, ces API continueront à fonctionner pour la compatibilité de transfert. Il y a quelques changements de comportement comme indiqué ci-dessous :
Lors de l’utilisation de createUser- si le statut de l’utilisateur dans le Control Hub n’est pas « actif », alors le statut de l’utilisateur sur le site ne sera pas actif. Si le statut de l’utilisateur dans Control Hub est actif, alors le statut de l’utilisateur sur le site est également actif, référence : Statut des utilisateurs nouveaux et convertis dans Control Hub.
L'élément mot de passe des API CreateUser et SetUser sera ignoré, nous commençons à envoyer un courrier électronique d'activation aux nouveaux utilisateurs, les utilisateurs peuvent cliquer sur le lien contenu dans le courrier électronique pour activer un nouveau compte et saisir un nouveau mot de passe.
Le actifélémentdel’API CreateUser sera ignoré, le nouvel utilisateur (non vérifié) ne peut pas être activé via ce paramètre en utilisant l’API DéfinirUtilisateur.
La valeur de identifiant webExId élément du bodyContent des APIs CreateUser doit être identique à la messagerie électronique. Si identifiant webExId est différent de e-mail, nous traiterons le identifiant webExId identique au courrier électronique lors du stockage dans WebDB et la valeur sera ignorée.
La valeur de identifiant webExId élément du bodyContent des APIs SetUser doit être l’identité utilisateur de l’adresse email, vous pouvez la modifier en utilisant <e-mail> dans bodyContent.
L'API SetUser prendra en charge la modification de l'adresse électronique de l'utilisateur existant : elle réussit si le compte d’exploitation dans SecurityContext est l’administrateur complet du site Control Hub. Sinon, l'API signale une erreur avec un nouveau code d'erreur et un nouveau message ci-dessous :
030120 Le compte doit être un administrateur de site complet pour changer d'adresse électronique.
L'élément newWebExId dans le bodyContent de l'API SetUser sera ignoré.
L'API SetUser tente de passer à un courrier électronique déjà en cours d'utilisation, l'API passe au-dessous du nouveau code d'erreur et du nouveau message d'erreur :
030118 Le courrier électronique est déjà utilisé dans les sites gérés par Control Hub.
L'API DelUser désactive l'utilisateur du côté de la réunion Webex et la licence de réunion correspondante est supprimée du site Webex. Cet utilisateur désactivé peut être réactivé en utilisant l’API : SetUser (<active>ACTIVATED</active>) tant que l'utilisateur est vérifié auparavant.
Les API CreateUser et SetUser émettent un nouveau code d'erreur et un nouveau message d'erreur comme illustré ci-dessous :
030117, cet utilisateur existe en dehors de votre organisation, il doit donc être réclamé, pour se déplacer dans votre organisation via le processus de réclamation de l'utilisateur. Pour les étapes à suivre pour revendiquer l’utilisateur dans votre organisation, voir Revendiquer des utilisateurs dans votre organisation (Convertir des utilisateurs). Vous devrez vérifier le domaine auquel appartient l’utilisateur avant de le revendiquer.
030119 Le jeton d’accès au CI doit inclure le périmètre webexsquare : administrateur lors du provisionnement de l’utilisateur.
La compatibilité avant est prise en charge uniquement pour une période limitée. Nous vous informerons à l’avance avant que cette compatibilité ne soit supprimée. |
Modifications du schéma
Aucun changement de schéma sur ces API : CreateUser
, SetUser
, DelUser
et GetUser
.
Exemple de requête et de réponse API
Demande et réponse de l'API CreateUser
Demande d'API :
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xmlns:serv="http://www.webex.com/schemas/2002/06/service"
xsi:schemaLocation="http://www.webex.com/schemas/2002/06/servicehttp://www.webex.com/schemas/2002/06/service/service.xsd">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{compte Admin du site}</webExID>
<email>{compte Admin du site}</email>
<sessionTicket>xxxx</sessionTicket> ou <password> ou <webExAccessToken>
ou <accessToken>, lors de l'utilisation de CI « accessToken », il doit inclure la portée webexsquare:admin lors du provisionnement de l'utilisateur
</accessToken></webExAccessToken></password></securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.CreateUser">
<webExId>Jack@qa.webex.com</webExId> --- il doit s’agir de l’identité de l’utilisateur de l’adresse électronique
<email>Jack@qa.webex.com</email>
<firstName>Cric</firstName>
<lastName>Smith</lastName>
<password>...</password>
<privilege>
<host>vrai</host>
</privilege>
<active>ACTIVÉ</active> ---ce paramètre ne peut pas activer l'utilisateur directement jusqu'à ce que l'utilisateur s'active lui-même via un courrier électronique d'activation.
</bodyContent>
</body>
Exemple de réponse API :
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:use="http://www.webex.com/schemas/2002/06/service/user">
<serv:header>
<serv:response>
<serv:result>SUCCÈS</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="use:createUserResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<use:userId>23778617</use:userId>
</serv:bodyContent>
</serv:body>
</serv:message>
Affecter les API :
Créer un utilisateur
Définir l’utilisateur
SupprUtilisateur
L’API XML prend en charge la compatibilité de transfert d’authentification des utilisateurs existants après la conversion du site Webex classique en site géré par Control Hub
API concernées
Une fois le site Webex classique converti en site géré par Control Hub, la valeur de l’élément <webExID> dans <securityContext> doit être identique à celle de l’e-mail, détails ci-dessous :
Pour les utilisateurs existants créés sur le site Webex classique, nous prenons en charge les deux anciens webExID (Par exemple : Jack) et le nouveau webExID (le contenu est identique au courrier électronique, exemple : Jack@xx.com) pour se connecter, cette authentification rétrocompatibilité est pour toutes les API XML.
Pour les nouveaux utilisateurs créés dans les sites gérés par le Control Hub, la valeur de l’élément webExID doit être identique à celle de l’adresse électronique pour la connexion.
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- les utilisateurs existants ont été créés sur le site classique webEx, il peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com
<sessionTicket>xxxx</sessionTicket> ou <password> ou <webExAccessToken> ou <accessToken>
</accessToken></webExAccessToken></password></securityContext>
</header>
Affecter les API :
Toutes les API XML.
Après la conversion du site Webex classique en un site géré par Control Hub, la valeur de l’<webExID> élément <bodyContent> doit être identique à celle de l’e-mail, détails ci-dessous :
Pour les utilisateurs existants créés sur le site Webex classique, nous prenons en charge les deux anciens identifiant webExId(ex : Jack) et neuf webExId(le contenu est identique au courrier électronique, par exemple : Jack@xx.com) dans bodyContent.
Pour les nouveaux utilisateurs créés dans les sites gérés par Control Hub, la valeur de identifiant webExId L’élément doit être identique à l’e-mail dans
bodyContent
.
<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- utilisateurs existants ont été créés sur le site webEx classique, il peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com
</bodyContent>
Affecter les API :GetUser
, SetUser
et DelUser
.
Modifications du schéma
Aucun changement de schéma sur les API.
Exemple de requête et de réponse API
Demande et réponse API GetUser
Demande d'API :
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xmlns:serv="http://www.webex.com/schemas/2002/06/service"
xsi:schemaLocation="http://www.webex.com/schemas/2002/06/servicehttp://www.webex.com/schemas/2002/06/service/service.xsd">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- les utilisateurs existants ont été créés sur le site classique webEx, cela peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com
<sessionTicket>xxxx</sessionTicket> ou <password> ou <webExAccessToken> ou <accessToken>
</accessToken></webExAccessToken></password></securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- les utilisateurs existants ont été créés sur le site webEx classique, il peut être : jack ou jack@xx.com ; le nouvel utilisateur doit utiliser jack@xx.com
</bodyContent>
</body>
Exemple de réponse de l'API :
...comme avant
Amélioration de l’API de rapport de l’historique des affichages des enregistrements pour prendre en charge dans Webex Meetings, Webex Events (Nouveau) et Webex Events (Classique)
API concernées
API actuelle : lstrecordaccessHistory
et lstrecordaccessDetailHistory
ne prend en charge que le rapport de l’historique des accès à l’affichage des enregistrements Webex Trainings. La nouvelle amélioration prend également en charge Webex Meetings, Webex Events (nouveau) et Webex Events (classique) l’historique des accès à l’affichage des enregistrements.
Modifications du schéma
Nous prenons en charge le nouveau schéma ci-dessous dans l'API lstrecordaccessHistory dans le corps de la requête de l'API :
<serviceTypes>
<serviceType>MeetingCenter</serviceType>
<serviceType>TrainingCenter</serviceType>
<serviceType>EventCenter</serviceType>
</serviceTypes>
Détails
L’API : lstrecordaccessHistory
est en mesure de restituer l’historique des accès à l’affichage des enregistrements pour Webex Meetings, Webex Events (nouveau), Webex Events (classique) et Webex Trainings.
S’il n’y a pas Type de service spécifié dans la requête de l'API, l'API de
lstrecordaccessHistory
renvoie uniquement l’historique des accès à l’affichage des enregistrements de Webex Trainings.Lorsque le serviceType est MeetingCenter, l'API de
lstrecordaccessHistory
renvoie à la fois l’historique des accès aux vues des enregistrements Webex Meetings et Webex Events (nouveau).Lorsque le Type de service est EventCenter, l'API de
lstrecordaccessHistory
retourne l’historique des accès à l’affichage de l’enregistrement Webex Events (classique).
L’API : lstrecordaccessDetailHistory
est en mesure de renvoyer les détails en recordID
de Webex Meetings, Webex Events (nouveau), Webex Events (classique) et Webex Trainings.
Exemple de requête et de réponse API
lstrecordaccessHistory
Demande et réponse de l’API
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<header>
<securityContext>
<webExID>{userName}</webExID>
<password>{password}</password>
<siteName>{siteName}</siteName>
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.history.LstrecordaccessHistory">
<viewTimeScope>
<viewTimeStart>20/09/2021 00:00:00</viewTimeStart>
<viewTimeEnd>28/09/2021 23:59:59</viewTimeEnd>
</viewTimeScope>
<listControl>
<startFrom>1</startFrom>
<maximumNum>100</maximumNum>
</listControl>
<order>
<orderBy>RECORDID</orderBy>
<orderAD>ASC</orderAD>
</order>
<serviceTypes>
<serviceType>Centre de réunions</serviceType>
<serviceType>Centre de formation</serviceType>
<serviceType>Centre d'événements</serviceType>
</serviceTypes>
</bodyContent>
</body>
</serv:message>
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:history="http://www.webex.com/schemas/2002/06/service/history">
<serv:header>
<serv:response>
<serv:result>RÉUSSITE</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="history:lstrecordaccessHistoryResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test TC-20210924 1324-1</history:recordName>
<history:creationTime>24/09/2021 13:28:13</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>2</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>TestErollment_001-20210610 1905-1</history:recordName>
<history:creationTime>06/10/2021 19:10:15</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:viewed>3</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>Tester la lecture instantanée 2-20210705 0709-1</history:recordName>
<history:creationTime>Le 07/05/2021 07:15:06</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>EC2.0_232423-20210922 0447-1</history:recordName>
<history:creationTime>22/09/2021 04:53:05</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test EC2.0-20210924 1315-1</history:recordName>
<history:creationTime>24/09/2021 13:19:00</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>1</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test MC-20210924 1319-1</history:recordName>
<history:creationTime>24/09/2021 13:25:12</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>1</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test EC classic-20210924 1331-1</history:recordName>
<history:creationTime>24/09/2021 13:37:28</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>1</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:matchingRecords>
<serv:total>8</serv:total>
<serv:returned>7</serv:returned>
<serv:startFrom>1</serv:startFrom>
</history:matchingRecords>
</serv:bodyContent>
</serv:body>
</serv:message>
lstrecordaccessDetailHistory
Demande et réponse de l’API
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xmlns:serv="http://www.webex.com/schemas/2002/06/service">
<header>
<securityContext>
<webExID>{userName}</webExID>
<password>{password}</password>
<siteName>{siteName}</siteName>
</securityContext>
</header>
<body>
<bodyContent xsi:type="">
"java:com.webex.service.binding.history.LstrecordaccessDetailHistory">
<recondID>1XXXXXX7</recondID>
<timeZoneID>20</timeZoneID>
</body>
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:history="http://www.webex.com/schemas/2002/06/service/history">
<serv:header>
<serv:response>
<serv:result>RÉUSSITE</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="history:lstrecordaccessDetailHistoryResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<history:recordDetail>
<history:viewID>1XXXXXX7</history:viewID>
<history:participantName>Axxxg</history:participantName>
<history:participantEmail>Axxxg@qa.webex.com</history:participantEmail>
<history:accessTime>24/09/2021 13:27:26</history:accessTime>
<history:registered>faux</history:registered>
<history:downloaded>faux</history:downloaded>
<history:viewed>vrai</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordDetail>
<history:recordDetail>
<history:viewID>1XXXXXX7</history:viewID>
<history:participantName>Axxxg</history:participantName>
<history:participantEmail>Axxxg@qa.webex.com</history:participantEmail>
<history:accessTime>24/09/2021 13:27:39</history:accessTime>
<history:registered>faux</history:registered>
<history:downloaded>vrai</history:downloaded>
<history:viewed>faux</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordDetail>
<history:matchingRecords>
<serv:total>2</serv:total>
<serv:returned>2</serv:returned>
<serv:startFrom>1</serv:startFrom>
</history:matchingRecords>
</serv:bodyContent>
</serv:body>
</serv:message>
Affecter les API :
lstrecordaccessHistory
lstrecordaccessDetailHistory
Corrigez l’écart de la longueur maximale autorisée de la description de Webex Events (classique) entre XMLAPI et la page Webex.
API concernées
L' API XML : Élément CreateEvent et SetEvent de description autorisera les entrées de maximum 10 000 caractères, si la saisie est trop importante, elle entraînera le nouveau code d'erreur et le nouveau message :
060068 Description de saisie illégale. Cette description ne peut pas dépasser 10 000 caractères.
Modifications du schéma
Aucun changement de schéma.
Exemple de requête et de réponse API
Demande et réponse de l'API CreateEvent
#Exemple de demande d'API :
...
<body>
<bodyContent xsi:type="java:com.webex.service.binding.event.CreateEvent">
xmlns:att="http://www.webex.com/schemas/2002/06/service/event" xsi:schemaLocation="http://www.webex.com/schemas/2002/06/service/eventhttp://www.webex.com/schemas/2002/06/service/event/event.xsd">
<accessControl>
<sessionPassword>111111</sessionPassword>
<listing>PRIVÉ</listing>
</accessControl>
<metaData>
<sessionName>Test CE</sessionName>
<description>.......Supposons que vous remplissiez 10000 caractères dans la description.......</description>
</metaData>
...
------------------------------------
#Exemple de réponse API lorsque la description dépasse 10000 caractères :
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:header>
<serv:response>
<serv:result>ÉCHEC</serv:result>
<serv:reason>Description de saisie illégale. La description ne peut pas dépasser 10000 caractères</serv:reason>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
<serv:exceptionID>060068</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>
Affecter les API :
CreateEvent
SetEvent
API XML : GetUser retourne un nouvel élément de freeAccount
API concernées
GetUser
retourne un nouvel élément qui identifie freeAccount
le compte utilisateur est FreeAccount
ou pas.
Modifications du schéma
Exemple de réponse GetUser
Réponse de GetUser :
<use:initials>AW</use:initials>
<use:isUploaded>false</use:isUploaded>
<use:largeEventCapacity>3</use:largeEventCapacity>
<use:freeAccount>false</use:freeAccount>
Affecter les API :
GetUser
Mises à jour de l'API 41.10.0
Il n'y a aucune modification de schéma au schéma XML API 41.10.0. |
Mises à jour de l'API 41.9.0
Mises à jour de l'API XML 41.9.0
Désactiver l'API XML 10.0.0 pour tous les sites T31
Webex prévoit de mettre fin à la prise en charge de l’API XML version 10.0.0 pour tous les sites T31.
Nous mettons hors service le code XML API 10.0.0 de toutes les productions dans la mise à jour 41.9.0.
Mises à jour de l'API 41.8.0
Mises à jour de l'API XML 41.8.0
Désactiver l'API XML 10.0.0 pour tous les sites T31
Webex prévoit de mettre fin à la prise en charge de l’API XML version 10.0.0 pour tous les sites T31.
Webex a trouvé des clients accédant à l’URL de l’API XML en utilisant une manière incorrecte comme : https://{siteName}.webex.com/WBXService/xml10.0.0/XMLService, la bonne façon d'accéder à l'URL de l'API XML en tant que : https://{siteName}.webex.com/WBXService/XMLService.
Veuillez changer votre API XML d'accès au code en utilisant la bonne manière pour éviter tout impact avant que nous ne mettions fin à la prise en charge de l'API XML version 10.0.0.
Mises à jour de l'API 41.7.0
Mises à jour de l'API XML 41.7.0
La suppression et la modification de l'enregistrement mobile doivent être contrôlées par l'option d'administration du site : Autoriser les coorganisateurs à réattribuer, modifier, désactiver et supprimer les enregistrements
Modifications des API et du schéma concernées
GetSite
: renverra de nouveaux éléments nommant enableNBRMCModify
et separateNoRecordingEdit
sous les outils.
Exemple de réponse
GetSiteResponse
:
GetSite
<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:ns1="http://www.webex.com/schemas/2002/06/service/site" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:header>
<serv:response>
<serv:result>SUCCÈS</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="ns1:getSiteResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
<ns1:tools>
...
<ns1:enableNBRMCModify>false</ns1:enableNBRMCModify>
<ns1:separateNoRecordingEdit>true</ns1:separateNoRecordingEdit>
...
</ns1:tools>
</serv:bodyContent>
</serv:body>
</serv:message>
Mises à jour de l'API 41.6.3
Mises à jour de l'API XML 41.6.3
GetSite
Réponse nouvel élément de supportLargeEvent
Modifications des API et du schéma concernées
Obtenir le site : renvoie de nouveaux éléments nommant supportLargeEvent
sous siteCommonOptions
pour indiquer à l’appelant si le site prend en charge Grand événement (Webex Event (nouveau)) ou non.
Changement de schéma
Exemple de réponse
GetSiteResponse
:
GetSite
<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:ns1="http://www.webex.com/schemas/2002/06/service/site" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:header>
<serv:response>
<serv:result>SUCCÈS</serv:result>
<serv:gsbStatus>PRIMAIRE</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="ns1:getSiteResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
<ns1:siteCommonOptions>
...
<ns1:enablePreMeetingLobby>false</ns1:enablePreMeetingLobby>
<ns1:supportLargeEvent>true</ns1:supportLargeEvent>
</ns1:siteCommonOptions>
</serv:bodyContent>
</serv:body>
</serv:message>
Mises à jour de l'API 41.6.0
Mises à jour de l'API XML 41.6.0
XMLAPI prend en charge Webex Events 2.0 dans le provisionnement
API concernées
GetUser
: retourne un nouveau nom d'élément largeEventCapacity
qui indique la capacité du nouvel événement 2.0 (EC 2.0) sous ce compte utilisateur. Par exemple, si le compte utilisateur a une licence CI_EC3K, la valeur de largeEventCapacity
c'est 3000.
Modifications du schéma
Exemple de réponse
ObtenirRéponseUtilisateur :
L'heure de création de l'enregistrement XMLAPI LstRecording applique l'heure de démarrage de l'enregistrement
API concernées
LstRecording
: LstRecording
réponse CreateTime
comme l'heure à laquelle l'utilisateur appuie réellement sur le bouton d'enregistrement.
Détails
Dans le passé, l'API XML utilisait l'horodatage de la création de l'enregistrement dans la base de données comme heure de création dans LstRecording
réponse. C'est maintenant l'heure à laquelle l'utilisateur commence réellement à enregistrer. Ce changement s’applique à tous les enregistrements de service. Il n’y a pas de changement de schéma.
Mises à jour de l'API 41.5.0
Mises à jour XML API 41.5.0
XMLAPI a la possibilité de démarrer des réunions programmées Webex à partir du RTCP en tant qu’organisateur
API concernées
CreateUser
: génèrehostPIN
que la salle de réunion personnelle (PMR) de l'utilisateur soit activée ou non lorsque le rôle de l'utilisateur est l'organisateur ou les administrateurs de site complets ou en lecture seule ou de gestion des utilisateurs.SetUser
: ensembleshostPIN
utilisationphones.hostPIN
lorsquepersonalMeetingRoom.hostPIN
n'est pas dans la requête XML (pré-condition : bascule de fonctionnalitéAllowStartScheduledMtgFromPhone
est activé).GetUser
: retoursphones.hostPIN
que la salle de réunion personnelle (PMR) de l’utilisateur soit activée ou non. (condition préalable : bascule de fonctionnalitéAllowStartScheduledMtgFromPhone
est activé).
Modifications du schéma
GetUserResponse
:
SetUser
:
Exemple de réponse
GetUserResponse
:
SetUser
:
XMLAPI GetSite
réponse deux nouveaux éléments pour le client mobile
API concernées
GetSite
:GetSite
va maintenant répondre à deux nouveaux éléments pour prendre en charge le client mobile a la logique d'afficher ou non l'onglet d'enregistrement.enableRecordingAccess
: vrai ou faux, les super administrateurs Webex peuvent activer ou désactiver l’accès à l’enregistrement à l’aide de la fonction bascule(EnableRecordingAccesses
).storageEmptyStatus
: vrai ou faux, si les deux sites ne prennent pas en charge la fonction NBR et ont attribué l'espace de stockage NBR à zéro, alors la réponse du statut est vrai, sinon est faux.
Modifications du schéma
Demande d’échantillon pour GetSite
Exemple de réponse pour Getsite
L’objet du courrier électronique contenant des caractères non ASCII sera encodé avec RFC2047. Dans le cas d’un objet de courrier électronique à caractère ASCII pur, il n’y a pas d’encodage
API concernéesIl n’y a aucun impact sur les demandes d’API, la charge utile des réponses, mais cela modifie le comportement d’encodage de l’objet du courrier électronique. Lorsque l'objet du courrier électronique contenant des caractères non ASCII sera encodé avec RFC2047. Dans le cas d’un objet de courrier électronique purement ASCII, il n’y a pas d’encodage.
Modifications du schéma
Il n'y a pas de changements de schéma.
Mises à jour de l'API 41.4.0
Mises à jour de l'API XML 41.4.0
Webex Events peut tirer parti de la tonalité par défaut au niveau du site à l’entrée et à la sortie
XMLAPI s’aligne sur la nouvelle logique actuelle de contrôle de la tonalité d’entrée et de sortie. Toutes les tonalités pour Webex Events ont été contrôlées par un paramètre différent dans l’administration du site. Dans GetSite
, XMLAPI renvoie un champ supplémentaire entryExitToneEC
pour indiquer la valeur. À l'origine, lorsque l'administrateur du site définit une tonalité par défaut, la création d'événement n'exploite pas ce paramètre en appliquant la valeur par défaut XMLAPI.
API concernées
L' API XML : GetSite renvoie un nouvel élément entryExitToneEC
pour indiquer la valeur.
L' API XML : La logique métier back-end CreateEvent, SetEvent, GetEvent lit la valeur de entryExitToneEC
.
Modifications du schéma
API XML : Exemple de réponse GetSite :
<ns1:defaults>
<ns1:emailReminders>true</ns1:emailReminders>
<ns1:entryExitTone>ANNOUNCENAME</ns1:entryExitTone>
<ns1:entryExitToneEC>NOTONE</ns1:entryExitToneEC>
<ns1:voip>true</ns1:voip>
<ns1:teleconference>
<ns1:telephonySupport>NONE</ns1:telephonySupport>
</ns1:teleconference>
<ns1:joinTeleconfNotPress1>true</ns1:joinTeleconfNotPress1>
<ns1:updateTSPAccount>false</ns1:updateTSPAccount>
</ns1:defaults>
Affecter les API :
Obtenir le site
CréerEvénement
SetEvent
ObtenirÉvénement
XMLAPI renvoie simplement les informations détaillées de l'événement de grande envergure (Webex Event 2.0)
Si la réunion Webex est le grand événement ou le webcast,
GetSessionInfo
renvoie certaines informations détaillées, y compris le mot de passe de la réunion, le mot de passe numérique de la réunion, le mot de passe du co-animateur et le mot de passe numérique du co-animateur (Aucun schéma ne doit être modifié).XMLAPI ne prend pas en charge la création et la modification d'une fonctionnalité d'événement ou de webcast de grande envergure, donc
CreateMeeting
etSetMeeting
renvoyer une nouvelle exception (110064, L’événement et le type de session webcast ne sont pas pris en charge.) pour le cas d’événement de grande envergure ou de webcast.
API d’impact
Nom de l'API | Description | Remarque |
---|---|---|
| Si la réunion Webex est le grand événement ou le webcast, | Aucun schéma ne doit être modifié. |
| Si l’utilisateur essaie d’utiliser | Le comportement doit être changé. |
Mises à jour de l'API 41.3.0
Mises à jour XML API 41.3.0
Les nouvelles modifications de l’API XML prennent en charge la fonctionnalité Webex Events 2.0
API concernées
Les deux API : Éléments de retour GetSessionInfo et GetMeeting enableEvent
et enableWebniar
aussi.
Nom de l'élément | Description |
---|---|
activer l'événement | Prend en charge EC 2.0 au cours d'une réunion Webex |
activer le webinaire | Prend en charge le webinaire au cours d’une réunion Webex |
La prise en charge XMLAPI renvoie au-dessus de deux éléments pour EC 2.0. La version actuelle de l'API XML ne prend pas en charge la programmation et la configuration de la réunion EC2.0. |
Modifications du schéma
GetSessionInfo
éléments de retour enableEvent
et enableWebniar
pour EC 2.0.
GetMeeting
éléments de retour enableEvent
et enableWebniar
pour EC 2.0.
Échantillon de réponse :
GetSessionInfo
réponse :
<ep:accessControl>
<ep:listStatus>PUBLIC</ep:listStatus>
<ep:registration>false</ep:registration>
<ep:passwordReq>true</ep:passwordReq>
<ep:isEnforceAudioPassword>false</ep:isEnforceAudioPassword>
<ep:isEnforceAudioLogin>false</ep:isEnforceAudioLogin>
<ep:enableEvent>false</ep:enableEvent>
<ep:enableWebniar>false</ep:enableWebniar>
<ep:enablePreMeetingLobby>true</ep:enablePreMeetingLobby>
</ep:accessControl>
GetMeeting
réponse :
<meet:supportPKI>false</meet:supportPKI>
<meet:HQvideo>true</meet:HQvideo>
<meet:HDvideo>true</meet:HDvideo>
<meet:viewVideoThumbs>true</meet:viewVideoThumbs>
<meet:enableEvent>false</meet:enableEvent>
<meet:enableWebniar>false</meet:enableWebniar>
<meet:enablePreMeetingLobby>true</meet:enablePreMeetingLobby>
Les nouvelles modifications XMLAPI prennent en charge la fonctionnalité de lobby de pré-réunion
API concernées
L' API XML : GetSite
, LstSummarySession
, GetSessionInfo
et GetMeeting
répondra au nouvel élément enablePreMeetingLobby
pour le lobby de pré-réunion.
Modifications du schéma
L' API XML : GetSite
élément de retour enablePreMeetingLobby
pour le lobby de pré-réunion.
L' API XML : LstSummarySession
élément de retour enablePreMeetingLobby
pour le lobby de pré-réunion.
L' API XML : GetSessionInfo
élément de retour enablePreMeetingLobby
pour le lobby de pré-réunion.
L' API XML : GetMeeting
élément de retour enablePreMeetingLobby
pour le lobby de pré-réunion.
Échantillon de réponse :
GetSite
réponse :
<ns1:siteCommonOptions>
<ns1:SupportCustomDialRestriction>false</ns1:SupportCustomDialRestriction>
<ns1:SupportTelePresence>false</ns1:SupportTelePresence>
<ns1:SupportTelePresencePlus>false</ns1:SupportTelePresencePlus>
<ns1:EnableCloudTelepresence>true</ns1:EnableCloudTelepresence>
<ns1:EnableCMRForAllUsers>true</ns1:EnableCMRForAllUsers>
<ns1:enablePersonalMeetingRoom>true</ns1:enablePersonalMeetingRoom>
<ns1:SupportAlternateHost>true</ns1:SupportAlternateHost>
<ns1:SupportXMLAPIReturnScheduledPMR>false</ns1:SupportXMLAPIReturnScheduledPMR>
<ns1:SupportAnyoneHostMeetings>true</ns1:SupportAnyoneHostMeetings>
<ns1:enablePreMeetingLobby>true</ns1:enablePreMeetingLobby>
</ns1:siteCommonOptions>
LstSummarySession
réponse :
<ep:isException>false</ep:isException>
<ep:isNextUpcomingInstance>true</ep:isNextUpcomingInstance>
<ep:seriesMeetingKey>0</ep:seriesMeetingKey>
<ep:isScheduledPMR>false</ep:isScheduledPMR>
<ep:enableEvent>false</ep:enableEvent>
<ep:enableWebniar>false</ep:enableWebniar>
<ep:enablePreMeetingLobby>true</ep:enablePreMeetingLobby>
GetSessionInfo
réponse :
<ep:accessControl>
<ep:listStatus>PUBLIC</ep:listStatus>
<ep:registration>false</ep:registration>
<ep:passwordReq>true</ep:passwordReq>
<ep:isEnforceAudioPassword>false</ep:isEnforceAudioPassword>
<ep:isEnforceAudioLogin>false</ep:isEnforceAudioLogin>
<ep:enableEvent>false</ep:enableEvent>
<ep:enableWebniar>false</ep:enableWebniar>
<ep:enablePreMeetingLobby>true</ep:enablePreMeetingLobby>
</ep:accessControl>
GetMeeting
réponse :
<meet:supportPKI>false</meet:supportPKI>
<meet:HQvideo>true</meet:HQvideo>
<meet:HDvideo>true</meet:HDvideo>
<meet:viewVideoThumbs>true</meet:viewVideoThumbs>
<meet:enableEvent>false</meet:enableEvent>
<meet:enableWebniar>false</meet:enableWebniar>
<meet:enablePreMeetingLobby>true</meet:enablePreMeetingLobby>
L'API XML GetSite
réponse Information changement de comportement divulgué
API concernées
L' API XML : GetSite
seule réponse ci-dessous les éléments pour le compte administrateur, qui incluent les rôles : SiteAdmin
, RO_SiteAdmin
et UserAdmin
.
<ns1:activeUserCount>...</ns1:activeUserCount>
<ns1:EEActiveUserCount>...</ns1:EEActiveUserCount>
<ns1:activeCETHost>...</ns1:activeCETHost>
<ns1:auoActiveUserCount>...</ns1:auoActiveUserCount>
<ns1:MCActiveUserCount>...</ns1:MCActiveUserCount>
<ns1:ECActiveUserCount>...</ns1:ECActiveUserCount>
<ns1:TCActiveUserCount>...</ns1:TCActiveUserCount>
<ns1:SCActiveUserCount>...</ns1:SCActiveUserCount>
Comportement modifié
Autoriser uniquement le rôle d’administrateur à avoir des données de licence de réponse de GetSite
. L’organisateur ou l’invité ne recevra pas ces données de licence dans GetSite
réponse.
Voici les API : GetSite's
exemple de réponse pour siteadmin
ou prêt uniquement siteadmin
ou admin de gestion des utilisateurs :
Mises à jour de l'API 41.2.0
Mises à jour de l'API XML 41.2.0
XMLAPI doit prendre en charge « CMR Hybrid VOIP » si le site prend en charge la téléphonie Webex
API concernées
GetSite
renvoie un nouvel élémentIsWebexTelephony
dans la réponse.CreateUser
etSetUser
peut mettre à jourcmrHybridVoip
élément siIsWebexTelephony
est vrai avec d'autres conditions.IsTSPUsingTelephonyAPI
n’est plus conséquente.
Modifications du schéma
API XML : GetSite
la réponse renvoie un élément supplémentaire IsWebexTelephony
GetSite
la réponse inclut ce nouvel élément :
<ns1:telephonyConfig>
<ns1:isWebexTelephony>true</ns1:isWebexTelephony>
<ns1:isTSPUsingTelephonyAPI>false</ns1:isTSPUsingTelephonyAPI>
<ns1:serviceName>N° conférence personnelle</ns1:serviceName>
<ns1:participantAccessCodeLabel>Code d'accès invité</ns1:participantAccessCodeLabel>
<ns1:subscriberAccessCodeLabel>Code d'accès organisateur</ns1:subscriberAccessCodeLabel>
<ns1:attendeeIDLabel>ID invité</ns1:attendeeIDLabel>
.....
</ns1:telephonyConfig>
LstSummarySession
prend en charge EC2.0
Les API XML seront impactées
LstSummarySession
retournera deux nouveaux éléments pour soutenir EC 2.0
Nom de l'élément | Description |
---|---|
activer l'événement | Prend en charge EC 2.0 au cours d'une réunion Webex |
activer le webinaire | Prend en charge le webinaire au cours d’une réunion Webex |
Modifications du schéma
API XML : LstSummarySession
: Ajouter le < enableEvent
> et < enableWebniar
> éléments
Réponse de l'API XML : LstSummarySession
Réponse pour EC 2.0
<ep:isNextUpcomingInstance>true</ep:isNextUpcomingInstance>
<ep:seriesMeetingKey>0</ep:seriesMeetingKey>
<ep:isScheduledPMR>false</ep:isScheduledPMR>
<ep:enableEvent>true</ep:enableEvent>
<ep:enableWebniar>true</ep:enableWebniar>
XMLAPI prend en charge le retour de l'utilisateur du site Webex-voice-assistant
option d'intégration TCM
APIs affectées
GetUser
renvoie un nouvel élément webexAssistantEnabled
(vrai ou faux) dans la réponse.
Modifications du schéma
getUserResponse
:
Exemple de réponse
Mises à jour de l'API 41.1.0
Il n'y a aucune modification de schéma au schéma XML API 41.1. |