> > Lump services together. Look at ECAs and service groups. I think this will > satisfy your transaction requirements. >
kewl! On Tue, Mar 20, 2018 at 7:42 PM, Taher Alkhateeb <slidingfilame...@gmail.com > wrote: > 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. > > > > > > > > > > > >
