Adobe Connect IDs are changing from INT to BIGINT
[Update: 12/12/2017] This is an update to the below blog post originally published on 11/25/2015. It is intended only for XML API developers that create custom integrations and should not be a concern to regular Adobe Connect users. When we released Adobe Connect 9.5.2 in our Hosted environment at the beginning of 2016, we started migrating certain Hosted accounts from INT to BIGINT/Long, as described in the article below (which has remained unedited and still valid other than this update). We have completed some migrations over the course of the last couple of years, and now at Adobe Connect version 9.7, we are continuing to migrate Adobe Connect Hosted accounts. This notice is intended to be another communication out to our API developers and integration partners to make sure they have made the necessary changes in their integration code to account for these changes that will continue to be made across our Hosted Adobe Connect environments this coming year.
NOTE: THIS ARTICLE IS FOR XML API DEVELOPERS ONLY. If you are not using the XML API with Adobe Connect to write your own custom built applications that integrate with Adobe Connect, please do not worry about the message below as it will not apply to you.
Due to the growing popularity of Adobe Connect, more and more customers rely on Adobe Connect for their collaboration needs and this naturally requires that we make adjustments to accommodate the growth. We want to make you aware of an upcoming adjustment to the ID values in Adobe Connect databases to support longer values which will accommodate growing customer use of Adobe Connect.
What is being changed?
Starting with release 9.5.2, Adobe Connect will migrate the ID values in Connect databases from INT to BIGINT/Long.
What is the impact?
This change will impact any applications using Adobe Connect Web Service APIs.
How will Adobe Connect Web Service APIs be affected?
The change is for those APIs which consume/return id values i.e. which have a parameter in request/response which is an Id. (examples: sco-id, account-id, folder-id, etc). The id fields in such APIs would return/accept larger values. The support and behavior of existing APIs remains same.
What does this mean for you?
In case you are interpreting ids as integers the new values might overflow. We strongly recommend using strings to represent id values. In case you still need to represent/store ids as a numeral please use integral data type with higher capacity. (Preferably 64 bit)
What is the timing?
We expect to release Connect 9.5.2 in the first quarter of 2016, so the change should be made as soon as possible in order to be ready prior to the release.