Weitere Informationen zu XML API 39 und XML API 11 finden Sie in der Übersicht der Cisco Webex Meetings XML API-Updates (XML API 39 und früher).

Weitere Informationen zu XML API 40 finden Sie in der Übersicht der Cisco Webex Meetings XML API-Updates (XML API 40 und später).

Aktualisierungen für XML API 11 SP9 und früher finden Sie unter Cisco DevNet.

Aktualisierungen von XML API 41.12.0

Klicken Sie hier, um das XML API 41.12.0-Schema herunterzuladen.

XMLAPI blockiert den Webex Events (Classic)-Zeitplan und die Bearbeitung gemäß Site-Konfigurationselement von EnableClassicEvent das ist falsch

Betroffene APIs und Schemaänderungen

Wenn das Kontrollkästchen Klassisches Event aktivieren auf der Konfigurationsseite der Site-Administration falsch ist, unterstützt diese Site keine Webex Events (klassischen) Meetings mehr.

Wenn das Kontrollkästchen Klassisches Event aktivieren falsch ist, rufen Sie diese APIs an, um ein Webex Events-Meeting (klassisch) zu betreiben:

CreateEvent, SetEvent, GetEvent, GetSessionInfo, LstsummaryEvent, LstrecordedEvent, LstsummaryProgram, UploadEventImage

Die API reagiert auf neue Ausnahme 010106 Das klassische Event wurde deaktiviert .

Schemaänderungen

Keine Schemaänderungen.

Beispiel für eine API Anfrage und -Antwort

Event erstellen API-Anforderung und -Antwort

Anforderung von CreateEvent

<bodyContent xsi:type="java:com.webex.service.binding.event.CreateEvent">
<accessControl>
<sessionPassword>XXXXXXXX</sessionPassword>
</accessControl>
<metaData>
<sessionName>XMLAPI EC-Prüfung</sessionName>
</metaData>
<schedule>
<startDate>17.07.2021 01:29:15</startDate>
<openTime>15</openTime>
</schedule>
</bodyContent>

Antwort von 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>FEHLER </serv:result>
<serv:reason> Das klassische Event wurde deaktiviert.</serv:reason>
<serv:gsbStatus>PRIMÄR <UNK> </serv:gsbStatus> <UNK>
<serv:exceptionID> <UNK> 010106</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>

CreateEvent3.1.3 Betrifft APIs:

• SetEvent GetEvent

• GetSessionInfo

• LstsummaryEvent

• LstrecordedEvent

• LstsummaryProgram

• UploadEventImage

XMLAPI LstMeetingType wird auf neues Element von reagieren subProductCodePrefix

Betroffene APIs

Aktuelle API LstMeetingType Antwortelement von productionCodePrefix: PRO, AUO und andere, bei denen es sich um vordefinierte Meeting-Typ-Präfix von Webex handelt.

Nach dieser neuen Verbesserung reagiert die API auf ein neues Element von subProdctCodePrefix:PRO1, PRO2, etc., die angepasst werden können, treffen Typ Präfix.

Schemaänderungen bei API: LstMeetingType

Es reagiert auf neues Element: subProdctCodePrefix

Beispiel für eine API Anfrage und -Antwort

LstMeetingType API-Anforderung und -Antwort

Anforderung von LstMeetingType

<bodyContent xsi:type="java:com.webex.service.binding.meetingtype.LstMeetingType">
<meetingTypeID>13810</meetingTypeID>
</bodyContent>

Antwort von 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> //Neues Element für angepassten Meeting-Typ
<mtgtype:active>AKTIVIERT</mtgtype:active>
<mtgtype:name>C)us_C)hat_Geschlossen</mtgtype:name>
<mtgtype:displayName>C)us_C)hat_Geschlossen</mtgtype:displayName>

Aktualisierungen von XML API 41.11.0

Klicken Sie hier, um das XML API 41.11.0-Schema herunterzuladen.

XML-API-Unterstützung für Vorwärtskompatibilität in der Benutzerverwaltungs-API für von Control Hub verwaltete Sites

Betroffene APIs und Schemaänderungen

Wenn Ihre Integrationsanwendung derzeit Webex XMLAPI-Benutzerverwaltungs-APIs verwendet: CreateUser, SetUser, DelUser, und GetUser um Benutzer bereitzustellen oder zu verwalten, nachdem Ihre klassische Webex-Site in eine von Control Hub verwaltete Site konvertiert wurde, funktionieren diese APIs weiterhin für die Forward-Kompatibilität. Es gibt einige Verhaltensänderungen, wie unten erwähnt:

• Bei Verwendung von createUser - ist der Benutzerstatus in Control Hub nicht „aktiv“, ist der Benutzerstatus auf der Site nicht aktiv. Wenn der Benutzerstatus in Control Hub „ Aktiv“ ist, ist auch der Benutzerstatus auf der Site „Aktiv“. Referenzwert: Benutzerstatus neuer und konvertierter Benutzer in Control Hub .

• Das Element password der APIs CreateUser und SetUser wird ignoriert, wir senden eine Aktivierungs-E-Mail an neue Benutzer, Benutzer können auf den Link in der E-Mail klicken, um ein neues Konto zu aktivieren und ein neues Passwort einzugeben.

• Die Aktiv element von CreateUser API wird ignoriert, neuer Benutzer (nicht verifiziert) kann nicht über diesen Parameter mithilfe der API aktiviert werden SetUser .

• Der Wert von webExId Element im TextInhalt von CreateUser APIs muss mit E-Mail identisch sein. Wenn webExId unterscheidet sich von E-Mail , behandeln wir die webExId wie E-Mail beim Speichern in WebDB, und der Wert wird ignoriert.

• Der Wert von webExId Element im TextInhalt von SetUser APIs muss die Benutzeridentität der E-Mail-Adresse sein, Sie können sie mit < E-Mail > in bodyContent.

• Die SetUser-API unterstützt die Änderung der E-Mail-Adresse eines vorhandenen Benutzers: ist es erfolgreich, wenn das Konto für den Vorgang in SecurityContext Control Hub-Site-Administrator mit Vollzugriff ist. Andernfalls meldet die API einen Fehler mit neuem Fehlercode und folgender Meldung:

  • 030120 Das Konto muss ein vollständiger Site-Administrator sein, um die E-Mail-Adresse zu ändern.

• Das Element newWebExId im TextInhalt der SetUser API wird ignoriert.

• Die SetUser API versucht, in eine E-Mail zu wechseln, die bereits verwendet wird. Die API wird unter neuem Fehlercode und Fehlermeldung angezeigt:

  • 030118 E-Mail wird bereits in von Control Hub verwalteten Sites verwendet.

• Die DelUser-API deaktiviert den Benutzer auf der Webex-Meeting-Seite, und die entsprechende Meeting-Lizenz wird von der Webex-Site entfernt. Dieser deaktivierte Benutzer kann über die API erneut aktiviert werden: SetUser (<active> AKTIVIERT </active>), solange der Benutzer zuvor verifiziert wurde.

• Die APIs CreateUser und SetUser werfen neuen Fehlercode und eine Fehlermeldung auf, wie unten gezeigt:

  • 030117 , Dieser Benutzer existiert außerhalb Ihrer Organisation. Daher muss er beansprucht werden, damit er über das Beanspruchungsbenutzerverfahren in Ihre Organisation wechseln kann. Schritte zum Beanspruchen des Benutzers in Ihrer Organisation finden Sie unter Beanspruchen von Benutzern für Ihre Organisation (Benutzer konvertieren). Sie müssen die Domäne verifizieren, zu der der Benutzer gehört, bevor Sie den Benutzer beanspruchen können.

  • 030119 Das CI-Zugriffstoken muss einen Umfang enthalten webexsquare: Administrator – bei der Bereitstellung des Benutzers.

Nur für einen begrenzten Zeitraum wird die Forward-Kompatibilität unterstützt. Wir benachrichtigen Sie im Voraus, bevor diese Kompatibilität entfernt wird.

Schemaänderungen

Keine Schemaänderungen für diese APIs: CreateUser, SetUser, DelUser, und GetUser.

Beispiel für eine API Anfrage und -Antwort

Anforderung und Antwort für CreateUser API

API-Anforderung:
<?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>{Site-Admin-Konto}</webExID>
<email>{Site-Admin-Konto}</email>
<sessionTicket>xxxx</sessionTicket> oder <password> oder <webExAccessToken>
oder <accessToken>, wenn CI „accessToken“ verwendet wird, muss es das Ziel webexsquare:admin bei der Bereitstellung des Benutzers enthalten
</accessToken></webExAccessToken></password></securityContext>
</header>



