Bug 7613 - OCLC Connexion Gateway, including extension svc/import_bib
Summary: OCLC Connexion Gateway, including extension svc/import_bib
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: 3.8
Hardware: All All
: P5 - low enhancement (vote)
Assignee: D Ruth Holloway
QA Contact: Ian Walls
URL:
Keywords:
Depends on:
Blocks: 26278
  Show dependency treegraph
 
Reported: 2012-02-28 00:04 UTC by Srdjan Jankovic
Modified: 2021-10-01 23:01 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
patch (25.34 KB, patch)
2012-03-13 04:04 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (27.83 KB, patch)
2012-03-19 09:46 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
OCLC set up 1 (67.51 KB, image/png)
2012-03-19 12:11 UTC, Nicole C. Engard
Details
OCLC set up 2 (74.00 KB, image/png)
2012-03-19 12:11 UTC, Nicole C. Engard
Details
OCLC set up 3 (34.77 KB, image/png)
2012-03-19 12:11 UTC, Nicole C. Engard
Details
patch (27.88 KB, patch)
2012-03-20 07:00 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
bug_7613: OCLC Connexion gateway (27.92 KB, patch)
2012-03-22 14:52 UTC, MJ Ray (software.coop)
Details | Diff | Splinter Review
oneitem.xml (2.69 KB, text/plain)
2012-03-22 15:19 UTC, MJ Ray (software.coop)
Details
patch (29.36 KB, patch)
2012-03-23 04:04 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (31.41 KB, patch)
2012-03-29 03:08 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
bug_7613: OCLC Connexion gateway (31.45 KB, patch)
2012-03-29 14:41 UTC, MJ Ray (software.coop)
Details | Diff | Splinter Review
Bug 7613 follow up to fix perlcritic errors (1.28 KB, patch)
2012-04-05 02:28 UTC, Chris Cormack
Details | Diff | Splinter Review
Followup patch. (10.93 KB, patch)
2012-06-11 19:40 UTC, D Ruth Holloway
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Srdjan Jankovic 2012-02-28 00:04:32 UTC
Work to be done:
* C4::ImportBatch: create sub GetImportBatchByFilename($filename) which will get the last import_batches record with the filename
* Create svc/import_bib
  -  POST request structure:
param1: val
param2: val
<?xml version="1.0" encoding="UTF-8"?>
<record ...
</record>
  -  call C4::ImportBatch::GetImportBatchByFilename("webservice"); if in 'stage' status use it, otherwise create new one AddImportBatch() using POST param
  -  call C4::ImportBatch::AddBiblioToBatch() and AddItemsToImportBiblio()
  -  if import mode = 'direct' call C4::ImportBatch::BatchCommitBibRecords()
* misc/cronjobs/import_webservice_batch.pl:
  -  input params: framework (default 'default')
  -  call C4::ImportBatch::GetImportBatchByFilename("webservice"); if in 'stage' status
  -  call C4::ImportBatch::BatchCommitBibRecords()
* create OCLC requests listening daemon connexion_import.pl
  -  base on HTTP::Server or similar
  -  command line params: config file
  -  config values as per spec
  -  first get the auth cooki from auth url, then make request to import url

How to test:
* using some tool (wget or curl) make a request with some MARC xml to OCLC daemon
* check koha import batches that a webservice batch is created with params as in the config file
* run cron job from the command line and check the batch status
Comment 1 Srdjan Jankovic 2012-03-13 04:04:44 UTC Comment hidden (obsolete)
Comment 2 Marcel de Rooy 2012-03-14 12:09:18 UTC
Except from the title, this problem report does not really tell people what to expect from this patch. Questions are welcome, but documentation about this new feature too ;)
Comment 3 Nicole C. Engard 2012-03-16 16:11:19 UTC
patch
Apply? [yn] y

Applying: bug_7613: OCLC Connexion gateway
/home/nengard/kohaclone/.git/rebase-apply/patch:237: trailing whitespace.
    
/home/nengard/kohaclone/.git/rebase-apply/patch:363: trailing whitespace.
       
