| Description |
Imagine a third-party application that needs to communicate to i21 and sync it's vendors and customers. We somehow did it through the client side but it is inefficient, speed-wise. Hence, we have to do this on the server-side.
Think about the ability to create or update an entity (vendor/customer) in a very impressive speed. Customers may need to be able to create or update thousands of records in seconds!
The complexity is that our current code has a lot of validation, default data initialization, etc. that is happeing on the client-side. You need to communicate with [~mon.gonzales] so we can change the entity API (or create a separate one) to facilitate this kind of need. It could be best if we can change the same API that is being used by the Entity screen and just make minimal changes on the client side if we have to.
The server-side API should be useable through any kind of Ajax call. It has to be RESTful.
This is just Phase 1 (rush and immediate but working) of a rather bigger task.
[~steve.palm] , feel free to add more details. But if you think of explaining the Zapier approach, you can use FRM-2253. :)
# One of our customers who needs this ASAP is Western Milling. They plan to start with importing entities and then managing data updates from another application. They have over 10,000 customers and need to import them from another application and then keey them in sync with any updates on a daily or even more frequent basis.
# Start with the Entity and related tables but plan to extend this gloablly to ALL i21 tables for data importing and synchronization.
# This should be built in a way that all the i21 module programmers can eventually contribute to from their modules. Think of this like a framework that others can contribute to and build from to extend their modules.
# In talking with Western Milling they asked if we could use Node.js to write this since they use Node.js in some of their other apps and really like it.
# Node.js is {color:#333333}asynchronous {color}which is very important for this project but that's not to say we can't use ASP.NET Web API if it's better, easier or more efficent.
# However, we decide to build this we want to make sure we use industry standard RESTful API, asynchronous and strong Authentication like [OAuth|http://oauth.net/2/] .
# Longer term we need to think about how we extend this to other i21 functions. For example, I may want to import an invoice from and ecommerce site and then post it using an i21 API without ever opening the i21 interface. We don't need this in phase 1 but we need to keep it in mind as we build this API.
|