<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.CreateUser">
<webExId>Jack@qa.webex.com</webExId> --- Es sollte sich um die Benutzeridentität der E-Mail-Adresse handeln
<email>Jack@qa.webex.com</email>
<firstName>Buchse</firstName>
<lastName>Schmied</lastName>
<password>....</password>
<privilege>
<host>wahr</host>
</privilege>
<active>AKTIVIERT</active> ---dieser Parameter kann den Benutzer nicht direkt aktivieren, bis der Benutzer sich selbst über die Aktivierungs-E-Mail aktiviert hat.
</bodyContent>
</body>


API-Antwortbeispiel:
<?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>ERFOLG</serv:result>
<serv:gsbStatus>VORRANG</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>

Betroffen sind APIs:

• Benutzer erstellen

• Benutzer festlegen

• Benutzer löschen

XML API unterstützt die Vorwärtskompatibilität der Authentifizierung vorhandener Benutzer, nachdem die klassische Webex-Site in eine von Control Hub verwaltete Site konvertiert wurde

Betroffene APIs

Nachdem die klassische Webex-Site in eine von Control Hub verwaltete Site konvertiert wurde, muss der Wert des <webExID> Elements in <securityContext> der E-Mail-Adresse entsprechen. Einzelheiten hierzu finden Sie unten:

• Für bestehende Benutzer, die auf der klassischen Webex-Site erstellt wurden, unterstützen wir beide alten webExID (Beispiel: Jack) und new webExID (der Inhalt ist derselbe wie E-Mail, Beispiel: Jack@xx.com), um sich anzumelden, ist diese Abwärtskompatibilität der Authentifizierung für alle XML-APIs.

• Für neue Benutzer, die in von Control Hub verwalteten Sites erstellt wurden, muss der Wert des Elements webExID dem Wert für die Anmeldung per E-Mail entsprechen.

<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- In der klassischen WebEx-Site wurden vorhandene Benutzer erstellt: jack oder jack@xx.com; neuer Benutzer muss jack@xx.com
<sessionTicket> xxxx </sessionTicket> oder <password> oder <webExAccessToken> oder <accessToken>
</accessToken></webExAccessToken></password></securityContext>
</header>

Betroffen sind APIs:

Alle XML-APIs.

Nachdem die klassische Webex-Site in eine von Control Hub verwaltete Site konvertiert wurde, muss der Wert des <webExID> Elements < bodyContent > mit der E-Mail identisch sein. Einzelheiten hierzu finden Sie unten:

• Für bestehende Benutzer, die auf der klassischen Webex-Site erstellt wurden, unterstützen wir beide alten webExId (z. B.: Jack) und neu webExId (der Inhalt entspricht der E-Mail-Adresse, z. B.: Jack@xx.com) in bodyContent .

• Für neue Benutzer, die in von Control Hub verwalteten Sites erstellt wurden, gilt der Wert von webExId Element muss mit E-Mail in identisch sein bodyContent.

<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx </webExId> --- Vorhandene Benutzer wurden in der klassischen WebEx-Site erstellt. Dies kann Folgendes sein: jack oder jack@xx.com; neuer Benutzer muss jack@xx.com verwenden
</bodyContent>

Betroffen sind APIs:GetUser, SetUser, und DelUser.

Schemaänderungen

Keine Schemaänderungen auf APIs.

Beispiel für eine API Anfrage und -Antwort

GetUser API-Anforderung und -Antwort

API-Anforderung:
<?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> --- Vorhandene Benutzer wurden in der klassischen WebEx-Site erstellt. Dies kann Folgendes sein: jack oder jack@xx.com; neuer Benutzer muss jack@xx.com verwenden
<sessionTicket>xxxx</sessionTicket> oder <password> oder <webExAccessToken> oder <accessToken>
</accessToken></webExAccessToken></password></securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- Vorhandene Benutzer wurden in der klassischen WebEx-Site erstellt. Dies kann Folgendes sein: jack oder jack@xx.com; neuer Benutzer muss jack@xx.com verwenden
</bodyContent>
</body>


API-Antwortbeispiel:
... wie zuvor

Verbesserung der API für Aufzeichnungsansicht, die in Webex Meetings, Webex Events (neu) und Webex Events (klassisch) unterstützt wird

Betroffene APIs

Aktuelle API: lstrecordaccessHistory und lstrecordaccessDetailHistory unterstützt nur die Aufzeichnungsansicht von Webex Trainings, auf die der Verlaufsbericht zugegriffen wurde. Die neue Verbesserung unterstützt Webex Meetings, Webex Events (neu) und Webex Events (klassische) Aufzeichnungsansicht, auf die auch der Verlaufsbericht zugegriffen wird.

Schemaänderungen

