Expose drupal_recurly_account via services views module

Yay, I’ve done it! It was not very easy, though it was really interesting.

End user features

• Configurable service definition, Recurly request “List Accounts” is included as an example - no additional coding needed, you could add other requests definitions via UI. See attached screenshot #1 for an illustration of user interface for configuring service definition.
• Fully Views integration: module contains query plugin for each operation for each defined service. Fully-functional view ‘recurly_accounts’ is included as an example - no additional coding needed, you could create your own views for other requests via Views UI. See attached screenshot #3 for an illustration of view output.
• Fully Rules integration: each defined via UI Recurly request is Rules action and each defined Recurly data type is Rules data type.
• Services module is not required for functioning, because Recurly module is client application (i.e., who makes requests) not server application as Services (i.e., who takes requests and sends responses). Though it is fully compatible with any application, which uses Services.
• No data is stored locally: so no synchronization troubles.

Is it the solution you’re ready to pay for?;)

Installation & configuration

1) Apply attached patch. It is really huge piece of change: it is going to get rid of some dependencies (Libraries module and external recurly-php-client library) and adds new dependencies (Web Service Client, Web Service Client Views (it is a sandbox), wsclient_ui from wsclient also requires Rules) - so I think it makes sense to commit it to a new major branch (7.x-2.x). I didn’t remove old functionality to migrate evolutionally.
2) Download and apply patches to required modules (full list of needed modules and patches is inside recurly.make file). I suggest to use drush make for this task: recurly.make file is included into the patch from 1).
Please note!: Some projects couldn’t be downloaded and some patches couldn’t be applied automatically because of merging conflicts - you should review recurly.make file for additional info.
3) Install & enable required modules. Here is the list of modules that must be enabled:
- Recurly (recurly)
- Recurly Views (recurly_views) (is inside recurly, added by the attached patch)
- Web Service Client (wsclient)
- Web Service Client UI (wsclient_ui) (is inside wsclient)
- Web Service Client Views (wsclient_views)
- Views (views)
Please make sure that you have set correct Recurly API key and subdomain settings.
4) Clear all caches just to make sure that default implementations, included into patch, were loaded by Drupal.
5) Go to admin/config/services/wsclient/manage/recurly to make sure that what you see is very much similar to screenshot #1. As you could notice, it is UI for defining new and editing existing operations and data types.
Please note!: Make sure your URL is https not http.
6) Click at “Views Configuration” link near operation you want (in our case “List Accounts”, which leads to admin/config/services/wsclient/manage/recurly/views/accounts). It is the place to enable and configure Views integration. Make sure that what you see is very much similar to screenshot #2.
7) Go to admin/structure/views/view/recurly_accounts/edit - and enjoy the list of account codes of accounts from your Recurly account. Illustration is at screenshot #3. Request parameters that are required for request are Contextual filters. In order to get the view of other requests, just create new view, changing ‘Show’ parameter at admin/structure/views/add to ‘WS: Recurly, Op: {needed_operation}’.
In case if you want to add additional request definition from the list at https://docs.recurly.com/api, just follow the steps from 5 to 7. You could use cool wsclient_tester module (which is shipped together with wsclient) to debug your requests: see screenshot #4.
Hope it makes you happy:)

I have re-rolled the patch to make it apply automatically using drush make without any troubles - enjoy! So the only patch you should apply yourself is attached to this post. After that run
drush make sites/all/modules/recurly/recurly.make . --no-core
from your site root directory - and here we go!

Hello Jay,

Wow, I am glad the first step is behind!

Hopefully this report is helpful?

Not so much as I desire:) First of all please flush all caches
drush cc all
- and try reloading pages.
UPDATE: Also please make sure that you've performed updates via update.php. It is important, because make-file downloaded the most recent dev-versions of the modules, which require update (for example, Rules).
Then follow the instructions 5-7 to make sure that necessary configuration is installed properly. Please report if you find any misconfiguration.
In case if everything looks fine, visit admin/reports/dblog and find corresponding error message (or messages) - please copy/paste here (removing sensitive data if any) the content of any unusual message from the log (no matter what kind of: whether error, exception, warning or just info). That would be really helpful.

