XML Tips and Tricks: How to Identify HTML Client Enabled Rooms

This article is in addition to the article (http://blogs.connectusers.com/connectsupport/xml-tips-and-tricks-setting-html-client-settings/) posted earlier this year on how to enable or disable the HTML Client.  It is intended to shed a little more light on the API around this feature.

This article is intended to help API Developers. If you are not an API developer who builds integrations and applications to extend the Adobe Connect functionality, this article will most likely not be applicable to your normal day to day workflow.

Administrators may want to have the ability to query the entire Connect system to find out what Meeting rooms, Seminar Rooms, or Virtual Classrooms have the HTML Client enabled or disabled.  It may be necessary to get a list so that they can know which rooms to target if they need to turn on or off the HTML Client setting.  By default, ‘HTML Client Enabled‘ setting is ‘No‘ for newly created rooms and existing rooms that were created before Connect 10.

There is also a global setting for allowing the Hosts of the rooms to allow the HTML Client depending on the type of Room it is.  Depending on what you have enabled in your account (the below screenshot is from an account that has Meetings, Virtual Classrooms, and Seminars enabled), you will have 1, 2, or 3 check boxes under Administration > Compliance and Control > HTML Client Settings.

Let’s say these are checked for a period of time and hosts have had the ability to enable or disable the HTML client in their rooms.  Then it is decided that the Administrator wants to disable this across all rooms that have the setting set to YES… how would they identify which rooms have it set to YES so they can change them all to NO?

The previous article talks about taking an individual room, identifying whether the room has this setting enabled or disabled, and then changing the setting with the API.  In order to pull a list of all rooms that have the field-id = meetingHTMLLaunch you would make the following API call(s):

https://{myConnectURL}/api/xml?action=acl-field-list&field-id=meetingHTMLLaunch&filter-value=true 

This will list out all rooms with HTML Client = Yes (if that room sits in the Meetings area of Adobe Connect).

The format of the response would look like this was an example:

https://{myConnectURL}/api/xml?action=acl-field-list&field-id=meetingHTMLLaunch&filter-value=false

This will list out all rooms with HTML Client = No (if that room sits in the Meetings area of Adobe Connect).

The format of the response would look like this as an example:

Similarly, if you wanted to find all Seminars or Virtual Classrooms, you would make the same ‘acl-field-list‘ API call but substitute the field-id of ‘meetingHTMLLaunch’ with either:

webinarHTMLLaunch

or

trainingHTMLLaunch

for Seminars (Shared Seminars or Named Webinars)  or Virtual Classrooms respectively, like below:

https://{myConnectURL}/api/xml?action=acl-field-list&field-id=webinarHTMLLaunch&filter-value=true
https://{myConnectURL}/api/xml?action=acl-field-list&field-id=webinarHTMLLaunch&filter-value=false

https://{myConnectURL}/api/xml?action=acl-field-list&field-id=trainingHTMLLaunch&filter-value=true
https://{myConnectURL}/api/xml?action=acl-field-list&field-id=trainingHTMLLaunch&filter-value=false

The list returned for any of these calls only returns the ‘acl-id‘ (the sco-id of the room) and the value of the field (true or false).

To get more information on the acl/sco itself, you’d have to loop over the acl-id for each child node of the XML response and run a ‘sco-info‘ call on it (to get the name or folder ID of the item, etc for example).

But to get the initial list and the IDs, the one ‘acl-field-list‘ call will suffice.

There are multiple caveats to this workflow however…

First, if you have a room on the system that pre-dates the Connect 10 version (so the room was created prior to Connect 10), it will NOT have any field-id corresponding to the HTML Client launch.  So it will not show up in any acl-field-list API call.  It will however have the HTML Client setting of ‘No‘ (false) by default.  This means to truly list out (via the API) a list of say Meeting rooms in the Connect account with ‘No‘ for the HTML Client setting, you have to not only run the acl-field-list API with field-id=meetingHTMLLaunch&filter-value=false to get all post-Connect 10 rooms and existing rooms that have had the setting set to false, but you also have to consider any Connect rooms with no HTMLLaunch field to also be ‘false’.  This adds complexity to the workflow as there isn’t a great way to find meetings without this field easily with the API.

Second, if you MOVE rooms between offerings (so moving a Meeting to the Training area to make it a Virtual Classroom or moving a Meeting to the Seminars area or vice versa…), the room will now get a new field that corresponds to the area of Connect it now resides in.

Take the case of a Meeting.  Lets say you have a Meeting that has the HTML Client = YES setting set.

Then you move that Meeting room to the Shared Seminars area or the My Seminars area (if you are a Named Webinar Manager).

By default, after you move the room, it will have HTML Client = NO set in the UI.

If you look at the sco-info API now, it will actually have TWO fields now in the XML response:

.

The original ‘meetingHTMLLaunch‘ value is still true (from when it was a Meeting).  But it now has the additional ‘webinarHTMLLaunch‘ setting of ‘false‘ (the default) because it now sits in the Seminars area of Connect.

This may cause confusion if you are running APIs to identify what rooms have HTML Client = YES set.  Because this room will show up in this call:

/api/xml?action=acl-field-list&field-id=meetingHTMLLaunch&filter-value=true

HOWEVER, it actually does NOT allow the HTML Client to launch because it lives in the Seminars area now and technically also has ‘webinarHTMLLaunch‘ value set to ‘false‘.

You have to take these factors into consideration if you have multiple features enabled on your account (Meeting, Seminars, and Training). If you only have Meetings or only have Training, etc. then you don’t need to worry about the possibility of one Sco having multiple field values for this setting.