Wir unterstützen das folgende neue Schema in API lstrecordaccessHistory im API-Anforderungstext:

<serviceTypes>
<serviceType>MeetingCenter </serviceType>
<serviceType> TrainingCenter </serviceType>
<serviceType> EventCenter</serviceType>
</serviceTypes>

Details

Die API: lstrecordaccessHistory ist in der Lage, die aufgerufene Aufzeichnungsansicht für Webex Meetings, Webex Events (neu), Webex Events (klassisch) und Webex Trainings zurückzugeben.

• Wenn es keine Servicetyp in API-Anforderung angegeben, die API von lstrecordaccessHistory gibt die Aufzeichnungsansicht für Webex Trainings zurück, auf die nur der Verlauf zugegriffen wurde.

• Wenn der Diensttyp MeetingCenter ist, wird die API von lstrecordaccessHistory gibt sowohl die Webex Meetings- als auch die Webex Events (neue) Aufzeichnungsansicht zurück, auf die auf den Verlauf zugegriffen wurde.

• Wenn die Servicetyp ist EventCenter, die API von lstrecordaccessHistory gibt die auf den Verlauf zugegriffene Webex Events-Aufzeichnungsansicht (klassisch) zurück.

Die API: lstrecordaccessDetailHistory ist in der Lage, Details zurückzugeben durch recordID von Webex Meetings, Webex Events (neu), Webex Events (klassisch) und Webex Trainings.

Beispiel für eine API Anfrage und -Antwort

lstrecordaccessHistory Anforderung und Antwort der 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>AUFGEZEICHNET</orderBy>
<orderAD>ASC</orderAD>
</order>
<serviceTypes>
<serviceType>MeetingCenter</serviceType>
<serviceType>Trainingszentrum</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>ERFOLG</serv:result>
<serv:gsbStatus>VORRANG</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 Uhr</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>Instant-Wiedergabe testen 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>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 Uhr</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 Uhr</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 Uhr</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 Anforderung und Antwort der 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>ERFOLG</serv:result>
<serv:gsbStatus>VORRANG</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>falsch</history:registered>
<history:downloaded>falsch</history:downloaded>
<history:viewed>wahr</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>falsch</history:registered>
<history:downloaded>wahr</history:downloaded>
<history:viewed>falsch</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>

Betroffen sind APIs:

• lstrecordaccessHistory

• lstrecordaccessDetailHistory

Beheben Sie die Lücke der maximal zulässigen Beschreibung für Webex Events (Classic) zwischen XMLAPI und Webex-Seite.

Betroffene APIs

Die XML API: CreateEvent und SetEvent's Element von Beschreibung erlaubt maximal 10000 Zeichen Eingaben, wenn Übergröße inputing, wird es in der neuen Fehlercode und Meldung führen:

060068 Ungültige Eingabebeschreibung. Diese Beschreibung darf 10.000 Zeichen nicht überschreiten.

Schemaänderungen

Keine Schemaänderung.

Beispiel für eine API Anfrage und -Antwort

CreateEvent API-Anforderung und -Antwort

#API-Anforderungsbeispiel:
...
<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>PRIVAT</listing>
</accessControl>
<metaData>
<sessionName>EC-Test</sessionName>
<description>.......Angenommen, Sie füllen 10000 Zeichen in der Beschreibung.......</description>
</metaData>
...


------------------------------------
#API-Antwortbeispiel, wenn die Beschreibung 10000 Zeichen überschreitet:

<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>FEHLER </serv:result>
<serv:reason> Ungültige Eingabebeschreibung. Die Beschreibung darf 10000 Zeichen nicht überschreiten </serv:reason>
<serv:gsbStatus> PRIMARY </serv:gsbStatus>
<serv:exceptionID> 060068</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>

Betroffen sind APIs:

• CreateEvent

• SetEvent

XML API: GetUser gibt neues Element von freeAccount zurück

Betroffene APIs

GetUser gibt ein neues Element zurück, das identifiziert freeAccount Das Benutzerkonto lautet FreeAccount oder nicht.

Schemaänderungen

Beispiel für eine GetUser-Antwort

GetUser-Antwort:
<use:initials>AW </use:initials>
<use:isUploaded> false </use:isUploaded>

<use:largeEventCapacity> 3 </use:largeEventCapacity>
<use:freeAccount> false</use:freeAccount>

Betroffen sind APIs:

GetUser

Aktualisierungen von XML API 41.9.0

Klicken Sie hier, um das XML API 41.9.0-Schema herunterzuladen.

