Questions about Openbravo POS to ERP

Help is preferred to those who publish their work as Open Source and not as private branches rejecting collaboration. Such projects are not maintainable and shall be deleted.
Forum rules
This forum is personally pruned to avoid redundant posts. Related topics are grouped together. IF YOU HAVE REGISTERED, you need to send email to red1(a)red1.org with your username in the subject title to get me to activate you.

Questions about Openbravo POS to ERP

Postby red1 » Wed Sep 07, 2011 12:31 pm

I put here FAQs that arise from newbies and users regarding the integration done. If you have more questions do ask below this thread and we shall get back to you by replying below that.

1. How are the queue messages formed?
Answer: Each synchronisation process whether it be from the POS or from the ERP is stored as a single queue message or actually a single XML string. In that string, is made up of <detail> tags where each detail is a single record, be they an order or product.

2. How would the system know which record belongs to which model?
Answer: At the moment we are using different queue paths, ie. for Products it is http://localhost:61613/Products and for Customer info it is ../Customers. Also in the code it checks for <DocType> to be the right model i.e. M_Product. So there is double measure to ensure the record is not taken wrongly. Even if it does, it should break into an exception and not proceed.

3. What if the ERP server is offline or the web access is down or unstable?
Answer: The beauty of ActiveMQ approach is that it is asynchronous, meaning that if either the POS or ERP host is down, there is no worry of getting the queue delivered in the end. Once either one is up and does a synch with the Queue server, the message is there for consumption.

4. What if the Queue server is down?
Answer: Then either ends cannot send or collect anything and have to wait for it to be up.

5. What happens to the queued messages that was not consumed when the Queue goes down?
Answer: There are not gone but stored in a disk cache database based on Derby at the queue server. They are still present if we are using PERSISTENT=TRUE setting when sending the message. At the moment we are using such a setting in the header property.

6. What if we have many POS clients all over needing to access the same ERP export queue? Would it disappear after the first POS client consumed the queue?
Answer: We are removing the removal of the queue for POS clients. The queue can only be removed by the ERP Server. Thus we leave the Products or Customers or any info for the POS stations on until all of them have taken it. In future we can incorporate an auto ACK (acknowledgment) that ensures all POS clients have synched with the ERP info before removing it.

7. How scalable is this thing?
Answer: This may be manageable to whatever degree we want solely at the ActiveMQ server (with some code change at the ERP side). We have not tested in a multi POS and real life remotely spread environment. But due to the maturity of ActiveMQ and its many features, we can extend the system to cover high performance requirements. At the moment you can use this to test the concept and even apply it to some 10 POS stations quietly.

8. How different is this from the previous work on replication and integration here and here.
Answer: The work done here is simple and limited but more up-to-date. It is simpler because we are using the Stomp broker that has minimal code to achieve very powerful build-up of functionality within ActiveMQ service. Thus it can be extended when needed. It is simple but limited because we are not making an end to end replication but just a definite scope of synching POS orders to the ERP end and taking products, inventory and customer info from the ERP side onto the POS. It is more up-to-date because besides the Stomp approach, we are referring to latest openbravo POS for 2.3 and not 2.2. The ERP side is also referring to ADempiere 361 of CarlosRuiz which is itself on same page with iDempiere by Hengsin.

9. Why should we refer to this instead of previous works?
Answer: Firstly you should ask if this is what you want. This project is as its title says is for 'integrating openbravo POS to ADempiere ERP' and not 'replication' proper. If so, then this is the right place as it is more clearly well commented in its code work and well documented here as well as in a complete PDF guide. The guide will also advice openly and freely how developers can take this and extend it further. With red1.org and his peers (Carlos Ruiz, HengSin and others) there is absolutely no information hiding. There is also the best practice compliance standards imposed on his peers that all code must be (a) English language based in namespace, (b) backward compatible or reported where it is not, (c) well tested and reviewable.

10. What about POSterita?
Answer: Sadly it is not contributed to the standards required. Now no one is contributing it further nor maintaining it. Also here we are concerned about the synch here and not the POS per say.

10.1. What about Openbravo ERP? Why not use it instead of ADempiere ERP?
Answer: Yes that is logical since Openbravo effectively introduced new plugin framework using Pentaho data tool which necessitates doing that synching from Openbravo ERP itself. ADempiere does not have that.This means in order for ADempiere to do the same, we have to close this gap with Openbravo also, which is beyond this Proof of Concept's scope. If you wish to go completely Openbravo, then that path is recommended. If you wish to stick to ADempiere, this is what we got. However we are community FOSS wheras Openbravo is commercial FOSS. There is a catch eventually.

11. Can we also contribute code work to the project?
Answer: We heard this many times. Just do it. We will find you and acknowledge you in if you did. But what we find is also (if there are such contributions) that work done is not to our standard of quality nor compliant to best practice. In those cases we do not respond nor wish to get involve with any controversy that will result if we do.

12. What if I cannot contribute accordingly but i can sponsor more work with money?
Answer: That is also nice, and you can write to us personally to negotiate the terms. However we must insist that our work is strictly FOSS and no code or info hiding is allowed. One of the issues with POSterita mentioned was that. You need not worry about trade secret client data as that is not code. Even client private configs is not code but metadata. We also give you back brand recognition when we publish you as the sponsor as the case here where SYSNOVA, Bangladesh is our main sponsor.

13. What if we need this for our own commercial environment? Can we purchase any guarantee or support?
Answer: This project is under clauses of GPL which like any other license (including proprietary) has no guarantee or liability for risks. However if you require paid implementation and support services, we can recommend you the following that we know personally to have delivered responsible and accountable service known within our community:
A. Adaxa, Melbourne, Australia with associates in USA (Joel Stangeland)
B. GlobalQSS, Colombia
(insist that they do not offer a discount. That is known to reduce the level of priority of you).
red1
Site Admin
 
Posts: 2759
Joined: Tue Jul 06, 2004 3:01 pm
Location: Kuala Lumpur, Malaysia

Re: Questions about Openbravo POS to ERP

Postby red1 » Wed Sep 07, 2011 1:02 pm

(message moved from other thread)

Hi Red!

Your work looks really good :-) I'm in the process of helping a food company with two grocery stores. Each sale is of relative low value and many products. There's really no need to accumulate all details of every purchase. Doing that, the data will grow very fast.

I have the idea that each day, all that's sold in a store would be imported into Adempiere as a single POS-sales order. Do you think that would be easy to implement in Open Bravo POS and Adempiere? I will look into it myself, but if you know anything about it, it would be helpful to know.

So, instead of exporting sales orders for each purchase, create just one sales order per day of the accumulated sales on each POS. WDYT?

/Daniel T

Thank you for your kind words, Dantam! I would love to help and if possible get a chance to work with you in Sweden! Yes, this technology really keep blowing me away more and more each passing moment. Ok about your one SO per day, it is actually more of 'one Queue per day'. In the queue is a long whole XML string that collects all the SOs, i.e. if there are 20 sales per day, there will be one XML string in the queue with 20 <details> ... </details>. The importer i created will untangle this and import into the I_Order table right off. In essence it is very achievable. But now i am very concerned about persistence, and security. My next pre-occupation right now and hope to work out something substantial and published it as soon as i found out. Looking forward to see this work well for you!

(post-note: Persistence was solved as stated in other thread and in this FAQ thread)
red1
Site Admin
 
Posts: 2759
Joined: Tue Jul 06, 2004 3:01 pm
Location: Kuala Lumpur, Malaysia


Return to HELP ME!!!

Who is online

Users browsing this forum: No registered users and 5 guests

cron