Posts in Category "XML API"

XML API Tips: Internal-error When Executing Reporting Calls

Periodically when executing a reporting API call, you may get an unexpected return as shown below:

<results>
<status code=”internal-error”>
<exception>java.sql.SQLNonTransientConnectionException: [Macromedia][SQLServer JDBC Driver][SQLServer]Cannot open database “XXXXXXXXX” requested by the login. The login failed.</exception>

</status>
</results>

Where the ‘XXXXXXXXX’ would be the database name of the database your request was trying to hit.

This is expected if you are making one of the ‘reporting database API calls‘ during the exact time that the db is locked for a small restore.  As previously discussed, the reporting database is not real-time. It is synched occasionally and can be behind by as much as 24 hours.   That error (you would see it in the logs and in your response) is thrown when the DB is being restored.  When the db is being restored, the DB is locked down and the result will be a failed login (internal-error).  The reporting DB is log shipped every 15 minutes.  So every 15 minutes there will be a small restore.  All you’re application needs to do is retry when you get that message.  It could be as much as a minute of downtime, but most of the time is less.

 

XML API Tips: Reporting API Calls and the Reporting Database

One common question from API developers revolves around the existence of our reporting database vs our production database on Adobe’s Hosted platform.  There are a few API calls that will hit the reporting database rather than production, to retrieve information.  This is by design and is to prevent some of the more expensive APIs from being run on a multi-tenant environment’s production database.  The current calls that are redirected to our reporting database and not to our production (real-time) database are:

/api/xml?action=report-bulk-consolidated-transactions
/api/xml?action=report-bulk-objects
/api/xml?action=report-bulk-questions
/api/xml?action=report-bulk-users
/api/xml?action=report-bulk-slide-views

As you can see, these are all the ‘bulk’ API calls.  There is one additional call that is currently (as of Adobe Connect 9.2.2) being directed to the reporting database rather than production, and that is:

/api/xml?action=report-quiz-results

This action will be shifted to the production database in the next major release of Adobe Connect.

The reason this is important is that the reporting database is not real-time like production.  It is delayed, sometimes up to 24 hours.  So it is recommended that if you need to have real-time information in your application, you avoid making the calls above and use other APIs to retrieve the desired data.

XML API Tips: Arkadin Profile Creation – Display Numbers