XML API 10.0.0 für alle T31-Sites außer Betrieb nehmen

Webex plant das Ende der Unterstützung der XML-API ver 10.0.0 für alle T31-Sites.

Wir bauen den XML API 10.0.0-Code aus allen Produktionen im 41.9.0-Update aus.

Aktualisierungen von XML API 41.8.0

Klicken Sie hier, um das XML API 41.8.0-Schema herunterzuladen.

XML API 10.0.0 für alle T31-Sites außer Betrieb nehmen

Webex plant das Ende der Unterstützung der XML-API ver 10.0.0 für alle T31-Sites.

Webex hat festgestellt, dass einige Kunden Client Zugriff auf XML API URL mit falscher Weise wie: https://{siteName}.webex.com/WBXService/xml10.0.0/XMLService, der richtige Weg für den Zugriff auf XML API URL als: https://{siteName}.webex.com/WBXService/XMLService.

Bitte wechseln Sie die XML-API Ihres Codezugriffs auf die richtige Weise, um Auswirkungen zu vermeiden, bevor die Unterstützung der XML-API-Version 10.0.0 eingestellt wird.

Aktualisierungen von XML API 41.7.0

Klicken Sie hier, um das XML API 41.7.0-Schema herunterzuladen.

Das Löschen und Bearbeiten von Aufzeichnungen auf Mobilgeräten sollte über die Option der Site-Administration gesteuert werden: Gastgeber dürfen Aufzeichnungen erneut zuweisen, bearbeiten, deaktivieren und löschen

Betroffene APIs und Schemaänderungen

GetSite: wird neue Elemente-Benennung zurückgeben enableNBRMCModify, und separateNoRecordingEdit unter Werkzeuge.

Antwortbeispiel

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>ERFOLG</serv:result>
<serv:gsbStatus>VORRANG</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>

Aktualisierungen von XML API 41.6.3

Klicken Sie hier, um das XML API 41.6.3 Schema herunterzuladen.

GetSite Antwort neues Element von supportLargeEvent

Betroffene APIs und Schemaänderungen

GetSite : gibt neue Elementbenennung zurück supportLargeEvent unter siteCommonOptions um dem Anrufer mitzuteilen, ob die Site Large Event (Webex Event (neu)) unterstützt oder nicht.

Schemaänderung

Antwortbeispiel

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>ERFOLG</serv:result>
<serv:gsbStatus>VORRANG</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>

Aktualisierungen von XML API 41.6.0

Klicken Sie hier, um das XML API 41.6.0-Schema herunterzuladen.

XMLAPI unterstützt Webex Events 2.0 bei der Bereitstellung

Betroffene APIs

GetUser: gibt neue Elementbenennung zurück largeEventCapacity welches die Kapazität des neuen Events 2.0 (EC 2.0) unter diesem Benutzerkonto anzeigt. Wenn das Benutzerkonto beispielsweise über eine CI _ EC3K-Lizenz verfügt, wird der Wert von largeEventCapacity ist 3000.

Schemaänderungen

Antwortbeispiel

GetUserResponse:

Die Erstellungszeit von XMLAPI LstRecording gilt für die Startzeit der Aufzeichnung

Betroffene APIs

LstRecording: LstRecording Antwort CreateTime als Zeitpunkt, zu dem der Benutzer tatsächlich die Schaltfläche „Aufzeichnen“ drückt.

Details

In der Vergangenheit hat die XML-API den Zeitstempel zum Zeitpunkt der Erstellung der Aufzeichnung in der Datenbank als Erstellungszeit in verwendet. LstRecording Antwort. Jetzt ist es der Zeitpunkt, an dem der Benutzer tatsächlich mit der Aufzeichnung beginnt. Diese Änderung gilt für alle Dienstaufzeichnungen. Es gibt keine Schemaänderung.

Aktualisierungen von XML API 41.5.0

Klicken Sie hier, um das XML API 41.5.0-Schema herunterzuladen.

XMLAPI hat die Möglichkeit, angesetzte Webex-Meetings von PSTN aus als Gastgeber zu starten

Betroffene APIs

• CreateUser: generiert hostPIN unabhängig davon, ob Benutzer-PMR aktiviert ist oder nicht, wenn die Benutzerrolle Gastgeber oder vollständige oder schreibgeschützte Site-Administratoren oder Benutzer-Management-Site-Administratoren ist.

• SetUser: Sätze hostPIN verwenden phones.hostPIN wenn personalMeetingRoom.hostPIN ist nicht in XML-Anforderung (Vorbedingung: Umschaltoption AllowStartScheduledMtgFromPhoneaktiviert ist).

