Technical issues have a funny way of resurfacing sometimes. For example, a number of months ago I came across a problem relating to the SOAP API and Users module and more recently I come across another oddity involving both elements. This time around, however, it seems the problem is broader in scope, applicable to all modules.
For those of you that work with the SOAP API on a regular basis, take note that there is an issue with the get_entry_list() method. If you are unfamiliar with this method, it is used to retrieve a list of records from a given module such as a list of all contacts whose last name is "Smith."
In addition to filtering the data retrieved, the method also permits one to control the number of records retrieved. This is helpful because it allows us to limit the amount of bandwidth and calls used to interact with SugarCRM.
Going back to our example, we could use it to retrieve 20, 50 or 100+ records with one call, by simply specifying any of those numbers as a parameter to the method. This is also where we can run into trouble. As it turns out, there is an issue with the interpretation of this number. In short, if one attempts to retrieve a greater number of records than what exists in the target module, the method fails and none of the records are returned.
In most cases, it is unlikely one would run into this problem, but if one is working with a module that typically does not contain a large number of records, the chances increase. The Users module exposed it to me because I was attempting to get a list of all users defined for a given instance. Because it is not a large implementation, retrieving 50 records in one call seemed feasible. But the process continually failed, leading me to the realization that the Users module only had approximately 30 records.
Once I updated my code to retrieve an equal number of records as what existed in the module, all was fine.
Yes, I did, but I don't have the # handy, and it doesn't appear to be showing showing up in "My Bugs" either. So I couldn't tell you what has happened to it.
ReplyDeleteHey Angel,
ReplyDeleteI've noticed all sorts of strangeness on some of the older versions of the api (non-db fields tend to be problematic in v2, for example). Are you seeing this while using the soap.php endpoint in the root of the installation, or something like service/vX/soap.php?
Hey Wes,
DeleteI am seeing it with the one in the root. Likewise, I've seen other oddities, but don't have exact steps for them. One that does come to mind that appears to be fixed in newer versions is that if you used the ID column for the WHERE clause in get_entry_list(), it would triplicate the results.
My personal favorite: in the REST apis, the 'order' in which the JSON is serialized for method calls matters. So if you're calling get_entry, and your JSON gets serialized as {module_name: 'foo', session: 'bar'...} instead of {session: 'bar', module_name: 'foo'...}, you're going to have a bad day. :)
ReplyDeleteI vaguely recall seeing something along those lines on the forums. A similar one exists with the SOAP API where the order of the fields that you request via get_entry() doesn't coincide with the order in which you request them.
DeleteCome to think of it, that would make for a good post as well as I do recall the pattern for that one.
hi Angel,
ReplyDeleteIs there a limit to the number of records set_entry can process?
-Jesal
Hi Jesal,
Deleteset_entry() is designed to update or create a single record only.
Angel,
ReplyDeleteGracias! Reading this article months ago paid off. I remembered your post and actually was forced to deal with it.
Here was my inline fix
1) Get the list
2) Check the "row_count" for total records
3) Re-Request the list
Sample:
// Lets grab all the records
$arrTypesBean = $typesBean->get_list("",'module_list="Events"');
// Stupid max results fix
$totalTypes = $arrTypesBean["row_count"];
$arrTypesBean = $typesBean->get_list("name",'module_list="Events"',0,$totalTypes,$totalTypes);
Thanks again,
Michael W Joyner
You are welcome. Glad I could be of help, and thanks for sharing your solution as well!
Delete