[Evergreen-dev] Fieldmapper usage for vendor making api calls

[Bill Erickson]

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 <
evergreen-dev at list.evergreen-ils.org> 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 <
> evergreen-dev at list.evergreen-ils.org> 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
>> [image: Company logo]
>> *Josh Stompro*
>> IT Director
>> stomproj at gsuite.larl.org | 218-233-3757 ext. 139 | 218-790-2110
>> *Lake Agassiz Regional Library *
>> 118 5th ST S
>> Moorhead MN 56560
>> www.larl.org
>> *Our mission is to enrich lives and strengthen communities.*
>> _______________________________________________
>> Evergreen-dev mailing list
>> Evergreen-dev at list.evergreen-ils.org
>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
>>
>
>
> --
> Galen Charlton
> Implementation and IT Manager
> Equinox Open Library Initiative
> gmc at equinoxOLI.org
> https://www.equinoxOLI.org
> phone: 877-OPEN-ILS (673-6457)
> direct: 770-709-5581
> <http://evergreen-ils.org>
> _______________________________________________
> Evergreen-dev mailing list
> Evergreen-dev at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20231011/89917623/attachment-0001.htm>