Site admins have no way to monitor deferred push behavior by inspecting the queue.
In these steps, Entity refers to whatever entity you can create that has a push mapping to Salesforce, eg: Redhen Contact.
1. Salesforce/Mappings/Entity/Settings
2. Disable real-time push, and Save settings.
3. Create a new Entity and save it.
4. Examine Configuration/System/Queue Manager. EXPECT: Salesforce Push queue, particularly since there's a Salesforce Pull queue. ACTUAL: no such queue.
Examining the code it appears that the salesforce_pull module used the built-in Drupal queue which has nice Admin UI, but salesforce_push rolled their own custom queue and failed to implement any Admin UI.
I don't know if there's a particular requirement that led to this differing implementation. If there isn't, an ideal fix would refactor salesforce_push to just use Drupal's built-in queue.
I have a pressing need and lack time to do that ideal fix.
A more expedient fix is to implement hook_views_data() which would let site admins build their own UI using Views.
Maintainer review & merge (hopefully!).
Salesforce Push Queue newly appears as an available view source table.
None.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | salesforce_push_3491809_queue_not_visible.patch | 3.93 KB | josephr5000 |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
josephr5000 commentedMR added. Here's a patch for convenience.
Comment #4
josephr5000 commentedComment #5
josephr5000 commentedComment #6
josephr5000 commentedUpdated the remaining tasks since fix and MR are done.
Comment #7
aaronbaumanYes, the whole queue system needs an overhaul.
Ideally, each mapping would define its own derivative, so that we can continue to use the per-mapping settings we have now.
We probably still need a custom database backend for the push queue, but I don't think we actually need the custom PushQueueProcessorInterface.
Probably would be useful to have a custom database backed for pull queue as well.
Anyway, thank you for the patch - this looks fine and good.
I'm hesitant to merge it because I don't really want to go down the rabbit hole of supporting a views integration in the short and medium term if we're looking towards this longer term change.
Comment #8
josephr5000 commentedThanks Aaron, and I agree this isn't the right solution...it's an expedient workaround. I agree it should not be merged.
Curious about one item in your comment. Wondering why the current pull queue back-end (the default database queue) wouldn't also work for the push queue? That way you get all the nice Drupal queue UI for free.
Comment #9
aaronbaumanOne reason is to dedupe the queue entries.
This is happening already in Push Queue, but not Pull Queue.
Since the core database queue serializes all the data, there's no simple way to dedupe without loading every single queue item.
Not feasible.
For this same reason, I think Pull Queue should also be converted to a custom backend.
Another reason - not currently happening for push queue, but again not feasible with core queue - is so that queue items can be batched to minimize API usage.
Comment #10
josephr5000 commentedAaron, thanks for the clarification.
Aside-- advancedqueue added deduplication support. Not sure if that meets your needs but am wondering if it's a way for you to lower the amount of custom queue code (and associated admin UI) required in this module.
Comment #11
aaronbaumanoh nice, https://www.drupal.org/project/advancedqueue might do the trick
i'm all about maintaining less code whenever possible
Comment #12
aron novakI can imagine it cannot fit in Salesforce module, but I went ahead and created a new contrib module around it https://www.drupal.org/project/salesforce_push_queue_ui - it is usable until the larger refactor arrives.
Comment #13
aron novakFor the long-term solution: https://www.drupal.org/project/salesforce/issues/3544787 - I started this issue alongside with a MR.