• GetUser: Rendite phones.hostPIN unabhängig davon, ob Benutzer-PMR aktiviert ist oder nicht. (Vorbedingung: Umschaltoption AllowStartScheduledMtgFromPhone aktiviert ist).

Schemaänderungen

GetUserResponse:

SetUser:

Antwortbeispiel

GetUserResponse:

SetUser:

XMLAPI GetSite Antwort zwei neue Elemente für mobilen Client

Betroffene APIs

• GetSite: GetSite reagiert nun auf zwei neue Elemente zur Unterstützung mobiler Clients hat die Logik, die Registerkarte „Aufzeichnung“ anzuzeigen oder nicht anzuzeigen.

  • enableRecordingAccess: true oder false, Webex Super-Administratoren können den Aufzeichnungszugriff über die Umschaltfunktion aktivieren oder deaktivieren( EnableRecordingAccesses).

  • storageEmptyStatus: true oder false, wenn beide Sites die NBR-Funktion nicht unterstützen und den NBR-Speicherplatz als Null zugewiesen haben, dann ist die Statusantwort true, andernfalls ist false.

Schemaänderungen

Beispielanforderung für GetSite

Beispielantwort für Getsite

E-Mail-Betreff mit Nicht-ASCII-Zeichen wird mit RFC2047 codiert. Bei einem reinen ASCII-Zeichen-E-Mail-Betreff gibt es keine Codierung.

Es gibt keine Auswirkungen auf API-Anfragen oder die Nutzlast von Antworten, aber es ändert das Verschlüsselungsverhalten des E-Mail-Betreffs. Wenn der Betreff einer E-Mail Nicht-ASCII-Zeichen enthält, wird er mit RFC2047 codiert. Bei einem reinen ASCII-Zeichen-E-Mail-Betreff gibt es keine Codierung.

Schemaänderungen

Es gibt keine Schemaänderungen.

Aktualisierungen von XML API 41.4.0

Klicken Sie hier, um das XML API 41.4.0-Schema herunterzuladen.

Angesetztes Event erstellen Webex Events kann den Standard auf Site-Ebene bei Ton bei Beitritt und Verlassen nutzen

XMLAPI entspricht der aktuellen neuen Logik zur Steuerung des Ein- und Ausgangstons. Alle Töne für Webex Events wurden durch eine andere Einstellung in der Site-Administration gesteuert. In GetSite, XMLAPI gibt ein zusätzliches Feld zurück entryExitToneEC um den Wert anzugeben. Wenn der Site-Administrator einen Standard auf den Ton festgelegt hat, nutzt „Event erstellen“ diese Einstellung nicht, indem er den XMLAPI-Standard anwendet.

Betroffene APIs

Die XML API: GetSite gibt ein neues Element zurück entryExitToneEC um den Wert anzugeben.

Die XML API: CreateEvent, SetEvent, GetEvent Back-End-Geschäftslogik liest den Wert von entryExitToneEC.

Schemaänderungen

XML API: GetSite-Antwortbeispiel:

<ns1:defaults>
<ns1:emailReminders>wahr</ns1:emailReminders>
<ns1:entryExitTone>ANNOUNCENAME</ns1:entryExitTone>
<ns1:entryExitToneEC>NOTON</ns1:entryExitToneEC>
<ns1:voip>wahr</ns1:voip>
<ns1:teleconference>
<ns1:telephonySupport>KEINER</ns1:telephonySupport>
</ns1:teleconference>
<ns1:joinTeleconfNotPress1>wahr</ns1:joinTeleconfNotPress1>
<ns1:updateTSPAccount>falsch</ns1:updateTSPAccount>
</ns1:defaults>

Betroffen sind APIs:

• GetSite

• Event erstellen

• Ereignis festlegen

• GetEvent

XMLAPI gibt nur die detaillierten Informationen zum großen Event (Webex Event 2.0) zurück.

1. Wenn das Webex-Meeting das große Event oder Webcast ist, GetSessionInfo gibt einige detaillierte Informationen zurück, einschließlich Meeting-Passwort, numerisches Meeting-Passwort, Diskussionsteilnehmer-Passwort und numerisches Diskussionsteilnehmer-Passwort (kein Schema kann geändert werden).

2. XMLAPI unterstützt nicht das Erstellen und Bearbeiten von Großereignissen oder Webcasts, also CreateMeeting und SetMeeting eine neue Ausnahme (110064, Der Event- und Webcast-Sitzungstyp wird nicht unterstützt) für große Events oder Webcasts zurückgeben.

