Going to cause a lot of pain for developers. There's already a SugarHttpClient or some such but it had a lot of limitations, too. This solidifies my conclusion that all integrations of a certain size should just be handled in a middleware, either some off-the-shelf ETL or a fully bespoke microservice, the latter being my preference. No rules, just treat Sugar and other systems as untrustworthy targets and build in proper error handling, retries, credential handling, etc. Not always an option, but when it is it's a winner.
This is bad. It means that I cannot update any existing packages using curl without rewriting those packages. Clients are not going to like that.
Deprecations need to be sent out well ahead of time so it can be communicated to the client and they can be asked how they would like to handle it. Maybe this one was, but we need a more direct communication path rather than the SugarCRM log file like was done with the recently deprecated "link_file".
Sorry for being late to the party. I definitely agree with Matthew and John. I've been updating some of my SugarOutfitters products and the documentation is so lacking I'm having a bit of trouble doing it.
There are already other libraries that could have been used in preference and to really even investigate I needed to setup a 12.1 instance. Would have been nice if at least we would have had a version or two with the new library first. Really frustrating and seems this one was really mishandled.
Going to cause a lot of pain for developers. There's already a SugarHttpClient or some such but it had a lot of limitations, too. This solidifies my conclusion that all integrations of a certain size should just be handled in a middleware, either some off-the-shelf ETL or a fully bespoke microservice, the latter being my preference. No rules, just treat Sugar and other systems as untrustworthy targets and build in proper error handling, retries, credential handling, etc. Not always an option, but when it is it's a winner.
This is bad. It means that I cannot update any existing packages using curl without rewriting those packages. Clients are not going to like that.
Deprecations need to be sent out well ahead of time so it can be communicated to the client and they can be asked how they would like to handle it. Maybe this one was, but we need a more direct communication path rather than the SugarCRM log file like was done with the recently deprecated "link_file".
Sorry for being late to the party. I definitely agree with Matthew and John. I've been updating some of my SugarOutfitters products and the documentation is so lacking I'm having a bit of trouble doing it.
There are already other libraries that could have been used in preference and to really even investigate I needed to setup a 12.1 instance. Would have been nice if at least we would have had a version or two with the new library first. Really frustrating and seems this one was really mishandled.