0
Completed

Composite Aurion connectors required

Shane Day (Chief Technology Officer) 8 years ago in UNIFYBroker/Aurion • updated by anonymous 4 years ago 2

A number of projects involving Aurion stall for a number of reasons, mostly to do with Aurion's API.

A topic on INTIDBAUR:Aurion project risk mitigation strategies has been commenced and will hopefully be completed in the next couple of days.

However, the only successful treatment will be to eventually get enough pressure on Aurion to fix the issue at their end. Some of our workarounds will only work for small datasets, or internally hosted solutions, and some of these end up being difficult to maintain. At present, however, the impact is critical.

As all Aurion teams will now be instructed to perform some treatment by insisting the client informs Aurion of any issue, and this being enforced through the new project management office, a version of the connector that permits composition of one of the following options is required to ensure current projects are not blocked:

  • A way of using the filter mechanism on the QUERY_TO_XML function to perform the same query with different filter parameters, resulting in the retrieval of all relevant data by requests that can be performed within the time-out period.
  • A away of using multiple queries with the same data schema to retrieve all relevant data by requests that can be performed within the time-out period.

At no time is this to be considered a permanent resolution to the Aurion query performance issue.

Affected Versions:
Fixed by Version:

I've spent the last day and a bit trying to get the filtering mechanism on the QUERY_TO_XML function to work, but have had no luck. With the help of some of the built in Aurion documentation I now understand exactly what it's supposed to do as we've used filters in the past for various things, and marking "Ask in batch" so it accepts parameters for filters from external requests is all I'm supposed to have to do, but it's just not doing anything with the parameters I send. Originally I was testing with Surname, but after specifying the filters directly in the query it seems "between", "greater than" and "less than" don't seem to mix well with it. Switched to "Person ID" which works with the built-in parameters, but still not ones sent through the API. If I mark "mandatory" on the fields an error is thrown saying no parameters were specified and if I don't it just ignores them. I suspect it's one of the following:

  • I'm not supplying the filter parameters in the correct format. No where does it say if I need to specify the name of the field and to specify parameters for different fields you just delimit them with a particular set of characters.
  • Our 9.3.02 documentation is out of date (probably unlikely as we've been told a few times it's never changed)
  • It's never worked before and we're the first ones to try it.

The second option of specifying multiple query ids in the config is still possible and I've done it before, just need to integrate it back in to the current version.

Config now accepts multiple query ids and merges the results of each, provided they have the same schema. Will likely put this in to a v3.0.5 along with password synchronization and any other changes we might make.