CiviCRM Standalone with FormProcessor: Mandatory key(s) missing from params array (MCRF Integration)

[rbaugh]

When using the WebHooks AddOn and CiviCRM Form Processor ext, I am getting an error: Mandatory key(s) missing from params array.

FormProcessor seems to need to have the form fields in the querystring as params rather than in the body. When using the WebHooks POST method, which is what FormProcessor expects, the fields from the feed are added to the body of the post request. This is then generating the error message from FormProcessor.

I used the Newsletter example GF Form and FormProcessor as imports to my sample site. Attached are the exports for GF/Feed/FormProcessor.

newsletter_subscribe.json
form--newsletter_subscribe.json
feeds--newsletter_subscribe.json

[agileware-justin]

Thanks for opening a separate issue.

The webhook feed has a mistake which will be recorded as this error "No route was found matching the URL and request method." on the corresponding Gravity Form, Entry for the submission.

The webhook endpoint for Webhooks Feed 1 is configured like so:
{rest_api_url}?entity=FormProcessor&action=newsletter_subscribe&key={gf_civicrm_site_key}&api_key={gf_civicrm_api_key}&json=1

Which is missing the CiviCRM rest route part (civicrm/v3/rest) as shown below:
{rest_api_url}civicrm/v3/rest?entity=FormProcessor&action=newsletter_subscribe&key={gf_civicrm_site_key}&api_key={gf_civicrm_api_key}&json=1

In case you don't know, we added webhook request and response logging, so that this can be viewed on each Gravity Form, Entry. Shown at the bottom of the page. Extremely useful for checking problems like this.

Once the webhook endpoint is corrected and the site key, api key is updated for my local site. Using the same exports, the submission works correctly on my local DEV, as shown below.

[agileware-justin]

One other thing to check is that you have the GF CiviCRM plugin enabled, assuming that you do - but good to confirm 😄

[rbaugh]

@agileware-justin, my CiviCRM instance is a standalone. I was testing out the newer MCRF options you all put together. So this works in conjunction with PR #7 where it is using the MCRF connection to the standalone. So my url in the MCRF is https://standalone.rb.io:8001/civicrm/ajax/rest and with the PR the {rest_api_url} in my webhook gets replaced by this url. It is then posting to the standalone and I get the error mentioned in this issue.

When testing, before using the PR code, I was just manually entering the full standalone URL as is above instead of the {rest_api_url} merge tag.

[rbaugh]

When I tried using PostMan to test the FormsProcessor, I had tried to use the POST with the data in the body as well and got the same error. If I use the params/querystring in PostMan, it worked.

[agileware-justin]

@rbaugh apologies, did not think to test using "standalone" (or even with MCRF and with PR #7)

[agileware-justin]

If using PostMan to submit directly to the Forms Processor end point fails, then yes that indicates something is wrong.

When we were testing MCRF, we used a remote CiviCRM site as a test end point. I don't think we've ever tested anything with CiviCRM standalone at this point in time.

[rbaugh]

It looks like when using Standalone and MCRF, that it is returning the data from APIv4. That is why I had to add in the checks for the [‘is_error’] in the PR. Didn’t get to testing out the Group and Payment processor with the MCRF branch.

[rbaugh]

I updated the issue title so it identifies it is related to the MCRF.

[agileware-justin]

Would you mind testing with McRF and a CiviCRM site that is not standalone?

[rbaugh]

Would you mind testing with McRF and a CiviCRM site that is not standalone?

@agileware-justin Using MCRF when CiviCRM is installed in WP will work without issues. So this is more of an issue with standalone. Not sure if it is related to API versions here. With the WP url, the path is to specify v3, but need to see what the v3 standalone path would be, assuming there is a direct path. I was just using civicrm/ajax/rest with my site domain. While this works for connecting, the response from the API seems to be in a v4 structure.

[agileware-iris]

Unfortunately, CMRF currently only works with v3. AbstractCall::getApiVersion() always returns '3' at the moment, so will only support v3 calls. If civicrm/ajax/rest can only accept v4 format, there's nothing we can do on our end.

You may want to open a ticket in CMRF (edit: CMRF Abstract Core) to ask about this. We'd also be interested in seeing more push to complete v4 support! We'll eventually be converting to v4 when CMRF is updated.

Will close this issue, since it's out-of-scope for this plugin at this point. Thanks for all your investigation, @rbaugh!

[rbaugh]

@agileware-iris I think this issue is the connection to a Standalone server. Currently, this remote branch doesn't work with standalone on a WP install. That was the reason for this issue. I am using the v3 Rest url indicated in the CiviCRM docs with the Connector CiviCRM MCRestFace plugin and it is working, but it seems like on Standalone, it is returning the data in v4 structure. I can put in an issue with them, but the instructions and how GF WebHooks works, this isn't working with Standalone. The WebHooks post isn't sending over in correct format that standalone is expecting.

I am curious, if you are looking to connect with the Connector CiviCRM MCRestFace plugin, why don't you just use the API to post your data over to Civi? I know you can use the FormProcessor to do other actions, but with the connector, it exposes the remote CiviCRM API to you so it seems odd to not just go ahead and use it rather then another plugin posting the data over.

Just a thought that came to me as I was working on the PR. In my GF CiviCRM plugin, I set it up as a GFFeedAddOn and process things using the API. I like the work you put in to leverage the connector which I can adapt to my plugin. Would really like to coordinate our efforts into one plugin, if you all are interested.