Previously I posted a blog entry on creating audio profiles via the XML API (http://blogs.adobe.com/connectsupport/xml-api-tips-creating-telephony-profiles-via-the-xml-api/).  This is an add-on article describing one additional step for finalizing an Arkadin profile.

Once you complete the Arkadin profile, you may notice the Conference Numbers aren’t showing up at the bottom of the profile (in the UI).  When you build a profile in the UI (without the API) and you save the profile, it will display the Conference Number and Conference Number Toll Free in a datagrid below the credentials.  When you create a profile with the API, it will not (unless you go into the UI and then click Edit and then Save again).

ark1

Notice no Conference Numbers listed in the grid below the Profile Status.

Also, if you create the profile with the API (and you don’t go into the UI and click Edit/Save), you may notice that the conference numbers are not displayed in the Dial In dialogue box in the meeting room for participants.  It will only list the Moderator and Participant codes.

ark3

Notice, no numbers appearing to call into…

To get the numbers to show up in the Profile and in the dial-in dialogue box inside of the meeting room itself, you need to add one additional web service call to your workflow as below:

Once you build your telephony profile from the previous article,  you need to take the profile-id value and make the ‘telephony-profile-dial-in-number-update‘ API call to input the new numbers as such:

/api/xml?action=telephony-profile-dial-in-number-update&profile-id=1379585623&location=Toll%20access%20number&conf-number=+1-8xx-xxx-xxxx&location=Toll%20free%20access%20number&conf-number=+1-xxx-xxx-xxxx

Where you add the profile-id
where you add all the ‘locations’ you want (the string for the conference number description)
where you add the applicable conference numbers for each (toll + toll free for instance)

After completing this step, if you view the profile in the UI again, you see the numbers appear:

ark2

Conference Numbers now listed in the grid below the Profile Status.

 

ark4

Notice now the number(s) appear.

Arkadin Audio Profile Conference Numbers

For Arkadin customers who integrate Arkadin audio profiles into Adobe Connect Meeting rooms, they need to be very careful in what numbers they are inputting into the profile fields when they are creating the telephony profiles.  Also, if these profiles are being provisioned automatically by an application utilizing the API, developers need to make sure the values they are passing in via the web services are also correct.

Arkadin has 3 phone numbers that are required when building an audio profile (UI pictured below).

arkprof

  1. Toll Access Number‘ (in the API this is: ‘x-tel-arkadin-conference-number‘)
  2. Toll Free Access Number‘ (in the API this is ‘x-tel-arkadin-conference-number-free‘)
  3. SIP Access Number‘ (in the API this is ‘x-tel-arkadin-conference-number-uvline‘)

It is crucial that you do NOT inadvertently put the Toll number (a non ‘1-8xx’ number) in for the Toll Free value and vice versa.  If you put a toll number in for the toll free number, the audio profile will save correctly, HOWEVER the UV line (Universal Voice) will not be able to connect to your meeting room when you try to start the audio (for Audio Broadcast and for Meeting Recording with Arkadin).  Universal Voice can only call out to a toll FREE number.  So if you are seeing your Arkadin audio conference not connecting correctly in the Adobe Connect Meeting room, please make sure to check your Arkadin profile that is assigned to the meeting, to make sure the toll free number is actually a toll free number, and the toll number is also correct.  The SIP access number should be set to the toll FREE number as well.

 

XML API Tips: Creating Telephony Profiles Via the XML API

UPDATED – 4-11-2014

The workflow for creating telephony profiles for INTEGRATED telephony providers via the XML API has changed over the last year or so.  Here is an update on the supported method for creating telephony profiles for users using the Adobe Connect Web Services (XML API).

First, you need to find the telephony provider id number (provider-id) that you want to create a profile from.

To do this, you can make the ‘telephony-provider-list‘ API call as follows:

https://{connectURL}/api/xml?action=telephony-provider-list

The results will look like this (with obvious real values for the provider-id and acl-id parameters):

<results>
<status code=”ok”/>
<providers-account>
<provider provider-id=”xxxxxxxxx” acl-id=”xxxxxxxxx” provider-type=”integrated”>
<class-name>
com.macromedia.breeze_ext.premiere.gateway.PTekGateway
</class-name>
<adaptor-id>premiere-adaptor</adaptor-id>
<name>PGi NA</name>
<provider-status>enabled</provider-status>
</provider>
<provider provider-id=”xxxxxxxxx” acl-id=”xxxxxxxxx” provider-type=”integrated”>
<class-name>
com.macromedia.breeze_ext.telephony.Intercall.IntercallTelephonyAdaptor
</class-name>
<adaptor-id>intercall-adaptor</adaptor-id>
<name>InterCall</name>
<provider-status>enabled</provider-status>
</provider>
<provider provider-id=”xxxxxxxxx” acl-id=”xxxxxxxxx” provider-type=”integrated”>
<class-name>
com.meetingone.adobeconnect.MeetingOneAdobeConnectAdaptor
</class-name>
<adaptor-id>meetingone-adaptor</adaptor-id>
<name>MeetingOne</name>
<provider-status>enabled</provider-status>
</provider>
<provider provider-id=”xxxxxxxxx” acl-id=”xxxxxxxxx” provider-type=”integrated”>
<class-name>com.macromedia.breeze_ext.arkadin.ArkadinAdaptor</class-name>
<adaptor-id>arkadin-adaptor</adaptor-id>
<name>Arkadin</name>
<provider-status>enabled</provider-status>
</provider>
</providers-account>
</results>

Next, you take the provider-id from the call above, and make the ‘telephony-profile-update‘ call to create the initial telephony profile container.  The formatted call will look like this:

https://{connectURL}/api/xml?action=telephony-profile-update&principal-id=xxxxxxxxx&profile-status=enabled&provider-id=xxxxxxxxx&profile-name=xxxxxxxx

Where:
principal-id = the principal id of the user for whom you are creating the profile (obtained by other APIs).
profile-status=enabled (to enable the profile).
provider-id = the provider-id value from the first API call above, for which you are creating the profile.
 profile-name =the name of the profile you are creating for the user (it’s up to you for naming convention).

The results will look like this:

<results>
<status code=”ok”/>
<telephony-profile profile-status=”enabled” provider-id=”xxxxxxxxx” principal-id=”xxxxxxxxx” profile-id=”xxxxxxxxx”>
<profile-name>xxxxxxxxx</profile-name>
</telephony-profile>
</results>

Next, you take the applicable provider-id value from the result above, and run the telephony-provider-info API call to get the appropriate fields you would need to add to the profile (and hard code them into your app for future):

https://{connectURL}/api/xml?action=telephony-provider-info&provider-id=xxxxxxxxx

Where:
   provider-id = value from the first call.

The results will look like this (using Arkadin as an example).  What you really want to look for are the ‘telephony-provider-fields’ in the results.  The rest of the provider-dial-in-info can be ignored for the purpose of creating integrated profiles in this fashion.

The results in BLUE are the required ‘x-tel’ values for (in this example) Arkadin, to create a profile.

<results>
<status code=”ok”/>
<telephony-provider-fields>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-arkadin-conference-id” display-in-meeting=”none” required=”true” user-specified=”true” input-type=”text” is-hidden=”false”>
<name>Web login</name>
</field>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-arkadin-moderator-code” display-in-meeting=”hosts” required=”true” user-specified=”true” input-type=”text” is-hidden=”false”>
<name>Moderator pin code</name>
</field>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-arkadin-participant-code” display-in-meeting=”participants” required=”true” user-specified=”false” input-type=”text” is-hidden=”false”>
<name>Participant pin code</name>
</field>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-arkadin-conference-number” display-in-meeting=”none” required=”true” user-specified=”true” input-type=”text” is-hidden=”false”>
<name>Toll access number</name>
</field>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-arkadin-conference-number-free” display-in-meeting=”none” required=”true” user-specified=”true” input-type=”text” is-hidden=”false”>
<name>Toll free access number</name>
</field>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-arkadin-company-url” display-in-meeting=”participants” required=”true” user-specified=”false” input-type=”url” is-hidden=”false”>
<name>Other access numbers</name>
</field>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-arkadin-conference-number-uvline” display-in-meeting=”none” required=”true” user-specified=”true” input-type=”text” is-hidden=”false”>
<name>SIP access number</name>
</field>
</telephony-provider-fields>
</results>

Lastly, now you put everything together.  You take the profile-id that was from the newly created profile as part of the telephony-profile-update API above, and all the applicable ‘x-tel’ values from the telephony-provider-info call directly above, and piece them all together in an acl-field-update call as below (again, this example is for Arkadin):

https://{connectURL}/api/xml?action=acl-field-update&acl-id=xxxxxxxxx&field-id=x-tel-arkadin-conference-id&value=xxxxxxxxx&field-id=x-tel-arkadin-moderator-code&value=xxxxxxxxx&field-id=x-tel-arkadin-participant-code&value=xxxxxxxxx&field-id=x-tel-arkadin-conference-number&value=1-xxx-xxx-xxxx&field-id=x-tel-arkadin-conference-number-free&value=1-xxx-xxx-xxxx&field-id=x-tel-arkadin-conference-number-uvline&value=1-xxx-xxx-xxxx

Where:
 acl-id = the profile id value of the profile you created in the telephony-profile-update call above.
field-id = the x-tel params required by the provider.  As you can see above, for Arkadin, there are 6.
value = the value of the x-tel parameters.  You would get this from your conference provider.

The results will simply be:

<results>
<status code=”ok”/>
</results>

UPDATED – 4-11-2014
For completing an ARKADIN profile, please also add the following to the workflow:
http://blogs.adobe.com/connectsupport/xml-api-tips-arkadin-profile-creation-display-numbers/

For all the main providers on hosted, here are the required ‘x-tel’ values:

Arkadin:

x-tel-arkadin-conference-id
x-tel-arkadin-moderator-code
x-tel-arkadin-participant-code
x-tel-arkadin-conference-number
x-tel-arkadin-conference-number-free
x-tel-arkadin-conference-number-uvline

PGI:

x-tel-premiere-user-id
x-tel-premiere-password
x-tel-premiere-moderator-code

InterCall:

x-tel-intercall-participant-code
x-tel-intercall-leader-pin

MeetingOne:

x-tel-meetingone-conference-id
x-tel-meetingone-host-pin

XML API Tips: Listing Users’ Telephony Profiles

As an Administrator, often times you may want to view other users’ telephony profiles in order to troubleshoot issues or administer additional profiles, etc.  From the UI, there is no way easy way to get at other users’ audio profiles.  From the API perspective, there is one method that often goes unlooked (although it is documented).

The ‘telephony-profile-list‘ API will only show the caller’s telephony profiles unless you actually specify a principal-id in the call.  If you specify the additional ‘principal-id=XXXXXXXX‘ parameter, you will get the list of all that users’ telephony profiles.  You can then obtain the profile-id of a specific profile, and continue to fetch additional information by using the ‘telephony-profile-info’ API call to get all the fields and values you are looking for, for that specific profile.

Here is an example of how to fetch the list of other users’ telephony profiles on the system:

First, log in as an Administrator.

Then find the users’ principal-id you want to search on.

Lastly, run this call to get the list of that users’ telephony profiles:

https://my.adobeconnect.com/api/xml?action=telephony-profile-list&principal-id=12345678

Result:

<results>
<status code=”ok”/>
<telephony-profiles>
<profile profile-id=”123456789″ provider-id=”234567890″ profile-status=”enabled”>
<adaptor-id>arkadin-adaptor</adaptor-id>
<name>Arkadin</name>
<profile-name>My Arkadin Profile</profile-name>
</profile>
<profile profile-id=”987654321″ provider-id=”098765432″ profile-status=”enabled”>
<adaptor-id>intercall-adaptor</adaptor-id>
<name>InterCall</name>
<profile-name>My InterCall Profile</profile-name>
</profile>
</telephony-profiles>
</results>

XML API Tips: Identifying a Sco’s Owner

A common ask from users is how to identify the creator of a content object or meeting, etc. in Adobe Connect.  Sometimes it’s easy to decipher (from an Admin perspective) who ‘owns’ a meeting, by seeing the specific meeting (for example) in a specific user’s ‘User Meeting’ folder.  However that doesn’t necessarily mean that they ‘created’ the meeting.  Also, if a meeting is sitting in the Shared Meetings area, and you want to know who created the meeting initially, it wouldn’t be possible (via the UI).  In order to see who created the object or meeting, you can use the ‘sco-by-url’ API call.  Here’s how:

As an Administrator, log in and find the URL of the meeting or sco in question.

Then, formulate the web service call as such:

https://{connectDomain}/api/xml?action=sco-by-url&url-path=XXXXXXX

Where the url-path = the actual custom (or auto generated) url path of your meeting or content.  The format will look like this: ‘/myMeeting/’.

Here’s an example:

Call:

https://my.adobeconnect.com/api/xml?action=sco-by-url&url-path=/jimssharedmeeting/

Result:

<results>
<status code=”ok”/>
<owner-principal type=”content” principal-id=”12345678″ account-id=”87654321″ has-children=”false” is-hidden=”false” is-primary=”false” tos-status=””>
<ext-login>jimjohnson@mycompany.com</ext-login>
<login>jimjohnson@mycompany.com</login>
<name>Jim Johnson</name>
<email>jimjohnson@mycompany.com</email>
</owner-principal>
<sco sco-id=”123456789″ account-id=”87654321″ display-seq=”0″ folder-id=”12345678″ icon=”meeting” lang=”en” max-retries=”” source-sco-id=”98765432″ type=”meeting” version=”0″>
<url-path>/jimssharedmeeting/</url-path>
<date-begin>2014-03-31T09:00:00.000-04:00</date-begin>
<date-created>2014-03-31T09:10:12.220-04:00</date-created>
<date-end>2014-03-31T10:00:00.000-04:00</date-end>
<date-modified>2014-03-31T09:10:12.220-04:00</date-modified>
<name>Jim’s Shared Meeting</name>
</sco>
</results>

LDAP Sync Log File Access

Scenario: You may be an Adobe Connect Administrator and want to access the LDAP sync logs to see who has been (via an LDAP sync) brought into Adobe Connect, removed from Adobe Connect, or has been added or removed from a group membership, and when.  The problem is that these logs are only accessible for the most part, on the server itself by a server admin who can log into the Configuration Console on the localhost and access them manually via the Directory Service area of the console.  This is not accessible from outside of the actual Connect server.

The solution is to use the API to find all the LDAP sync logs on the system (which are actually treated as content) and access them with just an Administrator username and password to the system.  Here’s how:

1) Log into the Adobe Connect interface as user with Administrator priviledges.
2) Assuming your Licensed account-id has not been changed, it will be ‘7’ so you can make the following API call:

http://{serverURL}/api/xml?action=sco-expanded-contents&sco-id=7&filter-icon=logos

Where 7 is the account ID and you filter on ‘icon=logos’ (not sure why)…

Result will look like this (example response):

<results>
<status code=”ok”/>
<expanded-scos>
<sco depth=”2″ sco-id=”12345” folder-id=”11005″ type=”content” icon=”logos” lang=”en” source-sco-id=”” display-seq=”0″ source-sco-type=”” source-sco-icon=”” content-source-sco-icon=”” duration=””>
<name>{ds-sync}</name>
<url-path>/p5u78ftvvsi/</url-path>
<date-created>2013-10-29T20:10:17.660-04:00</date-created>
<date-modified>2014-01-14T21:42:27.150-05:00</date-modified>
</sco>
</expanded-scos>
</results>

The name of the item should be {ds-sync} (short for Directory Service Synchronization).

3) Then use the following call to get all sync logs under that folder:

http://{serverURL}/api/xml?action=sco-expanded-contents&sco-id=12345

Where the sco-id is the one from the first call and will be the sco-id of the sync folder (so yours will be different than my example of 12345)

It will list all sync logs with their scos (like below).

They all have a name format of: {sync-sco-preview} + the date.
They all have an icon=archive

4) Look for the one you want, and then navigate to the file via the URL (value in RED in the response below).

Example response:

<results>
<status code=”ok”/>
<expanded-scos>
<sco depth=”0″ sco-id=”12345″ folder-id=”11005″ type=”content” icon=”logos” lang=”en” source-sco-id=”” display-seq=”0″ source-sco-type=”” source-sco-icon=”” content-source-sco-icon=”” duration=””>
<name>{ds-sync}</name>
<url-path>/p5u78ftvvsi/</url-path>
<date-created>2013-10-29T20:10:17.660-04:00</date-created>
<date-modified>2014-01-14T21:42:27.150-05:00</date-modified>
</sco>
<sco depth=”1″ sco-id=”26150″ folder-id=”12345″ type=”content” icon=”archive” lang=”en” source-sco-id=”” display-seq=”0″ source-sco-type=”” source-sco-icon=”” content-source-sco-icon=”” duration=””>
<name>{sync-sco-preview} [2014-01-14 18:23:35.47]</name>
<url-path>/p26150/</url-path>
<date-created>2014-01-14T21:23:35.470-05:00</date-created>
<date-modified>2014-01-14T21:23:35.470-05:00</date-modified>
</sco>
<sco depth=”1″ sco-id=”26017″ folder-id=”12345″ type=”content” icon=”archive” lang=”en” source-sco-id=”” display-seq=”0″ source-sco-type=”” source-sco-icon=”” content-source-sco-icon=”” duration=””>
<name>{sync-sco-preview} [2014-01-14 06:37:23.88]</name>
<url-path>/p26017/</url-path>
<date-created>2014-01-14T09:37:23.880-05:00</date-created>
<date-modified>2014-01-14T09:37:23.880-05:00</date-modified>
</sco>
…….
</expanded-scos>
</results>

 