Auswirkungen APIs

Aktualisierungen von XML API 41.3.0

Klicken Sie hier, um das XML API 41.3.0-Schema herunterzuladen.

Die neuen Änderungen an der XML-API unterstützen die Webex Events 2.0-Funktion

Betroffene APIs

Beide APIs: GetSessionInfo und GetMeeting Elemente zurückgeben enableEvent und enableWebniar auch.

Die XMLAPI-Unterstützung gibt über zwei Elemente für EC 2.0 zurück. Die aktuelle XML-API-Version unterstützt nicht das Ansetzen und Festlegen eines EC2.0-Meetings.

Schemaänderungen

GetSessionInfo Elemente zurückgeben enableEvent und enableWebniar für EC 2.0.

GetMeeting Elemente zurückgeben enableEvent und enableWebniar für EC 2.0.

Antwortbeispiel:

GetSessionInfo Antwort:

<ep:accessControl>
<ep:listStatus>ÖFFENTLICH</ep:listStatus>
<ep:registration>falsch</ep:registration>
<ep:passwordReq>wahr</ep:passwordReq>
<ep:isEnforceAudioPassword>falsch</ep:isEnforceAudioPassword>
<ep:isEnforceAudioLogin>falsch</ep:isEnforceAudioLogin>
<ep:enableEvent>falsch</ep:enableEvent>
<ep:enableWebniar>falsch</ep:enableWebniar>
<ep:enablePreMeetingLobby>wahr</ep:enablePreMeetingLobby>
</ep:accessControl>

GetMeeting Antwort:

<meet:supportPKI>falsch</meet:supportPKI>
<meet:HQvideo>wahr</meet:HQvideo>
<meet:HDvideo>wahr</meet:HDvideo>
<meet:viewVideoThumbs>wahr</meet:viewVideoThumbs>
<meet:enableEvent>falsch</meet:enableEvent>
<meet:enableWebniar>falsch</meet:enableWebniar>
<meet:enablePreMeetingLobby>wahr</meet:enablePreMeetingLobby>

Die neuen XMLAPI-Änderungen unterstützen die Lobby-Funktion vor dem Meeting

Betroffene APIs

Die XML API: GetSite, LstSummarySession, GetSessionInfo, und GetMeeting wird auf das neue Element antworten enablePreMeetingLobby für die Lobby vor dem Meeting.

Schemaänderungen

Die XML API: GetSite Element zurückgibt enablePreMeetingLobby für die Lobby vor dem Meeting.

Die XML API: LstSummarySession Element zurückgibt enablePreMeetingLobby für die Lobby vor dem Meeting.

Die XML API: GetSessionInfo Element zurückgibt enablePreMeetingLobby für die Lobby vor dem Meeting.

Die XML API: GetMeeting Element zurückgibt enablePreMeetingLobby für die Lobby vor dem Meeting.

Antwortbeispiel:

GetSite Antwort:

<ns1:siteCommonOptions>
<ns1:SupportCustomDialRestriction>falsch</ns1:SupportCustomDialRestriction>
<ns1:SupportTelePresence>falsch</ns1:SupportTelePresence>
<ns1:SupportTelePresencePlus>falsch</ns1:SupportTelePresencePlus>
<ns1:EnableCloudTelepresence>wahr</ns1:EnableCloudTelepresence>
<ns1:EnableCMRForAllUsers>wahr</ns1:EnableCMRForAllUsers>
<ns1:enablePersonalMeetingRoom>wahr</ns1:enablePersonalMeetingRoom>
<ns1:SupportAlternateHost>wahr</ns1:SupportAlternateHost>
<ns1:SupportXMLAPIReturnScheduledPMR>falsch</ns1:SupportXMLAPIReturnScheduledPMR>
<ns1:SupportAnyoneHostMeetings>wahr</ns1:SupportAnyoneHostMeetings>
<ns1:enablePreMeetingLobby>wahr</ns1:enablePreMeetingLobby>
</ns1:siteCommonOptions>

LstSummarySession Antwort:

<ep:isException>falsch</ep:isException>
<ep:isNextUpcomingInstance>wahr</ep:isNextUpcomingInstance>
<ep:seriesMeetingKey>0</ep:seriesMeetingKey>
<ep:isScheduledPMR>falsch</ep:isScheduledPMR>
<ep:enableEvent>falsch</ep:enableEvent>
<ep:enableWebniar>falsch</ep:enableWebniar>
<ep:enablePreMeetingLobby>wahr</ep:enablePreMeetingLobby>

