Thoughts On The API

[Lindsay Harris]

Now that I've had some playing around with the API, I've been thinking
of the question of how to specify the database name and user and
password.   Currently, when required,  the username and password are
passed along with each transaction.   Some of that is then placed
into the $_SESSION array.

My planned usage is for a standalone program,  but I see all the test
code is intended to be pages on a web server.   Nothing wrong with
that, but not what I *think* I want to do.  Cron is not very good at
running web browsers.

I think login and logout functions/methods would solves the identity
issue.   Following the interactive login approach, the magic stuff
would be held in the $_SESSION array,  and thus readily available
when/if needed.   And this would put the API functions into the same
environment as a regular interactive user.

The only issue I see is that of the manual page for the API.  It's
generated by the webserver using the API to talk to itself!  [Took me
a while looking at apache logs to see the two different "client"
addresses show up - one for my desktop, then the server calling
itself.]  I'm not sure this is a problem,  just something that would
need to be considered.

Anybody see any issues with this?   Tim, in particular, given your
work on this great feature.  I'm happy to do the work,  but if it's
not a good idea,  I'd rather not waste my time.

And should we have an access level for using the API?  I was planning
on using an API-only user ID.

Lindsay

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Tim Schofield]

Hi Lindsay,

I agree with most of your points.

A bit of history - I created the API principally because I needed to
integrate webERP with a hospital information system Care2x
(https://sourceforge.net/projects/care2002/). Although I wanted to
keep it as generalised as possible, by necessity I tended to code up
those functions I needed, which is why there are gaps in the
functionality such as supplier transactions that Royce pointed out. I
had a rather grand idea of a unified login module that would allow
users to authenticate with this module and then access either webERP
or Care2x within the same session. Unfortunately due to time
constraints this never got beyond being an idea. However the system
works fine with Care2x in several hospitals now. I have since done a
"proof of concept" example to show webERP working with oscommerce
through the api.

The web browser in the examples is just the interface to the client
application. The communication is between the two applications on the
server.

There are several weaknesses with it at the moment, and you have
pointed out two major ones. The first is the authentication. This
needs to be improved. I never quite got my head around how the two
applications would both track the session and as it wasn't vital for
my particular purposes I left it as it was. In theory the client app
could be anything written in any language on any platform.

The other is the necessity to hard code the database name, which is
clearly unsatisfactory. You might want to access several databases
through the same server. I think this should be the clients
responsibility to tell the server which database to update. Should
this be passed at authentication time and stored in a session variable
on the server side, as there would need to be a check that the client
had authority for that database?

I have always thought that the api had the potential to be "a killer
app" for webERP but never really had the time to polish it as much as
it deserves. Help would be greatly appreciated.

Thanks
Tim

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Lindsay Harris]

Tim,
Thanks for the long and informative reply.  I agree that the API could
be the killer app for webERP.  I understood that as soon as I
discovered what you had done.    And I would have used the same
strategy that you have did for implementing the bits I need now.

I am quite happy to sink my teeth into this and fix/extend/polish as
appropriate, and for the needs I have!  After all, that's part of the
benefits of open source - people contribute the bits they need/want
to make it better for others.

I had another thought last night,  and this might make the interface
much simpler.  Rather than using an RPC mechanism with many methods,
have a URL that accepts an XML encoded transaction.  For example, to
enter a sales order, something like:

<sales order>
 <sales header>
    <customer id>value</customer id>
    <del addr 1>24 big street</del addr 1>
 </sales header>
 <sales item line>
    <stockid>prod1</stockid>
    <price>27.34</price>
  </sales item line>
</sales order>

You get the idea.  The above may not be valid XML, it's for
illustration. The tags would have a 1:1 correspondence with the
database fields in which the value is placed.

This brings the interaction between systems to a text interaction over
an HTTP channel - basic stuff I would expect to be very adaptable.  
Although the XML tags are ASCII, the values would need to be accept
multiple encodings/utf-8 or whatever - I haven't been following that
discussion.  I presume that XML can handle that.

I am assuming that PHP has some functionality to handle XML document
parsing - that is my next task :)

What do others think of this?

Lindsay



On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:

> Hi Lindsay,
>
> I agree with most of your points.
>
> A bit of history - I created the API principally because I needed
> to integrate webERP with a hospital information system Care2x
> (https://sourceforge.net/projects/care2002/). Although I wanted to
> keep it as generalised as possible, by necessity I tended to code
> up those functions I needed, which is why there are gaps in the
> functionality such as supplier transactions that Royce pointed out.
> I had a rather grand idea of a unified login module that would
> allow users to authenticate with this module and then access either
> webERP or Care2x within the same session. Unfortunately due to time
> constraints this never got beyond being an idea. However the system
> works fine with Care2x in several hospitals now. I have since done
> a "proof of concept" example to show webERP working with oscommerce
> through the api.
>
> The web browser in the examples is just the interface to the client
> application. The communication is between the two applications on
> the server.
>
> There are several weaknesses with it at the moment, and you have
> pointed out two major ones. The first is the authentication. This
> needs to be improved. I never quite got my head around how the two
> applications would both track the session and as it wasn't vital
> for my particular purposes I left it as it was. In theory the
> client app could be anything written in any language on any
> platform.
>
> The other is the necessity to hard code the database name, which is
> clearly unsatisfactory. You might want to access several databases
> through the same server. I think this should be the clients
> responsibility to tell the server which database to update. Should
> this be passed at authentication time and stored in a session
> variable on the server side, as there would need to be a check that
> the client had authority for that database?
>
> I have always thought that the api had the potential to be "a
> killer app" for webERP but never really had the time to polish it
> as much as it deserves. Help would be greatly appreciated.
>
> Thanks
> Tim
>
> -------------------------------------------------------------------
>----------- Come build with us! The BlackBerry(R) Developer
> Conference in SF, CA is the only developer event you need to attend
> this year. Jumpstart your developing skills, take BlackBerry mobile
> applications to market and stay ahead of the curve. Join us from
> November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Dale Scott]

Does having an automated test system for WebERP based on the API make sense?
I haven't developed automated testing for a web app before, but it would
seem that a mature API covering core transactions would enable simple
automated testing of that core functionality. I suspect that simply
identifying core transactional functionality by creation of an automated
test suite would lead to distinction between core and GUI, which may also be
good.

You can listen to a good overview of Drupal's (a popular CMS) test
environment while you're commuting to work - see
http://www.lullabot.com/drupal-voices/drupal-voices-66-jimmy-berry-drupal-te
st-framework

I'm not in a position to contribute coding, but are there specific hot
topics where a non-coder could help out? Documentation, testing, ....
Something specific with well-defined requirements would be a good
mini-project to get started (and it doesn't have to be associated with
automated testing). Any suggestions?

Dale

-----Original Message-----
From: Lindsay Harris [mailto:lindsay@...]
Sent: October-31-09 10:01 PM
To: webERP Developers
Subject: Re: [WebERP-developers] Thoughts On The API

Tim,
Thanks for the long and informative reply.  I agree that the API could
be the killer app for webERP.  I understood that as soon as I
discovered what you had done.    And I would have used the same
strategy that you have did for implementing the bits I need now.

I am quite happy to sink my teeth into this and fix/extend/polish as
appropriate, and for the needs I have!  After all, that's part of the
benefits of open source - people contribute the bits they need/want
to make it better for others.

I had another thought last night,  and this might make the interface
much simpler.  Rather than using an RPC mechanism with many methods,
have a URL that accepts an XML encoded transaction.  For example, to
enter a sales order, something like:

<sales order>
 <sales header>
    <customer id>value</customer id>
    <del addr 1>24 big street</del addr 1>
 </sales header>
 <sales item line>
    <stockid>prod1</stockid>
    <price>27.34</price>
  </sales item line>
</sales order>

You get the idea.  The above may not be valid XML, it's for
illustration. The tags would have a 1:1 correspondence with the
database fields in which the value is placed.

This brings the interaction between systems to a text interaction over
an HTTP channel - basic stuff I would expect to be very adaptable.  
Although the XML tags are ASCII, the values would need to be accept
multiple encodings/utf-8 or whatever - I haven't been following that
discussion.  I presume that XML can handle that.

I am assuming that PHP has some functionality to handle XML document
parsing - that is my next task :)

What do others think of this?

Lindsay



On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:

> Hi Lindsay,
>
> I agree with most of your points.
>
> A bit of history - I created the API principally because I needed
> to integrate webERP with a hospital information system Care2x
> (https://sourceforge.net/projects/care2002/). Although I wanted to
> keep it as generalised as possible, by necessity I tended to code
> up those functions I needed, which is why there are gaps in the
> functionality such as supplier transactions that Royce pointed out.
> I had a rather grand idea of a unified login module that would
> allow users to authenticate with this module and then access either
> webERP or Care2x within the same session. Unfortunately due to time
> constraints this never got beyond being an idea. However the system
> works fine with Care2x in several hospitals now. I have since done
> a "proof of concept" example to show webERP working with oscommerce
> through the api.
>
> The web browser in the examples is just the interface to the client
> application. The communication is between the two applications on
> the server.
>
> There are several weaknesses with it at the moment, and you have
> pointed out two major ones. The first is the authentication. This
> needs to be improved. I never quite got my head around how the two
> applications would both track the session and as it wasn't vital
> for my particular purposes I left it as it was. In theory the
> client app could be anything written in any language on any
> platform.
>
> The other is the necessity to hard code the database name, which is
> clearly unsatisfactory. You might want to access several databases
> through the same server. I think this should be the clients
> responsibility to tell the server which database to update. Should
> this be passed at authentication time and stored in a session
> variable on the server side, as there would need to be a check that
> the client had authority for that database?
>
> I have always thought that the api had the potential to be "a
> killer app" for webERP but never really had the time to polish it
> as much as it deserves. Help would be greatly appreciated.
>
> Thanks
> Tim
>
> -------------------------------------------------------------------
>----------- Come build with us! The BlackBerry(R) Developer
> Conference in SF, CA is the only developer event you need to attend
> this year. Jumpstart your developing skills, take BlackBerry mobile
> applications to market and stay ahead of the curve. Join us from
> November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[royce]

Hi there, I'm also interested in the API.  My ultimate goal would be to be able to automatically process the XML files that we get from our order processing, vendors, shipping, etc systems.

I'm certainly no expert on XMLRPC vs. other methods of inter process communications, but it seems that the current implementation architecture is way overly complex.  I AM very familiar with REST based interfaces, and I'm more inclined to go towards that method.  That is the protocol for Amazon, Paypal, authorize.net, Google analyticis, and many other highly secure web services.

I'm a noob to webERP so I'm not sure how practical converting it to REST would be, but right now I'm testing out the XMLRPC API  and I'm getting a HTTP 500 error code on our system - this may be because we are testing it under a subdomain to our production UNIX server (it worked fine on our initial testing on our local LAMPP XP box).

Absent a working API, we would be forced to rewrite the functions  and totally cut out the XMPRPC stuff.  That option doesn't seem that difficult, but if possible, I would rather assist in rewriting the API for general use using an REST based approach.

[Tim Schofield]

Hi Lindsay,

Help to polish up the api would be greatly appreciated. Other than the
authentication issue and the hard coding of the db name, some of the
error handling is inconsistent and needs to be more robust. Obviously
there are more functions that could be added as well.

I chose xmlrpc as the protocol for several reasons. Firstly it was a
protocol I know very well having used it many times in the past. Also
it is simple elegant and lightweight. I felt it fitted well with the
philosophy of webERP. Although I can see merits in your idea I would
be reluctant to change to any other method now, especially as I have
the current api working in a number of locations.

Thanks
Tim

2009/11/1 Lindsay Harris <lindsay@...>:

> Tim,
> Thanks for the long and informative reply.  I agree that the API could
> be the killer app for webERP.  I understood that as soon as I
> discovered what you had done.    And I would have used the same
> strategy that you have did for implementing the bits I need now.
>
> I am quite happy to sink my teeth into this and fix/extend/polish as
> appropriate, and for the needs I have!  After all, that's part of the
> benefits of open source - people contribute the bits they need/want
> to make it better for others.
>
> I had another thought last night,  and this might make the interface
> much simpler.  Rather than using an RPC mechanism with many methods,
> have a URL that accepts an XML encoded transaction.  For example, to
> enter a sales order, something like:
>
> <sales order>
>  <sales header>
>    <customer id>value</customer id>
>    <del addr 1>24 big street</del addr 1>
>  </sales header>
>  <sales item line>
>    <stockid>prod1</stockid>
>    <price>27.34</price>
>  </sales item line>
> </sales order>
>
> You get the idea.  The above may not be valid XML, it's for
> illustration. The tags would have a 1:1 correspondence with the
> database fields in which the value is placed.
>
> This brings the interaction between systems to a text interaction over
> an HTTP channel - basic stuff I would expect to be very adaptable.
> Although the XML tags are ASCII, the values would need to be accept
> multiple encodings/utf-8 or whatever - I haven't been following that
> discussion.  I presume that XML can handle that.
>
> I am assuming that PHP has some functionality to handle XML document
> parsing - that is my next task :)
>
> What do others think of this?
>
> Lindsay
>
>
>
> On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
>> Hi Lindsay,
>>
>> I agree with most of your points.
>>
>> A bit of history - I created the API principally because I needed
>> to integrate webERP with a hospital information system Care2x
>> (https://sourceforge.net/projects/care2002/). Although I wanted to
>> keep it as generalised as possible, by necessity I tended to code
>> up those functions I needed, which is why there are gaps in the
>> functionality such as supplier transactions that Royce pointed out.
>> I had a rather grand idea of a unified login module that would
>> allow users to authenticate with this module and then access either
>> webERP or Care2x within the same session. Unfortunately due to time
>> constraints this never got beyond being an idea. However the system
>> works fine with Care2x in several hospitals now. I have since done
>> a "proof of concept" example to show webERP working with oscommerce
>> through the api.
>>
>> The web browser in the examples is just the interface to the client
>> application. The communication is between the two applications on
>> the server.
>>
>> There are several weaknesses with it at the moment, and you have
>> pointed out two major ones. The first is the authentication. This
>> needs to be improved. I never quite got my head around how the two
>> applications would both track the session and as it wasn't vital
>> for my particular purposes I left it as it was. In theory the
>> client app could be anything written in any language on any
>> platform.
>>
>> The other is the necessity to hard code the database name, which is
>> clearly unsatisfactory. You might want to access several databases
>> through the same server. I think this should be the clients
>> responsibility to tell the server which database to update. Should
>> this be passed at authentication time and stored in a session
>> variable on the server side, as there would need to be a check that
>> the client had authority for that database?
>>
>> I have always thought that the api had the potential to be "a
>> killer app" for webERP but never really had the time to polish it
>> as much as it deserves. Help would be greatly appreciated.
>>
>> Thanks
>> Tim
>>
>> -------------------------------------------------------------------
>>----------- Come build with us! The BlackBerry(R) Developer
>> Conference in SF, CA is the only developer event you need to attend
>> this year. Jumpstart your developing skills, take BlackBerry mobile
>> applications to market and stay ahead of the curve. Join us from
>> November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web-erp-developers@...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Tim Schofield]

Hi Dale,

I did some bash scripts a while ago that created sales orders using
curl, to post transactions using the webERP scripts. Also there are
some to create stock items. These could  maybe extended to an
automated testing system?

Also documentation is always needed. Phil did a great job with the
manual, but I am not so good with documentation. For instance the
purchase ordering manual needs redoing. Also someone mentioned on this
list a short time ago about writing some simple user guides, but
nothing has yet come of that. This sort of help is if anything more
useful than coding.

Thanks
Tim


2009/11/1 Dale Scott <dalescott@...>:

> Does having an automated test system for WebERP based on the API make sense?
> I haven't developed automated testing for a web app before, but it would
> seem that a mature API covering core transactions would enable simple
> automated testing of that core functionality. I suspect that simply
> identifying core transactional functionality by creation of an automated
> test suite would lead to distinction between core and GUI, which may also be
> good.
>
> You can listen to a good overview of Drupal's (a popular CMS) test
> environment while you're commuting to work - see
> http://www.lullabot.com/drupal-voices/drupal-voices-66-jimmy-berry-drupal-te
> st-framework
>
> I'm not in a position to contribute coding, but are there specific hot
> topics where a non-coder could help out? Documentation, testing, ....
> Something specific with well-defined requirements would be a good
> mini-project to get started (and it doesn't have to be associated with
> automated testing). Any suggestions?
>
> Dale
>
> -----Original Message-----
> From: Lindsay Harris [mailto:lindsay@...]
> Sent: October-31-09 10:01 PM
> To: webERP Developers
> Subject: Re: [WebERP-developers] Thoughts On The API
>
> Tim,
> Thanks for the long and informative reply.  I agree that the API could
> be the killer app for webERP.  I understood that as soon as I
> discovered what you had done.    And I would have used the same
> strategy that you have did for implementing the bits I need now.
>
> I am quite happy to sink my teeth into this and fix/extend/polish as
> appropriate, and for the needs I have!  After all, that's part of the
> benefits of open source - people contribute the bits they need/want
> to make it better for others.
>
> I had another thought last night,  and this might make the interface
> much simpler.  Rather than using an RPC mechanism with many methods,
> have a URL that accepts an XML encoded transaction.  For example, to
> enter a sales order, something like:
>
> <sales order>
>  <sales header>
>    <customer id>value</customer id>
>    <del addr 1>24 big street</del addr 1>
>  </sales header>
>  <sales item line>
>    <stockid>prod1</stockid>
>    <price>27.34</price>
>  </sales item line>
> </sales order>
>
> You get the idea.  The above may not be valid XML, it's for
> illustration. The tags would have a 1:1 correspondence with the
> database fields in which the value is placed.
>
> This brings the interaction between systems to a text interaction over
> an HTTP channel - basic stuff I would expect to be very adaptable.
> Although the XML tags are ASCII, the values would need to be accept
> multiple encodings/utf-8 or whatever - I haven't been following that
> discussion.  I presume that XML can handle that.
>
> I am assuming that PHP has some functionality to handle XML document
> parsing - that is my next task :)
>
> What do others think of this?
>
> Lindsay
>
>
>
> On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
>> Hi Lindsay,
>>
>> I agree with most of your points.
>>
>> A bit of history - I created the API principally because I needed
>> to integrate webERP with a hospital information system Care2x
>> (https://sourceforge.net/projects/care2002/). Although I wanted to
>> keep it as generalised as possible, by necessity I tended to code
>> up those functions I needed, which is why there are gaps in the
>> functionality such as supplier transactions that Royce pointed out.
>> I had a rather grand idea of a unified login module that would
>> allow users to authenticate with this module and then access either
>> webERP or Care2x within the same session. Unfortunately due to time
>> constraints this never got beyond being an idea. However the system
>> works fine with Care2x in several hospitals now. I have since done
>> a "proof of concept" example to show webERP working with oscommerce
>> through the api.
>>
>> The web browser in the examples is just the interface to the client
>> application. The communication is between the two applications on
>> the server.
>>
>> There are several weaknesses with it at the moment, and you have
>> pointed out two major ones. The first is the authentication. This
>> needs to be improved. I never quite got my head around how the two
>> applications would both track the session and as it wasn't vital
>> for my particular purposes I left it as it was. In theory the
>> client app could be anything written in any language on any
>> platform.
>>
>> The other is the necessity to hard code the database name, which is
>> clearly unsatisfactory. You might want to access several databases
>> through the same server. I think this should be the clients
>> responsibility to tell the server which database to update. Should
>> this be passed at authentication time and stored in a session
>> variable on the server side, as there would need to be a check that
>> the client had authority for that database?
>>
>> I have always thought that the api had the potential to be "a
>> killer app" for webERP but never really had the time to polish it
>> as much as it deserves. Help would be greatly appreciated.
>>
>> Thanks
>> Tim
>>
>> -------------------------------------------------------------------
>>----------- Come build with us! The BlackBerry(R) Developer
>> Conference in SF, CA is the only developer event you need to attend
>> this year. Jumpstart your developing skills, take BlackBerry mobile
>> applications to market and stay ahead of the curve. Join us from
>> November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web-erp-developers@...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> ----------------------------------------------------------------------------
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Tim Schofield]

Hi Royce,

I'm not sure in what way you consider it overly complex. I accept that
its not robust enough and can be hard to get working, but from a
client point of view its really fairly simple to use. I would have
thought that it was best to devote our efforts to improving the
current api rather than trying to re implement a server which would be
a complex job. However its open source, so if people want to write an
api with other protocols then that is also fine.

Tim


2009/11/1 royce <royce@...>:

>
> Hi there, I'm also interested in the API.  My ultimate goal would be to be
> able to automatically process the XML files that we get from our order
> processing, vendors, shipping, etc systems.
>
> I'm certainly no expert on XMLRPC vs. other methods of inter process
> communications, but it seems that the current implementation architecture is
> way overly complex.  I AM very familiar with REST based interfaces, and I'm
> more inclined to go towards that method.  That is the protocol for Amazon,
> Paypal, authorize.net, Google analyticis, and many other highly secure web
> services.
>
> I'm a noob to webERP so I'm not sure how practical converting it to REST
> would be, but right now I'm testing out the XMLRPC API  and I'm getting a
> HTTP 500 error code on our system - this may be because we are testing it
> under a subdomain to our production UNIX server (it worked fine on our
> initial testing on our local LAMPP XP box).
>
> Absent a working API, we would be forced to rewrite the functions  and
> totally cut out the XMPRPC stuff.  That option doesn't seem that difficult,
> but if possible, I would rather assist in rewriting the API for general use
> using an REST based approach.
>
>
> --
> View this message in context: http://old.nabble.com/Thoughts-On-The-API-tp26141405p26150930.html
> Sent from the web-erp-developers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Javier de Lorenzo-Cáceres]

Hi Dale,

I'm not the man to tell, but of course there is a lot of work to do, the
topics you mention are good examples, Documentation gives a lot of work and
never gets updated and testing is never enough because there are many things
to test. I only have a few months with WebERP and during this time I have
seen a good quantity of new features. If you are interested on an especific
area, let's say, API, security, browser's war, server's optimization,
multi-language, GUI, Chart of Accounts, Inventory, EDI, Document Management,
Human Resources, or any else, maybe you will enjoy a bit more if you help in
that area first. Also, documented opinions are always high valuable from my
point of view.

About the first part of your post, I know Drupal and also have an
installation but didn't know about the automated test system and I thank you
for that, I'm learning a lot from this kind of messages, they are like
gifts. What I believe I can tell is that there is nothing like "a Core an
API and a GUI" in WebERP. At least in the the usual way they are understood.
Usually, we understand them as software levels or layers where the user
interacts with the GUI, this with the API and this with the Core and
sometimes the GUI calls the Core or even further, why not if it's needed for
an especific situation. But again, I'm not the man to tell, as I said, it
has been only a few months since I began with WebERP and it's only now when
I'm beginning to know it.

Many Thanks,
javier

----- Original Message -----
From: "Dale Scott" <dalescott@...>
To: "'webERP Developers'" <web-erp-developers@...>
Sent: Sunday, November 01, 2009 6:06 PM
Subject: Re: [WebERP-developers] Thoughts On The API

> Does having an automated test system for WebERP based on the API make
> sense?
> I haven't developed automated testing for a web app before, but it would
> seem that a mature API covering core transactions would enable simple
> automated testing of that core functionality. I suspect that simply
> identifying core transactional functionality by creation of an automated
> test suite would lead to distinction between core and GUI, which may also
> be
> good.
>
> You can listen to a good overview of Drupal's (a popular CMS) test
> environment while you're commuting to work - see
> http://www.lullabot.com/drupal-voices/drupal-voices-66-jimmy-berry-drupal-te
> st-framework
>
> I'm not in a position to contribute coding, but are there specific hot
> topics where a non-coder could help out? Documentation, testing, ....
> Something specific with well-defined requirements would be a good
> mini-project to get started (and it doesn't have to be associated with
> automated testing). Any suggestions?
>
> Dale
>
> -----Original Message-----
> From: Lindsay Harris [mailto:lindsay@...]
> Sent: October-31-09 10:01 PM
> To: webERP Developers
> Subject: Re: [WebERP-developers] Thoughts On The API
>
> Tim,
> Thanks for the long and informative reply.  I agree that the API could
> be the killer app for webERP.  I understood that as soon as I
> discovered what you had done.    And I would have used the same
> strategy that you have did for implementing the bits I need now.
>
> I am quite happy to sink my teeth into this and fix/extend/polish as
> appropriate, and for the needs I have!  After all, that's part of the
> benefits of open source - people contribute the bits they need/want
> to make it better for others.
>
> I had another thought last night,  and this might make the interface
> much simpler.  Rather than using an RPC mechanism with many methods,
> have a URL that accepts an XML encoded transaction.  For example, to
> enter a sales order, something like:
>
> <sales order>
> <sales header>
>    <customer id>value</customer id>
>    <del addr 1>24 big street</del addr 1>
> </sales header>
> <sales item line>
>    <stockid>prod1</stockid>
>    <price>27.34</price>
>  </sales item line>
> </sales order>
>
> You get the idea.  The above may not be valid XML, it's for
> illustration. The tags would have a 1:1 correspondence with the
> database fields in which the value is placed.
>
> This brings the interaction between systems to a text interaction over
> an HTTP channel - basic stuff I would expect to be very adaptable.
> Although the XML tags are ASCII, the values would need to be accept
> multiple encodings/utf-8 or whatever - I haven't been following that
> discussion.  I presume that XML can handle that.
>
> I am assuming that PHP has some functionality to handle XML document
> parsing - that is my next task :)
>
> What do others think of this?
>
> Lindsay
>
>
>
> On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
>> Hi Lindsay,
>>
>> I agree with most of your points.
>>
>> A bit of history - I created the API principally because I needed
>> to integrate webERP with a hospital information system Care2x
>> (https://sourceforge.net/projects/care2002/). Although I wanted to
>> keep it as generalised as possible, by necessity I tended to code
>> up those functions I needed, which is why there are gaps in the
>> functionality such as supplier transactions that Royce pointed out.
>> I had a rather grand idea of a unified login module that would
>> allow users to authenticate with this module and then access either
>> webERP or Care2x within the same session. Unfortunately due to time
>> constraints this never got beyond being an idea. However the system
>> works fine with Care2x in several hospitals now. I have since done
>> a "proof of concept" example to show webERP working with oscommerce
>> through the api.
>>
>> The web browser in the examples is just the interface to the client
>> application. The communication is between the two applications on
>> the server.
>>
>> There are several weaknesses with it at the moment, and you have
>> pointed out two major ones. The first is the authentication. This
>> needs to be improved. I never quite got my head around how the two
>> applications would both track the session and as it wasn't vital
>> for my particular purposes I left it as it was. In theory the
>> client app could be anything written in any language on any
>> platform.
>>
>> The other is the necessity to hard code the database name, which is
>> clearly unsatisfactory. You might want to access several databases
>> through the same server. I think this should be the clients
>> responsibility to tell the server which database to update. Should
>> this be passed at authentication time and stored in a session
>> variable on the server side, as there would need to be a check that
>> the client had authority for that database?
>>
>> I have always thought that the api had the potential to be "a
>> killer app" for webERP but never really had the time to polish it
>> as much as it deserves. Help would be greatly appreciated.
>>
>> Thanks
>> Tim
>>
>> -------------------------------------------------------------------
>>----------- Come build with us! The BlackBerry(R) Developer
>> Conference in SF, CA is the only developer event you need to attend
>> this year. Jumpstart your developing skills, take BlackBerry mobile
>> applications to market and stay ahead of the curve. Join us from
>> November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web-erp-developers@...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> ----------------------------------------------------------------------------
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers 

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[royce]

Hi Tim, my 'overly complex' comment was specifically referring to relying on the 3rd party XMLRPC library (xmlrpc.inc 112k, xmlrpc_wrappers.inc 29K, xmlrpcs.inc 38K, and a 'compat' directory).  Again, I'm not a interprocess communication expert, but all of that stuff is unnecessary with a REST architecture - http does all of that plumbing for you.  

I would love to use the existing webERP API architecture - but the 'hard to get working' part is frustrating .  As I said in my last post, right now I'm getting an HTTP 500 error, and I'm not sure if that's coming from the API, the XMPRPC library, webERP itself, Apache, PHP, our interface to the API, our use of a subdomain, etc.

It certainly wouldn't make any sense to re-invent the wheel, and I wouldn't expect the community to embark on a new direction based on my experiences.  I'm just throwing it out there as food for thought for anyone else that may be running into issues.  

Tim Schofield wrote:

Hi Royce,

I'm not sure in what way you consider it overly complex. I accept that
its not robust enough and can be hard to get working, but from a
client point of view its really fairly simple to use. I would have
thought that it was best to devote our efforts to improving the
current api rather than trying to re implement a server which would be
a complex job. However its open source, so if people want to write an
api with other protocols then that is also fine.

Tim

[Tim Schofield]

Actually php has its own xmlrpc stuff written in, and it may make
sense to change the api to use that rather than the external library,
although I believe that to be better.

Regarding your error, have you tried setting the debug level to 2 in
the client? I find this often produces good debug information.

Tim


2009/11/1 royce <royce@...>:

>
> Hi Tim, my 'overly complex' comment was specifically referring to relying on
> the 3rd party XMLRPC library (xmlrpc.inc 112k, xmlrpc_wrappers.inc 29K,
> xmlrpcs.inc 38K, and a 'compat' directory).  Again, I'm not a interprocess
> communication expert, but all of that stuff is unnecessary with a REST
> architecture - http does all of that plumbing for you.
>
> I would love to use the existing webERP API architecture - but the 'hard to
> get working' part is frustrating :-).  As I said in my last post, right now
> I'm getting an HTTP 500 error, and I'm not sure if that's coming from the
> API, the XMPRPC library, webERP itself, Apache, PHP, our interface to the
> API, our use of a subdomain, etc.
>
> It certainly wouldn't make any sense to re-invent the wheel, and I wouldn't
> expect the community to embark on a new direction based on my experiences.
> I'm just throwing it out there as food for thought for anyone else that may
> be running into issues.
>
> Tim Schofield wrote:
>>
>> Hi Royce,
>>
>> I'm not sure in what way you consider it overly complex. I accept that
>> its not robust enough and can be hard to get working, but from a
>> client point of view its really fairly simple to use. I would have
>> thought that it was best to devote our efforts to improving the
>> current api rather than trying to re implement a server which would be
>> a complex job. However its open source, so if people want to write an
>> api with other protocols then that is also fine.
>>
>> Tim
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Thoughts-On-The-API-tp26141405p26154271.html
> Sent from the web-erp-developers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Lindsay Harris]

Hi,  Royce,

I've spent the morning looking over REST, and XMLRPC, and sparingly at
Amazon's web services structure etc.    As I understand it, REST is
basically an architecture definition,  not a specific set of
operations.   That is, if we used REST,  all that says is we do
things in this (to me rather obvious) way.   We still have to define
what the messages/interactions are.

Is that your understanding?   I may have quite misunderstood things
while reading them.

As for the HTTP 500 errors with the existing API,  grab the latest CVS
version and try that - Tim added my recent fixes to solve those
problems.   Remember that the database name is hard coded in the file
api/api_php.php.   I *think* I posted ALL the changes I made  :-(

Lindsay

On Mon, 2 Nov 2009 05:26:23 royce wrote:

> Hi there, I'm also interested in the API.  My ultimate goal would
> be to be able to automatically process the XML files that we get
> from our order processing, vendors, shipping, etc systems.
>
> I'm certainly no expert on XMLRPC vs. other methods of inter
> process communications, but it seems that the current
> implementation architecture is way overly complex.  I AM very
> familiar with REST based interfaces, and I'm more inclined to go
> towards that method.  That is the protocol for Amazon, Paypal,
> authorize.net, Google analyticis, and many other highly secure web
> services.
>
> I'm a noob to webERP so I'm not sure how practical converting it to
> REST would be, but right now I'm testing out the XMLRPC API  and
> I'm getting a HTTP 500 error code on our system - this may be
> because we are testing it under a subdomain to our production UNIX
> server (it worked fine on our initial testing on our local LAMPP XP
> box).
>
> Absent a working API, we would be forced to rewrite the functions
> and totally cut out the XMPRPC stuff.  That option doesn't seem
> that difficult, but if possible, I would rather assist in rewriting
> the API for general use using an REST based approach.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Lindsay Harris]

Hi,  Tim.

Your reply (the part about XMLRPC) has got me thinking again.  This is
sometimes dangerous!

I don't see any specific reason that webERP must have just one API.  
The important part of what you have done (as far as I am concerned)
is to provide access into the innards of webERP independent of a web
browser.

So now the thought is that there would be 2 levels of API.  An
internal one that interacts with webERP and the database.  This would
be very close, if not almost identical, to what you have done
already.    This would be a "private" API, in the sense that no other
entity would be expected to use it.

There would be a second level of public APIs - and not limited to just
one type.  These would build on top of the above set,  but be
available for the world to use.   Generally, the mapping from public
to private would be fairly simple in the case of the XMLRPC
interface.  But could be more complex,  if required/desired.  The
benefit of this approach is that webERP then has the structure to
accept new methods/standards of interaction as they appear,  without
having to get into the guts of the code/database - just create a new
frontend that uses the internal API.

And a question:  there are many implementations of XML-RPC, as listed
here:- http://www.xmlrpc.com/directory/1568/implementations   I
presume these are cross compatible, e.g. a C client would connect
correctly with a python server, for instance.  Is this so?

Lindsay

On Mon, 2 Nov 2009 06:04:02 Tim Schofield wrote:

> Hi Lindsay,
>
> Help to polish up the api would be greatly appreciated. Other than
> the authentication issue and the hard coding of the db name, some
> of the error handling is inconsistent and needs to be more robust.
> Obviously there are more functions that could be added as well.
>
> I chose xmlrpc as the protocol for several reasons. Firstly it was
> a protocol I know very well having used it many times in the past.
> Also it is simple elegant and lightweight. I felt it fitted well
> with the philosophy of webERP. Although I can see merits in your
> idea I would be reluctant to change to any other method now,
> especially as I have the current api working in a number of
> locations.
>
> Thanks
> Tim
>
> 2009/11/1 Lindsay Harris <lindsay@...>:
> > Tim,
> > Thanks for the long and informative reply.  I agree that the API
> > could be the killer app for webERP.  I understood that as soon as
> > I discovered what you had done.    And I would have used the same
> > strategy that you have did for implementing the bits I need now.
> >
> > I am quite happy to sink my teeth into this and fix/extend/polish
> > as appropriate, and for the needs I have!  After all, that's part
> > of the benefits of open source - people contribute the bits they
> > need/want to make it better for others.
> >
> > I had another thought last night,  and this might make the
> > interface much simpler.  Rather than using an RPC mechanism with
> > many methods, have a URL that accepts an XML encoded transaction.
> >  For example, to enter a sales order, something like:
> >
> > <sales order>
> >  <sales header>
> >    <customer id>value</customer id>
> >    <del addr 1>24 big street</del addr 1>
> >  </sales header>
> >  <sales item line>
> >    <stockid>prod1</stockid>
> >    <price>27.34</price>
> >  </sales item line>
> > </sales order>
> >
> > You get the idea.  The above may not be valid XML, it's for
> > illustration. The tags would have a 1:1 correspondence with the
> > database fields in which the value is placed.
> >
> > This brings the interaction between systems to a text interaction
> > over an HTTP channel - basic stuff I would expect to be very
> > adaptable. Although the XML tags are ASCII, the values would need
> > to be accept multiple encodings/utf-8 or whatever - I haven't
> > been following that discussion.  I presume that XML can handle
> > that.
> >
> > I am assuming that PHP has some functionality to handle XML
> > document parsing - that is my next task :)
> >
> > What do others think of this?
> >
> > Lindsay
> >
> > On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
> >> Hi Lindsay,
> >>
> >> I agree with most of your points.
> >>
> >> A bit of history - I created the API principally because I
> >> needed to integrate webERP with a hospital information system
> >> Care2x (https://sourceforge.net/projects/care2002/). Although I
> >> wanted to keep it as generalised as possible, by necessity I
> >> tended to code up those functions I needed, which is why there
> >> are gaps in the functionality such as supplier transactions that
> >> Royce pointed out. I had a rather grand idea of a unified login
> >> module that would allow users to authenticate with this module
> >> and then access either webERP or Care2x within the same session.
> >> Unfortunately due to time constraints this never got beyond
> >> being an idea. However the system works fine with Care2x in
> >> several hospitals now. I have since done a "proof of concept"
> >> example to show webERP working with oscommerce through the api.
> >>
> >> The web browser in the examples is just the interface to the
> >> client application. The communication is between the two
> >> applications on the server.
> >>
> >> There are several weaknesses with it at the moment, and you have
> >> pointed out two major ones. The first is the authentication.
> >> This needs to be improved. I never quite got my head around how
> >> the two applications would both track the session and as it
> >> wasn't vital for my particular purposes I left it as it was. In
> >> theory the client app could be anything written in any language
> >> on any platform.
> >>
> >> The other is the necessity to hard code the database name, which
> >> is clearly unsatisfactory. You might want to access several
> >> databases through the same server. I think this should be the
> >> clients responsibility to tell the server which database to
> >> update. Should this be passed at authentication time and stored
> >> in a session variable on the server side, as there would need to
> >> be a check that the client had authority for that database?
> >>
> >> I have always thought that the api had the potential to be "a
> >> killer app" for webERP but never really had the time to polish
> >> it as much as it deserves. Help would be greatly appreciated.
> >>
> >> Thanks
> >> Tim
> >>
> >> ----------------------------------------------------------------
> >>--- ----------- Come build with us! The BlackBerry(R) Developer
> >> Conference in SF, CA is the only developer event you need to
> >> attend this year. Jumpstart your developing skills, take
> >> BlackBerry mobile applications to market and stay ahead of the
> >> curve. Join us from November 9 - 12, 2009. Register now!
> >> http://p.sf.net/sfu/devconference
> >> _______________________________________________
> >> Web-erp-developers mailing list
> >> Web-erp-developers@...
> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
> > -----------------------------------------------------------------
> >------------- Come build with us! The BlackBerry(R) Developer
> > Conference in SF, CA is the only developer event you need to
> > attend this year. Jumpstart your developing skills, take
> > BlackBerry mobile applications to market and stay ahead of the
> > curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web-erp-developers@...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
> -------------------------------------------------------------------
>----------- Come build with us! The BlackBerry(R) Developer
> Conference in SF, CA is the only developer event you need to attend
> this year. Jumpstart your developing skills, take BlackBerry mobile
> applications to market and stay ahead of the curve. Join us from
> November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Tim Schofield]

Hi Lindsay,

You are correct, any language/platform combination that has an xml-rpc
implementation for it can communicate with webERP via the api, and
webERP can have a SOAP api, REST api etc.

Whatever we do we still need to expose the current interface as there
are people already using it. I still think as people get used to it
they will find the xml-rpc system easy to use. The reason the amazon
api is easier to use is not that REST is any easier, just the fact
that they can afford to have a number of programmers polishing the
server up so as to make it user friendly. I still believe that this is
what we need.

The way I have built client apps using php is to have a standard class
which does all the work of creating the client, encoding and decoding
the data and performing the communication with webERP. This class can
be used by any application. I can let anyone who wants have a copy of
this. I then have an application specific class that inherits the
first one and has methods that are specific to that application. For
example, in my hospital information system implementation class_weberp
has 2 methods one to create a customer another to create a branch. The
app specific class - class_weberp_c2x - has a method to create a
patient as a customer, that calls both of the methods of class_weberp.
Thus the only code that actually needs inserting in the care2x code is
two lines:

$weberpObject=new class_weberp_c2x;
$weberpObject->CreatePatientAsCustomer($PatientData);

and the patient is created in webERP as a customer with a branch as
well. It really is that simple once the classes have been built, and I
have done most of that work already.

Tim

2009/11/2 Lindsay Harris <lindsay@...>:

> Hi,  Tim.
>
> Your reply (the part about XMLRPC) has got me thinking again.  This is
> sometimes dangerous!
>
> I don't see any specific reason that webERP must have just one API.
> The important part of what you have done (as far as I am concerned)
> is to provide access into the innards of webERP independent of a web
> browser.
>
> So now the thought is that there would be 2 levels of API.  An
> internal one that interacts with webERP and the database.  This would
> be very close, if not almost identical, to what you have done
> already.    This would be a "private" API, in the sense that no other
> entity would be expected to use it.
>
> There would be a second level of public APIs - and not limited to just
> one type.  These would build on top of the above set,  but be
> available for the world to use.   Generally, the mapping from public
> to private would be fairly simple in the case of the XMLRPC
> interface.  But could be more complex,  if required/desired.  The
> benefit of this approach is that webERP then has the structure to
> accept new methods/standards of interaction as they appear,  without
> having to get into the guts of the code/database - just create a new
> frontend that uses the internal API.
>
> And a question:  there are many implementations of XML-RPC, as listed
> here:- http://www.xmlrpc.com/directory/1568/implementations   I
> presume these are cross compatible, e.g. a C client would connect
> correctly with a python server, for instance.  Is this so?
>
> Lindsay
>
> On Mon, 2 Nov 2009 06:04:02 Tim Schofield wrote:
>> Hi Lindsay,
>>
>> Help to polish up the api would be greatly appreciated. Other than
>> the authentication issue and the hard coding of the db name, some
>> of the error handling is inconsistent and needs to be more robust.
>> Obviously there are more functions that could be added as well.
>>
>> I chose xmlrpc as the protocol for several reasons. Firstly it was
>> a protocol I know very well having used it many times in the past.
>> Also it is simple elegant and lightweight. I felt it fitted well
>> with the philosophy of webERP. Although I can see merits in your
>> idea I would be reluctant to change to any other method now,
>> especially as I have the current api working in a number of
>> locations.
>>
>> Thanks
>> Tim
>>
>> 2009/11/1 Lindsay Harris <lindsay@...>:
>> > Tim,
>> > Thanks for the long and informative reply.  I agree that the API
>> > could be the killer app for webERP.  I understood that as soon as
>> > I discovered what you had done.    And I would have used the same
>> > strategy that you have did for implementing the bits I need now.
>> >
>> > I am quite happy to sink my teeth into this and fix/extend/polish
>> > as appropriate, and for the needs I have!  After all, that's part
>> > of the benefits of open source - people contribute the bits they
>> > need/want to make it better for others.
>> >
>> > I had another thought last night,  and this might make the
>> > interface much simpler.  Rather than using an RPC mechanism with
>> > many methods, have a URL that accepts an XML encoded transaction.
>> >  For example, to enter a sales order, something like:
>> >
>> > <sales order>
>> >  <sales header>
>> >    <customer id>value</customer id>
>> >    <del addr 1>24 big street</del addr 1>
>> >  </sales header>
>> >  <sales item line>
>> >    <stockid>prod1</stockid>
>> >    <price>27.34</price>
>> >  </sales item line>
>> > </sales order>
>> >
>> > You get the idea.  The above may not be valid XML, it's for
>> > illustration. The tags would have a 1:1 correspondence with the
>> > database fields in which the value is placed.
>> >
>> > This brings the interaction between systems to a text interaction
>> > over an HTTP channel - basic stuff I would expect to be very
>> > adaptable. Although the XML tags are ASCII, the values would need
>> > to be accept multiple encodings/utf-8 or whatever - I haven't
>> > been following that discussion.  I presume that XML can handle
>> > that.
>> >
>> > I am assuming that PHP has some functionality to handle XML
>> > document parsing - that is my next task :)
>> >
>> > What do others think of this?
>> >
>> > Lindsay
>> >
>> > On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
>> >> Hi Lindsay,
>> >>
>> >> I agree with most of your points.
>> >>
>> >> A bit of history - I created the API principally because I
>> >> needed to integrate webERP with a hospital information system
>> >> Care2x (https://sourceforge.net/projects/care2002/). Although I
>> >> wanted to keep it as generalised as possible, by necessity I
>> >> tended to code up those functions I needed, which is why there
>> >> are gaps in the functionality such as supplier transactions that
>> >> Royce pointed out. I had a rather grand idea of a unified login
>> >> module that would allow users to authenticate with this module
>> >> and then access either webERP or Care2x within the same session.
>> >> Unfortunately due to time constraints this never got beyond
>> >> being an idea. However the system works fine with Care2x in
>> >> several hospitals now. I have since done a "proof of concept"
>> >> example to show webERP working with oscommerce through the api.
>> >>
>> >> The web browser in the examples is just the interface to the
>> >> client application. The communication is between the two
>> >> applications on the server.
>> >>
>> >> There are several weaknesses with it at the moment, and you have
>> >> pointed out two major ones. The first is the authentication.
>> >> This needs to be improved. I never quite got my head around how
>> >> the two applications would both track the session and as it
>> >> wasn't vital for my particular purposes I left it as it was. In
>> >> theory the client app could be anything written in any language
>> >> on any platform.
>> >>
>> >> The other is the necessity to hard code the database name, which
>> >> is clearly unsatisfactory. You might want to access several
>> >> databases through the same server. I think this should be the
>> >> clients responsibility to tell the server which database to
>> >> update. Should this be passed at authentication time and stored
>> >> in a session variable on the server side, as there would need to
>> >> be a check that the client had authority for that database?
>> >>
>> >> I have always thought that the api had the potential to be "a
>> >> killer app" for webERP but never really had the time to polish
>> >> it as much as it deserves. Help would be greatly appreciated.
>> >>
>> >> Thanks
>> >> Tim
>> >>
>> >> ----------------------------------------------------------------
>> >>--- ----------- Come build with us! The BlackBerry(R) Developer
>> >> Conference in SF, CA is the only developer event you need to
>> >> attend this year. Jumpstart your developing skills, take
>> >> BlackBerry mobile applications to market and stay ahead of the
>> >> curve. Join us from November 9 - 12, 2009. Register now!
>> >> http://p.sf.net/sfu/devconference
>> >> _______________________________________________
>> >> Web-erp-developers mailing list
>> >> Web-erp-developers@...
>> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> >
>> > -----------------------------------------------------------------
>> >------------- Come build with us! The BlackBerry(R) Developer
>> > Conference in SF, CA is the only developer event you need to
>> > attend this year. Jumpstart your developing skills, take
>> > BlackBerry mobile applications to market and stay ahead of the
>> > curve. Join us from November 9 - 12, 2009. Register now!
>> > http://p.sf.net/sfu/devconference
>> > _______________________________________________
>> > Web-erp-developers mailing list
>> > Web-erp-developers@...
>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>> -------------------------------------------------------------------
>>----------- Come build with us! The BlackBerry(R) Developer
>> Conference in SF, CA is the only developer event you need to attend
>> this year. Jumpstart your developing skills, take BlackBerry mobile
>> applications to market and stay ahead of the curve. Join us from
>> November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web-erp-developers@...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Lindsay Harris]

Hi,  Tim.

I agree that we cannot break existing interfaces.  Unnecessarily  
annoying our users is not a good policy for peaceful life.

Perhaps we should now be considering an SDK (software developers kit)
for the API side of webERP.  Sample code goes a long way to getting
users started.   I speak from experience :)   I'd suggest this be a
distinct zip file from the basic package.  Your 2 classes sound like
an excellent starting point.

If I can grab a copy,  I'll put them into a "releasable" condition,
with notes written as I get it working.

I've also been thinking about how to automate some of the parameter
checking/verification code in the API functions.  Note: I've only
looked at a couple, so this is a very preliminary concept.   The idea
revolves around making them table driven, with the table indexed by
the parameter name, containing parameter type and possible limits
and/or a function to call to validate.  Some of this, at least, could
be automatically generated from the DB schema;  I would see this as
being done during a "table build" phase, not dynamically at run time.

Validation would be done in a common function, using the data passed
in and the name of the function name that is calling or the
validation table for the calling function.  I think this would shrink
the size of the code for each function, as well as reduce the often
tediously generated sequence of calls for validation, and should also
reduce errors.

Lindsay

On Mon, 2 Nov 2009 22:42:18 Tim Schofield wrote:

> Hi Lindsay,
>
> You are correct, any language/platform combination that has an
> xml-rpc implementation for it can communicate with webERP via the
> api, and webERP can have a SOAP api, REST api etc.
>
> Whatever we do we still need to expose the current interface as
> there are people already using it. I still think as people get used
> to it they will find the xml-rpc system easy to use. The reason the
> amazon api is easier to use is not that REST is any easier, just
> the fact that they can afford to have a number of programmers
> polishing the server up so as to make it user friendly. I still
> believe that this is what we need.
>
> The way I have built client apps using php is to have a standard
> class which does all the work of creating the client, encoding and
> decoding the data and performing the communication with webERP.
> This class can be used by any application. I can let anyone who
> wants have a copy of this. I then have an application specific
> class that inherits the first one and has methods that are specific
> to that application. For example, in my hospital information system
> implementation class_weberp has 2 methods one to create a customer
> another to create a branch. The app specific class -
> class_weberp_c2x - has a method to create a patient as a customer,
> that calls both of the methods of class_weberp. Thus the only code
> that actually needs inserting in the care2x code is two lines:
>
> $weberpObject=new class_weberp_c2x;
> $weberpObject->CreatePatientAsCustomer($PatientData);
>
> and the patient is created in webERP as a customer with a branch as
> well. It really is that simple once the classes have been built,
> and I have done most of that work already.
>
> Tim
>
> 2009/11/2 Lindsay Harris <lindsay@...>:
> > Hi,  Tim.
> >
> > Your reply (the part about XMLRPC) has got me thinking again.
> >  This is sometimes dangerous!
> >
> > I don't see any specific reason that webERP must have just one
> > API. The important part of what you have done (as far as I am
> > concerned) is to provide access into the innards of webERP
> > independent of a web browser.
> >
> > So now the thought is that there would be 2 levels of API.  An
> > internal one that interacts with webERP and the database.  This
> > would be very close, if not almost identical, to what you have
> > done already.    This would be a "private" API, in the sense that
> > no other entity would be expected to use it.
> >
> > There would be a second level of public APIs - and not limited to
> > just one type.  These would build on top of the above set,  but
> > be available for the world to use.   Generally, the mapping from
> > public to private would be fairly simple in the case of the
> > XMLRPC interface.  But could be more complex,  if
> > required/desired.  The benefit of this approach is that webERP
> > then has the structure to accept new methods/standards of
> > interaction as they appear,  without having to get into the guts
> > of the code/database - just create a new frontend that uses the
> > internal API.
> >
> > And a question:  there are many implementations of XML-RPC, as
> > listed here:-
> > http://www.xmlrpc.com/directory/1568/implementations   I presume
> > these are cross compatible, e.g. a C client would connect
> > correctly with a python server, for instance.  Is this so?
> >
> > Lindsay
> >
> > On Mon, 2 Nov 2009 06:04:02 Tim Schofield wrote:
> >> Hi Lindsay,
> >>
> >> Help to polish up the api would be greatly appreciated. Other
> >> than the authentication issue and the hard coding of the db
> >> name, some of the error handling is inconsistent and needs to be
> >> more robust. Obviously there are more functions that could be
> >> added as well.
> >>
> >> I chose xmlrpc as the protocol for several reasons. Firstly it
> >> was a protocol I know very well having used it many times in the
> >> past. Also it is simple elegant and lightweight. I felt it
> >> fitted well with the philosophy of webERP. Although I can see
> >> merits in your idea I would be reluctant to change to any other
> >> method now, especially as I have the current api working in a
> >> number of locations.
> >>
> >> Thanks
> >> Tim
> >>
> >> 2009/11/1 Lindsay Harris <lindsay@...>:
> >> > Tim,
> >> > Thanks for the long and informative reply.  I agree that the
> >> > API could be the killer app for webERP.  I understood that as
> >> > soon as I discovered what you had done.    And I would have
> >> > used the same strategy that you have did for implementing the
> >> > bits I need now.
> >> >
> >> > I am quite happy to sink my teeth into this and
> >> > fix/extend/polish as appropriate, and for the needs I have!
> >> >  After all, that's part of the benefits of open source -
> >> > people contribute the bits they need/want to make it better
> >> > for others.
> >> >
> >> > I had another thought last night,  and this might make the
> >> > interface much simpler.  Rather than using an RPC mechanism
> >> > with many methods, have a URL that accepts an XML encoded
> >> > transaction. For example, to enter a sales order, something
> >> > like:
> >> >
> >> > <sales order>
> >> >  <sales header>
> >> >    <customer id>value</customer id>
> >> >    <del addr 1>24 big street</del addr 1>
> >> >  </sales header>
> >> >  <sales item line>
> >> >    <stockid>prod1</stockid>
> >> >    <price>27.34</price>
> >> >  </sales item line>
> >> > </sales order>
> >> >
> >> > You get the idea.  The above may not be valid XML, it's for
> >> > illustration. The tags would have a 1:1 correspondence with
> >> > the database fields in which the value is placed.
> >> >
> >> > This brings the interaction between systems to a text
> >> > interaction over an HTTP channel - basic stuff I would expect
> >> > to be very adaptable. Although the XML tags are ASCII, the
> >> > values would need to be accept multiple encodings/utf-8 or
> >> > whatever - I haven't been following that discussion.  I
> >> > presume that XML can handle that.
> >> >
> >> > I am assuming that PHP has some functionality to handle XML
> >> > document parsing - that is my next task :)
> >> >
> >> > What do others think of this?
> >> >
> >> > Lindsay
> >> >
> >> > On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
> >> >> Hi Lindsay,
> >> >>
> >> >> I agree with most of your points.
> >> >>
> >> >> A bit of history - I created the API principally because I
> >> >> needed to integrate webERP with a hospital information system
> >> >> Care2x (https://sourceforge.net/projects/care2002/). Although
> >> >> I wanted to keep it as generalised as possible, by necessity
> >> >> I tended to code up those functions I needed, which is why
> >> >> there are gaps in the functionality such as supplier
> >> >> transactions that Royce pointed out. I had a rather grand
> >> >> idea of a unified login module that would allow users to
> >> >> authenticate with this module and then access either webERP
> >> >> or Care2x within the same session. Unfortunately due to time
> >> >> constraints this never got beyond being an idea. However the
> >> >> system works fine with Care2x in several hospitals now. I
> >> >> have since done a "proof of concept" example to show webERP
> >> >> working with oscommerce through the api.
> >> >>
> >> >> The web browser in the examples is just the interface to the
> >> >> client application. The communication is between the two
> >> >> applications on the server.
> >> >>
> >> >> There are several weaknesses with it at the moment, and you
> >> >> have pointed out two major ones. The first is the
> >> >> authentication. This needs to be improved. I never quite got
> >> >> my head around how the two applications would both track the
> >> >> session and as it wasn't vital for my particular purposes I
> >> >> left it as it was. In theory the client app could be anything
> >> >> written in any language on any platform.
> >> >>
> >> >> The other is the necessity to hard code the database name,
> >> >> which is clearly unsatisfactory. You might want to access
> >> >> several databases through the same server. I think this
> >> >> should be the clients responsibility to tell the server which
> >> >> database to update. Should this be passed at authentication
> >> >> time and stored in a session variable on the server side, as
> >> >> there would need to be a check that the client had authority
> >> >> for that database?
> >> >>
> >> >> I have always thought that the api had the potential to be "a
> >> >> killer app" for webERP but never really had the time to
> >> >> polish it as much as it deserves. Help would be greatly
> >> >> appreciated.
> >> >>
> >> >> Thanks
> >> >> Tim
> >> >>
> >> >> -------------------------------------------------------------
> >> >>--- --- ----------- Come build with us! The BlackBerry(R)
> >> >> Developer Conference in SF, CA is the only developer event
> >> >> you need to attend this year. Jumpstart your developing
> >> >> skills, take BlackBerry mobile applications to market and
> >> >> stay ahead of the curve. Join us from November 9 - 12, 2009.
> >> >> Register now! http://p.sf.net/sfu/devconference
> >> >> _______________________________________________
> >> >> Web-erp-developers mailing list
> >> >> Web-erp-developers@...
> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-develope
> >> >>rs
> >> >
> >> > --------------------------------------------------------------
> >> >--- ------------- Come build with us! The BlackBerry(R)
> >> > Developer Conference in SF, CA is the only developer event you
> >> > need to attend this year. Jumpstart your developing skills,
> >> > take BlackBerry mobile applications to market and stay ahead
> >> > of the curve. Join us from November 9 - 12, 2009. Register
> >> > now! http://p.sf.net/sfu/devconference
> >> > _______________________________________________
> >> > Web-erp-developers mailing list
> >> > Web-erp-developers@...
> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developer
> >> >s
> >>
> >> ----------------------------------------------------------------
> >>--- ----------- Come build with us! The BlackBerry(R) Developer
> >> Conference in SF, CA is the only developer event you need to
> >> attend this year. Jumpstart your developing skills, take
> >> BlackBerry mobile applications to market and stay ahead of the
> >> curve. Join us from November 9 - 12, 2009. Register now!
> >> http://p.sf.net/sfu/devconference
> >> _______________________________________________
> >> Web-erp-developers mailing list
> >> Web-erp-developers@...
> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
> > -----------------------------------------------------------------
> >------------- Come build with us! The BlackBerry(R) Developer
> > Conference in SF, CA is the only developer event you need to
> > attend this year. Jumpstart your developing skills, take
> > BlackBerry mobile applications to market and stay ahead of the
> > curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web-erp-developers@...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
> -------------------------------------------------------------------
>----------- Come build with us! The BlackBerry(R) Developer
> Conference in SF, CA is the only developer event you need to attend
> this year. Jumpstart your developing skills, take BlackBerry mobile
> applications to market and stay ahead of the curve. Join us from
> November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Tim Schofield]

Hi Lindsay,

I will send you the classes off list.

I'm not sure if I understand your suggestion correctly, so if I am
talking rubbish please tell me :) A number of API transactions contain
multiple calls to multiple database tables. For instance think of
raising a sales invoice for a stock item. How would your method work
with this?

Tim


2009/11/3 Lindsay Harris <lindsay@...>:

> Hi,  Tim.
>
> I agree that we cannot break existing interfaces.  Unnecessarily
> annoying our users is not a good policy for peaceful life.
>
> Perhaps we should now be considering an SDK (software developers kit)
> for the API side of webERP.  Sample code goes a long way to getting
> users started.   I speak from experience :)   I'd suggest this be a
> distinct zip file from the basic package.  Your 2 classes sound like
> an excellent starting point.
>
> If I can grab a copy,  I'll put them into a "releasable" condition,
> with notes written as I get it working.
>
> I've also been thinking about how to automate some of the parameter
> checking/verification code in the API functions.  Note: I've only
> looked at a couple, so this is a very preliminary concept.   The idea
> revolves around making them table driven, with the table indexed by
> the parameter name, containing parameter type and possible limits
> and/or a function to call to validate.  Some of this, at least, could
> be automatically generated from the DB schema;  I would see this as
> being done during a "table build" phase, not dynamically at run time.
>
> Validation would be done in a common function, using the data passed
> in and the name of the function name that is calling or the
> validation table for the calling function.  I think this would shrink
> the size of the code for each function, as well as reduce the often
> tediously generated sequence of calls for validation, and should also
> reduce errors.
>
> Lindsay
>
> On Mon, 2 Nov 2009 22:42:18 Tim Schofield wrote:
>> Hi Lindsay,
>>
>> You are correct, any language/platform combination that has an
>> xml-rpc implementation for it can communicate with webERP via the
>> api, and webERP can have a SOAP api, REST api etc.
>>
>> Whatever we do we still need to expose the current interface as
>> there are people already using it. I still think as people get used
>> to it they will find the xml-rpc system easy to use. The reason the
>> amazon api is easier to use is not that REST is any easier, just
>> the fact that they can afford to have a number of programmers
>> polishing the server up so as to make it user friendly. I still
>> believe that this is what we need.
>>
>> The way I have built client apps using php is to have a standard
>> class which does all the work of creating the client, encoding and
>> decoding the data and performing the communication with webERP.
>> This class can be used by any application. I can let anyone who
>> wants have a copy of this. I then have an application specific
>> class that inherits the first one and has methods that are specific
>> to that application. For example, in my hospital information system
>> implementation class_weberp has 2 methods one to create a customer
>> another to create a branch. The app specific class -
>> class_weberp_c2x - has a method to create a patient as a customer,
>> that calls both of the methods of class_weberp. Thus the only code
>> that actually needs inserting in the care2x code is two lines:
>>
>> $weberpObject=new class_weberp_c2x;
>> $weberpObject->CreatePatientAsCustomer($PatientData);
>>
>> and the patient is created in webERP as a customer with a branch as
>> well. It really is that simple once the classes have been built,
>> and I have done most of that work already.
>>
>> Tim
>>
>> 2009/11/2 Lindsay Harris <lindsay@...>:
>> > Hi,  Tim.
>> >
>> > Your reply (the part about XMLRPC) has got me thinking again.
>> >  This is sometimes dangerous!
>> >
>> > I don't see any specific reason that webERP must have just one
>> > API. The important part of what you have done (as far as I am
>> > concerned) is to provide access into the innards of webERP
>> > independent of a web browser.
>> >
>> > So now the thought is that there would be 2 levels of API.  An
>> > internal one that interacts with webERP and the database.  This
>> > would be very close, if not almost identical, to what you have
>> > done already.    This would be a "private" API, in the sense that
>> > no other entity would be expected to use it.
>> >
>> > There would be a second level of public APIs - and not limited to
>> > just one type.  These would build on top of the above set,  but
>> > be available for the world to use.   Generally, the mapping from
>> > public to private would be fairly simple in the case of the
>> > XMLRPC interface.  But could be more complex,  if
>> > required/desired.  The benefit of this approach is that webERP
>> > then has the structure to accept new methods/standards of
>> > interaction as they appear,  without having to get into the guts
>> > of the code/database - just create a new frontend that uses the
>> > internal API.
>> >
>> > And a question:  there are many implementations of XML-RPC, as
>> > listed here:-
>> > http://www.xmlrpc.com/directory/1568/implementations   I presume
>> > these are cross compatible, e.g. a C client would connect
>> > correctly with a python server, for instance.  Is this so?
>> >
>> > Lindsay
>> >
>> > On Mon, 2 Nov 2009 06:04:02 Tim Schofield wrote:
>> >> Hi Lindsay,
>> >>
>> >> Help to polish up the api would be greatly appreciated. Other
>> >> than the authentication issue and the hard coding of the db
>> >> name, some of the error handling is inconsistent and needs to be
>> >> more robust. Obviously there are more functions that could be
>> >> added as well.
>> >>
>> >> I chose xmlrpc as the protocol for several reasons. Firstly it
>> >> was a protocol I know very well having used it many times in the
>> >> past. Also it is simple elegant and lightweight. I felt it
>> >> fitted well with the philosophy of webERP. Although I can see
>> >> merits in your idea I would be reluctant to change to any other
>> >> method now, especially as I have the current api working in a
>> >> number of locations.
>> >>
>> >> Thanks
>> >> Tim
>> >>
>> >> 2009/11/1 Lindsay Harris <lindsay@...>:
>> >> > Tim,
>> >> > Thanks for the long and informative reply.  I agree that the
>> >> > API could be the killer app for webERP.  I understood that as
>> >> > soon as I discovered what you had done.    And I would have
>> >> > used the same strategy that you have did for implementing the
>> >> > bits I need now.
>> >> >
>> >> > I am quite happy to sink my teeth into this and
>> >> > fix/extend/polish as appropriate, and for the needs I have!
>> >> >  After all, that's part of the benefits of open source -
>> >> > people contribute the bits they need/want to make it better
>> >> > for others.
>> >> >
>> >> > I had another thought last night,  and this might make the
>> >> > interface much simpler.  Rather than using an RPC mechanism
>> >> > with many methods, have a URL that accepts an XML encoded
>> >> > transaction. For example, to enter a sales order, something
>> >> > like:
>> >> >
>> >> > <sales order>
>> >> >  <sales header>
>> >> >    <customer id>value</customer id>
>> >> >    <del addr 1>24 big street</del addr 1>
>> >> >  </sales header>
>> >> >  <sales item line>
>> >> >    <stockid>prod1</stockid>
>> >> >    <price>27.34</price>
>> >> >  </sales item line>
>> >> > </sales order>
>> >> >
>> >> > You get the idea.  The above may not be valid XML, it's for
>> >> > illustration. The tags would have a 1:1 correspondence with
>> >> > the database fields in which the value is placed.
>> >> >
>> >> > This brings the interaction between systems to a text
>> >> > interaction over an HTTP channel - basic stuff I would expect
>> >> > to be very adaptable. Although the XML tags are ASCII, the
>> >> > values would need to be accept multiple encodings/utf-8 or
>> >> > whatever - I haven't been following that discussion.  I
>> >> > presume that XML can handle that.
>> >> >
>> >> > I am assuming that PHP has some functionality to handle XML
>> >> > document parsing - that is my next task :)
>> >> >
>> >> > What do others think of this?
>> >> >
>> >> > Lindsay
>> >> >
>> >> > On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
>> >> >> Hi Lindsay,
>> >> >>
>> >> >> I agree with most of your points.
>> >> >>
>> >> >> A bit of history - I created the API principally because I
>> >> >> needed to integrate webERP with a hospital information system
>> >> >> Care2x (https://sourceforge.net/projects/care2002/). Although
>> >> >> I wanted to keep it as generalised as possible, by necessity
>> >> >> I tended to code up those functions I needed, which is why
>> >> >> there are gaps in the functionality such as supplier
>> >> >> transactions that Royce pointed out. I had a rather grand
>> >> >> idea of a unified login module that would allow users to
>> >> >> authenticate with this module and then access either webERP
>> >> >> or Care2x within the same session. Unfortunately due to time
>> >> >> constraints this never got beyond being an idea. However the
>> >> >> system works fine with Care2x in several hospitals now. I
>> >> >> have since done a "proof of concept" example to show webERP
>> >> >> working with oscommerce through the api.
>> >> >>
>> >> >> The web browser in the examples is just the interface to the
>> >> >> client application. The communication is between the two
>> >> >> applications on the server.
>> >> >>
>> >> >> There are several weaknesses with it at the moment, and you
>> >> >> have pointed out two major ones. The first is the
>> >> >> authentication. This needs to be improved. I never quite got
>> >> >> my head around how the two applications would both track the
>> >> >> session and as it wasn't vital for my particular purposes I
>> >> >> left it as it was. In theory the client app could be anything
>> >> >> written in any language on any platform.
>> >> >>
>> >> >> The other is the necessity to hard code the database name,
>> >> >> which is clearly unsatisfactory. You might want to access
>> >> >> several databases through the same server. I think this
>> >> >> should be the clients responsibility to tell the server which
>> >> >> database to update. Should this be passed at authentication
>> >> >> time and stored in a session variable on the server side, as
>> >> >> there would need to be a check that the client had authority
>> >> >> for that database?
>> >> >>
>> >> >> I have always thought that the api had the potential to be "a
>> >> >> killer app" for webERP but never really had the time to
>> >> >> polish it as much as it deserves. Help would be greatly
>> >> >> appreciated.
>> >> >>
>> >> >> Thanks
>> >> >> Tim
>> >> >>
>> >> >> -------------------------------------------------------------
>> >> >>--- --- ----------- Come build with us! The BlackBerry(R)
>> >> >> Developer Conference in SF, CA is the only developer event
>> >> >> you need to attend this year. Jumpstart your developing
>> >> >> skills, take BlackBerry mobile applications to market and
>> >> >> stay ahead of the curve. Join us from November 9 - 12, 2009.
>> >> >> Register now! http://p.sf.net/sfu/devconference
>> >> >> _______________________________________________
>> >> >> Web-erp-developers mailing list
>> >> >> Web-erp-developers@...
>> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-develope
>> >> >>rs
>> >> >
>> >> > --------------------------------------------------------------
>> >> >--- ------------- Come build with us! The BlackBerry(R)
>> >> > Developer Conference in SF, CA is the only developer event you
>> >> > need to attend this year. Jumpstart your developing skills,
>> >> > take BlackBerry mobile applications to market and stay ahead
>> >> > of the curve. Join us from November 9 - 12, 2009. Register
>> >> > now! http://p.sf.net/sfu/devconference
>> >> > _______________________________________________
>> >> > Web-erp-developers mailing list
>> >> > Web-erp-developers@...
>> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developer
>> >> >s
>> >>
>> >> ----------------------------------------------------------------
>> >>--- ----------- Come build with us! The BlackBerry(R) Developer
>> >> Conference in SF, CA is the only developer event you need to
>> >> attend this year. Jumpstart your developing skills, take
>> >> BlackBerry mobile applications to market and stay ahead of the
>> >> curve. Join us from November 9 - 12, 2009. Register now!
>> >> http://p.sf.net/sfu/devconference
>> >> _______________________________________________
>> >> Web-erp-developers mailing list
>> >> Web-erp-developers@...
>> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> >
>> > -----------------------------------------------------------------
>> >------------- Come build with us! The BlackBerry(R) Developer
>> > Conference in SF, CA is the only developer event you need to
>> > attend this year. Jumpstart your developing skills, take
>> > BlackBerry mobile applications to market and stay ahead of the
>> > curve. Join us from November 9 - 12, 2009. Register now!
>> > http://p.sf.net/sfu/devconference
>> > _______________________________________________
>> > Web-erp-developers mailing list
>> > Web-erp-developers@...
>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>> -------------------------------------------------------------------
>>----------- Come build with us! The BlackBerry(R) Developer
>> Conference in SF, CA is the only developer event you need to attend
>> this year. Jumpstart your developing skills, take BlackBerry mobile
>> applications to market and stay ahead of the curve. Join us from
>> November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web-erp-developers@...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Lindsay Harris]

Hi,  Tim.

Firstly,  getting SVN working properly should be more important than
this thread right now - I have end of month accounting/reporting to
do anyway.

Having said that,  questions about a still-forming idea are most
welcome;  they often avoid the "Oh S**t" moments later on.

I would expect that table driven parameter validation applies per
database table.  So a sales order, e.g. would have a validation of
some parameters against the 'salesorders' table, and some against
the 'saleorderdetails' table.   Your API
function 'InsertSalesOrderHeader' has many lines devoted to verifying
the supplied parameters - as it should.  I *feel* that generating the
code for this should be able to be largely automated.   Note feel,
not certain,  but worth investigating further.

Creating tools to write code is something I do from time to time -
this is another example.   It just seems that given the definition of
a database table, we SHOULD be able to speed up creating the
verification code.

When it comes to accounting/bookkeeping, I'm a babe in the woods, and
am really glad the webERP exists to do all that for me.  Then I can
enjoy doing what I like doing :)

Lindsay


On Wed, 4 Nov 2009 00:07:40 Tim Schofield wrote:

> Hi Lindsay,
>
> I will send you the classes off list.
>
> I'm not sure if I understand your suggestion correctly, so if I am
> talking rubbish please tell me :) A number of API transactions
> contain multiple calls to multiple database tables. For instance
> think of raising a sales invoice for a stock item. How would your
> method work with this?
>
> Tim
>
> 2009/11/3 Lindsay Harris <lindsay@...>:
> > Hi,  Tim.
> >
> > I agree that we cannot break existing interfaces.  Unnecessarily
> > annoying our users is not a good policy for peaceful life.
> >
> > Perhaps we should now be considering an SDK (software developers
> > kit) for the API side of webERP.  Sample code goes a long way to
> > getting users started.   I speak from experience :)   I'd suggest
> > this be a distinct zip file from the basic package.  Your 2
> > classes sound like an excellent starting point.
> >
> > If I can grab a copy,  I'll put them into a "releasable"
> > condition, with notes written as I get it working.
> >
> > I've also been thinking about how to automate some of the
> > parameter checking/verification code in the API functions.  Note:
> > I've only looked at a couple, so this is a very preliminary
> > concept.   The idea revolves around making them table driven,
> > with the table indexed by the parameter name, containing
> > parameter type and possible limits and/or a function to call to
> > validate.  Some of this, at least, could be automatically
> > generated from the DB schema;  I would see this as being done
> > during a "table build" phase, not dynamically at run time.
> >
> > Validation would be done in a common function, using the data
> > passed in and the name of the function name that is calling or
> > the validation table for the calling function.  I think this
> > would shrink the size of the code for each function, as well as
> > reduce the often tediously generated sequence of calls for
> > validation, and should also reduce errors.
> >
> > Lindsay
> >
> > On Mon, 2 Nov 2009 22:42:18 Tim Schofield wrote:
> >> Hi Lindsay,
> >>
> >> You are correct, any language/platform combination that has an
> >> xml-rpc implementation for it can communicate with webERP via
> >> the api, and webERP can have a SOAP api, REST api etc.
> >>
> >> Whatever we do we still need to expose the current interface as
> >> there are people already using it. I still think as people get
> >> used to it they will find the xml-rpc system easy to use. The
> >> reason the amazon api is easier to use is not that REST is any
> >> easier, just the fact that they can afford to have a number of
> >> programmers polishing the server up so as to make it user
> >> friendly. I still believe that this is what we need.
> >>
> >> The way I have built client apps using php is to have a standard
> >> class which does all the work of creating the client, encoding
> >> and decoding the data and performing the communication with
> >> webERP. This class can be used by any application. I can let
> >> anyone who wants have a copy of this. I then have an application
> >> specific class that inherits the first one and has methods that
> >> are specific to that application. For example, in my hospital
> >> information system implementation class_weberp has 2 methods one
> >> to create a customer another to create a branch. The app
> >> specific class -
> >> class_weberp_c2x - has a method to create a patient as a
> >> customer, that calls both of the methods of class_weberp. Thus
> >> the only code that actually needs inserting in the care2x code
> >> is two lines:
> >>
> >> $weberpObject=new class_weberp_c2x;
> >> $weberpObject->CreatePatientAsCustomer($PatientData);
> >>
> >> and the patient is created in webERP as a customer with a branch
> >> as well. It really is that simple once the classes have been
> >> built, and I have done most of that work already.
> >>
> >> Tim
> >>
> >> 2009/11/2 Lindsay Harris <lindsay@...>:
> >> > Hi,  Tim.
> >> >
> >> > Your reply (the part about XMLRPC) has got me thinking again.
> >> >  This is sometimes dangerous!
> >> >
> >> > I don't see any specific reason that webERP must have just one
> >> > API. The important part of what you have done (as far as I am
> >> > concerned) is to provide access into the innards of webERP
> >> > independent of a web browser.
> >> >
> >> > So now the thought is that there would be 2 levels of API.  An
> >> > internal one that interacts with webERP and the database.
> >> >  This would be very close, if not almost identical, to what
> >> > you have done already.    This would be a "private" API, in
> >> > the sense that no other entity would be expected to use it.
> >> >
> >> > There would be a second level of public APIs - and not limited
> >> > to just one type.  These would build on top of the above set,
> >> >  but be available for the world to use.   Generally, the
> >> > mapping from public to private would be fairly simple in the
> >> > case of the XMLRPC interface.  But could be more complex,  if
> >> > required/desired.  The benefit of this approach is that webERP
> >> > then has the structure to accept new methods/standards of
> >> > interaction as they appear,  without having to get into the
> >> > guts of the code/database - just create a new frontend that
> >> > uses the internal API.
> >> >
> >> > And a question:  there are many implementations of XML-RPC, as
> >> > listed here:-
> >> > http://www.xmlrpc.com/directory/1568/implementations   I
> >> > presume these are cross compatible, e.g. a C client would
> >> > connect correctly with a python server, for instance.  Is this
> >> > so?
> >> >
> >> > Lindsay
> >> >
> >> > On Mon, 2 Nov 2009 06:04:02 Tim Schofield wrote:
> >> >> Hi Lindsay,
> >> >>
> >> >> Help to polish up the api would be greatly appreciated. Other
> >> >> than the authentication issue and the hard coding of the db
> >> >> name, some of the error handling is inconsistent and needs to
> >> >> be more robust. Obviously there are more functions that could
> >> >> be added as well.
> >> >>
> >> >> I chose xmlrpc as the protocol for several reasons. Firstly
> >> >> it was a protocol I know very well having used it many times
> >> >> in the past. Also it is simple elegant and lightweight. I
> >> >> felt it fitted well with the philosophy of webERP. Although I
> >> >> can see merits in your idea I would be reluctant to change to
> >> >> any other method now, especially as I have the current api
> >> >> working in a number of locations.
> >> >>
> >> >> Thanks
> >> >> Tim
> >> >>
> >> >> 2009/11/1 Lindsay Harris <lindsay@...>:
> >> >> > Tim,
> >> >> > Thanks for the long and informative reply.  I agree that
> >> >> > the API could be the killer app for webERP.  I understood
> >> >> > that as soon as I discovered what you had done.    And I
> >> >> > would have used the same strategy that you have did for
> >> >> > implementing the bits I need now.
> >> >> >
> >> >> > I am quite happy to sink my teeth into this and
> >> >> > fix/extend/polish as appropriate, and for the needs I have!
> >> >> >  After all, that's part of the benefits of open source -
> >> >> > people contribute the bits they need/want to make it better
> >> >> > for others.
> >> >> >
> >> >> > I had another thought last night,  and this might make the
> >> >> > interface much simpler.  Rather than using an RPC mechanism
> >> >> > with many methods, have a URL that accepts an XML encoded
> >> >> > transaction. For example, to enter a sales order, something
> >> >> > like:
> >> >> >
> >> >> > <sales order>
> >> >> >  <sales header>
> >> >> >    <customer id>value</customer id>
> >> >> >    <del addr 1>24 big street</del addr 1>
> >> >> >  </sales header>
> >> >> >  <sales item line>
> >> >> >    <stockid>prod1</stockid>
> >> >> >    <price>27.34</price>
> >> >> >  </sales item line>
> >> >> > </sales order>
> >> >> >
> >> >> > You get the idea.  The above may not be valid XML, it's for
> >> >> > illustration. The tags would have a 1:1 correspondence with
> >> >> > the database fields in which the value is placed.
> >> >> >
> >> >> > This brings the interaction between systems to a text
> >> >> > interaction over an HTTP channel - basic stuff I would
> >> >> > expect to be very adaptable. Although the XML tags are
> >> >> > ASCII, the values would need to be accept multiple
> >> >> > encodings/utf-8 or whatever - I haven't been following that
> >> >> > discussion.  I presume that XML can handle that.
> >> >> >
> >> >> > I am assuming that PHP has some functionality to handle XML
> >> >> > document parsing - that is my next task :)
> >> >> >
> >> >> > What do others think of this?
> >> >> >
> >> >> > Lindsay
> >> >> >
> >> >> > On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
> >> >> >> Hi Lindsay,
> >> >> >>
> >> >> >> I agree with most of your points.
> >> >> >>
> >> >> >> A bit of history - I created the API principally because I
> >> >> >> needed to integrate webERP with a hospital information
> >> >> >> system Care2x
> >> >> >> (https://sourceforge.net/projects/care2002/). Although I
> >> >> >> wanted to keep it as generalised as possible, by necessity
> >> >> >> I tended to code up those functions I needed, which is why
> >> >> >> there are gaps in the functionality such as supplier
> >> >> >> transactions that Royce pointed out. I had a rather grand
> >> >> >> idea of a unified login module that would allow users to
> >> >> >> authenticate with this module and then access either
> >> >> >> webERP or Care2x within the same session. Unfortunately
> >> >> >> due to time constraints this never got beyond being an
> >> >> >> idea. However the system works fine with Care2x in several
> >> >> >> hospitals now. I have since done a "proof of concept"
> >> >> >> example to show webERP working with oscommerce through the
> >> >> >> api.
> >> >> >>
> >> >> >> The web browser in the examples is just the interface to
> >> >> >> the client application. The communication is between the
> >> >> >> two applications on the server.
> >> >> >>
> >> >> >> There are several weaknesses with it at the moment, and
> >> >> >> you have pointed out two major ones. The first is the
> >> >> >> authentication. This needs to be improved. I never quite
> >> >> >> got my head around how the two applications would both
> >> >> >> track the session and as it wasn't vital for my particular
> >> >> >> purposes I left it as it was. In theory the client app
> >> >> >> could be anything written in any language on any platform.
> >> >> >>
> >> >> >> The other is the necessity to hard code the database name,
> >> >> >> which is clearly unsatisfactory. You might want to access
> >> >> >> several databases through the same server. I think this
> >> >> >> should be the clients responsibility to tell the server
> >> >> >> which database to update. Should this be passed at
> >> >> >> authentication time and stored in a session variable on
> >> >> >> the server side, as there would need to be a check that
> >> >> >> the client had authority for that database?
> >> >> >>
> >> >> >> I have always thought that the api had the potential to be
> >> >> >> "a killer app" for webERP but never really had the time to
> >> >> >> polish it as much as it deserves. Help would be greatly
> >> >> >> appreciated.
> >> >> >>
> >> >> >> Thanks
> >> >> >> Tim
> >> >> >>
> >> >> >> ----------------------------------------------------------
> >> >> >>--- --- --- ----------- Come build with us! The
> >> >> >> BlackBerry(R) Developer Conference in SF, CA is the only
> >> >> >> developer event you need to attend this year. Jumpstart
> >> >> >> your developing skills, take BlackBerry mobile
> >> >> >> applications to market and stay ahead of the curve. Join
> >> >> >> us from November 9 - 12, 2009. Register now!
> >> >> >> http://p.sf.net/sfu/devconference
> >> >> >> _______________________________________________
> >> >> >> Web-erp-developers mailing list
> >> >> >> Web-erp-developers@...
> >> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-devel
> >> >> >>ope rs
> >> >> >
> >> >> > -----------------------------------------------------------
> >> >> >--- --- ------------- Come build with us! The BlackBerry(R)
> >> >> > Developer Conference in SF, CA is the only developer event
> >> >> > you need to attend this year. Jumpstart your developing
> >> >> > skills, take BlackBerry mobile applications to market and
> >> >> > stay ahead of the curve. Join us from November 9 - 12,
> >> >> > 2009. Register now! http://p.sf.net/sfu/devconference
> >> >> > _______________________________________________
> >> >> > Web-erp-developers mailing list
> >> >> > Web-erp-developers@...
> >> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-develo
> >> >> >per s
> >> >>
> >> >> -------------------------------------------------------------
> >> >>--- --- ----------- Come build with us! The BlackBerry(R)
> >> >> Developer Conference in SF, CA is the only developer event
> >> >> you need to attend this year. Jumpstart your developing
> >> >> skills, take BlackBerry mobile applications to market and
> >> >> stay ahead of the curve. Join us from November 9 - 12, 2009.
> >> >> Register now! http://p.sf.net/sfu/devconference
> >> >> _______________________________________________
> >> >> Web-erp-developers mailing list
> >> >> Web-erp-developers@...
> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-develope
> >> >>rs
> >> >
> >> > --------------------------------------------------------------
> >> >--- ------------- Come build with us! The BlackBerry(R)
> >> > Developer Conference in SF, CA is the only developer event you
> >> > need to attend this year. Jumpstart your developing skills,
> >> > take BlackBerry mobile applications to market and stay ahead
> >> > of the curve. Join us from November 9 - 12, 2009. Register
> >> > now! http://p.sf.net/sfu/devconference
> >> > _______________________________________________
> >> > Web-erp-developers mailing list
> >> > Web-erp-developers@...
> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developer
> >> >s
> >>
> >> ----------------------------------------------------------------
> >>--- ----------- Come build with us! The BlackBerry(R) Developer
> >> Conference in SF, CA is the only developer event you need to
> >> attend this year. Jumpstart your developing skills, take
> >> BlackBerry mobile applications to market and stay ahead of the
> >> curve. Join us from November 9 - 12, 2009. Register now!
> >> http://p.sf.net/sfu/devconference
> >> _______________________________________________
> >> Web-erp-developers mailing list
> >> Web-erp-developers@...
> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
> > -----------------------------------------------------------------
> >------------- Come build with us! The BlackBerry(R) Developer
> > Conference in SF, CA is the only developer event you need to
> > attend this year. Jumpstart your developing skills, take
> > BlackBerry mobile applications to market and stay ahead of the
> > curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web-erp-developers@...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
> -------------------------------------------------------------------
>----------- Come build with us! The BlackBerry(R) Developer
> Conference in SF, CA is the only developer event you need to attend
> this year. Jumpstart your developing skills, take BlackBerry mobile
> applications to market and stay ahead of the curve. Join us from
> November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Tim Schofield]

Ah ok, I get it now. Apologies for being slow on the uptake. Yes this
approach would be a good idea, and would cut out some of the silly
verification errors I have made in the past.

Thanks
Tim


2009/11/4 Lindsay Harris <lindsay@...>:

> Hi,  Tim.
>
> Firstly,  getting SVN working properly should be more important than
> this thread right now - I have end of month accounting/reporting to
> do anyway.
>
> Having said that,  questions about a still-forming idea are most
> welcome;  they often avoid the "Oh S**t" moments later on.
>
> I would expect that table driven parameter validation applies per
> database table.  So a sales order, e.g. would have a validation of
> some parameters against the 'salesorders' table, and some against
> the 'saleorderdetails' table.   Your API
> function 'InsertSalesOrderHeader' has many lines devoted to verifying
> the supplied parameters - as it should.  I *feel* that generating the
> code for this should be able to be largely automated.   Note feel,
> not certain,  but worth investigating further.
>
> Creating tools to write code is something I do from time to time -
> this is another example.   It just seems that given the definition of
> a database table, we SHOULD be able to speed up creating the
> verification code.
>
> When it comes to accounting/bookkeeping, I'm a babe in the woods, and
> am really glad the webERP exists to do all that for me.  Then I can
> enjoy doing what I like doing :)
>
> Lindsay
>
>
> On Wed, 4 Nov 2009 00:07:40 Tim Schofield wrote:
>> Hi Lindsay,
>>
>> I will send you the classes off list.
>>
>> I'm not sure if I understand your suggestion correctly, so if I am
>> talking rubbish please tell me :) A number of API transactions
>> contain multiple calls to multiple database tables. For instance
>> think of raising a sales invoice for a stock item. How would your
>> method work with this?
>>
>> Tim
>>
>> 2009/11/3 Lindsay Harris <lindsay@...>:
>> > Hi,  Tim.
>> >
>> > I agree that we cannot break existing interfaces.  Unnecessarily
>> > annoying our users is not a good policy for peaceful life.
>> >
>> > Perhaps we should now be considering an SDK (software developers
>> > kit) for the API side of webERP.  Sample code goes a long way to
>> > getting users started.   I speak from experience :)   I'd suggest
>> > this be a distinct zip file from the basic package.  Your 2
>> > classes sound like an excellent starting point.
>> >
>> > If I can grab a copy,  I'll put them into a "releasable"
>> > condition, with notes written as I get it working.
>> >
>> > I've also been thinking about how to automate some of the
>> > parameter checking/verification code in the API functions.  Note:
>> > I've only looked at a couple, so this is a very preliminary
>> > concept.   The idea revolves around making them table driven,
>> > with the table indexed by the parameter name, containing
>> > parameter type and possible limits and/or a function to call to
>> > validate.  Some of this, at least, could be automatically
>> > generated from the DB schema;  I would see this as being done
>> > during a "table build" phase, not dynamically at run time.
>> >
>> > Validation would be done in a common function, using the data
>> > passed in and the name of the function name that is calling or
>> > the validation table for the calling function.  I think this
>> > would shrink the size of the code for each function, as well as
>> > reduce the often tediously generated sequence of calls for
>> > validation, and should also reduce errors.
>> >
>> > Lindsay
>> >
>> > On Mon, 2 Nov 2009 22:42:18 Tim Schofield wrote:
>> >> Hi Lindsay,
>> >>
>> >> You are correct, any language/platform combination that has an
>> >> xml-rpc implementation for it can communicate with webERP via
>> >> the api, and webERP can have a SOAP api, REST api etc.
>> >>
>> >> Whatever we do we still need to expose the current interface as
>> >> there are people already using it. I still think as people get
>> >> used to it they will find the xml-rpc system easy to use. The
>> >> reason the amazon api is easier to use is not that REST is any
>> >> easier, just the fact that they can afford to have a number of
>> >> programmers polishing the server up so as to make it user
>> >> friendly. I still believe that this is what we need.
>> >>
>> >> The way I have built client apps using php is to have a standard
>> >> class which does all the work of creating the client, encoding
>> >> and decoding the data and performing the communication with
>> >> webERP. This class can be used by any application. I can let
>> >> anyone who wants have a copy of this. I then have an application
>> >> specific class that inherits the first one and has methods that
>> >> are specific to that application. For example, in my hospital
>> >> information system implementation class_weberp has 2 methods one
>> >> to create a customer another to create a branch. The app
>> >> specific class -
>> >> class_weberp_c2x - has a method to create a patient as a
>> >> customer, that calls both of the methods of class_weberp. Thus
>> >> the only code that actually needs inserting in the care2x code
>> >> is two lines:
>> >>
>> >> $weberpObject=new class_weberp_c2x;
>> >> $weberpObject->CreatePatientAsCustomer($PatientData);
>> >>
>> >> and the patient is created in webERP as a customer with a branch
>> >> as well. It really is that simple once the classes have been
>> >> built, and I have done most of that work already.
>> >>
>> >> Tim
>> >>
>> >> 2009/11/2 Lindsay Harris <lindsay@...>:
>> >> > Hi,  Tim.
>> >> >
>> >> > Your reply (the part about XMLRPC) has got me thinking again.
>> >> >  This is sometimes dangerous!
>> >> >
>> >> > I don't see any specific reason that webERP must have just one
>> >> > API. The important part of what you have done (as far as I am
>> >> > concerned) is to provide access into the innards of webERP
>> >> > independent of a web browser.
>> >> >
>> >> > So now the thought is that there would be 2 levels of API.  An
>> >> > internal one that interacts with webERP and the database.
>> >> >  This would be very close, if not almost identical, to what
>> >> > you have done already.    This would be a "private" API, in
>> >> > the sense that no other entity would be expected to use it.
>> >> >
>> >> > There would be a second level of public APIs - and not limited
>> >> > to just one type.  These would build on top of the above set,
>> >> >  but be available for the world to use.   Generally, the
>> >> > mapping from public to private would be fairly simple in the
>> >> > case of the XMLRPC interface.  But could be more complex,  if
>> >> > required/desired.  The benefit of this approach is that webERP
>> >> > then has the structure to accept new methods/standards of
>> >> > interaction as they appear,  without having to get into the
>> >> > guts of the code/database - just create a new frontend that
>> >> > uses the internal API.
>> >> >
>> >> > And a question:  there are many implementations of XML-RPC, as
>> >> > listed here:-
>> >> > http://www.xmlrpc.com/directory/1568/implementations   I
>> >> > presume these are cross compatible, e.g. a C client would
>> >> > connect correctly with a python server, for instance.  Is this
>> >> > so?
>> >> >
>> >> > Lindsay
>> >> >
>> >> > On Mon, 2 Nov 2009 06:04:02 Tim Schofield wrote:
>> >> >> Hi Lindsay,
>> >> >>
>> >> >> Help to polish up the api would be greatly appreciated. Other
>> >> >> than the authentication issue and the hard coding of the db
>> >> >> name, some of the error handling is inconsistent and needs to
>> >> >> be more robust. Obviously there are more functions that could
>> >> >> be added as well.
>> >> >>
>> >> >> I chose xmlrpc as the protocol for several reasons. Firstly
>> >> >> it was a protocol I know very well having used it many times
>> >> >> in the past. Also it is simple elegant and lightweight. I
>> >> >> felt it fitted well with the philosophy of webERP. Although I
>> >> >> can see merits in your idea I would be reluctant to change to
>> >> >> any other method now, especially as I have the current api
>> >> >> working in a number of locations.
>> >> >>
>> >> >> Thanks
>> >> >> Tim
>> >> >>
>> >> >> 2009/11/1 Lindsay Harris <lindsay@...>:
>> >> >> > Tim,
>> >> >> > Thanks for the long and informative reply.  I agree that
>> >> >> > the API could be the killer app for webERP.  I understood
>> >> >> > that as soon as I discovered what you had done.    And I
>> >> >> > would have used the same strategy that you have did for
>> >> >> > implementing the bits I need now.
>> >> >> >
>> >> >> > I am quite happy to sink my teeth into this and
>> >> >> > fix/extend/polish as appropriate, and for the needs I have!
>> >> >> >  After all, that's part of the benefits of open source -
>> >> >> > people contribute the bits they need/want to make it better
>> >> >> > for others.
>> >> >> >
>> >> >> > I had another thought last night,  and this might make the
>> >> >> > interface much simpler.  Rather than using an RPC mechanism
>> >> >> > with many methods, have a URL that accepts an XML encoded
>> >> >> > transaction. For example, to enter a sales order, something
>> >> >> > like:
>> >> >> >
>> >> >> > <sales order>
>> >> >> >  <sales header>
>> >> >> >    <customer id>value</customer id>
>> >> >> >    <del addr 1>24 big street</del addr 1>
>> >> >> >  </sales header>
>> >> >> >  <sales item line>
>> >> >> >    <stockid>prod1</stockid>
>> >> >> >    <price>27.34</price>
>> >> >> >  </sales item line>
>> >> >> > </sales order>
>> >> >> >
>> >> >> > You get the idea.  The above may not be valid XML, it's for
>> >> >> > illustration. The tags would have a 1:1 correspondence with
>> >> >> > the database fields in which the value is placed.
>> >> >> >
>> >> >> > This brings the interaction between systems to a text
>> >> >> > interaction over an HTTP channel - basic stuff I would
>> >> >> > expect to be very adaptable. Although the XML tags are
>> >> >> > ASCII, the values would need to be accept multiple
>> >> >> > encodings/utf-8 or whatever - I haven't been following that
>> >> >> > discussion.  I presume that XML can handle that.
>> >> >> >
>> >> >> > I am assuming that PHP has some functionality to handle XML
>> >> >> > document parsing - that is my next task :)
>> >> >> >
>> >> >> > What do others think of this?
>> >> >> >
>> >> >> > Lindsay
>> >> >> >
>> >> >> > On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
>> >> >> >> Hi Lindsay,
>> >> >> >>
>> >> >> >> I agree with most of your points.
>> >> >> >>
>> >> >> >> A bit of history - I created the API principally because I
>> >> >> >> needed to integrate webERP with a hospital information
>> >> >> >> system Care2x
>> >> >> >> (https://sourceforge.net/projects/care2002/). Although I
>> >> >> >> wanted to keep it as generalised as possible, by necessity
>> >> >> >> I tended to code up those functions I needed, which is why
>> >> >> >> there are gaps in the functionality such as supplier
>> >> >> >> transactions that Royce pointed out. I had a rather grand
>> >> >> >> idea of a unified login module that would allow users to
>> >> >> >> authenticate with this module and then access either
>> >> >> >> webERP or Care2x within the same session. Unfortunately
>> >> >> >> due to time constraints this never got beyond being an
>> >> >> >> idea. However the system works fine with Care2x in several
>> >> >> >> hospitals now. I have since done a "proof of concept"
>> >> >> >> example to show webERP working with oscommerce through the
>> >> >> >> api.
>> >> >> >>
>> >> >> >> The web browser in the examples is just the interface to
>> >> >> >> the client application. The communication is between the
>> >> >> >> two applications on the server.
>> >> >> >>
>> >> >> >> There are several weaknesses with it at the moment, and
>> >> >> >> you have pointed out two major ones. The first is the
>> >> >> >> authentication. This needs to be improved. I never quite
>> >> >> >> got my head around how the two applications would both
>> >> >> >> track the session and as it wasn't vital for my particular
>> >> >> >> purposes I left it as it was. In theory the client app
>> >> >> >> could be anything written in any language on any platform.
>> >> >> >>
>> >> >> >> The other is the necessity to hard code the database name,
>> >> >> >> which is clearly unsatisfactory. You might want to access
>> >> >> >> several databases through the same server. I think this
>> >> >> >> should be the clients responsibility to tell the server
>> >> >> >> which database to update. Should this be passed at
>> >> >> >> authentication time and stored in a session variable on
>> >> >> >> the server side, as there would need to be a check that
>> >> >> >> the client had authority for that database?
>> >> >> >>
>> >> >> >> I have always thought that the api had the potential to be
>> >> >> >> "a killer app" for webERP but never really had the time to
>> >> >> >> polish it as much as it deserves. Help would be greatly
>> >> >> >> appreciated.
>> >> >> >>
>> >> >> >> Thanks
>> >> >> >> Tim
>> >> >> >>
>> >> >> >> ----------------------------------------------------------
>> >> >> >>--- --- --- ----------- Come build with us! The
>> >> >> >> BlackBerry(R) Developer Conference in SF, CA is the only
>> >> >> >> developer event you need to attend this year. Jumpstart
>> >> >> >> your developing skills, take BlackBerry mobile
>> >> >> >> applications to market and stay ahead of the curve. Join
>> >> >> >> us from November 9 - 12, 2009. Register now!
>> >> >> >> http://p.sf.net/sfu/devconference
>> >> >> >> _______________________________________________
>> >> >> >> Web-erp-developers mailing list
>> >> >> >> Web-erp-developers@...
>> >> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-devel
>> >> >> >>ope rs
>> >> >> >
>> >> >> > -----------------------------------------------------------
>> >> >> >--- --- ------------- Come build with us! The BlackBerry(R)
>> >> >> > Developer Conference in SF, CA is the only developer event
>> >> >> > you need to attend this year. Jumpstart your developing
>> >> >> > skills, take BlackBerry mobile applications to market and
>> >> >> > stay ahead of the curve. Join us from November 9 - 12,
>> >> >> > 2009. Register now! http://p.sf.net/sfu/devconference
>> >> >> > _______________________________________________
>> >> >> > Web-erp-developers mailing list
>> >> >> > Web-erp-developers@...
>> >> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-develo
>> >> >> >per s
>> >> >>
>> >> >> -------------------------------------------------------------
>> >> >>--- --- ----------- Come build with us! The BlackBerry(R)
>> >> >> Developer Conference in SF, CA is the only developer event
>> >> >> you need to attend this year. Jumpstart your developing
>> >> >> skills, take BlackBerry mobile applications to market and
>> >> >> stay ahead of the curve. Join us from November 9 - 12, 2009.
>> >> >> Register now! http://p.sf.net/sfu/devconference
>> >> >> _______________________________________________
>> >> >> Web-erp-developers mailing list
>> >> >> Web-erp-developers@...
>> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-develope
>> >> >>rs
>> >> >
>> >> > --------------------------------------------------------------
>> >> >--- ------------- Come build with us! The BlackBerry(R)
>> >> > Developer Conference in SF, CA is the only developer event you
>> >> > need to attend this year. Jumpstart your developing skills,
>> >> > take BlackBerry mobile applications to market and stay ahead
>> >> > of the curve. Join us from November 9 - 12, 2009. Register
>> >> > now! http://p.sf.net/sfu/devconference
>> >> > _______________________________________________
>> >> > Web-erp-developers mailing list
>> >> > Web-erp-developers@...
>> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developer
>> >> >s
>> >>
>> >> ----------------------------------------------------------------
>> >>--- ----------- Come build with us! The BlackBerry(R) Developer
>> >> Conference in SF, CA is the only developer event you need to
>> >> attend this year. Jumpstart your developing skills, take
>> >> BlackBerry mobile applications to market and stay ahead of the
>> >> curve. Join us from November 9 - 12, 2009. Register now!
>> >> http://p.sf.net/sfu/devconference
>> >> _______________________________________________
>> >> Web-erp-developers mailing list
>> >> Web-erp-developers@...
>> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> >
>> > -----------------------------------------------------------------
>> >------------- Come build with us! The BlackBerry(R) Developer
>> > Conference in SF, CA is the only developer event you need to
>> > attend this year. Jumpstart your developing skills, take
>> > BlackBerry mobile applications to market and stay ahead of the
>> > curve. Join us from November 9 - 12, 2009. Register now!
>> > http://p.sf.net/sfu/devconference
>> > _______________________________________________
>> > Web-erp-developers mailing list
>> > Web-erp-developers@...
>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>> -------------------------------------------------------------------
>>----------- Come build with us! The BlackBerry(R) Developer
>> Conference in SF, CA is the only developer event you need to attend
>> this year. Jumpstart your developing skills, take BlackBerry mobile
>> applications to market and stay ahead of the curve. Join us from
>> November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web-erp-developers@...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Javier de Lorenzo-Cáceres]

Hi,

Please take a look inside "xmlrpc/lib/xmlrpc.inc" Lines 952-953:

"by default the xml parser can support these 3 charset encodings"
$this -> accepted_charset_encodings = array ('UTF-8', 'ISO-8859-1',
'US-ASCII');

what does "by default" mean here? Could it be changed to other ISO? or
Does it mean xmlrpc doesn't work in a non ISO-8859-1 or UTF-8 deployment?
(Line 953, 2558, 2574, 3471)

Also,
charsets declarations (Line 231),
symbols like 'xml_iso88591_Entities' and
values like 'ISO-8859-1_', 'ISO-8859-1_US-ASCII', 'ISO-8859-1_'UTF-8',
'ISO-8859-1_ISO-8859-1', etc.

Is xmlrpc a recent version? or Is there an available update?

Maybe it's not a bad idea to use the PhP embedded that Tim told us about?

Thanks,
javier


----- Original Message -----
From: "Tim Schofield" <tim.schofield1960@...>
To: "webERP Developers" <web-erp-developers@...>
Sent: Thursday, November 05, 2009 9:51 AM
Subject: Re: [WebERP-developers] Thoughts On The API


Ah ok, I get it now. Apologies for being slow on the uptake. Yes this
approach would be a good idea, and would cut out some of the silly
verification errors I have made in the past.

Thanks
Tim


2009/11/4 Lindsay Harris <lindsay@...>:

> Hi, Tim.
>
> Firstly, getting SVN working properly should be more important than
> this thread right now - I have end of month accounting/reporting to
> do anyway.
>
> Having said that, questions about a still-forming idea are most
> welcome; they often avoid the "Oh S**t" moments later on.
>
> I would expect that table driven parameter validation applies per
> database table. So a sales order, e.g. would have a validation of
> some parameters against the 'salesorders' table, and some against
> the 'saleorderdetails' table. Your API
> function 'InsertSalesOrderHeader' has many lines devoted to verifying
> the supplied parameters - as it should. I *feel* that generating the
> code for this should be able to be largely automated. Note feel,
> not certain, but worth investigating further.
>
> Creating tools to write code is something I do from time to time -
> this is another example. It just seems that given the definition of
> a database table, we SHOULD be able to speed up creating the
> verification code.
>
> When it comes to accounting/bookkeeping, I'm a babe in the woods, and
> am really glad the webERP exists to do all that for me. Then I can
> enjoy doing what I like doing :)
>
> Lindsay
>
>
> On Wed, 4 Nov 2009 00:07:40 Tim Schofield wrote:
>> Hi Lindsay,
>>
>> I will send you the classes off list.
>>
>> I'm not sure if I understand your suggestion correctly, so if I am
>> talking rubbish please tell me :) A number of API transactions
>> contain multiple calls to multiple database tables. For instance
>> think of raising a sales invoice for a stock item. How would your
>> method work with this?
>>
>> Tim
>>
>> 2009/11/3 Lindsay Harris <lindsay@...>:
>> > Hi, Tim.
>> >
>> > I agree that we cannot break existing interfaces. Unnecessarily
>> > annoying our users is not a good policy for peaceful life.
>> >
>> > Perhaps we should now be considering an SDK (software developers
>> > kit) for the API side of webERP. Sample code goes a long way to
>> > getting users started. I speak from experience :) I'd suggest
>> > this be a distinct zip file from the basic package. Your 2
>> > classes sound like an excellent starting point.
>> >
>> > If I can grab a copy, I'll put them into a "releasable"
>> > condition, with notes written as I get it working.
>> >
>> > I've also been thinking about how to automate some of the
>> > parameter checking/verification code in the API functions. Note:
>> > I've only looked at a couple, so this is a very preliminary
>> > concept. The idea revolves around making them table driven,
>> > with the table indexed by the parameter name, containing
>> > parameter type and possible limits and/or a function to call to
>> > validate. Some of this, at least, could be automatically
>> > generated from the DB schema; I would see this as being done
>> > during a "table build" phase, not dynamically at run time.
>> >
>> > Validation would be done in a common function, using the data
>> > passed in and the name of the function name that is calling or
>> > the validation table for the calling function. I think this
>> > would shrink the size of the code for each function, as well as
>> > reduce the often tediously generated sequence of calls for
>> > validation, and should also reduce errors.
>> >
>> > Lindsay
>> >
>> > On Mon, 2 Nov 2009 22:42:18 Tim Schofield wrote:
>> >> Hi Lindsay,
>> >>
>> >> You are correct, any language/platform combination that has an
>> >> xml-rpc implementation for it can communicate with webERP via
>> >> the api, and webERP can have a SOAP api, REST api etc.
>> >>
>> >> Whatever we do we still need to expose the current interface as
>> >> there are people already using it. I still think as people get
>> >> used to it they will find the xml-rpc system easy to use. The
>> >> reason the amazon api is easier to use is not that REST is any
>> >> easier, just the fact that they can afford to have a number of
>> >> programmers polishing the server up so as to make it user
>> >> friendly. I still believe that this is what we need.
>> >>
>> >> The way I have built client apps using php is to have a standard
>> >> class which does all the work of creating the client, encoding
>> >> and decoding the data and performing the communication with
>> >> webERP. This class can be used by any application. I can let
>> >> anyone who wants have a copy of this. I then have an application
>> >> specific class that inherits the first one and has methods that
>> >> are specific to that application. For example, in my hospital
>> >> information system implementation class_weberp has 2 methods one
>> >> to create a customer another to create a branch. The app
>> >> specific class -
>> >> class_weberp_c2x - has a method to create a patient as a
>> >> customer, that calls both of the methods of class_weberp. Thus
>> >> the only code that actually needs inserting in the care2x code
>> >> is two lines:
>> >>
>> >> $weberpObject=new class_weberp_c2x;
>> >> $weberpObject->CreatePatientAsCustomer($PatientData);
>> >>
>> >> and the patient is created in webERP as a customer with a branch
>> >> as well. It really is that simple once the classes have been
>> >> built, and I have done most of that work already.
>> >>
>> >> Tim
>> >>
>> >> 2009/11/2 Lindsay Harris <lindsay@...>:
>> >> > Hi, Tim.
>> >> >
>> >> > Your reply (the part about XMLRPC) has got me thinking again.
>> >> > This is sometimes dangerous!
>> >> >
>> >> > I don't see any specific reason that webERP must have just one
>> >> > API. The important part of what you have done (as far as I am
>> >> > concerned) is to provide access into the innards of webERP
>> >> > independent of a web browser.
>> >> >
>> >> > So now the thought is that there would be 2 levels of API. An
>> >> > internal one that interacts with webERP and the database.
>> >> > This would be very close, if not almost identical, to what
>> >> > you have done already. This would be a "private" API, in
>> >> > the sense that no other entity would be expected to use it.
>> >> >
>> >> > There would be a second level of public APIs - and not limited
>> >> > to just one type. These would build on top of the above set,
>> >> > but be available for the world to use. Generally, the
>> >> > mapping from public to private would be fairly simple in the
>> >> > case of the XMLRPC interface. But could be more complex, if
>> >> > required/desired. The benefit of this approach is that webERP
>> >> > then has the structure to accept new methods/standards of
>> >> > interaction as they appear, without having to get into the
>> >> > guts of the code/database - just create a new frontend that
>> >> > uses the internal API.
>> >> >
>> >> > And a question: there are many implementations of XML-RPC, as
>> >> > listed here:-
>> >> > http://www.xmlrpc.com/directory/1568/implementations I
>> >> > presume these are cross compatible, e.g. a C client would
>> >> > connect correctly with a python server, for instance. Is this
>> >> > so?
>> >> >
>> >> > Lindsay
>> >> >
>> >> > On Mon, 2 Nov 2009 06:04:02 Tim Schofield wrote:
>> >> >> Hi Lindsay,
>> >> >>
>> >> >> Help to polish up the api would be greatly appreciated. Other
>> >> >> than the authentication issue and the hard coding of the db
>> >> >> name, some of the error handling is inconsistent and needs to
>> >> >> be more robust. Obviously there are more functions that could
>> >> >> be added as well.
>> >> >>
>> >> >> I chose xmlrpc as the protocol for several reasons. Firstly
>> >> >> it was a protocol I know very well having used it many times
>> >> >> in the past. Also it is simple elegant and lightweight. I
>> >> >> felt it fitted well with the philosophy of webERP. Although I
>> >> >> can see merits in your idea I would be reluctant to change to
>> >> >> any other method now, especially as I have the current api
>> >> >> working in a number of locations.
>> >> >>
>> >> >> Thanks
>> >> >> Tim
>> >> >>
>> >> >> 2009/11/1 Lindsay Harris <lindsay@...>:
>> >> >> > Tim,
>> >> >> > Thanks for the long and informative reply. I agree that
>> >> >> > the API could be the killer app for webERP. I understood
>> >> >> > that as soon as I discovered what you had done. And I
>> >> >> > would have used the same strategy that you have did for
>> >> >> > implementing the bits I need now.
>> >> >> >
>> >> >> > I am quite happy to sink my teeth into this and
>> >> >> > fix/extend/polish as appropriate, and for the needs I have!
>> >> >> > After all, that's part of the benefits of open source -
>> >> >> > people contribute the bits they need/want to make it better
>> >> >> > for others.
>> >> >> >
>> >> >> > I had another thought last night, and this might make the
>> >> >> > interface much simpler. Rather than using an RPC mechanism
>> >> >> > with many methods, have a URL that accepts an XML encoded
>> >> >> > transaction. For example, to enter a sales order, something
>> >> >> > like:
>> >> >> >
>> >> >> > <sales order>
>> >> >> > <sales header>
>> >> >> > <customer id>value</customer id>
>> >> >> > <del addr 1>24 big street</del addr 1>
>> >> >> > </sales header>
>> >> >> > <sales item line>
>> >> >> > <stockid>prod1</stockid>
>> >> >> > <price>27.34</price>
>> >> >> > </sales item line>
>> >> >> > </sales order>
>> >> >> >
>> >> >> > You get the idea. The above may not be valid XML, it's for
>> >> >> > illustration. The tags would have a 1:1 correspondence with
>> >> >> > the database fields in which the value is placed.
>> >> >> >
>> >> >> > This brings the interaction between systems to a text
>> >> >> > interaction over an HTTP channel - basic stuff I would
>> >> >> > expect to be very adaptable. Although the XML tags are
>> >> >> > ASCII, the values would need to be accept multiple
>> >> >> > encodings/utf-8 or whatever - I haven't been following that
>> >> >> > discussion. I presume that XML can handle that.
>> >> >> >
>> >> >> > I am assuming that PHP has some functionality to handle XML
>> >> >> > document parsing - that is my next task :)
>> >> >> >
>> >> >> > What do others think of this?
>> >> >> >
>> >> >> > Lindsay
>> >> >> >
>> >> >> > On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
>> >> >> >> Hi Lindsay,
>> >> >> >>
>> >> >> >> I agree with most of your points.
>> >> >> >>
>> >> >> >> A bit of history - I created the API principally because I
>> >> >> >> needed to integrate webERP with a hospital information
>> >> >> >> system Care2x
>> >> >> >> (https://sourceforge.net/projects/care2002/). Although I
>> >> >> >> wanted to keep it as generalised as possible, by necessity
>> >> >> >> I tended to code up those functions I needed, which is why
>> >> >> >> there are gaps in the functionality such as supplier
>> >> >> >> transactions that Royce pointed out. I had a rather grand
>> >> >> >> idea of a unified login module that would allow users to
>> >> >> >> authenticate with this module and then access either
>> >> >> >> webERP or Care2x within the same session. Unfortunately
>> >> >> >> due to time constraints this never got beyond being an
>> >> >> >> idea. However the system works fine with Care2x in several
>> >> >> >> hospitals now. I have since done a "proof of concept"
>> >> >> >> example to show webERP working with oscommerce through the
>> >> >> >> api.
>> >> >> >>
>> >> >> >> The web browser in the examples is just the interface to
>> >> >> >> the client application. The communication is between the
>> >> >> >> two applications on the server.
>> >> >> >>
>> >> >> >> There are several weaknesses with it at the moment, and
>> >> >> >> you have pointed out two major ones. The first is the
>> >> >> >> authentication. This needs to be improved. I never quite
>> >> >> >> got my head around how the two applications would both
>> >> >> >> track the session and as it wasn't vital for my particular
>> >> >> >> purposes I left it as it was. In theory the client app
>> >> >> >> could be anything written in any language on any platform.
>> >> >> >>
>> >> >> >> The other is the necessity to hard code the database name,
>> >> >> >> which is clearly unsatisfactory. You might want to access
>> >> >> >> several databases through the same server. I think this
>> >> >> >> should be the clients responsibility to tell the server
>> >> >> >> which database to update. Should this be passed at
>> >> >> >> authentication time and stored in a session variable on
>> >> >> >> the server side, as there would need to be a check that
>> >> >> >> the client had authority for that database?
>> >> >> >>
>> >> >> >> I have always thought that the api had the potential to be
>> >> >> >> "a killer app" for webERP but never really had the time to
>> >> >> >> polish it as much as it deserves. Help would be greatly
>> >> >> >> appreciated.
>> >> >> >>
>> >> >> >> Thanks
>> >> >> >> Tim
>> >> >> >>
>> >> >> >> ----------------------------------------------------------
>> >> >> >>--- --- --- ----------- Come build with us! The
>> >> >> >> BlackBerry(R) Developer Conference in SF, CA is the only
>> >> >> >> developer event you need to attend this year. Jumpstart
>> >> >> >> your developing skills, take BlackBerry mobile
>> >> >> >> applications to market and stay ahead of the curve. Join
>> >> >> >> us from November 9 - 12, 2009. Register now!
>> >> >> >> http://p.sf.net/sfu/devconference
>> >> >> >> _______________________________________________
>> >> >> >> Web-erp-developers mailing list
>> >> >> >> Web-erp-developers@...
>> >> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-devel
>> >> >> >>ope rs
>> >> >> >
>> >> >> > -----------------------------------------------------------
>> >> >> >--- --- ------------- Come build with us! The BlackBerry(R)
>> >> >> > Developer Conference in SF, CA is the only developer event
>> >> >> > you need to attend this year. Jumpstart your developing
>> >> >> > skills, take BlackBerry mobile applications to market and
>> >> >> > stay ahead of the curve. Join us from November 9 - 12,
>> >> >> > 2009. Register now! http://p.sf.net/sfu/devconference
>> >> >> > _______________________________________________
>> >> >> > Web-erp-developers mailing list
>> >> >> > Web-erp-developers@...
>> >> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-develo
>> >> >> >per s
>> >> >>
>> >> >> -------------------------------------------------------------
>> >> >>--- --- ----------- Come build with us! The BlackBerry(R)
>> >> >> Developer Conference in SF, CA is the only developer event
>> >> >> you need to attend this year. Jumpstart your developing
>> >> >> skills, take BlackBerry mobile applications to market and
>> >> >> stay ahead of the curve. Join us from November 9 - 12, 2009.
>> >> >> Register now! http://p.sf.net/sfu/devconference
>> >> >> _______________________________________________
>> >> >> Web-erp-developers mailing list
>> >> >> Web-erp-developers@...
>> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-develope
>> >> >>rs
>> >> >
>> >> > --------------------------------------------------------------
>> >> >--- ------------- Come build with us! The BlackBerry(R)
>> >> > Developer Conference in SF, CA is the only developer event you
>> >> > need to attend this year. Jumpstart your developing skills,
>> >> > take BlackBerry mobile applications to market and stay ahead
>> >> > of the curve. Join us from November 9 - 12, 2009. Register
>> >> > now! http://p.sf.net/sfu/devconference
>> >> > _______________________________________________
>> >> > Web-erp-developers mailing list
>> >> > Web-erp-developers@...
>> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developer
>> >> >s
>> >>
>> >> ----------------------------------------------------------------
>> >>--- ----------- Come build with us! The BlackBerry(R) Developer
>> >> Conference in SF, CA is the only developer event you need to
>> >> attend this year. Jumpstart your developing skills, take
>> >> BlackBerry mobile applications to market and stay ahead of the
>> >> curve. Join us from November 9 - 12, 2009. Register now!
>> >> http://p.sf.net/sfu/devconference
>> >> _______________________________________________
>> >> Web-erp-developers mailing list
>> >> Web-erp-developers@...
>> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> >
>> > -----------------------------------------------------------------
>> >------------- Come build with us! The BlackBerry(R) Developer
>> > Conference in SF, CA is the only developer event you need to
>> > attend this year. Jumpstart your developing skills, take
>> > BlackBerry mobile applications to market and stay ahead of the
>> > curve. Join us from November 9 - 12, 2009. Register now!
>> > http://p.sf.net/sfu/devconference
>> > _______________________________________________
>> > Web-erp-developers mailing list
>> > Web-erp-developers@...
>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>> -------------------------------------------------------------------
>>----------- Come build with us! The BlackBerry(R) Developer
>> Conference in SF, CA is the only developer event you need to attend
>> this year. Jumpstart your developing skills, take BlackBerry mobile
>> applications to market and stay ahead of the curve. Join us from
>> November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web-erp-developers@...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers 


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Tim Schofield]

Hi Javier,

As always I have been a typical Anglo Saxon and focused on ISO-8859-1
without giving thought to other languages. Its great to have someone
on board to keep me in line with this.

Its something I need to look into. I chose this implementation because
in my opinion it is easy to use and more robust, but if it doesn't
work for other character sets clearly I must change.

Thanks
Tim


2009/11/6 AESE, S.L., Javier de Lorenzo-Cáceres. <info@...>:

> Hi,
>
> Please take a look inside "xmlrpc/lib/xmlrpc.inc" Lines 952-953:
>
> "by default the xml parser can support these 3 charset encodings"
> $this -> accepted_charset_encodings = array ('UTF-8', 'ISO-8859-1',
> 'US-ASCII');
>
> what does "by default" mean here? Could it be changed to other ISO? or
> Does it mean xmlrpc doesn't work in a non ISO-8859-1 or UTF-8 deployment?
> (Line 953, 2558, 2574, 3471)
>
> Also,
> charsets declarations (Line 231),
> symbols like 'xml_iso88591_Entities' and
> values like 'ISO-8859-1_', 'ISO-8859-1_US-ASCII', 'ISO-8859-1_'UTF-8',
> 'ISO-8859-1_ISO-8859-1', etc.
>
> Is xmlrpc a recent version? or Is there an available update?
>
> Maybe it's not a bad idea to use the PhP embedded that Tim told us about?
>
> Thanks,
> javier
>
>
> ----- Original Message -----
> From: "Tim Schofield" <tim.schofield1960@...>
> To: "webERP Developers" <web-erp-developers@...>
> Sent: Thursday, November 05, 2009 9:51 AM
> Subject: Re: [WebERP-developers] Thoughts On The API
>
>
> Ah ok, I get it now. Apologies for being slow on the uptake. Yes this
> approach would be a good idea, and would cut out some of the silly
> verification errors I have made in the past.
>
> Thanks
> Tim
>
>
> 2009/11/4 Lindsay Harris <lindsay@...>:
>> Hi, Tim.
>>
>> Firstly, getting SVN working properly should be more important than
>> this thread right now - I have end of month accounting/reporting to
>> do anyway.
>>
>> Having said that, questions about a still-forming idea are most
>> welcome; they often avoid the "Oh S**t" moments later on.
>>
>> I would expect that table driven parameter validation applies per
>> database table. So a sales order, e.g. would have a validation of
>> some parameters against the 'salesorders' table, and some against
>> the 'saleorderdetails' table. Your API
>> function 'InsertSalesOrderHeader' has many lines devoted to verifying
>> the supplied parameters - as it should. I *feel* that generating the
>> code for this should be able to be largely automated. Note feel,
>> not certain, but worth investigating further.
>>
>> Creating tools to write code is something I do from time to time -
>> this is another example. It just seems that given the definition of
>> a database table, we SHOULD be able to speed up creating the
>> verification code.
>>
>> When it comes to accounting/bookkeeping, I'm a babe in the woods, and
>> am really glad the webERP exists to do all that for me. Then I can
>> enjoy doing what I like doing :)
>>
>> Lindsay
>>
>>
>> On Wed, 4 Nov 2009 00:07:40 Tim Schofield wrote:
>>> Hi Lindsay,
>>>
>>> I will send you the classes off list.
>>>
>>> I'm not sure if I understand your suggestion correctly, so if I am
>>> talking rubbish please tell me :) A number of API transactions
>>> contain multiple calls to multiple database tables. For instance
>>> think of raising a sales invoice for a stock item. How would your
>>> method work with this?
>>>
>>> Tim
>>>
>>> 2009/11/3 Lindsay Harris <lindsay@...>:
>>> > Hi, Tim.
>>> >
>>> > I agree that we cannot break existing interfaces. Unnecessarily
>>> > annoying our users is not a good policy for peaceful life.
>>> >
>>> > Perhaps we should now be considering an SDK (software developers
>>> > kit) for the API side of webERP. Sample code goes a long way to
>>> > getting users started. I speak from experience :) I'd suggest
>>> > this be a distinct zip file from the basic package. Your 2
>>> > classes sound like an excellent starting point.
>>> >
>>> > If I can grab a copy, I'll put them into a "releasable"
>>> > condition, with notes written as I get it working.
>>> >
>>> > I've also been thinking about how to automate some of the
>>> > parameter checking/verification code in the API functions. Note:
>>> > I've only looked at a couple, so this is a very preliminary
>>> > concept. The idea revolves around making them table driven,
>>> > with the table indexed by the parameter name, containing
>>> > parameter type and possible limits and/or a function to call to
>>> > validate. Some of this, at least, could be automatically
>>> > generated from the DB schema; I would see this as being done
>>> > during a "table build" phase, not dynamically at run time.
>>> >
>>> > Validation would be done in a common function, using the data
>>> > passed in and the name of the function name that is calling or
>>> > the validation table for the calling function. I think this
>>> > would shrink the size of the code for each function, as well as
>>> > reduce the often tediously generated sequence of calls for
>>> > validation, and should also reduce errors.
>>> >
>>> > Lindsay
>>> >
>>> > On Mon, 2 Nov 2009 22:42:18 Tim Schofield wrote:
>>> >> Hi Lindsay,
>>> >>
>>> >> You are correct, any language/platform combination that has an
>>> >> xml-rpc implementation for it can communicate with webERP via
>>> >> the api, and webERP can have a SOAP api, REST api etc.
>>> >>
>>> >> Whatever we do we still need to expose the current interface as
>>> >> there are people already using it. I still think as people get
>>> >> used to it they will find the xml-rpc system easy to use. The
>>> >> reason the amazon api is easier to use is not that REST is any
>>> >> easier, just the fact that they can afford to have a number of
>>> >> programmers polishing the server up so as to make it user
>>> >> friendly. I still believe that this is what we need.
>>> >>
>>> >> The way I have built client apps using php is to have a standard
>>> >> class which does all the work of creating the client, encoding
>>> >> and decoding the data and performing the communication with
>>> >> webERP. This class can be used by any application. I can let
>>> >> anyone who wants have a copy of this. I then have an application
>>> >> specific class that inherits the first one and has methods that
>>> >> are specific to that application. For example, in my hospital
>>> >> information system implementation class_weberp has 2 methods one
>>> >> to create a customer another to create a branch. The app
>>> >> specific class -
>>> >> class_weberp_c2x - has a method to create a patient as a
>>> >> customer, that calls both of the methods of class_weberp. Thus
>>> >> the only code that actually needs inserting in the care2x code
>>> >> is two lines:
>>> >>
>>> >> $weberpObject=new class_weberp_c2x;
>>> >> $weberpObject->CreatePatientAsCustomer($PatientData);
>>> >>
>>> >> and the patient is created in webERP as a customer with a branch
>>> >> as well. It really is that simple once the classes have been
>>> >> built, and I have done most of that work already.
>>> >>
>>> >> Tim
>>> >>
>>> >> 2009/11/2 Lindsay Harris <lindsay@...>:
>>> >> > Hi, Tim.
>>> >> >
>>> >> > Your reply (the part about XMLRPC) has got me thinking again.
>>> >> > This is sometimes dangerous!
>>> >> >
>>> >> > I don't see any specific reason that webERP must have just one
>>> >> > API. The important part of what you have done (as far as I am
>>> >> > concerned) is to provide access into the innards of webERP
>>> >> > independent of a web browser.
>>> >> >
>>> >> > So now the thought is that there would be 2 levels of API. An
>>> >> > internal one that interacts with webERP and the database.
>>> >> > This would be very close, if not almost identical, to what
>>> >> > you have done already. This would be a "private" API, in
>>> >> > the sense that no other entity would be expected to use it.
>>> >> >
>>> >> > There would be a second level of public APIs - and not limited
>>> >> > to just one type. These would build on top of the above set,
>>> >> > but be available for the world to use. Generally, the
>>> >> > mapping from public to private would be fairly simple in the
>>> >> > case of the XMLRPC interface. But could be more complex, if
>>> >> > required/desired. The benefit of this approach is that webERP
>>> >> > then has the structure to accept new methods/standards of
>>> >> > interaction as they appear, without having to get into the
>>> >> > guts of the code/database - just create a new frontend that
>>> >> > uses the internal API.
>>> >> >
>>> >> > And a question: there are many implementations of XML-RPC, as
>>> >> > listed here:-
>>> >> > http://www.xmlrpc.com/directory/1568/implementations I
>>> >> > presume these are cross compatible, e.g. a C client would
>>> >> > connect correctly with a python server, for instance. Is this
>>> >> > so?
>>> >> >
>>> >> > Lindsay
>>> >> >
>>> >> > On Mon, 2 Nov 2009 06:04:02 Tim Schofield wrote:
>>> >> >> Hi Lindsay,
>>> >> >>
>>> >> >> Help to polish up the api would be greatly appreciated. Other
>>> >> >> than the authentication issue and the hard coding of the db
>>> >> >> name, some of the error handling is inconsistent and needs to
>>> >> >> be more robust. Obviously there are more functions that could
>>> >> >> be added as well.
>>> >> >>
>>> >> >> I chose xmlrpc as the protocol for several reasons. Firstly
>>> >> >> it was a protocol I know very well having used it many times
>>> >> >> in the past. Also it is simple elegant and lightweight. I
>>> >> >> felt it fitted well with the philosophy of webERP. Although I
>>> >> >> can see merits in your idea I would be reluctant to change to
>>> >> >> any other method now, especially as I have the current api
>>> >> >> working in a number of locations.
>>> >> >>
>>> >> >> Thanks
>>> >> >> Tim
>>> >> >>
>>> >> >> 2009/11/1 Lindsay Harris <lindsay@...>:
>>> >> >> > Tim,
>>> >> >> > Thanks for the long and informative reply. I agree that
>>> >> >> > the API could be the killer app for webERP. I understood
>>> >> >> > that as soon as I discovered what you had done. And I
>>> >> >> > would have used the same strategy that you have did for
>>> >> >> > implementing the bits I need now.
>>> >> >> >
>>> >> >> > I am quite happy to sink my teeth into this and
>>> >> >> > fix/extend/polish as appropriate, and for the needs I have!
>>> >> >> > After all, that's part of the benefits of open source -
>>> >> >> > people contribute the bits they need/want to make it better
>>> >> >> > for others.
>>> >> >> >
>>> >> >> > I had another thought last night, and this might make the
>>> >> >> > interface much simpler. Rather than using an RPC mechanism
>>> >> >> > with many methods, have a URL that accepts an XML encoded
>>> >> >> > transaction. For example, to enter a sales order, something
>>> >> >> > like:
>>> >> >> >
>>> >> >> > <sales order>
>>> >> >> > <sales header>
>>> >> >> > <customer id>value</customer id>
>>> >> >> > <del addr 1>24 big street</del addr 1>
>>> >> >> > </sales header>
>>> >> >> > <sales item line>
>>> >> >> > <stockid>prod1</stockid>
>>> >> >> > <price>27.34</price>
>>> >> >> > </sales item line>
>>> >> >> > </sales order>
>>> >> >> >
>>> >> >> > You get the idea. The above may not be valid XML, it's for
>>> >> >> > illustration. The tags would have a 1:1 correspondence with
>>> >> >> > the database fields in which the value is placed.
>>> >> >> >
>>> >> >> > This brings the interaction between systems to a text
>>> >> >> > interaction over an HTTP channel - basic stuff I would
>>> >> >> > expect to be very adaptable. Although the XML tags are
>>> >> >> > ASCII, the values would need to be accept multiple
>>> >> >> > encodings/utf-8 or whatever - I haven't been following that
>>> >> >> > discussion. I presume that XML can handle that.
>>> >> >> >
>>> >> >> > I am assuming that PHP has some functionality to handle XML
>>> >> >> > document parsing - that is my next task :)
>>> >> >> >
>>> >> >> > What do others think of this?
>>> >> >> >
>>> >> >> > Lindsay
>>> >> >> >
>>> >> >> > On Sat, 31 Oct 2009 23:46:40 Tim Schofield wrote:
>>> >> >> >> Hi Lindsay,
>>> >> >> >>
>>> >> >> >> I agree with most of your points.
>>> >> >> >>
>>> >> >> >> A bit of history - I created the API principally because I
>>> >> >> >> needed to integrate webERP with a hospital information
>>> >> >> >> system Care2x
>>> >> >> >> (https://sourceforge.net/projects/care2002/). Although I
>>> >> >> >> wanted to keep it as generalised as possible, by necessity
>>> >> >> >> I tended to code up those functions I needed, which is why
>>> >> >> >> there are gaps in the functionality such as supplier
>>> >> >> >> transactions that Royce pointed out. I had a rather grand
>>> >> >> >> idea of a unified login module that would allow users to
>>> >> >> >> authenticate with this module and then access either
>>> >> >> >> webERP or Care2x within the same session. Unfortunately
>>> >> >> >> due to time constraints this never got beyond being an
>>> >> >> >> idea. However the system works fine with Care2x in several
>>> >> >> >> hospitals now. I have since done a "proof of concept"
>>> >> >> >> example to show webERP working with oscommerce through the
>>> >> >> >> api.
>>> >> >> >>
>>> >> >> >> The web browser in the examples is just the interface to
>>> >> >> >> the client application. The communication is between the
>>> >> >> >> two applications on the server.
>>> >> >> >>
>>> >> >> >> There are several weaknesses with it at the moment, and
>>> >> >> >> you have pointed out two major ones. The first is the
>>> >> >> >> authentication. This needs to be improved. I never quite
>>> >> >> >> got my head around how the two applications would both
>>> >> >> >> track the session and as it wasn't vital for my particular
>>> >> >> >> purposes I left it as it was. In theory the client app
>>> >> >> >> could be anything written in any language on any platform.
>>> >> >> >>
>>> >> >> >> The other is the necessity to hard code the database name,
>>> >> >> >> which is clearly unsatisfactory. You might want to access
>>> >> >> >> several databases through the same server. I think this
>>> >> >> >> should be the clients responsibility to tell the server
>>> >> >> >> which database to update. Should this be passed at
>>> >> >> >> authentication time and stored in a session variable on
>>> >> >> >> the server side, as there would need to be a check that
>>> >> >> >> the client had authority for that database?
>>> >> >> >>
>>> >> >> >> I have always thought that the api had the potential to be
>>> >> >> >> "a killer app" for webERP but never really had the time to
>>> >> >> >> polish it as much as it deserves. Help would be greatly
>>> >> >> >> appreciated.
>>> >> >> >>
>>> >> >> >> Thanks
>>> >> >> >> Tim
>>> >> >> >>
>>> >> >> >> ----------------------------------------------------------
>>> >> >> >>--- --- --- ----------- Come build with us! The
>>> >> >> >> BlackBerry(R) Developer Conference in SF, CA is the only
>>> >> >> >> developer event you need to attend this year. Jumpstart
>>> >> >> >> your developing skills, take BlackBerry mobile
>>> >> >> >> applications to market and stay ahead of the curve. Join
>>> >> >> >> us from November 9 - 12, 2009. Register now!
>>> >> >> >> http://p.sf.net/sfu/devconference
>>> >> >> >> _______________________________________________
>>> >> >> >> Web-erp-developers mailing list
>>> >> >> >> Web-erp-developers@...
>>> >> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-devel
>>> >> >> >>ope rs
>>> >> >> >
>>> >> >> > -----------------------------------------------------------
>>> >> >> >--- --- ------------- Come build with us! The BlackBerry(R)
>>> >> >> > Developer Conference in SF, CA is the only developer event
>>> >> >> > you need to attend this year. Jumpstart your developing
>>> >> >> > skills, take BlackBerry mobile applications to market and
>>> >> >> > stay ahead of the curve. Join us from November 9 - 12,
>>> >> >> > 2009. Register now! http://p.sf.net/sfu/devconference
>>> >> >> > _______________________________________________
>>> >> >> > Web-erp-developers mailing list
>>> >> >> > Web-erp-developers@...
>>> >> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-develo
>>> >> >> >per s
>>> >> >>
>>> >> >> -------------------------------------------------------------
>>> >> >>--- --- ----------- Come build with us! The BlackBerry(R)
>>> >> >> Developer Conference in SF, CA is the only developer event
>>> >> >> you need to attend this year. Jumpstart your developing
>>> >> >> skills, take BlackBerry mobile applications to market and
>>> >> >> stay ahead of the curve. Join us from November 9 - 12, 2009.
>>> >> >> Register now! http://p.sf.net/sfu/devconference
>>> >> >> _______________________________________________
>>> >> >> Web-erp-developers mailing list
>>> >> >> Web-erp-developers@...
>>> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-develope
>>> >> >>rs
>>> >> >
>>> >> > --------------------------------------------------------------
>>> >> >--- ------------- Come build with us! The BlackBerry(R)
>>> >> > Developer Conference in SF, CA is the only developer event you
>>> >> > need to attend this year. Jumpstart your developing skills,
>>> >> > take BlackBerry mobile applications to market and stay ahead
>>> >> > of the curve. Join us from November 9 - 12, 2009. Register
>>> >> > now! http://p.sf.net/sfu/devconference
>>> >> > _______________________________________________
>>> >> > Web-erp-developers mailing list
>>> >> > Web-erp-developers@...
>>> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developer
>>> >> >s
>>> >>
>>> >> ----------------------------------------------------------------
>>> >>--- ----------- Come build with us! The BlackBerry(R) Developer
>>> >> Conference in SF, CA is the only developer event you need to
>>> >> attend this year. Jumpstart your developing skills, take
>>> >> BlackBerry mobile applications to market and stay ahead of the
>>> >> curve. Join us from November 9 - 12, 2009. Register now!
>>> >> http://p.sf.net/sfu/devconference
>>> >> _______________________________________________
>>> >> Web-erp-developers mailing list
>>> >> Web-erp-developers@...
>>> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>> >
>>> > -----------------------------------------------------------------
>>> >------------- Come build with us! The BlackBerry(R) Developer
>>> > Conference in SF, CA is the only developer event you need to
>>> > attend this year. Jumpstart your developing skills, take
>>> > BlackBerry mobile applications to market and stay ahead of the
>>> > curve. Join us from November 9 - 12, 2009. Register now!
>>> > http://p.sf.net/sfu/devconference
>>> > _______________________________________________
>>> > Web-erp-developers mailing list
>>> > Web-erp-developers@...
>>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>
>>> -------------------------------------------------------------------
>>>----------- Come build with us! The BlackBerry(R) Developer
>>> Conference in SF, CA is the only developer event you need to attend
>>> this year. Jumpstart your developing skills, take BlackBerry mobile
>>> applications to market and stay ahead of the curve. Join us from
>>> November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Web-erp-developers mailing list
>>> Web-erp-developers@...
>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web-erp-developers@...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers