Bad MARCXML to which Evergreen has been unable to add a 901c happens -
particularly with legacy MARCXML. Currently, TPAC crashes hard with an
ugly error if a 901c is not found when attempting to display the record
in search results. In comparison, the JSPAC displays the record without
a problem.
This commit logs a warning and enables the TPAC to continue somewhat
gracefully (the problem record is simply skipped in the search results).
A more robust solution may be to teach unapi.bre to add the record ID to
the results and to have the TPAC pull from that, rather than relying on
the MARCXML itself to contain the record ID.
Signed-off-by: Dan Scott <dscott@laurentian.ca>
Signed-off-by: Bill Erickson <berick@esilibrary.com>
my($self, $req) = @_;
my $data = $req->{response}->[0]->content;
my $xml = XML::LibXML->new->parse_string($data->{'unapi.bre'})->documentElement;
- my $bre_id = $xml->find('*[@tag="901"]/*[@code="c"]')->[0]->textContent;
+
+ # Protect against legacy invalid MARCXML that might not have a 901c
+ my $bre_id;
+ my $bre_id_nodes = $xml->find('*[@tag="901"]/*[@code="c"]');
+ if ($bre_id_nodes) {
+ $bre_id = $bre_id_nodes->[0]->textContent;
+ } else {
+ $logger->warn("Missing 901 subfield 'c' in " . $xml->toString());
+ }
push(@data, {id => $bre_id, marc_xml => $xml});
}
);