HPRM Trim associations connector failing to import

Hi Hayden,

The timeout is handled by the underlying connection, which means a response isn't being received inside the configured timeframe. This could be due to the system not being able to process the request in a timely manner, or a misconfigured connection. Given other connectors are working fine and the agent test is fine, I suspect the application just isn't handling the size of the request. 

Have you tried increasing the agent timeout, or adding an API filter to see if you can query a single record and determine if a response is received? See Filtering Connectors with an API Query / UNIFYBroker knowledge / UNIFY Solutions for more information on the filtering.

In the meantime I'll investigate the creation configuration issue you've outlined.

Thanks Matt,

I've attempted to increase the timeout to 10 minutes on the agent, however the connector seems to failing around the 1 minute mark or sooner. I have also tried decreasing the collection size on the connector to 50 records hoping that might improve things too, though it still seems to fail around the same point.

Hi Hayden,

Have you had a chance to try with the API filter? I've had a quick look, and both the timeout and the page size are passed through to the outgoing request. However there may still be too many records for the initial page to return a response. The actual request being made is in the control of the HPRM SDK, so I can't easily check how it's handling the timeout. Are you able to provide a screenshot of the agent configuration with the timeout configured?

In regards to your configuration issue, is this something you can reliably replicate? If so, it'd be good to jump on a screen sharing session or something - as I ran some testing and was unable to reproduce the problem. 

For further investigations, it'd be great to share the log file - particularly with the higher timeout. You mention it failed around the 1 minute mark, which is twice as long as the screenshot above - I'd be curious to know if it failed with the same error.

Hi Matt,

I'll try with a few different filters today and see how things go. There was an old filter remaining in the configuration so potentially this was causing the error, but yet to confirm. For reference though here is the below configured timeout:

For the configuration issue I've been able to replicate the issue many times, simply by selecting the following connector from the list creates the unexpected configuration.

Happy to jump in a screen share session to demonstrate this one if needed.

I'll try produce a few more errors for the logs as the connector has been turned off an get them to you, depending on how the filter testing goes today. Thanks

Thanks Hayden. Does the configuration issue replicate in a lower environment? And can you confirm that the installed version is 5.3.0 RTM? There was a newer version of the connector released (5.3.1 RTM) 5 months after 5.3.0, which may have the issue fixed. If the customer is truly on 5.3.0, can you try the update to 5.3.1 and see if the issue persists?

Yes I can replicate the configuration issue in test environment, and can confirm the version for the connector is 5.3.0 RTM in all environments.

What is interesting is the manual change to the association connector configuration does actually seem to import without timeout with the same connector filter in the test environment.

So probably an API issue im guessing for the timeout errors?

How much data gets returned in the test environment? It's likely that the filter being run in production is too large to get data returned in a time that the SDK is expecting. Strange the timeout isn't being respected, we can look into that a bit more but might be limited on solutions as we don't have an environment for ourselves to test against.

Sure. The import process for associations connector involves get all the relevant locations, then making a separate request for each one to get its associations. What I noticed is that all the association requests, regardless of how many locations, were being done in parallel. Limitations on threads and connections available to Broker would prevent all of the association requests from actually being run in parallel, but I suspect enough still were to bog down/overload CM, or at least something between Broker and CM.

The patch I provided limits the max number of parallel association requests to 10. This number is hard coded for now; it can be made configuration later on, if this approach helps.

Sorry for the delay in testing/implementing the patch.

Though the good news is I can now confirm the patch fixed the issues we were seeing in production.

Thanks for your help!