XML API Tips: Obtaining Quotas for Seminar Licenses

A while back I blogged about how to create a Seminar Session via the XML API in Adobe Connect 9.1 (view original blog here).  A question has since come up around how to obtain the quota for a Seminar License, so you know what to put in for the seminar-expected-load value in the acl-field-update call in the last step of that article.

You can obtain the Seminar License quotas for your different licenses by running this API call:

https://{myConnectURL}/api/xml?action=sco-seminar-licenses-list&sco-id=XXXXXXX

where sco-id = the sco-id of the SHARED SEMINARS folder (or the ‘seminars’ tree-id of the shortcut ‘seminars’).

Example Result (showing an example where there are 2 Licenses):

<results>
<status code=”ok”/>
<seminar-licenses>
<sco>
<begindate>2011-12-02T01:00:01.000+00:00</begindate>
<date-begin>2011-12-01T20:00:01.000-05:00</date-begin>
<date-created>2011-12-02T23:47:02.353-05:00</date-created>
<date-end>2016-12-01T19:59:59.000-05:00</date-end>
<date-modified>2013-11-29T10:53:56.590-05:00</date-modified>
<display-seq>0</display-seq>
<duration>XXXXXXXX</duration>
<enddate>2016-12-02T00:59:59.000+00:00</enddate>
<folder-id>XXXXXXXX</folder-id>
<icon>folder</icon>
<is-expired>false</is-expired>
<is-folder>1</is-folder>
<is-seminar>false</is-seminar>
<name>My Seminar License 1</name>
<quota>1000</quota>
<sco-id>XXXXXXXX</sco-id>
<type>folder</type>
<url-path>/fXXXXXXXX/</url-path>
</sco>
<sco>
<begindate>2011-12-02T01:00:01.000+00:00</begindate>
<date-begin>2011-12-01T20:00:01.000-05:00</date-begin>
<date-created>2011-12-02T23:47:04.490-05:00</date-created>
<date-end>2016-12-01T19:59:59.000-05:00</date-end>
<date-modified>2013-11-29T10:54:04.010-05:00</date-modified>
<display-seq>0</display-seq>
<duration>XXXXXXXX</duration>
<enddate>2016-12-02T00:59:59.000+00:00</enddate>
<folder-id>XXXXXXXX</folder-id>
<icon>folder</icon>
<is-expired>false</is-expired>
<is-folder>1</is-folder>
<is-seminar>false</is-seminar>
<name>My Seminar License 2</name>
<quota>1500</quota>
<sco-id>XXXXXXXX</sco-id>
<type>folder</type>
<url-path>/XXXXXXXX/</url-path>
</sco>
</seminar-licenses>
</results>

Again, there are multiple ways of getting the id of the main Seminars folder.  One quick one is :

https://{myConnectURL}/api/xml?action=sco-shortcuts

and pull the value from either in blue (the will both be the same):

<sco tree-id=”XXXXXXX” sco-id=”XXXXXXX” type=”seminars”>
<domain-name>http://{myConnectURL}</domain-name>
</sco>

Another is:

https://{myConnectURL}/api/xml?action=sco-expanded-contents&sco-id=XXXXXXXX&filter-type=tree

where the sco-id is = the account-id

and pull the value in blue:

<sco depth=”1″ sco-id=”XXXXXXX” folder-id=”XXXXXX” type=”tree” icon=”folder” lang=”en” source-sco-id=”” display-seq=”0″ source-sco-type=”” source-sco-icon=”” content-source-sco-icon=”” duration=””>
<name>Shared Seminars</name>
<url-path>/XXXXXXX/</url-path>
<date-created>2011-12-02T23:46:53.563-05:00</date-created>
<date-modified>2013-11-29T10:54:03.053-05:00</date-modified>
</sco>

Using the XML API with Enhanced Security

With the release of Adobe Connect 9.0.4 and beyond (view KB here), we have introduced the Enhanced Security feature (documentation) and it is ON by default on our hosted system.  If you are an Adobe Connect Hosted customer, you can toggle the Enhanced Security feature on or off (if you are an Administrator) by logging into your Adobe Connect Hosted account and navigating to: Administration > More Settings.  You will see the following Security Settings:

es

 

If you have ‘Enable Enhanced Security’ checked (and you save the settings), your account will now issue TWO session cookies to a user when they authenticate.  This is crucial to understand and plan for if you are using the XML API to integrate with another system.  Also, if you are a partner or developer who has built an application that integrates with Adobe Connect, you will need to rework your application to account for the possibility of this feature being ON or OFF.

From my experience, it is best to simply code the application to look for the second session cookie all the time (after initially authenticating the user) rather than try to check for the feature being on or off.

Typically in Adobe Connect Hosted accounts before this feature was implemented (and with this setting OFF), your application would first make a ‘common-info’ call as below, to obtain a session cookie before logging a user in:

https://myaccountURL/api/xml?action=common-info

<results>
<status code=”ok”/>
<common locale=”en” time-zone-id=”35″ time-zone-java-id=”US/Eastern”>
<cookie>naXbreezecookie123456789</cookie>
<date>2013-12-02T19:50:38.983-05:00</date>
<host>https://myaccountURL</host>
<local-host>connecthost01</local-host>
<admin-host>naXcps.adobeconnect.com</admin-host>
<url>/api/xml?action=common-info</url>
<version>9.1.2</version>
<tos-version>7.5</tos-version>
<product-notification>true</product-notification>
<account account-id=”12345678″/>
<user user-id=”45678901″ type=”user”>
<name>Jim Johnson</name>
<login>Jim</login>
</user>
<user-agent>
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
</user-agent>
<mobile-app-package>air.com.adobe.connectpro</mobile-app-package>
</common>
<reg-user>
<is-reg-user>false</is-reg-user>
</reg-user>
</results>

Then you would log the user in:

https://myaccountURL/api/xml?action=login&login=Jim&password=XXXXXXX&session=naXbreezecookie123456789

<results>
<status code=”ok”/>
</results>

That would normally be it.

Then, all subsequent calls, you would normally just append that same session cookie as the ‘session’ parameter and you’d be all set.  However, with Enhanced Security ON, that session cookie you obtained from the first common-info call will NOT work in calls after the login call authenticates the user.  Once the login API is called, you MUST call common-info one more time immediately after the OK response comes back from the login call.  When you run common-info again, you will notice you will get a DIFFERENT session cookie value.  That second cookie value is the session you need to include in your subsequent calls going forward.  If you do not use that second value in your API call, and instead include the value from the first common-info call result, you will get the following error response:

<results>
<status code=”no-access” subcode=”no-login“/>
</results>

So in summary:

Before Enhanced Security the workflow was:

1) common-info API to get cookie session value
2) login API using the cookie session value
3) continue on making API calls with that same session cookie throughout the user session

After Enhanced Security (post 9.0.4):

1) common-info API to get cookie session value
2) login API using the cookie session value
3) common-info API again a second time to get the final cookie session value to use going forward in all other calls
4) continue on making API calls with that NEW session cookie throughout the user session

Again, it is best to code your application to always look for a session cookie again AFTER logging a user in.  That way, even if you are still using the same session (say if the account had Enhanced Security set to OFF), your application will still work fine and in the cases where the account does have Enhanced Security turned ON, it will still continue to work as expected.