Lump services together. Look at ECAs and service groups. I think this will satisfy your transaction requirements.
On Tue, Mar 20, 2018, 4:16 PM Rajesh Mallah <mallah.raj...@gmail.com> wrote: > Hi Taher , > > there is ample space for the custom logic in the architecture . Its > basically in > an MVC pattern . There is a direct Model connected to the Entities(via > non-ofbiz > database connection) and an Indirect one via XMLRPC of OFBiz. > OFBiz is mostly being used as a data store now. > > With time as I familiarize myself with OFBiz capabilities, more custom > code can > be offloaded to OFBiz's inbuilt capabilities. Currently I have less > capability or > intent to mess with OFBiz code/ plugins. > > The only problem i see with the current approach is the lack of transaction > control. > I cannot rollback partial changes in case of run-time errors or failures. > the XMLRPC requests run on server in its own transaction context. But I am > yet > to face any real challenge due to this. > > regds > mallah. > > > > On Tue, Mar 20, 2018 at 3:24 PM, Taher Alkhateeb < > slidingfilame...@gmail.com > > wrote: > > > I like your approach, and my recommendation is to try and stick with > > the existing model. The combination between products, parties, stores > > and roles should be robust for your needs. However, I think you will > > probably need some custom logic around the processing of buyers and > > sellers since you're developing an exchange kind of market. > > > > I think maybe your custom logic is going to cover mostly the code > > _before_ a transaction happens between buyers and sellers. Maybe you > > can use the "opportunity" or "quote" or "requirement" entity to drive > > the follow up until a deal is closed at which time you trigger maybe > > an order which drives everything else. It depends on how you're > > exactly designing your system. > > > > > > >
