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.
Tengo un Mac Air, Yosemite. Hay algo que deba hacer? No entiendo, por favor explíqueme ¿qué es lo que debo cambiar y cómo? gracias
Hi Susana,
You shouldn’t have to worry about anything. This is only for developers to check their code in the case they use the XML API. For normal Adobe Connect usage, you shouldn’t have anything to worry about.
Will this have an impact on the URLs for Adobe Connect recorded sessions? I checked the “Using Adobe Connect 9” manual and I do not believe so. But I wanted to confirm that, thank you.
Hi John,
This won’t impact URLs at all. This is purely for IDs like ‘sco-id’s’, ‘principal-id’s’, etc. Developers of applications that use the XML API (Web Services) are the only ones that simply need to look at their code and change any type values from INT to BIGINT. If you aren’t an API developer, you do not need to worry about anything and won’t notice a thing.
Thank you for your notice.
However, you are speaking complete technical terms that I cannot understand. It would be helpful to receive instructions in layman’s terms.
What does it mean for me and my team, users of Adobe Connect?
What do we need to do differently?
Thank you,
Anne-Lucie
NAV CANADA
Hi Anne-Lucie,
As per some of the other comment responses on here… here’s an updated ‘canned’ response I need to use as there are a lot of people asking….hopefully it helps….
Think about it like this… everything in Connect gets a numeric ID. Users get a ‘principal-id’… meetings, training courses, curricula, events, seminars, virtual classrooms, folders, content (ppt, jpeg, mp3, swf, etc), etc. all get ‘sco-ids’…etc. Those are the IDs we are talking about.
Now, the change really only affects customers who use the XML API (web services) in custom applications they have built and integrated with Connect. If you do not use the XML API to do any custom development, you won’t need to worry about this. The IDs and everything else will continue to work as it always did. If you DO use the XML API in any custom application / integration you have developed (say to do custom reporting, custom provisioning of content, etc) you do need to make sure you make the change specified in the article. When developers build applications and deal with the Connect IDs that get returned as part of queries, etc. they will sometimes cast them as ‘integers’ (INT). If that is the case, once we make the change to ‘BIGINT’ as per the article, they will have to go back through their own code and change the type from INT to BIGINT in their custom application. Otherwise, they will have a problem as per the article.
So in summary, if you are not personally working on a custom application (say built in Java or Flex, etc) then you don’t need to worry about this. Normal Connect usage (out of the box) doesn’t change at all. This is just for custom development that uses the XML API.
We are not actually using the API directly as far as I know. are there any embedded API commands or statements that might affect us?
Hi Alex,
The in-product code and APIs on our end (in the product) are all going to be fine. If you aren’t using the the API explicitly in an application where you have your own code that you or your team has built an application on, that casts values as INT instead of BIGINT, you won’t have to worry. This doesn’t affect simply running APIs in a browser, etc. It only affects the code of custom built applications. Your use case seems like it won’t be affected at all.
Hello Support,
We simply use Adobe Connect for virtual interviews and training modules. Will this update impact our current usage? Thank you.
Hi John,
It won’t. The only way this will affect you is if you are using some third party or home-grown tool/interface/dashboard, etc. that was built by a developer that integrates somehow with Adobe Connect. If so, they’d have to make sure they audit their code to see if they need to make changes. If you don’t, and only use Adobe Connect out of the box (the Connect interface) with no custom integration anywhere else, then you don’t need to do anything.
This is Greek to me. I am simply trying to teach a class with Adobe Connect. Who do I contact to get “how to” information that helps a subscriber?
Frank, you should be all set. This article is really geared towards API developers. Just like any time I blog about an API tip/trick. That isn’t always geared towards everyone. Just the people who use the API. You should be all set.
I have no idea what this means! Can you please explain these terms? I do not understand what API’s are or changing them to be ID Values…
Please advise….
Hi Heather, I have put an explanation on some other comments on here. If you are an API developer, you’d need to audit your code of any custom application you may have built, to make sure you make the right change. If you are just a ‘normal’ Connect user, you won’t have to worry about a thing. This is really only for developers using the XML API with Adobe Connect. I you aren’t sure what that even is, you don’t have to worry about the change :).
Not being programming literate, nor ITs, what does all this mean for standard users?
How will this affect the video, audio and sharing features?
How will this affect the data previously saved under earlier version of Adobe Connect?
We are about to renew our yearly service with Adobe Connect and need to understand so we can consider prior to renewal.
Thank you for your support.
Jacques Lorin
A/C: qchallenge@qchallenge.com
Hi Jacques,
This only affects developers using the API. For video, audio, sharing, etc. No issues. It doesn’t affect product usage at all. If you are just simply doing all your work directly with Adobe Connect’s interface, you are fine. This is only if you have built or are using a custom built application that integrates with Adobe Connect. This won’t affect any Connect data, etc. Renewal should be as smooth as always. This isn’t even an Adobe product issue. This is an issue with custom customer code if customers have built custom applications. We are just telling them they may have to look at their custom code to make the appropriate change. For normal Connect users, this is a non issue.
Hi,
Unfortunately your message is totally impossible to understand for anyone who is not familiar with the technical terms you use. I can’t see if this message important or not. Please rewrite it in a simpler way if you need me and others to understand!
Thanks!
/Filippa
Examples of tech-terms:
– ID values
– INT
– BIGINT/Long.
– APIs
– parameter in request/response
– sco-id, account-id, folder-id
– integers
– values might overflow
– strings
– integral data type with higher capacity
Hi Filippa,
I have a canned statement I think will help…I’ve pasted it in here for a few other comments…
Think about it like this… everything in Connect gets a numeric ID. Users get a ‘principal-id’… meetings, training courses, curricula, events, seminars, virtual classrooms, folders, content (ppt, jpeg, mp3, swf, etc), etc. all get ‘sco-ids’…etc. Those are the IDs we are talking about.
Now, the change really only affects customers who use the XML API (web services) in custom applications they have built and integrated with Connect. If you do not use the XML API to do any custom development, you won’t need to worry about this. The IDs and everything else will continue to work as it always did. If you DO use the XML API in any custom application / integration you have developed (say to do custom reporting, custom provisioning of content, etc) you do need to make sure you make the change specified in the article. When developers build applications and deal with the Connect IDs that get returned as part of queries, etc. they will sometimes cast them as ‘integers’ (INT). If that is the case, once we make the change to ‘BIGINT’ as per the article, they will have to go back through their own code and change the type from INT to BIGINT in their custom application. Otherwise, they will have a problem as per the article.
So in summary, if you are not personally working on a custom application (say built in Java or Flex, etc) then you don’t need to worry about this. Normal Connect usage (out of the box) doesn’t change at all. This is just for custom development that uses the XML API.
How will his affect VLS interfaces to LMS?
Hi Mike,
This will affect possibly (but not definitively) any integration to Adobe Connect where custom code was written in either an adaptor for an LMS system or a custom interface/portal like SuccessFactors, etc. Developers need to audit their code to make sure that if they have cast any IDs as INT (integer) like our old documentation used to call for, they need to change it to BIGINT. So depending on the integration to LMS systems, changes would need to be made. Does this answer the question? We have reached out to many of our main integrating partners to make sure they know these changes were going to be made.
Can you please give the explanation in non-technical descriptions? I have no idea what I have to do where.
Thanks, Irma
Hi Irma,
Sure. If you scroll up (or down)…not sure which..You will see some other responses I’ve given where this really should only be applicable for developers. For normal Connect users or anyone else who may not understand the context of the blog article, it won’t be applicable. Developers will know exactly what this all means.
You assume that tech people are reading this and therefor understand everything you write. My husband and I use adobeconnect for our business and simply need webinar service. I have NO IDEA what all this jargon means–no idea if I need to do something. The amount of time I need to invest in figuring it all out is too much right now, I simply do not have the time. Please keep in mind, there are non-techies using your services who have no idea what the tech jargon is or what it means.
Hi Kelli, like anything else on this blog, not everything is geared towards all users. Certainly anything ‘XML API’ related that I blog (which is most of what I write about) or LDAP integration, etc. is not going to be applicable to all users. Just like anything dealing with the Training module is not going to be applicable to Meeting users who don’t use Training. If you are not sure what the article was describing, I’m confident you won’t have to worry about the change. It is really meant for developers. Our developers who write custom applications, will know what changes need to be made, based on the description. If you are only using Connect for the meetings/webinars, you are fine and won’t notice any changes. This became a confusing article to a lot of folks who aren’t familiar with the API. It should have been prefaced with ‘This is only for Developers’ or something similar. Apologies for the confusion.
None of the above makes any sense to me. All we use Adobe connect for is to set up meetings by conference calls. Does this affect us in any way?
Ria, you should be fine. If you aren’t an API developer, you won’t have to worry about anything. You will see a lot of other people commenting on the same confusion.
Could you please make this a little more user-friendly? It really isn’t clear what this means, and what if anything I have to do as an end user.
Hi there, please feel free to read the now numerous comments below/above :). It should make it a little clearer. Apologies for the confusion. You shouldn’t have to worry about.
What does this mean for platform uploads? Will this affect the connection with linked phone lines?
Hi Meredith,
The only thing this will affect (if I am understanding your question correctly) with uploads is if you actually use a custom built uploader and you have a custom application that does the API call for sco-upload on a sco-id that you’ve cast as an INT. You’d have to cast as BIGINT in your code. If you are not doing this and just using Adobe Connect to upload files (so using the in-product functionality) you won’t have to even worry about this. Also, this affects nothing around telephony integration, etc.
From a guy who uses the tool, but doesn’t understand how it really works…..How can I determine if our account will be affected by the change of ID’s from INT to BIGINT? I can’t find any reference to this in our agreement/account summary. Thanks for your assistance!
Hi Greg, as you can probably tell there’s been a lot of folks asking the same questions on here. If you aren’t using the API at all with any custom built application you may have coded, you don’t have to worry about this. This is really only for developers. If you are just using Adobe Connect as-is without anything custom that is integrated from say another company, then you are fine. The INT/ BIGINT change is made in custom code on the customer side. Our product isn’t changing at all. And not every custom application would need to change. Only ones that use INT. If you are just using 100% Adobe Connect and all the in-product functionality, etc. you don’t have to even worry about this.
I have no idea what the above means. Would someone please respond to me in plain English and let me know if the PowerPoint webinars we house with Adobe Connect will be affected and if so, what we can do about it.
Hi Mike,
No worries on the Powerpoint uploads/shares and meetings. This only relates to custom applications built using the web services / XML API we offer. If you don’t know what that is, you won’t have to worry about this change.
Sorry but I have no idea how this impacts me or what actions I need to take. Really , as a user, am I supposed to understand the language you have used above. I do not. I hope that when Connect 9.5.2 is released in first quarter that it will come with language a simple lay person, user can understand.
Thanks
Paula Hawkins
Hi Paula, only developers will need to worry about this. Developers who write code for applications that some customers may use to integrate with different parts of Adobe Connect will need to audit their own code to see if they need to make a change. For you, you shouldn’t have to worry about anything at all. I actually work closely with DHS (multiple accounts) and know the use case for the deployments. You shouldn’t have to worry about anything in your day to day usage of Connect. If you are interested, in some of the other comments below, I have expanded on the explanation.
English please. I have no idea what you’re talking about, even though I’ve been using Adobe Connect for teaching purposes for the past two years. Can someone please explain to me what if anything I need to do in a manner that a non-technical person can understand?
Glenn Perry
Hi Glenn… here’s an updated ‘canned’ response I need to use as there are a lot of people asking….hopefully it helps….
Think about it like this… everything in Connect gets a numeric ID. Users get a ‘principal-id’… meetings, training courses, curricula, events, seminars, virtual classrooms, folders, content (ppt, jpeg, mp3, swf, etc), etc. all get ‘sco-ids’…etc. Those are the IDs we are talking about.
Now, the change really only affects customers who use the XML API (web services) in custom applications they have built and integrated with Connect. If you do not use the XML API to do any custom development, you won’t need to worry about this. The IDs and everything else will continue to work as it always did. If you DO use the XML API in any custom application / integration you have developed (say to do custom reporting, custom provisioning of content, etc) you do need to make sure you make the change specified in the article. When developers build applications and deal with the Connect IDs that get returned as part of queries, etc. they will sometimes cast them as ‘integers’ (INT). If that is the case, once we make the change to ‘BIGINT’ as per the article, they will have to go back through their own code and change the type from INT to BIGINT in their custom application. Otherwise, they will have a problem as per the article.
So in summary, if you are not personally working on a custom application (say built in Java or Flex, etc) then you don’t need to worry about this. Normal Connect usage (out of the box) doesn’t change at all. This is just for custom development that uses the XML API.
I am a regular user of Adobe Connect, and I have no idea what this tells me. Can this be explained in lay person language? A specific example would be really helpful. Are you referring to how we name uploaded content, or the Adobe assigned URL’s for recordings, or something else entirely?
~ Joan
Hi Joan,
Think about it like this… everything in Connect gets a numeric ID. Users get a ‘principal-id’… meetings, training courses, curricula, events, seminars, virtual classrooms, folders, content (ppt, jpeg, mp3, swf, etc), etc. all get ‘sco-ids’…etc. Those are the IDs we are talking about.
Now, the change really only affects customers who use the XML API (web services) in custom applications they have built and integrated with Connect. If you do not use the XML API to do any custom development, you won’t need to worry about this. The IDs and everything else will continue to work as it always did. If you DO use the XML API in any custom application / integration you have developed (say to do custom reporting, custom provisioning of content, etc) you do need to make sure you make the change specified in the article. When developers build applications and deal with the Connect IDs that get returned as part of queries, etc. they will sometimes cast them as ‘integers’ (INT). If that is the case, once we make the change to ‘BIGINT’ as per the article, they will have to go back through their own code and change the type from INT to BIGINT in their custom application. Otherwise, they will have a problem as per the article.
So in summary, if you are not personally working on a custom application (say built in Java or Flex, etc) then you don’t need to worry about this. Normal Connect usage (out of the box) doesn’t change at all. This is just for custom development that uses the XML API.