Gateways with hash-based input/output would be amazing! Bill's Rust project 
sounds very exciting.

Maybe we could use Galen's suggestions as a starting point for some official 
documentation about how to use the API for third-party applications? It sounds 
like there are best practices that aren't documented anywhere (as far as I 
know).

________________________________________
From: Evergreen-dev <[email protected]> on behalf of 
Bill Erickson via Evergreen-dev <[email protected]>
Sent: Wednesday, October 11, 2023 8:44 AM
To: Galen Charlton
Cc: Evergreen Development
Subject: Re: [Evergreen-dev] Fieldmapper usage for vendor making api calls

What Galen said.

--

If we want to talk about the future, the community has previously discussed and 
experimented with delivering hash-based data via certain APIs so the IDL is not 
required.  This can simplify implementation for new vendors and avoid the "data 
shifted" issues that can occur with stale IDLs.

As part of the Redis project, I created Rust variants of the Websockets and 
HTTP gateways which contain runtime options to use hash-based input and output.

E.g. 
https://redis.demo.kclseg.org/eg-http-gateway?service=open-ils.actor&method=open-ils.actor.org_tree.retrieve&format=hashfull

Once we're running Redis at KCLS, I plan to deploy the Rust variants.  If all 
goes well, I expect this will be our default for vendor API access and some 
one-off patron interfaces going forward.

-b


On Wed, Oct 11, 2023 at 9:56 AM Galen Charlton via Evergreen-dev 
<[email protected]<mailto:[email protected]>>
 wrote:
Hi,

Having the app consult the IDL is indeed the way to go. This ideally should 
happen on startup, although it would be reasonable to cache the results, 
potentially for fairly lengthy durations. The 24 hours you suggest should 
generally be fine, although it could still lead to some friction for patrons 
the day after an Evergreen upgrade. Triggers for updating the cached IDL values 
would include:

- a change in Evergreen version number as reported by 
opensrf.open-ils.system.ils_version
- a change in file modification date reported by an HTTP HEAD request on 
/reports/fm_IDL.xml

Parsing /reports/fm_IDL.xml will work, but alternatives to parsing the whole 
IDL (most of which is presumably irrelevant to the app) is parsing the output 
of /IDL2js. This can be restricted to only the class of interested, e.g., 
/IDL2js?acp,au

Regards,

Galen

On Wed, Oct 11, 2023 at 8:55 AM Josh Stompro via Evergreen-dev 
<[email protected]<mailto:[email protected]>>
 wrote:
Hello, I was working with Solus on some breakage of their app after our upgrade 
to 3.11.  The issue was related to the fields ordering changing in the results 
to  service=open-ils.auth method=open-ils.auth.session.retrieve.

When they initially set it up, they just went by the index number of each 
result, but that changed due to actor.usr changes over the years.

I suggested that they could take a look at  /reports/fm_IDL.xml for the new 
ordering, and they quickly setup a system to grab that file every 24 hours and 
use it to access the fields for api results.  I just wanted to double check to 
see if that is the recommended way to handle things if they have customers with 
different versions of evergreen?  Is there a simpler approach that would be 
better?

Thanks
Josh
[Company logo]
Josh Stompro
IT Director
[email protected]<mailto:[email protected]> | 218-233-3757 ext. 
139 | 218-790-2110
Lake Agassiz Regional Library
118 5th ST S
Moorhead MN 56560
www.larl.org<http://www.larl.org>
Our mission is to enrich lives and strengthen communities.
_______________________________________________
Evergreen-dev mailing list
[email protected]<mailto:[email protected]>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev


--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
[email protected]<mailto:[email protected]>
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
<http://evergreen-ils.org>
_______________________________________________
Evergreen-dev mailing list
[email protected]<mailto:[email protected]>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
This message originated from outside the M365 organisation. Please be careful 
with links, and don't trust messages you don't recognise.
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev

Reply via email to