That's a little bit different then...
What you probably need/want is some code to take in the incoming ONIX
files and map the information to existing OFBiz entities rather than
creating new ones.
As you're doing the mapping you'll get into the issue you brought up
here about what should go where. Different things will most likely be
best handled in different ways. For example, the "publisher" would be
handled well by a ProductFeature, but the title and ISBN would not as
they are unique to each book. Those could be put into ProductContent
records (with new ProductContentTypes) and handled with existing
code, or perhaps even just added as fields to the Product entity, and
then only small changes would be needed in the ProductSearch code (or
no changes... it's been a while since I wrote it so I don't remember
exactly).
In any case, I think you'll find pretty flexible and efficient
performing search capabilities in the ProductSearch stuff. Make sure
you're looking at a moderately recent version of OFBiz (ie not one of
the ancient releases, like 3.0.0 or something).
-David
On Aug 8, 2006, at 12:43 AM, Iain Fogg wrote:
David,
Basically I'm looking to augment the standard OFBiz functionality
with functionality specifically required in the book selling
business. As an absolute minimum, I need to be able to periodically
refresh the OFBiz product and supplier data with a subset of the
ONIX data (new titles, price changes, supplier info, etc). I also
want to look at ways of providing a richer set of search options
specific to the book trade (eg, title, publisher, ISBN, etc), and
to have all of the ONIX data available for back-office (and
sometimes front-of-house) enquiries.
I've seen it suggested that one of the ways to provide richer
content in the OFBiz Product database is to use the Feature
mechanism. I've played around with this a little bit, and it might
work, but I'd need to be convinced about performance and
maintainability. The ONIX dataset can contain hundreds of thousands
of records, and modelling these with the OFBiz Feature feature
seems a bit clumsy. I'm not sure what the impact would be on search
queries.
I'm still exploring my requirements, and at this stage about the
only thing I know for sure is that I need to synch ONIX data with
OFBiz to ensure OFBiz is using up-to-date info. Probably the other
thing I know for sure is that I need richer search options, and
response needs to be reasonable.
At the end of the day, one of the things I need to work out is how
to "integrate" (and I use the term loosely), ONIX and OFBiz.
Cheers, Iain
David E. Jones wrote:
Is the intent to map it to the OFBiz data model or services? I'm
guessing that's not the case if you're trying to create entities
to represent it.
If you're trying to create a data model for an XML Schema and not
mapping it to an existing data model, then you'll have to design
a data model to match it. XML is an hierarchical data structure
which is very different from a relational (table-based) one. Some
design will have to be done to decide how to structure things
because there are no natural equivalencies. There are, of course,
some common patterns for dealing with hierarchical and other
structures in SQL, but doing an effective mapping requires more
of an understanding of the data model so that the same data can
be captured in both places and this is very difficult to
automate. You might find some commercial tools that give you a
good first pass though... ie to go from XSD to SQL DDL.
-David
On Aug 7, 2006, at 6:51 PM, Iain Fogg wrote:
Chris,
Good question, and this probably exposes my ignorance of XST.
Maybe it's not the right technology. Maybe I need to find a tool
that can translate from XSD -> SQL. Then it would be
straightforward to map the relational table defs to the OFBiz
entity def. My small brain can't get round the mapping of the
hierarchical XML Schema to a relational one - at least not given
it's size. Maybe when I was younger :-)
In case anyone is interested, the schema I want to map is the
ONIX schema (used in the book trade).
Cheers, Iain
Chris Howe wrote:
Correct me if I'm wrong, but wouldn't you need to know
what the source elements are in order to make an XST
to entity def? Absent knowing the structure of your
source it wouldn't matter what someone else's XST
looks like, it wouldn't work with yours.
--- Iain Fogg <[EMAIL PROTECTED]> wrote:
That's my question...has anyone already buit an XST
to do the conversion to OFBiz Entity defs?
BJ Freeman wrote:
the XSD defines the layout.
the XML is where the Entities definitions are.
you can try using an XST file to convert.
Iain Fogg sent the following on 8/7/2006 7:53 AM:
I have a slightly complicated XML Schema (.xsd)
that I would like to
import into OFBiz.
Has anyone written a tool to convert XML schemas
into OFBiz entity
definitions?
Cheers, Iain
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.7/411 -
Release Date: 7/08/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.7/411 - Release Date:
7/08/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.7/411 - Release Date:
7/08/2006
