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?
