My experencies at the Sprint: Form Processor and Action Provider extension

Last week we had a Sprint in the wonderful city of Brussels. This blog post is a recap of what I have been up to.

Form Processor

I started the sprint to work on a new extension the form processor.  This idea came to my mind as I had a few clients at which I had to develop a custom api for data coming from their website (in those cases CiviCRM was separated from the website). And my idea was that I wanted to give system administrator and implementers a tool in which they could create those kind of API by themselves. So the form processor was born.

Below is a sketch of the screen of the form processor (click the image for a larger preview):

The form processor is designed so that the user first defines the input fields and after that the actions.

As you can see the form processor has actions attached to it and that looks quite a bit as the actions at the CiviRules extension. Which got me thinking. But what got me even more thinking was Björn demonstrating his SQL Tasks extension at the sprint. The SQL Tasks extension also contains actions. Hang on... So we got two extensions already in the ecosystem implementing some kind of action system. Could it not be useful to have an Action extension, so that actions provided in the action extension could be resued by SQL Tasks, CiviRules, Form Processor and others. Hence the Action Provider extension was born.

Action Provider extension

The aim of the action provider extension is to provide a framework to implement actions which could then be used by CiviRules, SQL Tasks, Form Processor and other extensions. The action provider extension should also provide a default set of actions, such as Add to group, Set contribution status to completed, Send -email etc... Like the ones already present in CiviRules.

Architecture overview

So how does this all fit in the architecture of a CiviCRM environment? Tim Otten drew a diagram about CiviCRM form/action architecture, and I've excerpted a relevant section below. In this excerpt you can see in the top part the extensions with a user interface which are all related but do different things. In the middle you see the action provider is used by the other parts of the system and the standard API.

At the bottom of the picture are external websites/systems talking to CiviCRM. As you can see many parts of the architecture already exists.

Next steps

• Develop a proof of concept of the action provider with a proof of concept implementation in CiviRules. We have a working proof of concept of action-provider extension and CiviRules
• Develop a proof of concept of the Form Processor extension
• Refactor code of both extensions for publishing and use in production systems
• Write documentation on how to implement the action provider in your extension and how to develop a custom action;
• Write user/administrator documentation of the Form Processor

Links

• Form processor project wiki: https://lab.civicrm.org/jaapjansma/form-procesor/wikis/home
• Form processor extension code: https://lab.civicrm.org/jaapjansma/form-procesor
• Action-provider extension: https://lab.civicrm.org/jaapjansma/action-provider
• Action provider wiki: https://lab.civicrm.org/jaapjansma/action-provider/wikis/home
• SQL Tasks extension: https://civicrm.org/extensions/sql-tasks-extension-configurable-recurring-tasks
• CiviRules extension (with a prototype implementation of action-provide): https://github.com/jaapjansma/org.civicoop.civirules/tree/integration_with_action_provider
• Tims original diagram: https://docs.google.com/presentation/d/1Zs6UQDXBXe4K3zV5xrt8HK2R5nxttw2sGslZ82hM9us/edit?usp=sharing

Ps

I have used labs.civicrm.org as my new home for those project as this place was presented during the sprint as an alternative to GitHub. We as a community should practice what we preach (use open source whenever possible)

Ps2.

I have used the new short extension name for the form processor and the action provider. During the Sprint Michael McAndrew has been working on that and the reasoning behind is to remove the vendor dependency in the name of the extension so that it is easier for others to co-maintain an existing extension.

One last remark during the Sprint I have also used Michael McAndrews docker container with Buildkit; if you are experiencing troubles with setting up buildkit you should try out this docker container: https://github.com/michaelmcandrew/civicrm-buildkit-docker