Trouvez toutes les informations importantes dont vous avez besoin sur Cisco Webex Meetings’api de programmation, telles que les changements de schémas et autres annonces.
Pour plus d’informations sur l’API XML 39 et l’API XML 11, voir l’Aperçu des mises à jour de l’API XML Cisco Webex Meetings (API XML 39 et antérieure).
Pour plus d’informations sur l’API XML 40, voir la présentation des mises à jour Cisco Webex Meetings API XML (XML API 40 et version plus ultérieure).
Pour les mises à jour pour l’API XML 11 SP9 et version précédente, allez à Cisco DevNet.
Mises à jour API 41.12.0
Mises à jour de l’API XML 41.12.0
Cliquez ici pour télécharger le schéma de l’API XML 41.12.0.
XMLAPI bloquera la programmation Webex Events (Classique) et l’édition en fonction de l’élément de la config du site EnableClassicEvent
qui est faux
API et changements de schémas impactés
Dans la page de configuration de l’administration du site, si la case Activer l’événement classique est erronée, ce site ne Webex Events plus en charge les réunions (classiques).
Si la case Activer l’événement classique est erronée, vous appelez ces API pour Webex Events réunion (classique) :
CreateEvent
, SetEvent
, GetEvent
, GetSessionInfo
, LstsummaryEvent
, LstrecordedEvent
, LstsummaryProgram
, UploadEventImage
L’API va répondre aux nouvelles exceptions 010106l’événement classique a été désactivé.
Changements de schémas
Aucun changement de schéma.
Exemple de demande et de réponse API
Demande et réponse de l’API Créer un événement
Demande de Créer un événement
<bodyContent xsi:type="java:com.webex.service.binding.event.CreateEvent">
<accessControl>
<sessionPassword>XXXXXXXX</sessionPassword>
</accessControl>
<metaData>
<sessionName>XMLAPI EC Testing</sessionName>
</metaData>
<schedule>
<startDate>07/17/2021 01:29:15</startDate>
<openTime>15</openTime>
</schedule>
</bodyContent>
</body>
</serv:message>
Réponse de Créer un événement
<?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>FAILURE</serv:result>
<serv:reason>The classic Event has been disabled.</serv:reason>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
<serv:exceptionID>010106</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>
CréerEvent3.1.3 Affecter les API :
SetEvent GetEvent
GetSessionInfo
LstsummaryEvent
LstrecordedEvent
LstsummaryProgram
UploadEventImage
XMLAPI LstMeetingType
sera répondu au nouvel élément de subProductCodePrefix
API impactées
Current l’API LstMeetingType
élément de réponse productionCodePrefix
: PRO, AUO et autres qui sont le préfixe prédéfré de type de rencontre Webex.
Après cette nouvelle amélioration, l’API va répondre au nouvel élément de subProdctCodePrefix
:P RO1, PRO2, etc. qui peut être personnalisé préfixe de type meet.
Modifications du schéma sur l’API : LstMeetingType
Il répondra au nouvel élément : subProdctCodePrefix
Exemple de demande et de réponse API
LstMeetingType
Demande API &réponse
Demande de LstMeetingType
<bodyContent xsi:type="java:com.webex.service.binding.meetingtype.LstMeetingType">
<meetingTypeID>13810</meetingTypeID>
</bodyContent>
</body>
</serv:message>
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> //New element for customized meeting
type
<mtgtype:active>ACTIVATED</mtgtype:active>
<mtgtype:name>Cus_Chat_Closed</mtgtype:name>
<mtgtype:displayName>Cus_Chat_Closed</mtgtype:displayName>
Mises à jour API 41.11.0
Mises à jour de l’API XML 41.11.0
Cliquez ici pour télécharger le schéma de l’API XML 41.11.0.
Prise en charge XML API faire suivre la compatibilité dans l’API de gestion des utilisateurs pour les sites gérés par Control Hub
API et changements de schémas impactés
Si votre application d’intégration utilise actuellement des API de gestion des utilisateurs XMLAPI Webex : CreateUser
, SetUser
, DelUser
et GetUser
pour provisioner ou gérer les utilisateurs, après que votre site classique Webex soit converti en site géré par Control Hub, ces API continueront de fonctionner pour faire suivre la compatibilité. Il y a quelques changements de comportement comme indiqué ci-dessous :
Lors de l’utilisation de créerUtilisez - si le statut de l’utilisateur dans 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 du mot de passe des API Créer un utilisateur et Configurer un utilisateur sera ignoré, nous commençons à envoyer un courrier électronique d’activation aux nouveaux utilisateurs, les utilisateurs peuvent cliquer sur le lien dans le courrier électronique pour saisir un nouveau compte actif et saisir un nouveau mot de passe.
L’élément actif de l’API Créer un utilisateur sera ignoré, le nouvel utilisateur (pas vérifié) ne peut pas être activé via ce paramètre en utilisant Api SetUser.
La valeur de l’élément webExId dans le corpsContent des API Créerutiliseur doit être identique à l’adresse électronique. Si webExId est différent de la messagerie électronique, nous traiterons l’ID WebEx de la même façon que le courrier électronique lors de son stockage dans WebDB et la valeur sera ignorée.
La valeur de l’élément webExId dans le corpsContent des API SetUser doit être l’identité de l’utilisateur de l’adresse électronique, vous pouvez la changer à l’aide des > électroniques dans lecorpsContent.
L’API Configurer l’utilisateur prendra en charge la modification de l’adresse électronique de l’utilisateur existant : c’est un succès si le compte d’opération dans SécuritéContexte est l’administrateur complet du site de Control Hub. Sinon, l’API signale une erreur avec le nouveau code d’erreur et le nouveau message ci-dessous :
030120 Le compte doit être un administrateur de site complet pour modifier l’adresse électronique.
L’élément nouveauWebExId dans le corpsContent de l’API SetUser sera ignoré.
L’API Configurer l’utilisateur tente de changer en une adresse électronique qui est déjà en cours d’utilisation, l’API place sous le nouveau code d’erreur et le message d’erreur :
030118 électronique est déjà utilisée 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>(ACTIVÉ) tant que</active>l’utilisateur est vérifié avant.
Les API Créerutilneur et Configurer l’utilisseur envoient un nouveau code d’erreur et un message d’erreur comme démontré ci-dessous :
030117 , cet utilisateur existe hors de votre organisation, donc doit être réclamé, pour entrer dans votre organisation par le processus de réclamationde l’utilisateur. Pour les étapes à suivre pour revendiquer l’utilisateur dans votre organisation, voir Demander aux utilisateurs de prendre part à votre organisation (Convertir les utilisateurs). Vous devez vérifier le domaine à quel l’utilisateur appartient avant de réclamer l’utilisateur.
030119 le jeton d’accès CI doit inclure scope webexsquare : admin lors de l’approvisionnement de l’utilisateur.
La compatibilité avec un délai limité est prise en charge uniquement pour une période de temps limitée. Nous fournirons une notification avancée avant la suppression de cette compatibilité. |
Changements de schémas
Aucun changement de schéma sur ces API : CreateUser
, SetUser
, DelUser
et GetUser
.
Exemple de demande et de réponse API
Demande API CréerUtiliseur & Réponse
API request:
<?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/service http://www.webex.com/schemas/2002/06/service/service.xsd">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{site Admin account}</webExID>
<email>{site Admin account}</email>
<sessionTicket>xxxx</sessionTicket> or <password> or <webExAccessToken>
or <accessToken>, when using CI "accessToken", it must include scope webexsquare:admin when provisioning
user
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.CreateUser">
<webExId>Jack@qa.webex.com</webExId> --- it should is user identity of email address
<email>Jack@qa.webex.com</email>
<firstName>Jack</firstName>
<lastName>Smith</lastName>
<password>....</password>
<privilege>
<host>true</host>
</privilege>
<active>ACTIVATED</active> ---this parameter can't active the user directly until the user self activate itself via activation
email.
</bodyContent>
</body>
</serv:message>
API response example:
<?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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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 :
Createuser
Setuser
DelUser (Utiliseur)
L’API XML prend en charge la compatibilité de ascendant d’authentification des utilisateurs existants après la conversion du site classique Webex en site géré par Control Hub
API impactées
Lorsque le site classique de Webex a été converti en site géré par Control Hub, la valeur de l’élément doit être identique à l’adresse <webExID> <securityContext> électronique, détails ci-dessous :
Pour les utilisateurs existants créés dans le site Classique de Webex, nous prenons en charge à la fois les anciens services webExID (Par exemple : Jack) et le nouvel ID WebEx (le contenu est le même que la messagerie électronique, exemple : Jack@xx.com) pour se connecter, cette compatibilité ascendante de l’authentification est pour toutes les API XML.
Pour les nouveaux utilisateurs créés dans les sites gérés par Control Hub, la valeur de l’élément webExID doit être identique à l’adresse électronique pour la connexion.
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com;
new user must use jack@xx.com
<sessionTicket>xxxx</sessionTicket> or <password> or <webExAccessToken> or <accessToken>
</securityContext>
</header>
Affecter les API :
Toutes les API XML.
Après la conversion classique de Webex en un site géré par Control Hub, la valeur du corps de l’élément > doit être identique à l’adresse <webExID> électronique, détails ci-dessous :
Pour les utilisateurs existants créés dans le site Classique de Webex, nous supportons à la fois les anciens utilisateurs de webex(par exemple : Jack) et le nouveau webExId (le contenu est le même que la messagerie électronique, par exemple : Jack@xx.com) dans corpsContent.
Pour les nouveaux utilisateurs créés dans les sites gérés par Control Hub, la valeur de l’élément webExId doit être identique à l’adresse électronique dans
bodyContent
.
<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com; new user
must use jack@xx.com
</bodyContent>
Affecter les API :GetUser
, SetUser
et DelUser
.
Changements de schémas
Aucun changement de schéma sur les API.
Exemple de demande et de réponse API
Obtenir la requête API de l’utilisateur &réponse
API request:
<?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/service http://www.webex.com/schemas/2002/06/service/service.xsd">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com;
new user must use jack@xx.com
<sessionTicket>xxxx</sessionTicket> or <password> or <webExAccessToken> or <accessToken>
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com; new user
must use jack@xx.com
</bodyContent>
</body>
</serv:message>
API response example:
...same as before
Amélioration de l’API du rapport d’affichage de l’enregistrement à prendre en charge dans Webex Meetings, Webex Events (Nouveau) et Webex Events (Classique)
API impactées
API actuelle : lstrecordaccessHistory
et lstrecordaccessDetailHistory
uniquement en charge l’affichage des enregistrements Webex Trainings, rapport de l’historique des accès. La nouvelle amélioration prend en charge l Webex Meetings, Webex Events (nouveau) et l’affichage Webex Events d’enregistrement (classique) accès à l’historique rapport également.
Changements de schémas
Nous ons en charge ci-dessous le nouveau schéma 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
peut renvoyer l’affichage de l’enregistrement de l’historique des Webex Meetings, Webex Events (nouveau), Webex Events (classique) et Webex Trainings.
Si aucun serviceType n’est spécifié dans la requête API, l’API de
lstrecordaccessHistory
renvoie uniquement l’affichage de l’historique des accès aux enregistrements Webex Trainings.Lorsque le serviceType est MeetingCenter, l’API de
lstrecordaccessHistory
renvoie l’affichage Webex Meetings’enregistrement Webex Events’enregistrement (nouveau) dans l’historique d’accès.Lorsque serviceType est EventCenter, l’API de
lstrecordaccessHistory
renvoie l Webex Events d’affichage de l’enregistrement (classique) accéder à l’historique.
L’API : lstrecordaccessDetailHistory
peut renvoyer les détails par recordID
de Webex Meetings, Webex Events (nouveau), Webex Events (classique) et Webex Trainings.
Exemple de demande 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>9/20/2021 00:00:00</viewTimeStart>
<viewTimeEnd>9/28/2021 23:59:59</viewTimeEnd>
</viewTimeScope>
<listControl>
<startFrom>1</startFrom>
<maximumNum>100</maximumNum>
</listControl>
<order>
<orderBy>RECORDID</orderBy>
<orderAD>ASC</orderAD>
</order>
<serviceTypes>
<serviceType>MeetingCenter</serviceType>
<serviceType>TrainingCenter</serviceType>
<serviceType>EventCenter</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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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>09/24/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>Test instant playback 2-20210705 0709-1</history:recordName>
<history:creationTime>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>09/22/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>09/24/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>09/24/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>09/24/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>
</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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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>09/24/2021 13:27:26</history:accessTime>
<history:registered>false</history:registered>
<history:downloaded>false</history:downloaded>
<history:viewed>true</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>09/24/2021 13:27:39</history:accessTime>
<history:registered>false</history:registered>
<history:downloaded>true</history:downloaded>
<history:viewed>false</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 le trou de la longueur maximum de la description Webex Events (Classique) entre XMLAPI et la page Webex.
API impactées
L’API XML : L’élément créer un événement et configurer la description de l’événement permettra des entrées maximales de 1 000 caractères, si la saisie est plus importante que la taille, le nouveau code d’erreur et le nouveau message seront à l’écran :
060068 description de saisie illégale. Cette description ne peut pas dépasser 1 000 caractères.
Changements de schémas
Aucun changement de schéma.
Exemple de demande et de réponse API
Demande et réponse de l’API Créer un événement
#API request example:
...
<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/event
http://www.webex.com/schemas/2002/06/service/event/event.xsd">
<accessControl>
<sessionPassword>111111</sessionPassword>
<listing>PRIVATE</listing>
</accessControl>
<metaData>
<sessionName>EC test</sessionName>
<description>.......Suppose you filling in 10000 characters in description.......</description>
</metaData>
...
------------------------------------
#API response example when the description exceeds 10000 characters:
<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>FAILURE</serv:result>
<serv:reason>Illegal input description. The description can't exceed 10000 characters</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 renvoie un nouvel élément de compte gratuit
API impactées
GetUser
renvoie un nouvel élément qui identifie freeAccount
l’compte utilisateur est FreeAccount
Ou pas.
Changements de schémas
Obtenir l’exemple de réponse De l’utilneur
GetUser response:
<use:initials>AW</use:initials>
<use:isUploaded>false</use:isUploaded>
</use:avatar>
<use:largeEventCapacity>3</use:largeEventCapacity>
<use:freeAccount>false</use:freeAccount>
</serv:bodyContent>
</serv:body>
</serv:message>
Affecter les API :
GetUser
Mises à jour API 41.10.0
Il n’y a aucun changement de schéma au schéma de l’API XML 41.10.0. |
Mises à jour API 41.9.0
Mises à jour de l’API XML 41.9.0
Décommission XML API 10.0.0 pour tous les sites T31
Webex envisage de mettre fin à la prise en charge de l’API XML ver 10.0.0 pour tous les sites T31.
Nous désémissionons le code XML API 10.0.0 de toutes les productions dans la mise à jour 41.9.0.
Mises à jour API 41.8.0
Mises à jour de l’API XML 41.8.0
Décommission XML API 10.0.0 pour tous les sites T31
Webex envisage de mettre fin à la prise en charge de l’API XML ver 10.0.0 pour tous les sites T31.
Webex a trouvé certains clients clients accédant à l’URL de l’API XML de façon 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 code d’accès API XML en utilisant le bon moyen pour éviter tout impact avant que nous ne évitions la prise en charge de L’API XML version 10.0.0.
Mises à jour API 41.7.0
Mises à jour de l’API XML 41.7.0
La suppression et la modification des enregistrements mobiles doivent être contrôlées par l’option d’administration du site : Autoriser les organisateurs à réattribuer, modifier, désactiver et supprimer des enregistrements
API et changements de schémas impactés
GetSite
: va renvoyer les nouveaux éléments d’appellation enableNBRMCModify
et separateNoRecordingEdit
sous 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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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 API 41.6.3
Mises à jour de l’API XML 41.6.3
GetSite
Réponse nouvel élément de supportLargeEvent
API et changements de schémas impactés
Obtenir le site: renvoie les nouveaux éléments d’appellation supportLargeEvent
sous siteCommonOptions
pour que l’appelant sache si le site est en charge pour les grands événements (Webex Event (nouvel)) 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>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</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 API 41.6.0
Mises à jour de l’API XML 41.6.0
La prise en charge de XMLAPI Webex Events 2.0 en approvisionnement
API impactées
GetUser
: renvoie l’appellation d’un nouvel élément largeEventCapacity
qui affiche la capacité du nouvel événement 2.0 (EC 2.0) dans compte utilisateur. Par exemple, si le compte utilisateur a une licence_CI EC3K, la valeur de largeEventCapacity
est 3 000.
Changements de schémas
Exemple de réponse
Obtenir la réponse de l’utilneur :
L’heure de création de l’enregistrement XMLAPI LstRecording applique l’heure de démarrage de l’enregistrement
API impactées
LstRecording
: LstRecording
Réponse CreateTime
lorsque l’utilisateur appuie en fait sur le bouton d’enregistrement.
Détails
Par le passé, l’API XML utilisait horodatage moment où l’enregistrement était créé dans la base de données comme heure de création dans LstRecording
Réponse. C’est maintenant l’heure à partir de l’utilisateur qui démarre pour effectuer l’enregistrement. Cette modification s’applique à tous les enregistrements des services. Il n’y a aucun changement de schéma.
Mises à jour API 41.5.0
Mises à jour de l’API XML 41.5.0
XMLAPI a la possibilité de démarrer des réunions Webex programmées à partir de RTCP en tant qu’organisateur
API impactées
CreateUser
: génèrehostPIN
quel que soit PMR/SRP l’utilisateur est activé ou pas lorsque le rôle d’utilisateur est organisateur ou lorsque l’administrateur du site est en lecture seule ou en lecture seule.SetUser
: définithostPIN
Utilisantphones.hostPIN
QuandpersonalMeetingRoom.hostPIN
n’est pas dans la requête XML (pré-condition : activation ou désactivation de la fonctionnalitéAllowStartScheduledMtgFromPhone
est activé).GetUser
: renvoiephones.hostPIN
quel que soit PMR/SRP l’utilisateur est activé ou non. (condition préalable : activation ou désactivation de la fonctionnalitéAllowStartScheduledMtgFromPhone
est activé).
Changements de schémas
GetUserResponse
:
SetUser
:
Exemple de réponse
GetUserResponse
:
SetUser
:
XMLAPI GetSite
répondre à deux nouveaux éléments pour le client mobile
API impactées
GetSite
:GetSite
répondra maintenant à deux nouveaux éléments pour prendre en charge le client mobile a la logique d’afficher ou de ne pas afficher l’onglet d’enregistrement.enableRecordingAccess
: vrai ou faux, les super administrateurs Webex peuvent activer ou désactiver l’accès aux enregistrements par le basculement (EnableRecordingAccesses
).storageEmptyStatus
: vrai ou faux, si les deux sites ne supportent pas la fonction NBR et ont alloué l’espace de stockage NBR sous zéro, alors la réponse du statut est true (vrai), autre est false (faux).
Changements de schémas
Modèle de demande pour GetSite
Modèle de réponse pour Getsite
Le sujet du courrier électronique qui a des caractères non ASCII sera encodé avec RFC2047. En cas de sujet de courrier électronique ASCII pur, il n’y a pas d’encodage
API impactéesIl n’y a aucune conséquence sur une demande API, la charge utile des réponses, mais elle modifie le comportement du code électronique du sujet. Lorsque le sujet de l’adresse électronique qui a des caractères non ASCII sera encodé avec RFC2047. Il n’y a aucun encodage en cas de sujet de courrier électronique ASCII pur.
Changements de schémas
Il n’y a aucun changement de schéma.
Mises à jour API 41.4.0
Mises à jour de l’API XML 41.4.0
Créer un événement programmé Webex Events les paramètres par défaut au niveau du site lors de la tonalité d’entrée et de sortie
XMLAPI s’aligne avec la nouvelle logique actuelle pour contrôler les tonalités d’entrée et de sortie. Toutes les tonalités Webex Events é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 configurerait une tonalité par défaut, créer l’événement ne exploitait pas ce paramètre en appliquant la valeur par défaut XMLAPI.
API impactées
L’API XML : GetSite renvoie un nouvel élément entryExitToneEC
pour indiquer la valeur.
L’API XML : Créer un événement, Configurer un événement, Obtenir Un événement retour à la logique de l’entreprise finale lit la valeur de entryExitToneEC
.
Changements de schémas
API XML : Obtenir un exemple de réponse sur le site :
<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éer un événement
Configurer l’événement
Obtenir un événement
XMLAPI renvoie uniquement les informations détaillées sur les événements de grande taille (Webex Event 2.0)
Si l’Réunion Webex l’événement de grande taille ou la diffusion Web,
GetSessionInfo
renvoie certaines informations détaillées incluant le mot de passe numérique de la réunion, le mot de passe numérique de la réunion, le mot de passe du panéliste et le mot de passe numérique du panéliste (Aucun schéma ne doit être changé).XMLAPI ne prend pas en charge la création et la modification de toute fonctionnalité d’événement ou d’émission Web de grande taille, donc
CreateMeeting
etSetMeeting
revenir à une nouvelle exception (110064, les événements et les Type de session Web ne sont pas pris en charge) pour les événements de grande taille ou les cas d’émission Web.
API de l’impact
Nom de l’API |
Description |
Remarque |
---|---|---|
|
Si l’Réunion Webex l’événement de grande taille ou la diffusion Web, |
Aucun schéma n’a été modifié. |
|
Si l’utilisateur essaie d’utiliser |
Comportement à modifier. |
Mises à jour API 41.3.0
Mises à jour de l’API XML 41.3.0
Les nouveaux changements de l’API XML Webex Events fonction 2.0
API impactées
Les DEUX API : Obtenir lesinfos de lasession et obtenir les éléments de retour de laeteting enableEvent
et enableWebniar
Trop.
Nom de l’élément |
Description |
---|---|
activer l’événement |
Prend en charge EC 2.0 au cours d’une réunion Webex |
activerWebniar |
Prend en charge le webinaire au cours d’une réunion Webex |
La prise en charge XMLAPI renvoie les deux éléments ci-dessus pour EC 2.0. La version actuelle de l’API XML ne prend pas en charge la programmation et la programmation de la réunion EC2.0. |
Changements de schémas
GetSessionInfo
renvoie les éléments enableEvent
et enableWebniar
pour EC 2.0.
GetMeeting
renvoie les éléments enableEvent
et enableWebniar
pour EC 2.0.
Modèle 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>
</meet:enableOptions>
Les nouveaux changements XMLAPI supportent la fonctionnalité de lobby d’avant réunion
API impactées
L’API XML : GetSite
, LstSummarySession
, GetSessionInfo
et GetMeeting
répondra au nouvel élément enablePreMeetingLobby
pour le lobby d’avant réunion.
Changements de schémas
L’API XML : GetSite
renvoie un élément enablePreMeetingLobby
pour le lobby d’avant réunion.
L’API XML : LstSummarySession
renvoie un élément enablePreMeetingLobby
pour le lobby d’avant réunion.
L’API XML : GetSessionInfo
renvoie un élément enablePreMeetingLobby
pour le lobby d’avant réunion.
L’API XML : GetMeeting
renvoie un élément enablePreMeetingLobby
pour le lobby d’avant réunion.
Modèle 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>
</ep:session>
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>
</meet:enableOptions>
L’API XML GetSite
réponse Informations comportement changement divulguer
API impactées
L’API XML : GetSite
réponse ci-dessous uniquement pour le compte administrateur, qui inclut 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 ont les données de réponse des licences GetSite
. L’organisateur ou l’invité ne recevra pas ces données de licence dans GetSite
Réponse.
Voici l’API : GetSite's
exemple de réponse siteadmin
ou prêt uniquement siteadmin
ou admin de la gestion des utilisateurs :
Mises à jour API 41.2.0
Mises à jour de l’API XML 41.2.0
XMLAPI doit prendre en charge SRC hybride VOIP si le site prend en charge la téléphonie Webex
API impactées
GetSite
renvoie un nouvel élémentIsWebexTelephony
dans la réponse.CreateUser
etSetUser
peut mettre à jour lecmrHybridVoip
élément siIsWebexTelephony
est vrai avec d’autres conditions.IsTSPUsingTelephonyAPI
n’est plus conséquent.
Changements de schémas
API XML : GetSite
la réponse renvoie un élément supplémentaire IsWebexTelephony
GetSite
inclure ce nouvel élément :
<ns1:telephonyConfig>
<ns1:isWebexTelephony>true</ns1:isWebexTelephony>
<ns1:isTSPUsingTelephonyAPI>false</ns1:isTSPUsingTelephonyAPI>
<ns1:serviceName>Personal Conference No.</ns1:serviceName>
<ns1:participantAccessCodeLabel>Attendee access code</ns1:participantAccessCodeLabel>
<ns1:subscriberAccessCodeLabel>Host access code</ns1:subscriberAccessCodeLabel>
<ns1:attendeeIDLabel>Attendee ID</ns1:attendeeIDLabel>
.....
</ns1:telephonyConfig>
LstSummarySession
prend en charge EC2.0
Les API XML doivent être impactées
LstSummarySession
retournera deux nouveaux éléments pour prendre en charge 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 |
activerWebniar |
Prend en charge le webinaire au cours d’une réunion Webex |
Changements de schémas
API XML : LstSummarySession
: Annexez 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>
</ep:session>
XMLAPI prend en charge le retour de l’utilisateur du site Webex-voice-assistant
option pour l’intégration MCT
APIs affectées
GetUser
renvoie un nouvel élément webexAssistantEnabled
(vrai ou faux) dans la réponse.
Changements de schémas
getUserResponse
:
Exemple de réponse
Mises à jour API 41.1.0
Il n’y a aucun changement de schéma à l’API XML 41.1. |