Integration strategies and tech solutions

Support
1

I’m working on a specification work for a local food coop, Alterconso, who has a pretty achieved and complex model. The coop gathers 50 producers, 8 employees and 750 customers. They deliver subscription based baskets of fruits, vegetables, dairy, bread, etc. each in three sizes in 14 distribution points in Lyon (big city in southern France). On top of baskets they also have “grocery dried products” that people buy on demand (jams, juices, beer, etc.) so they are going to embed with iframe the “grocery shop” to start with.
They want their own website so that their customers can choose their subscription plan, modify it, set up a “holiday period” to stop momentary the baskets, etc. And also buy online their dried products.

They have a social pricing, they take 0% margin for low income people, 10% for students and unemployed people and 20% for the others so the users will need to be tagged and we are working on a new tag rule to apply or not entreprise fees.
Any user who has a subscription plan today is registered in a home made database.

We are super value aligned, and they don’t have the money to build their own super efficient custom platform, so we are going to partner and work together, they are a super reference for us, and we can co-finance some of the features they need.

The first step of our cooperation will be around the integration of the “grocery management” part, they will keep managing the subscription on their current home made system until we can test with them the subscription feature v1 and specify what they need for v2.
For the grocery shop, they want the user to see the shop with the good price depending on their tag, so we are going to embed with iframe the shop in their website, and the customer will need to be logged in ofn. For the moment we will start with only an OFN login so no need for Single Sign On.

BUT we would like to understand how we can integrate the existing home made database (or any wordpress database if the front end is based on wordpress and that’s were the client choose his subscription plan): when a new subscription is added to their home made database…

  • the corresponding user is created into OFN if not already existing
  • +the relevant tag is added depending on the category he is classified in in the existing home made database
  • +the user is added to the customer list of the corresponding private shop

To start with I guess they might have to set up manually the users in OFNby inviting them through the customer list and adding them a tag. But we need to know how later on we can avoid double entries…

On a step 2 we will need to build a similar integration to create in OFN the subscription plan chosen on their wordpress website.

@Augustin @pierredelacroix @Lory @balessan I let you share your views on that, I think it can be an interesting case to share with the community in the “standalone websites reflexion”, so I suggest we discuss that here.
Maybe also @oeoeaio @maikel and @lin_d_hop @Kirsten would have some ideas, maybe you have already faced this case and have found some solution you can share ?

1 Like
2

Unfortunately it means that we will have to modify the existing Koller software to send API requests to the OFN instance on each user creation. So far we need to know if:

  • a user API allowing user creation already exists.
  • this API allow us to tag the user accordingly.
  • a consumer API allowing the new user to be added to the corresponding private shop also exists.

Knowing that, two possibilities:

  • either those APIs already exists so all the job is to be done on the existing software side
  • either they don’t so we will have to implement them too.

I will need to look at the technical documentation of OFN to see if the project already have what’s needed :slight_smile:

3

I think we are conscious if we go for a more modular approach of OFN (with standalone websites integrating parts of the OFN features) we will need anyway to rebuild / reinforce the API as much more things will rely on it. Also @balessan for memory this will also be needed for DataFoodConsortium so you can keep that in mind in the format of the rebuilt API so that it is able to support the software interoperability :wink:

4

Good point :slight_smile:

5

Dumping a few thoughts:

  • The OFN has an external-facing API, which is mostly vanilla Spree. At present this allows for basic CRUD operations for the Spree::User model, but we can easily extend it to do more sophisticated things.
  • We may need to rethink authentication for these endpoints. We’ve never had to deal with third-party requests to create users before, so I am fairly sure these are only accessible to super admin at the moment. Maybe it’s fine, just something to consider.
  • Tags are actually applied to a separate model in the OFN (Customer), this is basically a join table between Enterprise and User, which allows per-shop settings to be stored for users.
  • No external-facing API endpoints currently exist for the customer model. Need to think about whether we create one, or couple creation of Customer instances with the User API or some other dedicated endpoint. I would prefer the former, but happy to discuss.
  • There is probably something here that relates to the email-confirm work that Matt, Pierre and Maikel have been working on. @MyriamBoure you are probably more on top of this than I am, but thought I should flag it.
6

@oeoeaio thanks for your thoughts, pretty valuables :slight_smile:

And do you have any idea regarding the amount of work required to implement it ? I am still a complete stranger to Rails, coming from the PHP world, even though I could get some help from @pierredelacroix or @Augustin on that I guess.

7

Can order some beer too :slight_smile: