[OPEN-ILS-DEV] ***SPAM*** Re: Adding ONIX support and Evergreen acquisitions

[Paul Waak]

The changes in 2.3 are indeed saving me a lot of time. I am using git to
follow master and have picked them up. Thanks.

You have it right that ONIX files are not normally part of EDI for a
library. However, we are adding native ebook support to Evergreen and now
need to let publishers load their product catalogs (usually in ONIX instead
of MARC) into Evergreen's catalog. These product catalogs need to be linked
to the provider, and we do not have the staff to manage all this manually.
Incorporating it into acquisitions seems like a good place to begin since
there is already a place for it in EDIFACT, X12, and EDItX. (Incidentally,
I only plan to add X12 or EDItX support if I absolutely have to. The
differences at first glance make me uneasy about just using a stylesheet
transform.)

My two other big changes to Evergreen will be allowing automatic
provisioning for user accounts that are authenticated via SIP2/NCIP (with a
gigantic "Thank you!" to whoever added the authentication proxy) and
allowing calls to a DRM service, like Adobe Content Server, during
acquisition and circulation (ugh).

On Sat, Aug 4, 2012 at 9:06 AM, Mike Rylander <mrylander at gmail.com> wrote:

> On Fri, Aug 3, 2012 at 3:20 PM, Paul Waak <ptwaak at gmail.com> wrote:
> > Hello everyone,
> >
> > I need to rapidly patch Evergreen to accept ONIX product selection files
> > from vendors as part of EDI. For the short term, the ONIX file will be
> > translated into MARC21slim XML and processed with Vandelay. I may have to
> > extend it to work with non-EDIFACT messages as well. At this point I have
> > two questions.
>
> IIUC, ONIX records are not EDI (that is, for the purposes of
> Evergreen, acquisitions/purchasing messages), but equivalent to MARC
> order records from a vendor.  Your current plan suggests I do, indeed,
> UC.
>
> Evergreen 2.3 just got massive feature improvements in this (ACQ order
> record loading) area, as well as EDI message processing.  You might
> want to look into those improvements, particularly the ACQ order
> record loading improvements, before too much code is written.  You may
> need nothing more than an ONIX-to-MARCXML stylesheet, and perhaps an
> X12-to-EDIFACT stylesheet for EDI.


> >
> > Is anyone already working on this?
> >
>
> That depends on exactly what version of Evergreen you're talking
> about; no new features go into existing releases, and 2.3 was just
> feature-frozen on August 1, so the next release that can get new
> features not already (nominally) complete is the release planned for
> the spring of 2013.  There is a good bit of ACQ work planned for then,
> but I'm not aware of ONIX support in particular.  Much of the recent
> work may simplify yours, however.  Here's a list of much of, but
> certainly not all, the recent ACQ related commits for 2.3 (now in
> beta):
>
>
> http://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=refs%2Fheads%2Frel_2_3&st=commit&s=ACQ
>
> > Also, I am looking at
> > Open-ILS/src/perlmods/lib/OpenILS/Application/Acq/EDI.pm and got
> curious. I
> > would like to follow the EDI file naming conventions "FTP FILENAMING
> > STANDARD – Issue 4" from EDItEUR / BISG / BIC. This would simplify a lot
> of
> > things. Before I dive into it, though, has anyone noticed whether vendors
> > actually follow this convention?
> >
>
> I doubt most ACQ suppliers do, but you'd need to confirm with them and
> test.  Even then, we'd surely need to be able to accept non-standard
> file names.
>
> --
> Mike Rylander
>  | Director of Research and Development
>  | Equinox Software, Inc. / Your Library's Guide to Open Source
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  miker at esilibrary.com
>  | web:  http://www.esilibrary.com
>



-- 
----------
Paul Waak
----------
Just as most issues are seldom black or white, so are most good
solutions seldom black or white.  Beware of the solution that requires
one side to be totally the loser and the other side to be totally the
winner.  The reason there are two sides to begin with usually is
because neither side has all the facts.  Therefore, when the wise
mediator effects a compromise, he is not acting from political
motivation.  Rather, he is acting from a deep sense of respect for the
whole truth.                 -- Stephen R. Schwambach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20120804/092271dc/attachment.htm>