Re: Web API

[Chris Travers <..hidden..>]

On Mon, Sep 10, 2012 at 11:26 PM, Pongrácz István <..hidden..> wrote:

Hi,

I started to work with a 3rd party migration tool, which is able to connect to software systems using web services (wsdl), http endpoint (http://xxx/yyy?zzzz=wwww etc.), direct database access.

I am wondering, how could I access to ledgersmb (1.3) to read and manipulate the data.

Functions are common:

Categorizing these by new or old framework 

• save new customer which registered in an online shop,

Customers:  new 

• modify customer data based on changed data in online shop,

New 

• read price/quantity information from lsmb based on sku,

Old, but Erik's contributed code that brings this at least partly into the new framework.  We may want another simple stored proc that gets a part by SKU.  Then it could be wired into the new framework very easily. 

• save new order from online webshop,

Old framework, I am afraid.

 

• modify orders (cancel etc.) based on online shop,

Old framework.

 

• etc.

As you can see, these are pretty common features in every webshops and in general functions in every use case.

So, my question what is the good way to start implementing these functions?

1. Direct sql manipulation,
2. Web service (using lsmb's own http access as normal usage),
3. Using future interface,
4. Modify lsmb to make a http://..... request with modified data as http parameters to pass values to the migration tool (like a trigger when something posted/updated).

My main goal with using 3rd party tool is that avoid to modify the original code of any webshop and lsmb. To make it realtime, a small modification would be necessary on these codes, for example like the 4th point above, but it would be nice to keep as little change as possible to the original code.

So, any advice?

Yeah.  First what language are you using? 

if it's Perl the simplest thing to do is to patch into the existing object model.  In other languages I think the best thing to do is to help modify LedgerSMB at the db level to provide some of the API;s you are looking at doing if they are not supported right now.  The advantage is simply that you put your code where more people will use it that way.  Then it is a matter of writing query mappers in whatever your language is, if not supported yet (currently support Perl and PHP, hope to have Java coming soon).  I can help with that.

I think Hugh Esco is also looking at doing something similar in Perl.  Even if you are using a different language it might be worth collaborating on common components.

Best Wishes,

Chris Travers