Author Archive: Jim Johnson

Update – CSO – DATE (11 JULY 2014) – Universal Voice Not Connecting for Certain Clusters

11:40am EST – Universal Voice is currently down for customers on the following clusters: (NA1, NA2, NA6, NA8, NA9, NA12).  This affects the ‘audio broadcast’ functionality in Adobe Connect Meeting rooms on those clusters.  This also affects ‘user-configured’ (non-integrated) telephony profiles on those clusters.  Meetings that utilize ‘UV Profiles’ (user-configured) will not have audio.  Meetings that use the ‘integrated’ telephony profiles (telephony adaptors for InterCall, MeetingOne, Arkadin, and PGI) will still have audio, but the ‘broadcast’ will not work.  We are currently working with our Operations team to resolve the issue. You can get full updates on our Adobe Connect Status Page here: https://status.acrobat.com

4:30pm EST - We have identified the issue and applied a fix for the Universal Voice issues that have occurred today in our EQX (SJ1) datacenter.  This was a configuration issue outside of the application that affected the integration with our SIP service.  The team has deployed the necessary changes and done appropriate testing to ensure the system is now stable.

 

Testbuilder Status’ Explained

When setting up an application-level health monitor (blog) on your LTM, you would point to the testbuilder diagnostic page at:

/servlet/testbuilder

As the previous article explains, ‘the testbuilder page will send back the “status-ok” string.  If there is any problem with the Connect server application, then testbuilder will not report the “status-ok” string’.  Expanding on this a little bit, the following (below) are the actual status’ and possible scenarios you may see:

STATUS_OK = 0;
STATUS_CRITICAL = 2;
STATUS_MAINT = 3;
STATUS_TEST = 4;

 

STATUS_OK = 0;
This means the server is fit to work (status-ok). Server status in PPS_ENUM_DATA_HOST table is neither ‘X’, ‘M’ nor ‘T’ and server is initialized.
This is what load balancers should look for health check.

STATUS_CRITICAL = 2;
Server is not fit to work (status-critical). Server is not yet initialized (during start up), or has server status of ‘X’ in PPS_ENUM_DATA_HOST table.
This is also triggered if no connection to database can be made.

STATUS_MAINT = 3;
Server is in maintenance mode (status-maintenance). Has server status of ‘M’ in PPS_ENUM_DATA_HOST table.
Active server can be put to maintenance mode and vice versa.  No new meetings will be run on this server, but currently active meetings will run until ended.

STATUS_TEST = 4;
Server is in “server isolation” mode (status-testing). Has server status of ‘T’ in PPS_ENUM_DATA_HOST table.
Used to put server in separate zone from other servers in cluster. This is hosted feature that is not actively used in production.

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.

Connect Reports Never Returning Data in Firefox

reports
The Adobe Connect Reports module is Flex based and for longer queries (reports on courses or curricula with large enrollments for example), sometimes the report can take many minutes to return data back to the browser.  Previously we have worked on issues with the reporting module in which the busy cursor (spinning wheel) continues to spin indefinitely and doesn’t return data because the query took too long to return.  We have made adjustments to the DB views and code to fix the performance of the reports in the latest versions of Adobe Connect and up until recently, we had solved this problem for users running the latest versions of the application.

However recently we have seen with newer versions of the Firefox web browser, the reports once again spin indefinitely and not return data in the Flex based reports in some instances where the queries are large.  Investigation into this lead us to determine that after a period of 5 minutes, we saw a socket write error in the debug log like the one below:

[05-29 10:15:30,623] http-80-15 (INFO) Exception caught in Rows.parse(), e= org.xml.sax.SAXException

ClientAbortException:  java.net.SocketException: Software caused connection abort: socket write error

After changing various FireFox timeout settings to no avail, we noticed the following newer setting ‘network.http.response.timeout’, which was introduced in Firefox 29 (the current version is 30). The default value for this timeout is 300 seconds (5 minutes).  In previous versions there was no default value.

After changing it to a longer value, the reporting now works in our testing. With the current implementation of the reporting module, there is no way for Flex to detect that the http response has timed out. Until we can address this in the Flex code and provide a warning, we just have to be mindful of this setting in FireFox.

To change this setting, you simply type this in the Firefox browser address bar: about:config and hit enter.

You will see a page with all of the configurable settings.  Search for ‘network.http.response.timeout‘ to isolate just the one setting you need to change (there are a lot of settings to scroll through otherwise).  The default value is 300 seconds (5 minutes).  If you are running into the situation where your reports are not coming back with data (and you are running the latest version of Adobe Connect , 9.2 and above), you can adjust this setting to see if it helps (if you are using Firefox as a browser).  If you anticipate users having to run large queries (like curriculum reports with large enrollments in the 1000s of users), you will need to adjust this setting.

ffsetting1

Type ‘about:config’ in the address bar. Then search for ‘network.http.response.timeout’

ffsetting2

Modify the value by clicking on the 300 value itself and then entering the new value when prompted.

 

 

Adobe Connect 9.2.2 Patch Now Available

The Adobe Connect 9.2.2 On Premise (Licensed) patch is now available for download at:

http://helpx.adobe.com/adobe-connect/kb/connect-90-patches.html

This download includes deployment instructions. It is intended for installation on Adobe Connect servers already running 9.2, as this is a patch (not a full install).

 

 

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.

 

DB_PING_TIMEOUT Value Change

Recently we have discovered that a newer setting for on-premise (licensed) Adobe Connect servers may lead to a memory leak on the system in certain rare circumstances.  Here is some history and recommendations in case you believe you may be running into a memory leak problem in your Adobe Connect licensed environment and you are running a version newer than 9.0.3.

The DB_PING_TIMEOUT value was introduced back in Connect 7 (2008 timeframe).  It enables invalidated DB connections to be recognized quickly. In the absence of a reasonable value for this timeout, we have had instances in the past where critical CPS threads (e.g. the scheduler sweeper thread) have waited on a stale DB connection for too long, causing fastfails. This value had since always been set to ’0′ which means there is no time out.  Since the default host health check time out value is 40 seconds, it is recommended that the DB_PING_TIMEOUT default value be set to 30 seconds, so that it is under the limit that causes potential server fast-fails. This was a fairly minor change in the config.ini, where the DB_PING_TIMEOUT value was changed from 0 to 30.  This was done at the Connect 9.0.3 version.  So every version above 9.0.3 will have the default set to 30.  [Important note - this value is in seconds, not milliseconds]

Recent longevity tests in version 9.2 suggested that this might be triggering a memory leak in the driver. The going theory for why that behavior wasn’t seen in previous longevity tests (between 9.0.3 and 9.2) is that we only upgraded to JRE 7 in 9.2. So the setting we were running with previously suddenly seemed to be a problem once we also upgraded to 1.7.

That value of 30 was introduced for a reason, so we don’t suggest turning it off without knowing that it causes a problem. On the Adobe hosted clusters, we have made the decision to do so since there were signs of memory issues even previously and we didn’t want to compound that.

That said, there are known issues with our driver and JRE 1.7, but only under some circumstances. In the case of Adobe Connect system administrators observing  (continuous) increases in heap memory usage, this parameter value should be set back to 0.

This can be done by changing this value either in the config.ini  from 30 to 0 (DB_PING_TIMEOUT=0)  or by adding this value in the custom.ini (it won’t be there by default, but if you add it, it will take precedence over what is in the config.ini)

 

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