@John_Borelli please suggest more on this.
Ok so you’re dealing with a compound issue. It’s fine to set your origin to a character set but the values that identify those characters will represent different characters at the destination. You would see this if you saved, say an excel sheet with one character set, and then I viewed it with my own settings…they wouldn’t look the same. You’re talking about internationalization and it is a much more complicated subject than it appears on the surface.
Which char set i need to set. PLease tell me
You’re not understanding internationalization. What character set you use will not solve your issue because you don’t have control over the other end’s character set (in this case, Infusionsoft’s)
If possible let me know so we can set char set and not need for destination’s text looks like same. Just want insertion.
I don’t have any way of knowing what character set you need. You can probably google character sets for your location to find out what you should use.
I have found a solutio 1st we need to set the charset to iso-8895-15 then convert string to using utf8_encode function. That worked
Sometimes i am getting 502 bad gateway error when make request to infusionsoft (fXmlRpc). That function is written in try catch block. Can i add same script from try block into catch block, but that’s not right to handle that. Can you suggest me a solution for this.
It’s not unheard of to get an error (maybe 1 out of 1000 calls). Most manage it as you suggest and just retry the call once or even twice to be sure to account for the occasional “fluke”
Not sure about the 1 out of 1000 calls, that would seem quite high in my opinion. I don’t see that type of failure often, although I am referring to the XML-RPC calls. If there was too many of those, I would see far more errors or data issues.
Personally, I do not agree with the retrying of calls, because depending on what type of API Call you are doing, you could end up having duplicate data being added into Infusionsoft. An example would be like adding a new Order, but it oddly fails, then adding back the Order again. To be on the safe side, if it fails, you could do a check to see if it is added, and then retry again if its missing.
If you are getting too many failures, I would check the code, the server and connection you are using. If its the REST API failing too often, that is something Infusionsoft need to fix.
Using the Legacy API Key or OAuth?
I don’t know for sure off the top of my head but I am going to go out on a limb and say that most if not all were legacy
3% to me is quite high for a failure rate.
The thing is I am not seeing that amount of failure. So either I am doing something right, or plain lucky, or there is unfortunate developers that get that failure rate.
If I was getting consistent failures, then I would see data being mangled, or weird things being reported. But I generally do not see those, and nor has my clients.
I have seen bugs in the API over the years, but the majority of them were reproducible. I recently found one in the Contacts Saved Searches in which it fails to load when the Lead Score column is in there. That use to work previously, but now it fails.
David Bullock said that he’s seen as high as 3% with Memberium
Maybe David needs to find a new job, and get someone else to write his code.
Pav you Goof
It’s not always 3% and as I posted I haven’t measured it lately. It was on Legacy.
What I was seeing before was up to 3% of the API calls resulted in a 500 error due to a server-side TomCat session initialization problem, or thats what the error said. I actually ran into it before Memberium when I was building custom API driven funnels.
It was transient, never took more than 2 retries to resolve, and when I got that error the API call had not processed, so retrying took care of the problem.
I am using Oauth not the legacy
I have split the records into 1000 then 5 min sleep. But some time again get 502 error.
Can you let me know how can i retrying calls and why the api calls return 502 error? Please suggest.
502 is a server response to a protocol error. If you are using REST then this might equate to using a PUT when a POST was needed or something else along those lines. You can trap api error responses by checking for valid return types. If the documented return value is supposed to be an array but you get a string, it’s a good bet (a certainty) that the string is an error message.