Regards,
Dmitry (aka PatchRanger).

Hello Jay,

I see that you did a lot, thank you.

tried to use the tester but I don't know where to find it. It's enabled but it doesn't show up anywhere that I've found yet.

As its README says: http://drupalcode.org/project/wsclient.git/blob/refs/heads/7.x-1.x:/wscl... - it adds 'Test' link to service's operations. Also in such situations I am looking to hook_menu implementation: http://drupalcode.org/project/wsclient.git/blob/refs/heads/7.x-1.x:/wscl... - it helps a lot.

MESSAGE WSClientException: Error invoking the REST service Recurly, operation accounts: Failed to unserialize response in WSClientRESTEndpoint->call() (line 89 of /data/disk/o5042658434/static/loud-test/sites/all/modules/wsclient/wsclient_rest/wsclient_rest.module).

Thank you for such detailed error messages, they really facilitate the process of debugging.
The reason is definitely described here: https://drupal.org/node/1280332#comment-5049744 . That's the reason why Twitter fails as well. (BTW, it looks like Twitter will fail anyway because its service definition is obsolete.) I am working on a patch - I doubt it'll take much time.
PS I haven't got such errors during testing, because my local copy of Wsclient module was hacked by me a bit. Those hacks were not incorporated into any patch because they were too moot - sorry. I guess we should use klausi's suggestion: define formatter in the settings without any hacking.

Ok, done.
Attached 2 patches:
- The first is to be applied in your case: over previously applied patch.
- The second is completely re-rolled version of the old patch to eliminate the need for others of applying several patches.
I've tested it locally with "unhacked" version of Wsclient - it works. So it should work in your case too.
Please review.

Hello Jay,

I tried patching with "recurly-2035975-patch_to_be_applied_over_previous.patch" but that didn't work.

What do you mean by "didn't work"? Was patch applied cleanly - or there were troubles with patching? Or "didn't work" means that forementioned error continues to appear?
If the last - try clearing all caches. It's my credo: "In case of any troubles - first flush all caches". :) I tried to reproduce at fresh copy of the module on my local machine - and yes, it continues to arise and completely gone after flushing caches.
It's usually some kind of implicit assumption that every patch needs flushing caches, because old (unpatched) code shows itself in the caches. So the only way to see new (patched) behavior - is to remove all pieces of cache, left from unpatched code. That's the reason why one of the most popular debug advice is to clear all caches. Sorry for not clarifying this point earlier.

But as I said, I'm getting the error with the twitter search example too.

Let me point to https://drupal.org/node/1280332#comment-5049744 once again: it's Wsclient issue - so it affects all services, including both Twitter and Recurly.

Hello Jay,

Did flushing caches help - or you continue to get such errors? Does view display your Recurly accounts? Do you have any other questions or need any help?

I just installed a test site and tested this just fine. I was even able to create some additional views so that I can load up lists of accounts, account details, and subscription details.

Well done! That's the point: make it really easy configurable and customizable. Glad you've succeed.

This wsclient is actually a really nice tool. Are you suggesting that this become the way the recurly module communicates with the recurly api instead of using their recurly php client?

Yes, you're right, I am going to completely replace recurly php client with such a great tool Wsclient. Here is the corresponding issue: #2058091: Proposal for 2.x branch: Replace Recurly PHP Client library with Wsclient.

I'm curious how existing users look to this change. I feel like this might be helpful for various users.

I agree, looks promisingly.

i's and t's

I weighed in at #2058091: Proposal for 2.x branch: Replace Recurly PHP Client library with Wsclient on this general approach. Overall, it's not a direction in which I'd be happy taking the project, considering it's a significantly different approach from the current module. Views integration with the current Recurly table doesn't provide a lot of value, but I could see it being part of this project if necessary. The remaining portions of this patch for integrating with wsclient_views (which I don't think has made it to an official project yet) won't be included in this module.

So if we're interested in using this issue as a starting point for just including Views integration with the current table, I'm up for that, but without wsclient_views there isn't much benefit to it, so I'm inclined to close this issue entirely. If Views integration with the current table still seems valuable, let's address it in a stand-alone issue.