GetSessionInfo Antwort:

<ep:accessControl>
<ep:listStatus>ÖFFENTLICH</ep:listStatus>
<ep:registration>falsch</ep:registration>
<ep:passwordReq>wahr</ep:passwordReq>
<ep:isEnforceAudioPassword>falsch</ep:isEnforceAudioPassword>
<ep:isEnforceAudioLogin>falsch</ep:isEnforceAudioLogin>
<ep:enableEvent>falsch</ep:enableEvent>
<ep:enableWebniar>falsch</ep:enableWebniar>
<ep:enablePreMeetingLobby>wahr</ep:enablePreMeetingLobby>
</ep:accessControl>

GetMeeting Antwort:

<meet:supportPKI>falsch</meet:supportPKI>
<meet:HQvideo>wahr</meet:HQvideo>
<meet:HDvideo>wahr</meet:HDvideo>
<meet:viewVideoThumbs>wahr</meet:viewVideoThumbs>
<meet:enableEvent>falsch</meet:enableEvent>
<meet:enableWebniar>falsch</meet:enableWebniar>
<meet:enablePreMeetingLobby>wahr</meet:enablePreMeetingLobby>

Die XML-API GetSite Offenlegung des Verhaltens von Antwortinformationen

Betroffene APIs

Die XML API: GetSite nur die Antwort unter den Elementen für das Administratorkonto, die Rollen enthalten: SiteAdmin, RO_SiteAdmin, und 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>

Verhalten geändert

Nur zulassen, dass Administratorrollen Antwort haben Lizenzdaten von GetSite. Gastgeber oder Teilnehmer erhalten diese Lizenzdaten nicht in GetSite Antwort.

Im Folgenden finden Sie die API: GetSite's Antwortbeispiel für siteadmin oder nur bereit siteadmin oder Benutzerverwaltungsadministrator:

Aktualisierungen von XML API 41.2.0

Klicken Sie hier, um das XML API 41.2.0-Schema herunterzuladen.

XMLAPI sollte „CMR Hybrid VOIP“ unterstützen, wenn die Site Webex-Telefonie unterstützt

Betroffene APIs

• GetSite gibt ein neues Element zurück IsWebexTelephony in der Antwort.

• CreateUser und SetUser kann die Aktualisierung cmrHybridVoip Element, wenn IsWebexTelephony gilt zusammen mit anderen Bedingungen. IsTSPUsingTelephonyAPI ist keine Konsequenz mehr.

Schemaänderungen

XML API: GetSite Antwort gibt ein zusätzliches Element zurück IsWebexTelephony

GetSite die Antwort enthält dieses neue Element:

<ns1:telephonyConfig>

<ns1:isWebexTelephony>wahr</ns1:isWebexTelephony>
<ns1:isTSPUsingTelephonyAPI>falsch</ns1:isTSPUsingTelephonyAPI>
<ns1:serviceName>Persönliche Konferenz-Nr.</ns1:serviceName>
<ns1:participantAccessCodeLabel>Zugriffscode für Teilnehmer</ns1:participantAccessCodeLabel>
<ns1:subscriberAccessCodeLabel>Zugriffscode für Gastgeber</ns1:subscriberAccessCodeLabel>
<ns1:attendeeIDLabel>Teilnehmer-ID</ns1:attendeeIDLabel>

.....

</ns1:telephonyConfig>

LstSummarySession unterstützt EC2.0

XML-APIs sind betroffen

LstSummarySession wird neue zwei Elemente zur Unterstützung EC 2.0 zurückgeben

Schemaänderungen

XML API: LstSummarySession: Anhängen des < enableEvent> und < enableWebniar> Elemente

Antwort von XML API: LstSummarySession

Antwort für EC 2.0

<ep:isNextUpcomingInstance>wahr</ep:isNextUpcomingInstance>

<ep:seriesMeetingKey>0</ep:seriesMeetingKey>
<ep:isScheduledPMR>falsch</ep:isScheduledPMR>
<ep:enableEvent>wahr</ep:enableEvent>
<ep:enableWebniar>wahr</ep:enableWebniar>

XMLAPI unterstützt die Rückgabe von Site-Benutzern Webex-voice-assistant Option für MCT-Integration

Betroffene API

GetUser gibt ein neues Element zurück webexAssistantEnabled(true oder false) in der Antwort.

Schemaänderungen

getUserResponse:

Antwortbeispiel