Implementing Open Supporter Data Interface (OSDI) API for CiviCRM Part II - Concluding Post

Looking back at the ‘Overview’
The OSDI API implementation is in line with CiviCRM’s mission to be an open platform for organizations of all sizes. Creating the implementation will allow them to use the OSDI API easily. The existence of a common API will reduce progressive data vendors’ customer costs related to moving data between different systems, lower integration costs and enhance the ability of innovators to create products for the marketplace. You can learn more about OSDI at www.opensupporter.org

The ‘org.civicrm.osdi’ Extension

The OSDI implementation project was developed as an extension for CiviCRM. This extension act as a connecting bridge between two systems one having OSDI implementation and the one using this extension. It can perform GET request to retrieve the people’s data from the implemented system based on OSDI specifications. It includes ‘Person Sign-up Helper’ which is a helper endpoint to aid in the creation of People resources via POST requests. This extension utilizes REST API calls, you can GET the desired data or perform various actions like POST, PUT and DELETE through the REST interface.

AEP : API Entry Point

To explore the people’s data on the server AEP was constructed which is a part of the OSDI specification. The AEP helps in exploring the various endpoints like people’s collection, individual person’s record, brand logo etc. Also, AEP has ‘Person Sign-up Helper’ for the creation of new individual resources.

AEP

This extension is capable of handling the following actions, let’s look up to them briefly:

  • GET -requests are automatically invoked when you want to retrieve the People’s data or any individual person’s data. You can look up to the desired data through the API explorer on your own CiviCRM site at /civicrm/api (available from the menubar at Help -> Developer -> Api Explorer). Also, you can execute a REST call having an entity as ‘People’ and action as ‘get’ passing along the user key and site key, parameters like options or limits can be added to these REST URI requests.

GET

  • POST -these requests are used to add a new person’s record into the system. The ‘Person Sign-up Helper’ accepts these requests in JSON format having fields’ name according to OSDI specification. To POST a new record click on the NON-GET button (orange colour) and provide the data in JSON format. The fields provided should be based OSDI specification in order to get this request accepted into the system.

POST

  • PUT -This is primarily used to update an existing person’s record. You need to provide the ‘Method’ while using the HAL-browser interface at the person’s endpoint whose record has to be updated.

PUT

  • DELETE -It deletes the person’s record. Similarly, just fill the ‘Method’ field as ‘DELETE’ to remove that record.

DELETE

Using the extension: You can follow the documentation present in the GitHub repository of this project. Here : https://github.com/anuditverma/org.civicrm.osdi

Conclusion: This project fulfils the basic requirements to be considered as an extension for implementing OSDI into the CiviCRM system. The ‘Person Sign-up Helper’ is developed to post a new record into the system based on OSDI specification. Similarly, various actions like GET, POST, PUT and DELETE are used to perform control actions as per OSDI specification. So as per GSoC and other mandatory fulfillments this project stands complete. Right now, its alpha version would be released and uploaded to the CiviCRM extension directory. Though I would continue contributing to the Git Hub repository, testing the extension more, fixing self-raised issues and issues reported by others. I would add more helpers which are defined in the OSDI specification.

Acknowledgments: I would like to thanks, Joe McLaughlin and Eileen McNaughton who were the mentors assigned to me for this project.

  • Joe Sir, thank you for believing in me as many may not be knowing that originally I applied in CiviCRM with a different proposal which was not very much similar to this project. So I am very thankful for selecting me and how we worked together in understanding OSDI by attending the weekly OSDI Technology Committee meetings which were very helpful for moving ahead in the completion of this project.
  • Eileen ma’am, we had a time zone difference in which it was sometimes difficult to match our work timings. Despite this, I am very much grateful to you as whenever I had a query regarding CiviCRM you always responded in quickly whether it was late in the night at your end or us hanging out on IRC for hours. So thank you for assisting me in understanding CiviCRM.
  • I would like to thanks, Joe Murray who encouraged me and pushed me ahead when I needed the most. Thank you Sir, for advising me on setup-ing my development environment and helping on other Civi issues.
  • Thanks to Jason Rosenbaum from Action Network who helped me get an insight into an existing OSDI implementation at their organization. Well, Jason and I discussed the issues he raised on my Git Hub repository which helped this implementation work effectively and as per OSDI specification. So thanks to him for contributing his time to this project.
  • Josh Cohen, founder of OSDI for hosting weekly online OSDI Technology Committee meetings that helped me gain knowledge about OSDI significantly.
  • Edsel Roque Lopez, who works for JMA consulting, Joe Murray got us introduced to each other. We share the same time zone and Edsel’s expertise on CiviCRM also helped me gain a lot of background working of this software. So Thanks to him as well for contributing his valuable time to this project.
  • Thanks to Timothy Anderegg for joining in the discussion of this project and for sharing your valuable thoughts on it.

See Also

Share: Twitter Facebook LinkedIn