—Continuing this support request based on other posts I have seen here:
* I Have uninstalled (with removing all data from plugin) 1.7 from my WP, and installed 1.6 (which was the last working version). The error seems to persist even when downgrading to 1.6
I can confirm that BOTH
object_sync_sf_field_map
AND
object_sync_sf_object_map
Tables have been created in my DB.
So the plugin is successfully creating the tables, and syncing with SF. BUT it doesn’t seem to be updating the tables based on records that are created in SF, and isn’t logging errors.
Any ideas on what is happening?
–Continuing Further–
If I turn DEBUG Mode ON, log is generated API HTTP requests to Salesforce
In the request I can see the objects that is attempting to map (with code 200)…so no error
For example I can plainly see every ‘picklist’ value for a field on the object I am attempting to map.
Continuing down the rabbit hole—
I found a post here that mentioned the plugins reliance on cron https://wordpress.org/support/topic/scheduled-sync-not-running/
GREAT INFO
So I confirmed with the cron manage plugin, and in my c-panel, that there are no cron jobs queued.
****
___If this is the ‘only’ issue that is occurring. How do I manually adjust the settings of cron to permit OBJECT SYNC FOR SALESFORCE to initialize a cron job?
****
@jaysitcc it’s really helpful to know that cron appears to be the issue at this point. For purposes of this answer I’ll assume that you’re running the WP Crontrol plugin.
Here are a couple of things you could try:
1. Go to the scheduling tab and resave the settings, and then go back to the cron manage screen (the URL would be /wp-admin/tools.php?page=crontrol_admin_manage_page) and see if there are entries.
2. Check with your host and make sure there aren’t cron issues.
Jonathan,
Thank you for your prompt reply, and for all of the other valuable information you have posted here (I’ve learned a lot in my failed efforts to fix this because of you).
Cron Events does not show anything after re-saving the scheduler
Here are the list of Cron Scheduled Actions (last time it was successful was 1/16/2019)
View post on imgur.com
Here is the last time it failed (1/16/2019)
View post on imgur.com
No entries after this…is it strange that the Scheduled date is 5 weeks prior to the log? These entries were created on 1/16/2019….so why are they scheduled for 12/23/2018
My host’s cron (through WHM) doesn’t show any pending jobs either.
Regarding 2 — Is there anything in particular I should reach out to my host regarding ‘cron issues’, assuming this is the step I need to take?
Hi @jonathanstegall,
Is this anything in particular I should be looking for with regards to the cron issue?
My cron is scheduling other tasks just fine, and there don’t appear to be any issues with other plugins on my site accessing it.
Is there any other information I can provide you with that may help?
OK….update?
Not sure what I did, but I’m receiving success logs now (yay progress)
Here is what is strange. I’m trying to pull SF records to drafts in WP. I created two flows to try and debug this issue which are both mapped to the same object in SF, but with separate post types in WP.
*If the log entry is “Success Update WordPress (post)” – The plugin is working and the post is created.
*If the log entry is “Success Create WordPress (post) . There is NO data in WP. As far as I can tell this log entry is invalid.
@jonathanstegall
My issue has been fixed. But I thought I would share a few things (and ask a question while I’m at it)
1. Running the schedule every (2) minutes instead of every (1) minute seems to have fixed the issue.
2. DO NOT attempt to map two separate post types in WP with the same object in SF. The plugin seems to create the same post ID for each entry which was likely causing the error.
Question for you! – When this plugin runs on the schedule. Is it a single API call to SF? Or is it (1) call per updated record? Because SF imposes limits on the API this is good information to know so the plugin doesn’t stop working suddenly due to going over the API limit your SF environment.
@jaysitcc I’m glad to hear it’s been fixed.
1. That seems reasonable to me. It could be that you were running into the plugin’s throttle limits. But in any case, running cron as often as every 1 minute is probably not going to be helpful for you; the Salesforce API (in my experience) is just not performant enough for that to be worthwhile.
2. Yes. That is certainly true. I think it’d be nice to support such a thing. We have a GitHub issue for it, but certainly have no plans to add it soon. Perhaps this should go into the documentation – happy to accept pull requests for that, of course.
3. Here’s how the API calls work:
– When the schedule for checking for data runs, the plugin makes an API call to find out how many records meet the criteria. It caches the results of this call.
– If any records matched the criteria, the plugin saves those records (not the full result, if I recall) into the queue.
– When the schedule to process the data runs, the plugin makes an API call for that object’s data and then it maps it to the WordPress fields. It does not cache this API call’s results at this time.
Certainly any API has limits, but the most problematic limit that Salesforce imposes (I think) is that a query cannot have an offset higher than 2000. Theoretically, the API supports a batchSize parameter, but Salesforce determines whether or not to listen to it based on its own performance and not the requesting server’s, and when it is ignored it can crash a WordPress server so we don’t use it.
What we do instead is change the date when a record is processed. So if you pull 2000 records in from Salesforce, the plugin should start over with a new query, using the date from the last processed record. It’s not perfect by any means, but it is the state of things unless Salesforce decides to really support batchSize someday.
Thanks @jonathanstegall,
Just want to recap the API…am I understanding this correctly?
– 1 API call per {schedule}
-example – so at {schedule = 6 minutes} 10(hour)*24(hours in day) = 240 API calls per day?
– # of Updated records in {schedule} cannot exceed more than 2000
@jaysitcc
That is partially right.
1. 1 API call per schedule when it checks for new data. That means all it’s doing is checking to see if there’s any matching data. This would be 240 per day, in your example.
2. Then there’s another API call to get the individual record’s data when it is processed. This is entirely dependent on how much data you are processing, but it certainly could be a lot.
3. The 2000 number is more complicated than that. It’s the way the API generates SOQL queries. SOQL is very similar to SQL, but in the case of SOQL you cannot have an offset higher than 2000.
So for example:
SELECT Id, Email From Contact WHERE LastModifiedDate > 'whatever' OFFSET 2000;
is a valid query in Salesforce.
SELECT Id, Email From Contact WHERE LastModifiedDate > 'whatever' OFFSET 2001;
is not a valid query in Salesforce. So when the plugin gets to 2000, it increments the LastModifiedDate value to the last record’s modified date value. This allows the plugin to (imperfectly, but relatively stably) continue processing large batches of data.
*excuse my ignorance…
OFFSET is just negating the first (x) records that match?
The query
SELECT Id, Email from Contact WHERE LastModifiedDate
Would naturally sort this is descending chronological order, right? So it will always pull (up to) the last 2000 records that were modified.
So this example request would call Contact, and query the last 2k records that were modified (regardless of the fields that need to be mapped in the plugin)
