[OFBiz] Users - synching with OFBiz

[T E Schmitz]

Hello,

A while back we developed a stand-alone POS application
(Java/Postgres/Swing). The client now wants to generate an e-commerce
site from this database.

The existing application has no inventory management. The website is not
supposed to track stock levels either.

I downloaded OFBiz 3.0.0 for evaluation and we would like to use it for
the website. We set the OFBiz demo up with Postgres, Jetty and Apache.
In fact, we set up two copies because we might be running multiple
instances in the future.

However, we will need to "synch" the OFBiz database with the
application's database, either periodically or on demand. Any suggestions?

I know, I know, with hindsight it would have been best to have used
OFBiz' POS module. but the customer originally only wanted to run a
coffee-shop :-(, nor did we know of OFBiz then.

--


Regards/Gruß,

Elisabeth
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Ray Barlow]

Firstly don't use OFBiz 3.0.0. Either work from SVN, or one of Si Chens
weekly builds or wait until the next release. The 3.0.0 code base is
over a year old and lots has changed since then and the mailing list
will struggle to support you on 3.0.0.

How about a little more info about your preferred synch options i.e. are
you talking bi-directional, products only, transactions, from ofbiz to
app or from app to ofbiz?

The OFBiz entity engine does have a synch features, but you'd need to
dig a little deeper to see if you could use that. You could maybe
refactor the OFBiz code into your app so the communication is taken from
the OFBiz code and you write a layer to transform between your entities
and OFBiz?

You could write a service to export xml, csv or excel data from OFBiz
periodically or even import the data.

Ray



T E Schmitz wrote:

> Hello,
>
> A while back we developed a stand-alone POS application
> (Java/Postgres/Swing). The client now wants to generate an e-commerce
> site from this database.
>
> The existing application has no inventory management. The website is
> not supposed to track stock levels either.
>
> I downloaded OFBiz 3.0.0 for evaluation and we would like to use it
> for the website. We set the OFBiz demo up with Postgres, Jetty and
> Apache. In fact, we set up two copies because we might be running
> multiple instances in the future.
>
> However, we will need to "synch" the OFBiz database with the
> application's database, either periodically or on demand. Any
> suggestions?
>
> I know, I know, with hindsight it would have been best to have used
> OFBiz' POS module. but the customer originally only wanted to run a
> coffee-shop :-(, nor did we know of OFBiz then.
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[T E Schmitz]

Hello Ray,
Thanks for your reply.

Ray wrote:
> Firstly don't use OFBiz 3.0.0. Either work from SVN, or one of Si Chens
> weekly builds or wait until the next release. The 3.0.0 code base is
> over a year old and lots has changed since then and the mailing list
> will struggle to support you on 3.0.0.

It appeared to be the latest stable release. At least it was the last
one available on Sorceforge. I noticed, in Subversion (tags), there is a
REL_3.1.0 and a 3.2.0. 3.2.0, I understand is not far away from being
released but how stable is it? Stability is kind of crucial.

> How about a little more info about your preferred synch options i.e. are
> you talking bi-directional, products only, transactions, from ofbiz to
> app or from app to ofbiz?

First of all, let me give you a brief idea of our application and set-up.

It's a Swing application on a TouchScreen terminal talking to a Postgres
DB via Torque object mapper. Currently, there is one terminal only and
the DB is on a local server. The table structure is /simple/ bearing in
mind that this was designed for a coffee shop with max. hundred cakes
and coffees. Basically, to express it in OFBiz terms, there are
Categories and Products (1:n). There is a VAT (=tax) table - each
Product must be given a tax status. Transactions are stored for later
turnover analysis and quarterly VAT reports.

To complicate this posting further: not only does the user sell gifts
now but also works of art, which are handled completely differently
taxwise. They *must* be printed on separate invoices in order to
maintain their VAT status. But that problem could be solved later.

The required set-up: Products and Categories can only be changed
locally, only a uni-directional synch required. Products might be
deleted/discontinued. Pictures are stored in the local DB (bytea).
Web Transactions need to be synched into the local DB.

> The OFBiz entity engine does have a synch features, but you'd need to
> dig a little deeper to see if you could use that. You could maybe
> refactor the OFBiz code into your app so the communication is taken from
> the OFBiz code and you write a layer to transform between your entities
> and OFBiz?
>
> You could write a service to export xml, csv or excel data from OFBiz
> periodically or even import the data.

As we need a quick solution, one of the ideas I had was to export our
Categories and Products to xml. I had a look at ecommerce/data and it
would seem fairly straightforward to translate that to OFBiz entities.
And then get OFBiz to import the data. But how would that cope with
Products deleted in the local DB?

Kind regards,
Tarlika

> T E Schmitz wrote:
>
>> A while back we developed a stand-alone POS application
>> (Java/Postgres/Swing). The client now wants to generate an e-commerce
>> site from this database.
>>
>> The existing application has no inventory management. The website is
>> not supposed to track stock levels either.
>>
>> However, we will need to "synch" the OFBiz database with the
>> application's database, either periodically or on demand. Any
>> suggestions?

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users