/home/nengard/kohaclone/.git/rebase-apply/patch:396: trailing whitespace.
        
/home/nengard/kohaclone/.git/rebase-apply/patch:662: trailing whitespace.
    print XMLout($result, NoAttr => 1, RootName => 'response', XMLDecl => 1); 
/home/nengard/kohaclone/.git/rebase-apply/patch:700: trailing whitespace.
    
error: patch failed: installer/data/mysql/updatedatabase.pl:4892
error: installer/data/mysql/updatedatabase.pl: patch does not apply
Patch failed at 0001 bug_7613: OCLC Connexion gateway
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Patch left in /tmp/patch-FolgxS.patch
nengard@kohavm:~/kohaclone$
Comment 4 Srdjan Jankovic 2012-03-19 09:46:25 UTC Comment hidden (obsolete)
Comment 5 Srdjan Jankovic 2012-03-19 09:56:57 UTC
(In reply to comment #2)
> Except from the title, this problem report does not really tell people what
> to expect from this patch. Questions are welcome, but documentation about
> this new feature too ;)

This is an implementation of OCLC Connexion Gateway. I suppose it makes more sense for people dealing with OCLC.
It also improves on svc/new_bib script in the way that it creates an imort batch rather than adding bib records directly. Again, I assume it makes sense to people using svc/new_bib. I do not know why svc/new_bib was implemented, I just made a (hopefully more useful) drop in replacement.

I have documented implementation/usage details in the patch comments, and connexion_import_daemon.pl help message is useful. I'm happy to expand, but need some help, ie which documentation in particular and where.
Comment 6 Nicole C. Engard 2012-03-19 11:59:52 UTC
Okay, this patch applies now, but I need a test plan.  I have OCLC Connexion on my computer and accessible via the web.  How do I connect it to Koha? I catalog a record in OCLC and do what to get that record in to Koha?

Nicole
Comment 7 Ian Walls 2012-03-19 12:05:23 UTC
Nicole,


You'll need to figure OCLC Connexion to export to the Koha gateway.  This should be done in their admin menu somewhere.  Once you've input the configurations, it should be as simple as pressing F5, and your record will export to Koha, and you'll get a confirmation message.
Comment 8 Nicole C. Engard 2012-03-19 12:10:23 UTC
That I understand, but I have no idea what values to put in the set up - see attached.
Comment 9 Nicole C. Engard 2012-03-19 12:11:03 UTC
Created attachment 8268 [details]
OCLC set up 1
Comment 10 Nicole C. Engard 2012-03-19 12:11:20 UTC
Created attachment 8269 [details]
OCLC set up 2
Comment 11 Nicole C. Engard 2012-03-19 12:11:36 UTC
Created attachment 8270 [details]
OCLC set up 3
Comment 12 MJ Ray (software.coop) 2012-03-19 16:35:19 UTC
I think new_bib was created for biblios.net to send records to Koha. I wonder if it predates the import batch management system, or if there was some reason for biblios.net to not use it.

I have tested branch 'bug_7613_wr89060' of git://git.catalyst.net.nz/koha as of Mon Mar 19 22:37:16 2012 +1300, but testing an import_bib failed because it has use Carp::Always which seems like a new dependency. Commenting it out seemed to let it work - is it necessary?
Comment 13 Srdjan Jankovic 2012-03-20 07:00:05 UTC Comment hidden (obsolete)
Comment 14 MJ Ray (software.coop) 2012-03-21 19:31:56 UTC
(In reply to comment #13)

I tested attachment 8328 [details] [review] 

I don't think the commented Carp::Always is against the policy - see http://wiki.koha-community.org/wiki/Coding_Guidelines#Perl

The problem I have now is that sending the first ebook from http://www.clicweb.org/images/stories/ediscover/ebook.mrc as marcxml to import_bib with curl -b svc.cookie --data @one.xml http://intranet/cgi-bin/koha/svc/import_bib # produced no output or visible effect on Koha. Should it?

The marcxml converted with xml2marc went through Tools: Stage MARC Records for Import fine so I think the problem is with either import_bib or my curl command. Which do you think?
Comment 15 Srdjan Jankovic 2012-03-22 01:04:05 UTC
There are some things to watch out for. I don't think
  curl -b svc.cookie --data @one.xml
will work, cause it will make a request with
  Content-Type: application/x-www-form-urlencoded
This is actually a non-standard POST, so needs to be
  Content-Type: text/plain
That's because we don't have param/value pairs, and we don't have them because
* then we'd need to encode xml
* svc/new_bib did not do that, and the idea was to make this a drop-in replacement; this also ruled out multipart option

So CGI will devour content if it is application/x-www-form-urlencoded. I assume --header="content-type: text/plain" would work (it did with wget).

Regardless, an error should be thrown in the apache log file

So can you please:
* try with --header, and if no luck
* send me:
- one.xml
- curl response
- error from the apache log if any
Comment 16 MJ Ray (software.coop) 2012-03-22 14:49:02 UTC
(In reply to comment #15)
> assume --header="content-type: text/plain" would work (it did with wget).

Yes, that worked.

I'll sign off now (I'm updating status prematurely now).  Is there a way to trigger the import of a staged batch from the svc API and if not, could that be added under this bug, or should that be another enh bug?
Comment 17 MJ Ray (software.coop) 2012-03-22 14:52:10 UTC Comment hidden (obsolete)
Comment 18 MJ Ray (software.coop) 2012-03-22 15:19:31 UTC
Created attachment 8527 [details]
oneitem.xml

test data
Comment 19 MJ Ray (software.coop) 2012-03-22 15:24:15 UTC
Actually can I revoke that signoff? Sorry, but I confused myself with what I put in through the web interface yesterday. I thought one.xml had uploaded, but I realise now that it was the copy I uploaded through Tools yesterday.

I can submit oneitem.xml using curl as outlined above (curl -b svc.cookie -d '@oneitem.xml' -H 'Content-Type: text/plain' http://intranet/cgi-bin/koha/svc/import_bib) and import_bib now answers with

<?xml version='1.0' standalone='yes'?>
<response>
  <import_batch_id>4</import_batch_id>
  <marcxml>
&lt;collection
  xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;
  xsi:schemaLocation=&quot;http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd&quot;
  xmlns=&quot;http://www.loc.gov/MARC21/slim&quot;&gt;

&lt;record&gt;
  &lt;leader&gt;00867nam a2200241Ki 4500&lt;/leader&gt;
  &lt;controlfield tag=&quot;001&quot;&gt;PG5739&lt;/controlfield&gt;
  &lt;controlfield tag=&quot;005&quot;&gt;20101215134800.0&lt;/controlfield&gt;
  &lt;controlfield tag=&quot;006&quot;&gt;m||||||||d||||||||&lt;/controlfield&gt;
  &lt;controlfield tag=&quot;007&quot;&gt;cr||n |||muaua&lt;/controlfield&gt;
  &lt;controlfield tag=&quot;008&quot;&gt;101213s2004    utu     o           eng d&lt;/controlfield&gt;
  &lt;datafield tag=&quot;042&quot; ind1=&quot; &quot; ind2=&quot; &quot;&gt;
;
    &lt;subfield code=&quot;h&quot;&gt;[electronic resource].&lt;/subfield&gt;
  &lt;/datafield&gt;
  &lt;datafield tag=&quot;260&quot; ind1=&quot; &quot; ind2=&quot; &quot;&gt;
    &lt;subfield code=&quot;a&quot;&gt;Salt Lake City :&lt;/subfield&gt;
    &lt;subfield code=&quot;b&quot;&gt;Project Gutenberg Literary Archive Foundation,&lt;/subfield&gt;
    &lt;subfield code=&quot;c&quot;&gt;2004.&lt;/subfield&gt;
  &lt;/datafield&gt;
  &lt;datafield tag=&quot;300&quot; ind1=&quot; &quot; ind2=&quot; &quot;&gt;
    &lt;subfield code=&quot;a&quot;&gt;1 online resource :&lt;/subfield&gt;
    &lt;subfield code=&quot;b&quot;&gt;multiple file formats.&lt;/subfield&gt;
  &lt;/datafield&gt;
  &lt;datafield tag=&quot;500&quot; ind1=&quot; &quot; ind2=&quot; &quot;&gt;
    &lt;subfield code=&quot;a&quot;&gt;Records generated from Project Gutenberg
RDF data.&lt;/subfield&gt;
  &lt;/datafield&gt;
  &lt;datafield tag=&quot;500&quot; ind1=&quot; &quot; ind2=&quot; &quot;&gt;
    &lt;subfield code=&quot;a&quot;&gt;ISO 639-2 language code:&lt;/subfield&gt;  &lt;/datafield&gt;
  &lt;datafield tag=&quot;540&quot; ind1=&quot; &quot; ind2=&quot; &quot;&gt;
    &lt;subfield code=&quot;a&quot;&gt;Applicable license: http://www.gutenberg.org/license&lt;/subfield&gt;
  &lt;/datafield&gt;
  &lt;datafield tag=&quot;546&quot; ind1=&quot; &quot; ind2=&quot; &quot;&gt;
    &lt;subfield code=&quot;a&quot;&gt;Text in Korean and English.&lt;/subfield&gt;
  &lt;/datafield&gt;
  &lt;datafield tag=&quot;655&quot; ind1=&quot; &quot; ind2=&quot;0&quot;&gt;
    &lt;subfield code=&quot;a&quot;&gt;Electronic books.&lt;/subfield&gt;
  &lt;/datafield&gt;
  &lt;datafield tag=&quot;700&quot; ind1=&quot;1&quot; ind2=&quot; &quot;&gt;
    &lt;subfield code=&quot;a&quot;&gt;Kuperman, Leon,&lt;/subfield&gt;
    &lt;subfield code=&quot;e&quot;&gt;author.&lt;/subfield&gt;
  &lt;/datafield&gt;
  &lt;datafield tag=&quot;710&quot; ind1=&quot;2&quot; ind2=&quot; &quot;&gt;
    &lt;subfield code=&quot;a&quot;&gt;Project Gutenberg.&lt;/subfield&gt;
  &lt;/datafield&gt;
  &lt;datafield tag=&quot;856&quot; ind1=&quot;4&quot; ind2=&quot;0&quot;&gt;
    &lt;subfield code=&quot;u&quot;&gt;http://www.gutenberg.org/etext/5739&lt;/subfield&gt;
    &lt;subfield code=&quot;y&quot;&gt;Click here to access a downloadable ebook.&lt;/subfield&gt;
  &lt;/datafield&gt;
&lt;/record&gt;

&lt;/collection&gt;</marcxml>
  <status>ok</status>
</response>

but when I visit http://intranet/cgi-bin/koha/tools/manage-marc-import.pl there is no import batch number 4. Also, I've just attached the oneitem.xml which includes an item tag 952, but the marcxml above doesn't include the item.  I'm not sure I understand how this is meant to work.  I'll keep hacking for a while.
Comment 20 MJ Ray (software.coop) 2012-03-22 15:41:41 UTC
OK, it seems that the books are appearing and that putting import_mode: direct on the first line before the XML causes, so my remaining questions are:

1. why don't the batches appear on http://intranet/cgi-bin/koha/tools/manage-marc-import.pl for me? Should C4::ImportBatch::GetImportBatchRangeDesc and ::GetNumberOfNonZ3950ImportBatches be changed?

2. why are we using a mixed colon-delimited and XML input file, instead of GET parameters and an XML post? So it would be like http://intranet/cgi-bin/koha/svc/import_bib?import_mode=direct and just an XML file POSTed, which I think may be more portable for web API libraries.

Thanks for this and sorry for getting so confused.
Comment 21 Srdjan Jankovic 2012-03-22 23:23:18 UTC
(In reply to comment #20)
>
> 1. why don't the batches appear on
> http://intranet/cgi-bin/koha/tools/manage-marc-import.pl for me? Should
> C4::ImportBatch::GetImportBatchRangeDesc and
> ::GetNumberOfNonZ3950ImportBatches be changed?

Yes, it's an omission, will correct that

> 
> 2. why are we using a mixed colon-delimited and XML input file, instead of
> GET parameters and an XML post? So it would be like
> http://intranet/cgi-bin/koha/svc/import_bib?import_mode=direct and just an
> XML file POSTed, which I think may be more portable for web API libraries.

Frankly, I have not thought of that. I've never encountered such situation, and had only problems when mixing url and post params. However, this is a different case, and it does look better, so I'll try to implement it.
Comment 22 Srdjan Jankovic 2012-03-23 04:04:04 UTC Comment hidden (obsolete)
Comment 23 MJ Ray (software.coop) 2012-03-27 11:17:43 UTC
I'm still unable to signoff because when uploading the above-attached oneitem.xml which includes an item tag 952, the marcxml above doesn't include the item.  I'm not sure I understand how this is meant to work.

The command I'm using now is:

curl -b svc.cookie -d '@oneitem.xml' -H 'Content-Type: text/plain' 'http://intranet/cgi-bin/koha/svc/import_bib?import_mode=direct
Comment 24 Srdjan Jankovic 2012-03-28 00:06:04 UTC
I cannot give an authoritative answer, I can only say "It should work as UI import". So if you want items to appear you may need to turn on some knobs, eg
"http://intranet/cgi-bin/koha/svc/import_bib?import_mode=direct&item_action=always_add"
Comment 25 Srdjan Jankovic 2012-03-29 03:08:48 UTC Comment hidden (obsolete)
Comment 26 MJ Ray (software.coop) 2012-03-29 14:36:52 UTC
Now there's a 0 to the left of every bib shown on screens like
http://intranet/cgi-bin/koha/tools/manage-marc-import.pl?import_batch_id=14

I can't be sure (cleaned all old imports during testing) but I'm
pretty sure that was working until this patch.  Sorry!

I think I'm willing to sign it off without fixing that problem as it
seems to be merely cosmetic, but I'm checking with #koha
Comment 27 MJ Ray (software.coop) 2012-03-29 14:41:37 UTC
Created attachment 8691 [details] [review]
bug_7613: OCLC Connexion gateway

svc/import_bib:
* takes POST request with parameters in url and MARC XML as DATA
* pushes MARC XML to an impoort bach queue of type 'webservice'
* returns status and imported record XML
* is a drop-in replacement for svc/new_bib

misc/cronjobs/import_webservice_batch.pl:
* a cron job for processing impoort bach queues of type 'webservice'
* batches can also be processed through the UI

misc/bin/connexion_import_daemon.pl:
* a daemon that listens for OCLC Connexion requests and is compliant
  with OCLC Gateway spec
* takes request with MARC XML
* takes import batch params from a config file and forwards the lot to
  svc/import_bib
* returns status

ImportBatches:
* Added new import batch type of 'webservice'
* Changed interface to AddImportBatch() - now it takes a hashref
* Replaced batch_type = 'batch' with
  batch_type IN ( 'batch', 'webservice' ) in some SELECTs

Signed-off-by: MJ Ray <mjr@phonecoop.coop>
Comment 28 Srdjan Jankovic 2012-03-30 00:40:41 UTC
Sequence will always be 0 for webservice batches. Those records are added individually and sequence makes no sense in that context.
Comment 29 Ian Walls 2012-04-03 19:49:48 UTC
I'm not in a position to test the OCLC Connexion Gateway itself, but the new daemon looks to be alright.  At the very least, it's not going to break anything.  Neither will the new web service import_bib.

The changes to C4 modules, tests and manage-marc-import.pl are all implemented safely, with all changes to the AddImportBatch() subroutine changed to use the new hashref param.

Marking as Passed QA.
Comment 30 Paul Poulain 2012-04-04 12:48:28 UTC
QA comment:

sorry, but there is a new file that is not perlcritic compliant:
misc/bin/connexion_import_daemon.pl: Bareword file handle opened at line 115, column 5.  See pages 202,204 of PBP.  (Severity: 5)
misc/bin/connexion_import_daemon.pl: Two-argument "open" used at line 115, column 5.  See page 207 of PBP.  (Severity: 5)
misc/bin/connexion_import_daemon.pl: Two-argument "open" used at line 148, column 9.  See page 207 of PBP.  (Severity: 5)

can you please submit a follow-up and resubmit (mark passed QA directly, the rest is OK from a QA pov, i haven't tested yet, will do with the follow-up)
Comment 31 Chris Cormack 2012-04-05 02:28:48 UTC
Created attachment 8896 [details] [review]
Bug 7613 follow up to fix perlcritic errors
Comment 32 Paul Poulain 2012-04-06 15:36:48 UTC
(In reply to comment #5)
> (In reply to comment #2)
> > Except from the title, this problem report does not really tell people what
> > to expect from this patch. Questions are welcome, but documentation about
> > this new feature too ;)
> 
> This is an implementation of OCLC Connexion Gateway. I suppose it makes more
> sense for people dealing with OCLC.
> It also improves on svc/new_bib script in the way that it creates an imort
> batch rather than adding bib records directly. Again, I assume it makes
> sense to people using svc/new_bib. I do not know why svc/new_bib was
> implemented, I just made a (hopefully more useful) drop in replacement.
> 
> I have documented implementation/usage details in the patch comments, and
> connexion_import_daemon.pl help message is useful. I'm happy to expand, but
> need some help, ie which documentation in particular and where.

Patch pushed, but I haven't tested it because I'm like Marcel, I don't understand what it is adding.
I think it's useful because MJ seem interested, I just hope Nicole understand and will be able to document.
Comment 33 D Ruth Holloway 2012-06-01 12:59:08 UTC
Reopening--the OCLC Connexion client for Windows can't use this daemon--something is happening in there, and the socket payload is not getting to the import_bib phase, at all.  I'm working on it now.
Comment 34 D Ruth Holloway 2012-06-11 19:40:36 UTC
Created attachment 10240 [details] [review]
Followup patch.
Comment 35 Srdjan Jankovic 2012-06-11 23:15:32 UTC
The patch is good, except for one issue - it was requested for svc/import_bib to be a drop in replacement for svc/new_bib. This patch changes interface, ie makes a proper url encoded post param/value POST request. svc/new_bib has pure XML in POST body.
Please check if that is fine.
Comment 36 D Ruth Holloway 2012-08-17 12:32:34 UTC
Srdjan,

The change was not merely aesthetic; I was unable to make pure-XML requests such as the new_bib functionality work when using the OCLC Connexion Web--"working but different than planned" when planned doesn't work, implies a flawed plan.

The new_bib functionality doesn't take into account the desired settings for overlay, matching, etc; it just does a brute-force AddBiblio. The Connexion listener provides for setting up values for overlay, matching, item processing, and default framework, so making import_bib *not* be a drop-in replacement here is quite okay; it actually allows the Connexion listener to work as designed.

If new_bib works, well, that's fine. I haven't tested that, so don't *know* if this will be a desirable replacement--but I *do* know, through rather a lot of testing, that import_bib as fixed in this patch, does.  (and, as you mentioned, properly encoded, which is a plus, and also taking into account the settings from the listener's config file.)

Aside, probably relevant to testing:

OCLC Connexion Web and the OCLC Connexion Client are two entirely different animals--they send the data differently, and their behavior after doing so is different as well.  Connexion Web sends the data blindly, and says, "okay, I did it," pretty-much regardless of what is going on in the Koha end--even if the service is *not turned on*.  The Connexion Desktop Client, however, actually initiates a connection to the Koha system, confirms the functionality, knows to log in and what will happen if it can't, and waits for an answer from the Koha end to make sure the record was added.  Much superior, which is why the sponsoring libraries are *NOT* using Connexion Web.

Nonetheless, I wanted this to actually work for both.  And now it does.
Comment 37 Tom 2012-08-17 16:26:20 UTC
As one of the library's that sponsored development of Koha functionality to import bibliographic records directly from OCLC's Connexion application, I would like to inform the community that the patch has been used in production in our library for roughly 45 days.  We consider the patch well-tested and it functions properly.  Below are a few comments:

We use it daily and it works well for the way we use it.  We use it to "directly" import bibliographic records from OCLC's Connexion application's Gateway Export.  We do not examine or manually manage the resevoir, rather we let this new development totally import the records.

We only use OCLC's Connexion client software so this is the OCLC Connexion product we tested with.  We did not test Koha (the patch) with or use it with OCLC's web version of the software.  

Of course when the patch is integrated into the stable Koha code, it will need documentation for the configuration and use.

In closing, we (Preston Library - Virginia Military Institute) would like to sign-off/indicate that the patch was well tested at our library for the client version of Connexion.  If we need to do this more formally, please let me know what I need to do to sign off on it.
Tom
Comment 38 Ian Walls 2012-08-17 17:53:29 UTC
Fixes the daemon and svc import mechanism to actually work, and since this is in production live for a library that relies on the functionality day to day, I'm inclined to believe this is a solid improvement.  Again, as it does not impact the rest of Koha, these changes are safe and Pass QA.
Comment 39 Srdjan Jankovic 2012-08-19 23:39:59 UTC
(In reply to comment #36)
> Srdjan,
> 
> The change was not merely aesthetic; I was unable to make pure-XML requests
> such as the new_bib functionality work when using the OCLC Connexion
> Web--"working but different than planned" when planned doesn't work, implies
> a flawed plan.
> 
> The new_bib functionality doesn't take into account the desired settings for
> overlay, matching, etc; it just does a brute-force AddBiblio. The Connexion
> listener provides for setting up values for overlay, matching, item
> processing, and default framework, so making import_bib *not* be a drop-in
> replacement here is quite okay; it actually allows the Connexion listener to
> work as designed.

That is perfectly fine. I asked the question because when given the task, the spec said that it was intended to be a drop in replacement for new_bib, and I used it as the starting point. It is possible that I took it a bit too far with the interpertation of "drop-in". I agree that the most important thing is that it does the job.

> OCLC Connexion Web and the OCLC Connexion Client are two entirely different
> animals--they send the data differently, and their behavior after doing so
> is different as well.  Connexion Web sends the data blindly, and says,
> "okay, I did it," pretty-much regardless of what is going on in the Koha
> end--even if the service is *not turned on*.  The Connexion Desktop Client,
> however, actually initiates a connection to the Koha system, confirms the
> functionality, knows to log in and what will happen if it can't, and waits
> for an answer from the Koha end to make sure the record was added.  Much
> superior, which is why the sponsoring libraries are *NOT* using Connexion
> Web.

That is another thing. I was not aware that it was supposed to be testing it with a windows client that I don't have. I would have discussed it more had I known.

> 
> Nonetheless, I wanted this to actually work for both.  And now it does.

Thanks a lot for taking this over under the circumstances, and apologies for the pain caused.
Comment 40 Paul Poulain 2012-09-03 09:38:23 UTC
Ruth : I think only the follow-up patch is to apply. Could you confirm by obsoleting what can be obsoleted ? (ie: the 2 first patches I think)
Comment 41 D Ruth Holloway 2012-09-04 14:03:31 UTC
"Obsolete" is probably incorrect--all three patches are necessary for the thing to work..but the first two *have* already been pushed, so all you need to push is the third one.

Thanks!
Comment 42 Paul Poulain 2012-09-05 12:54:22 UTC
Follow-up patch pushed

(Ruth, when I say "obsolete", I mean mark patches as obsolet on the bug, because they are already applied. That's how it's usually done)
Comment 43 Chris Cormack 2012-09-06 05:07:34 UTC
Follow up pushed to 3.8.x will be in 3.8.5